Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Re: bitx v6 is here
|
Jack, W8TEE
Jerry: I agree that the type specifier should be a capital 'L': ????? ? #define INIT_USB_FREQ? ?(11059200L) and I use them, not for the compiler's benefit, as you're right that the compiler can figure that out. I do it as a form of documentation. Therefore, if I use the constant in a complex expression of mixed data types, the compiler uses the correct data type (e.g., a long, not a long long or an unsigned long) after the parse. (There are tools that let you see the source after the preprocessor pass and it can be helpful there.) Another change I would make on Farhan's new code is to change all of the *.INO files except ubitx_v6.3_code,ino (because it contains setup() and loop() in it) to *.cpp files. If you use a bunch of *.ino files, the compiler must gather all of the files into one "super" ino file before it can compile the code. If you have only one *.ino file, the compiler can perform incremental compiles. The time savings can be substantial. The JackAl code was 11,000+ lines of source code spread over 19 files. The first compile in the morning would take about a minute on a pretty fast machine. Then, since I tend to end up working on just one file most of the day, the compiler can see that the dirty flag is only set on the file I'm editing. Therefore, it only compiles that one file and let's the linker splice the other (previously-compiled) files into the executable. This can cut the compile time by 90%. For me, this could save a half hour each day of unnecessary thumb-twiddling. Making the change involves some work, since it usually means a header file with extern data declarations in it and the actual data defintions in INO file. I did this for Farhan on the V5 code, but he never released it. It probably would have just confused people. Still, if you plan on messing around with the code to any extent, using *.cpp files will end up saving you a lot of time in the long run. Jack, W8TEE
On Saturday, December 14, 2019, 2:34:59 PM EST, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
Farhan wrote >? If your board has 12 mhz, you have to just edit that one line to change the second IF. That would probably be this line in ubitx_v6.3_code.ino: ? ? #define INIT_USB_FREQ? ?(11059200l) Older code has this line instead: ? ? #define INIT_USB_FREQ? ?(11996500l) Note that the final character is a lower case L (for long integer), not a one. This has caused confusion in the past, would be better to change that letter to upper case, here and many instances elsewhere in the code. Better in my opinion is to remove the L entirely, the compiler is perfectly capable of figuring out how many bits are needed.? I'm seeing two routines in ubitx_v6.3_code.ino, One is named setTXFilters(), this one gets used down in setFrequency() The other is named setTXFilters_v5(), has identical code in the function body, does not get used. I believe v5 and v6 have an identical configuration for the filter relays. However v3 and v4 uBitx hardware will want to replace setTXFilters() with the older version of that routine. Code for the ILI9341 display is in v6, the old v3,v4,v5 code using the LiquidCrystal library for the old 2x16 display has been removed. Would be nice if this was if-def'd so code could be compiled for either. So "you have to just edit that one line" applies to changing the IF frequency,? but you have a fair bit more work to do if planning to use v6 code on v3,v4,v5. Jerry, KE7ER On Fri, Dec 13, 2019 at 06:58 PM, Ashhar Farhan wrote: We have left the old traces, connectors etc in exactly the same place. The software is backwards compatible with the previous versions. If your board has 12 mhz, you have to just edit that one line to change the second IF. -- Jack, W8TEE |
to navigate to use esc to dismiss