Topics

Furlouogh 40 Goes Color - Arduino FFT Display Module #arduino #fft

Dean Souleles
 

The Furlough 40 Goes Color

I got tired of the industrial look of the 4x20 LCD display on my homebrew 40 meter transceiver, the  Furlough 40. So I decided to build a color display for it.  I have gotten quite fond of the Nextion display on my v5 uBitx and have been inspired by some of the work of the guys on the forum.  And no offense to the terrific programmers on the board here I also wanted to write a simple to understand, well documented, 100% reusable module for anyone wanting to learn about Arduino programming and understand how to control and manipulate a color display.  The result is the KK4DAS SSB TFT Display Module.  See the demonstration at the link above and check  out the KK4DAS Blog for more details, including the link to the source code.

Prospective builders take note.  This is the display module only - it is not a complete control sketch - for a complete controller you'll likely need a variety of other modules including an SI-5351 control module and a rotary encoder module.  That said, the SSB TFT  Display module should fit in well with just about any homebrew transceiver project that is looking for a little extra sizzle.

Please check it out and let me know what you think. .

73,
Dean
KK4DAS


Reed N
 

Hi Dean,

I enjoyed reading your blog. Lots of helpful comments in the code! Documentation is definitely something I tend to skimp on for hobby projects, even though I know it's not best practice.

One thing to note about the Arduino IDE - any *.ino files will recompile every time, but *.c and *.cpp files will only recompile when needed. As such, I'd recommend you rename your SSB_TFT_Display.ino to SSB_TFT_Display.cpp for faster dev as your project grows :)


Reed

Dean Souleles
 

Thanks Reed,

Good advice.  I had read that here on the board.  I tried it and got compile errors.  Every call from the .ino to a function in the .cpp throws a " not defined in this scope " error.  Presumably, I need to add function prototypes to the h file. Or is there another way to make those functions visible to the main program?  My cpp is a tad rusty so I will have to figure that out.

Thanks for looking it over. I appreciate it.

Dean




Jack, W8TEE
 

Dean:

Create a project header file and place the function prototypes in there. I have the header file from my CAT project for the QCX xcvr attached so you can see how I organized such a header file. My organization isn't etched in stone, but it's served me well over the years. Then at the top of each source code file, I have this preprocessor directive:

#ifndef BEENHERE
#include "Doc.h"
#endif

In the attached Doc.h header file, it starts out with:

#ifndef BEENHERE
#define BEENHERE
// all the header file stuff...
#endif

with the closing #endif at the bottom of the header file. You can see how the data declarations are in the header file, but all globals are defined in the INO file. Data declarations are NOT the same as data definitions and programmers are horrible about treating them as though they are the same. Declarations create an attribute list for the variable and, in essence, the keyword extern tells the compiler: "This variable is defined in another file, but let me use it in this file as a [...attribute list]". I usually create the header file first, then move all of those data DECLARATIONS to the INO file, and use search-and-replace to remove the keyword extern from the declarations. Doing this means all variables are now defined when the INO file is compiled. A data definition also constructs that variable's attribute list, but also allocates storage for it in memory (i.e., it now has an lvalue). Using the header file as described above allows you to write code using the INO globally-defined variables in all cpp files that read in the header file using the #ifndef directive. It's the linker's responsibility to fill in all the lvalues during the compilation process.

Again...long answer to short question.

Jack, W8TEE


On Friday, June 5, 2020, 8:13:09 AM EDT, Dean Souleles <dsouleles@...> wrote:


Thanks Reed,

Good advice.  I had read that here on the board.  I tried it and got compile errors.  Every call from the .ino to a function in the .cpp throws a " not defined in this scope " error.  Presumably, I need to add function prototypes to the h file. Or is there another way to make those functions visible to the main program?  My cpp is a tad rusty so I will have to figure that out.

Thanks for looking it over. I appreciate it.

Dean





--
Jack, W8TEE

Jack, W8TEE
 

Amen! I ran into a project recently with over 10,000 lines of code in a single ino file. That's just plain stupid. As I've said here before, working on the JackAl project with 19 source files would take over a minute each morning to compile. Subsequent compiles were typically less than 5 seconds. I often work 12 hour days, so if a bug is giving me problems and I compile a file 30 times a day, I save myself a half-hour of thumb-twiddling each day. Over 18 months, that's giving you back a pretty big chunk of time.

Jack, W8TEE

On Friday, June 5, 2020, 1:20:15 AM EDT, Reed N <greenkid336600+groupsio@...> wrote:


Hi Dean,

I enjoyed reading your blog. Lots of helpful comments in the code! Documentation is definitely something I tend to skimp on for hobby projects, even though I know it's not best practice.

One thing to note about the Arduino IDE - any *.ino files will recompile every time, but *.c and *.cpp files will only recompile when needed. As such, I'd recommend you rename your SSB_TFT_Display.ino to SSB_TFT_Display.cpp for faster dev as your project grows :)


Reed

--
Jack, W8TEE

Dean Souleles
 

Thank you Jack - that is great advice from a true code wizard..... I have followed your lead and built the project header file per your example.  Works perfectly.  

I haven't been an active programmer(as in writing software all day long for a living) in over 20 years.  I've been an executive who "used to do stuff".  But prior to that I spent 20 years programming full time.  With 10 years at NASA JPL I was able to try out and use all of the latest technology before it hit the mainstream.  That means I have probably forgotten more programing techniques than many people know. But there was a day when I was pretty good a it!  Your post reminded me that I used to use that technique all the time when work on large C program libraries and later C++.  I was one the first Ada programmers when I was JPL in the 80's - and I loved, loved, that I no longer needed to worry about that kind of thing - since it was built in to the very strong object orientation of the language. (Oh yeah and no more dang pointers that let a simple programming error make a hash of your runtime.)  Many of those ideas made there way in to C++ and other more modern languages, but most of those have the fortunate (and unfortunate) problem of being derivatives of C - good for its time, but why are we still using it nearly 50 years later?   Ada had many other failings, but in many ways it implemented best practices that have been lost along the way.  

Your Doc.h looks suspiciously like the header file for my Furlough 40 build - so it is reassuring that I haven't forgotten as much as I thought.  By coincidence, I also recently included CAT functionality into my F40 build.  I found a terrific library by Pavel, C07WT -  https://github.com/pavelmc/FT957d, which makes adding FT857 style CAT to a rig almost a snap. I later found that folks on this board (Farhan, Ian, et al) had used it also. This is a terrific community.  

One of my goals, as I know is yours, is to demystify this for the many excellent hams who have no software background.  So much of the code that gets passed around the internet is pretty atrocious (your 10,000 lines in a single file is a great example of worst practice).  Often, the code mostly works, but figuring out why it works can be a challenge, and modding or maintaining it nearly impossible.  So a few best practices, information hiding, object orientation, meaningful variable names, liberal use of named constants and your good guidance about managing declarations, definitions and globals could go a long way to improving people's code.

Thanks again and 73,
Dean
KK4DAS



Dean

Jack, W8TEE
 

Thanks Dean...kindred spirits!! Keep us posted...

Jack, W8TEE

On Friday, June 5, 2020, 10:14:13 AM EDT, Dean Souleles <dsouleles@...> wrote:


Thank you Jack - that is great advice from a true code wizard..... I have followed your lead and built the project header file per your example.  Works perfectly.  

I haven't been an active programmer(as in writing software all day long for a living) in over 20 years.  I've been an executive who "used to do stuff".  But prior to that I spent 20 years programming full time.  With 10 years at NASA JPL I was able to try out and use all of the latest technology before it hit the mainstream.  That means I have probably forgotten more programing techniques than many people know. But there was a day when I was pretty good a it!  Your post reminded me that I used to use that technique all the time when work on large C program libraries and later C++.  I was one the first Ada programmers when I was JPL in the 80's - and I loved, loved, that I no longer needed to worry about that kind of thing - since it was built in to the very strong object orientation of the language. (Oh yeah and no more dang pointers that let a simple programming error make a hash of your runtime.)  Many of those ideas made there way in to C++ and other more modern languages, but most of those have the fortunate (and unfortunate) problem of being derivatives of C - good for its time, but why are we still using it nearly 50 years later?   Ada had many other failings, but in many ways it implemented best practices that have been lost along the way.  

Your Doc.h looks suspiciously like the header file for my Furlough 40 build - so it is reassuring that I haven't forgotten as much as I thought.  By coincidence, I also recently included CAT functionality into my F40 build.  I found a terrific library by Pavel, C07WT -  https://github.com/pavelmc/FT957d, which makes adding FT857 style CAT to a rig almost a snap. I later found that folks on this board (Farhan, Ian, et al) had used it also. This is a terrific community.  

One of my goals, as I know is yours, is to demystify this for the many excellent hams who have no software background.  So much of the code that gets passed around the internet is pretty atrocious (your 10,000 lines in a single file is a great example of worst practice).  Often, the code mostly works, but figuring out why it works can be a challenge, and modding or maintaining it nearly impossible.  So a few best practices, information hiding, object orientation, meaningful variable names, liberal use of named constants and your good guidance about managing declarations, definitions and globals could go a long way to improving people's code.

Thanks again and 73,
Dean
KK4DAS



Dean

--
Jack, W8TEE