For the 10 or so of you out there coding audio projects using C and the Raspberry Pi Foundation's RP2040 microcontroller, good news: the world has yet another C library for the AD9833 function generator IC.
I'll use the library in upcoming projects, but for now, the RP2040 AD9833 C library can be found on github--get it here.
 |
| Test the library.... |
This was one of the more complicated embedded C coding exercises I've taken on to date.
The library does far more than its predecessor (blog post here--github here--Atmel 328 version).
Progress? I put descriptions of what each function does in the AD9833.h file, and main.c has routines to test the methods using the UART serial protocol (see the last post--here).
 |
| Wiring on the bench for the library tests..... |
I only had one issue while coding, but it was a big time-waster and took a day and a half to figure out.
All the functions for register0 for the AD9833 IC worked, but any time I tried to use anything saved in register 1 I got nothing--like the entire register was smoked.
It turned out I was using SPI mode 0 initially, but the AD9833 needed SPI mode 2 to operate.
Because of this mistake, any SPI MOSI transmission that tried to use a 1 as the MSB didn't work--for AD9833, that one means you are sending data to register 1.
I figured this out (finally!) by comparing a logic trace from an Arduino Uno R3 <--> AD9833 with a sketch running the AD9833 Arduino library that I wrote previously, the Arduino C library is available here.
I then did similar a logic analysis of my RP2040 library wired up in the manner you see above.
When comparing the logic analyses, it was obvious that my PR2040 code was trying to use SPI mode 0.
Why? Dumb bug!
I had an if/then statement error in my previously posted RP2040 SPI library (here). Simple fix once I spotted it.
Lesson learned: use your logic analyzer to debug code issues!!
Early and often!!
UPDATE 10-1-22 I copied the library and examples to a new project and it wouldn't compile! It used to! I was getting multiple definition errors--hello? I was adding #ifndef--etc in the h library files correctly. So that wasn't it.
After some cursing, I made a lucky guess: adding the static keyword before the global array declarations in ad9833.h and uart.h made the error go away.
Best I can guess, some part of the toolchain--maybe GCC?--was recently updated, the old version was correctly inferring which variables were "extern's" vs "static", but the new version couldn't or didn't want to make this inference.
I read that correctly implementing static vs. extern keywords in C is tricky....Good video on static variables in C/C++ is here.
After reading up on these keywords and then watching the video, I was a bit surprised the linker didn't throw errors linking initial versions of the ad9833 library and examples code.
Anyway, I have updated the github reposiotry for the library with these changes. It now compiles again without issue.
As a side note: I also added to github a couple of bin2hex.c functions, as well as a python script that can be used to craft binary to frequency tables, which I figure I will need for future projects.
Next time it's back to hardware. Analog! I'll be hitting my generous sponsor PCBWAY up for more boards soon and post the results, working or not. For example, I have a commuinty Eurorack VCA almost built and ready to post. Coming soon! Until then don't breathe the Sea fumes.
No comments:
Post a Comment