RP2040 DMA, a Plug, and a Great YouTube Find

Hello again!

This time I continue to plug away at the RP2040, the processor I started messing around with during "shelter in place."

This time we will look into running DMA embedded C code on this superb microprocessor.  

All hail the RPi RP2040!

 BUT FIRST--A MESSAGE ABOUT MY SPONSOR

I don't do this sort of plug often, really almost never, but the good folks at PCBWAY have been going the extra mile for this blog for a long time now and deserve a bit of extra love.

They approached me a few years ago with a sponsorship deal--something I didn't think much about before I got their "is this real?" email. 

The offer surprised me--this blog was my trail of crumbs to help me remember whatever new self-taught EE skills I stumbled upon....the blog can be extremely geeky and well off the beaten path at times....some of my posts have a ton of views but some not so many...I never considered any sort of sponsorship or monetization.  

But, I said: sure. 

I had used PCBWAY's services before the deal began and had really good interactions with them....PCBWAY offered services at a low price, things I couldn't find elsewhere--for instance,  affordable sheet aluminum fabrication I used for front panels—yes, in a previous life I used aluminum sheet (cut and drilled by PCBWAY) and a thermal decal process for electronics projects:

With a huge amount of PCBway's support my front panels are looking better I think--yes, PCBWAY fabs all the PCBs I use for this blog, as well as the front panels I use in my rack.   

Anything I've ever gotten from PCBWAY has been super solid, of great quality, and they have always gotten the boards to me very quickly. 

Most of all I've been impressed with how friendly their staff is. Super nice, very enthusiastic, very helpful. Funny, they are half a world away, but they feel a lot closer than that.

So yes this is a blatant plug, think banana jacks, but really, for all the help they've given me over the past few years, a washed up rock and roller with a virtual computer and a soldering iron, the good folks at PCBWAY deserve a big shout out. 

They let me post any sort of tech I want, are always upbeat, and encourage me to keep trying new things. So: if you need fab or whatever, please, give them a shot. Tell 'em audiodiwhy sent ya.  

OK on with the post.

DMA

I've done zero work with DMA to date.   

The elevator pitch: data is sent to or from memory to a peripheral without bogging down the processor--in fact, DMA involves little to no processor interaction at all. 

Good general introductions to DMA are here and here--a million and one uses, especially since when processing digital audio we have to move data around fast. 

So, where to start?  

The DMA function calls from the Pico SDK and RPi's embedded C examples were a bit daunting. I needed to look elsewhere.

To this end I googled the stuffing out of "RPi Pico DMA" and its variations.  

This led me to a wonderful series of videos by Cornell lecturer Hunter Adams. He took the content of one of the EE/CS courses he teaches--ECE 4760/5730--and put it on YouTube.

ECE 4760 covers DMA in depth but a whole lot more. Think of it like this: everything you ever wanted to know about RP2040s....as well as other far ranging topics....extremely useful for all kinds of things we do...rolled into a single semester blow-out.

This guy is a terrific, top-notch explainer, he's enthusiastic and encourages his students to get involved and passionate about projects, he's highly entertaining, and his example code is useful and exceptionally well documented. 

Begs the question--back in my day, why the hell didn't Cal have anyone who took teaching undergraduate EE this seriously? Run, don't walk, and check out his videos, starting here.  

Makes me wish I was young again.....

OK....after emailing Mr Adams to get permission to use the his code (he said it would be OK) I got my first DMA bench experiment working, get the embedded C here.  

Here is the wiring I used:

Victory! Sine wave at output, derived from DMA--with no code in processor main() loop. 

Very Nice.

I went through the code, trying to understand what each part of it did. Fortunately Hunter's documentation is extremely thorough so this wasn't too onerous. 

Again, you can get his code and documentation here.  Unasked for advice: Don't just compile the code and upload it--to paraphrase Michael jackson--just Read It! I won't repeat what Mr. Hunter's notes here, rather, present some of the takeaways of my own.

FORMING 16 BIT WORDS 

When using DMA to send data to a SPI peripheral, each 16 bit word has to have control and data good to go. 

This makes sense, since we don't have a microprocessor at our disposal to change out 4 MSB's for each SPI write, or anything else, really.  What you put into memory is what the peripheral is going to get.

The code assumes the DAC uses 4 MSBs for control and 12 LSB for data. I used an MCP4921 which luckily conforms.

The control word I used:

#define DAC_config_chan_A 0b0011000000000000

GPIO PINS

When I first fired up the bench experiment I got--nothing. Hmm. 

I stuck an oscilloscope on the MCP4921, as I suspected SPI wasn't working--it wasn't. The serial input and clock pins showed no signal. That's not SPI, that's ground!

Turns out SCK and MOSI signals were appearing on the wrong (?) pins....

I ended up using this code modification which worked:

#define PIN_MISO 6  /// not used

#define PIN_CS   7   // Pico pin 7

#define PIN_SCK  4   // pico pin 9

#define PIN_MOSI 5   // pico pin 10

 

But I still can't figure out why SPI data showed up on pins 9 and 10--the pin #'s from schematics (RP2040--see page 10; Pico--page 24) didn't tell me why pins 9 and 10 were involved at all. But from looking at things with a 'scope--and hearing a sine wave coming out of the MCP4921's output--they clearly were the correct pins based on the code.

I must have missed something simple!  In future projects I figure this will come up again and I will need to figure this out. 

But for now I will take the fact that the circuit works as a win.

SPI

(You have to understand basics of SPI for this to make sense--a good introduction to the SPI protocol is here).

Another thing I have not seen before is this call from the Pico SDK:

gpio_set_function();

The argument for this function is taken from an enum; for SPI, its value is 1. This appears to make the RP2040 smart about CS pins logic downs and ups.  I didn't know about this.

Here is what I think is going on:

In SPI code I've written to date I've set CS to 1 and 0 as needed, but this function seems to tell RP2040 to do this heavy lifting for us. Exactly why/how it works this way is unclear--does this 1 value set a register somewhere and make CS work with less code?  It must. Well, it works! Cool!  

All of it--interesting! Lots to learn here. Mr. Hunter's code was an excellent start. 

OUTTRO

Up next--I bought some inexpensive CODEC ICs, it would be interesting if I could port this code to move data from memory to a Codec. 

I hope to have that working and written up in a future post.

The DMA functions are still very new to me, but I am happy to get this on the bench and working. 

Onward!

Small MS20 Filter PCB--Eurorack Ready

I am porting some old Frac Format synthesizer modules I built over the past few years....I am out of space in my studio so I want to port them to a slightly smaller Eurorack "skiff" format.  

Euro is still a bit new to me....but is the way of the present and future.  

Some design goals for these ports:

• Small footprint throughout
• Some SMD components but let's use through-hole where we can, so it's easy to build.
• Modular--so you can mix and match PCBs with future projects
• Want a stereo version?  Make two. Want a Quad version? Make four.  
• 100 mil edge connectors and minimal hookup wire

First up is a classic Korg MS20 filter clone based on the classic Rene Schmitz-bits layout. You can find Rene's interpretation about a million places on the Internet--LookMa has cloned this filter, LanterTronics has cloned this filter. I previously cloned this filter. 

Behringer may have cloned the "rene" interpretation of this filter for their K2?--don't know, but, knowing those guys--probably.

MS20 filter clone on the bench--Seems working!

Let's cut the blah blah ginger blah blah and get right to some useless build photos:

A happily bagged boardlette from this blog's sponsor--PCBWAY.  Please help out this blog and check 'em out for your next DIY project.

Op amps are SOIC SMD.  I can solder these without a microscope or magnifying glass....

Board layout.....  

Easy build....Ready to test!

Wiring used to test the design. The dots down the center are male 100mil PCB edge connectors.  

As an homage to Rene I used CA3080 OTA ICs; slightly hard to find but still out there, as of writing this post Jameco and Small Bear have them in stock....the design can be pretty easily ported to 13700 OTAs, an IC that is currently a bit easier to find; if there is interest comment below....but if you have skills with Eagle it would be pretty to grab eagle files off the PCBWAY community site and swap a 13700 into the sch and brd file yourself.

On the bench this small VCF board pretty much tested working first time....I didn't read my own notes on the previous Frac build (doh!) so I repeated a few of the same mistakes, but they were easily fixed. 

I have posted the gerber, PDFs, BOM, eagle files etc. on the PCB on PCBWAY's community page (here)....I hope to wrap this Euro port up in the next few weeks--I am currently finishing up a layout for a stereo pots n jacks board and a Euro formatted 14HP front panel. I will upload all those soon.  

Until then--don't breathe the fumes!

AD9833 Volt/Octave VCO--New Jacks n' Pots Board--I am happy!

 Last post on this VCO, for a while anyway?  Hope!

AD9833/RP2040 VCO--seeeeems WORKING!

I took a month off and it helped! 

This module was driving me nuts. 

I got a fresh start March 1st and got the damn thing working after a single morning. Good news, I think it sounds really good, and all the swearing and head scratching was worth it.

There are plenty of previous posts about everything that went into designing, programming, laying out, and building this post's AD9833/RP2040 VCO, for instance:

• C library for AD9833 Function generator IC for the RP2040 MCU: here.
• AD9833 Triangle out to Ramp/Pulse board: here.
• SEEED buffer board for SEEED XAIO 2040 RP2040 MCU dev board: here.
• SPI library for RP2040: here
• UART for debugging: here
• Toolchain for RP2040/Ubuntu Linux/VMware virtual machine starts here.
• Getting volt-octave working on the bench: here.
• Getting the initial chock-full-o'-errors Euro skiff  build to work (sort of): here.
• And on and on....this VCO was a butt-ton of work!

BUILDING THE VCO

I knew I had to replace the pots n' jacks board from the previous revision--this is the board that sits behind the front panel--it had some dumb mistakes. 

I redesigned the board and sent it off for fabrication to this blog's humble and patient sponsor, PCBWAY....

Happiness is new PCBs from this blog's sponsor, PCBWAY.  Please help this geeky DiWhy blog and check 'em out.

It took me about 15 minutes to get the old pots off the bad board. Was it worth the time? Why not use new ones? I can't say, except  I hate electronic-wasting perfectly good hardware.  

I used a hot air tool to melt the pots' solder joints and get them off the no good board. Patience is needed.

Success--ready to reuse!

Next, let's build the revised pots n jacks board--resistors first:

(I will spare you more useless build photos....JOY!)

....the RP2040/SEEED breakout/buffer board and tri-ramp-pulse PCBs were attached to back of the pots n jacks board:

Front panel mounted--ready to test!

HOW DID IT COME OUT?

To my surprise, after the new "motherboard" was deployed, the VCO sounded and worked--GREAT! 

The pitch jitter was gone--not sure what was causing it before--I thought I had to go to a 14 bit ADC instead of 12 bits, but, no--12 bits seems to be adequate for this application.  

To test, I used the CV output of my MIDI to CV generator (intelligel uMIDI), multed it with a Mutable links and fed the volt per octave signal to the AD9833 VCO in parallel with a trusted analog VCO: a Doepfer A-111-3 Micro Precision VCO / LFO. 

These two were mixed through a CP3 clone mixer and presented directly to Ableton Live.

I wanted see how how they sounded together:

• How well did the AD9833/RP2040 VCO track compared to the Doepfer-smoker 111 for volt/octave tracking?
• Same question for portamento and pitch bend
• How did its FM modulation input sound?
• How "analog" did the AudioDiWHY AD9833 VCO sound in general?

The jury is in.

The AD9833 VCO behaved and sounded--trying to be objective here?--fantastic. 

No drift from this VCO, no overt temp/pitch issues, no oddness when tracking all over the place along side the Doepfer; to my ears both stayed in tune over at least 6 octaves, maybe 7. 

For what I do--definitely good enough.  

Pitch and glide sounded the same for either VCO.

FM modulation for the AD9833 VCO sounded, well, the way you'd expect. Pleasingly warbly, buzzy, ring-moddy, or whatever you want.

Best of all, this digital VCO sounded "analog" to my ears--between some distortion in the triangle to pulse/ramp conversion, and whatever slight errors are caused by the 12 bit A/D, I got a few slight pitch drift issues and a small bit of analog output oddness, the same sort of miniscule errors and cross-tweeze I get from the many analog VCO's I have in my rig.

Overall, this may be the most "analog sounding" digital VCO I've heard to date, but that might be me. Of course, I have not heard endless digital VCO designs, but I've owned FPGA based audio waveform generation offerings from Korg, Roland and whatnot....apologies and due respect to Seiki Kato, but to me, this one sounded more, well, analog.

The AD9833 VCO's pulse width controls were aggressive (?), but sonically pleasing.

The ramp audio output is a bit distorted but had a pleasing and very usable buzzy rampy sound.

In general, for all the consternation, fear and loathing with this build, in the end, I couldn't have been happier.  

I wanted a digital VCO that sounded analog, and think i got that, but more important, I wanted to see if I could bring together the many many hours spent learning embedded C, teaching myself electrical engineering, studying schematics, pondering what makes something I like "sound good" and improving my PCB design skills--the "geeking" (as my psychiatrist fiance calls it) that ramped way up during the pandemic...and ultimately make something challenging that is useful in my Eurorack....Goals met.  

HOW TO BUILD IT?

If you want to play along at home:

You can get the embedded C files, CMAKE files, firmware (including ready-to-use .uf2 file--drag and drop it directly to the RP2040--so, no need to compile or have a working C toolchain) and all other code needed for this project from github, here.  

Then get hardware files--gerbers for the 4 PCBs, BOMs, Eagle CAD files, and a PDF of the board layout, from another github repo here. 

You can also purchase the PCBs through PCB way's community site, here, but get all the gerbers from Github first.

Make sure to read the BOMs which have specific information and tips about components and hardware used.

Hopefully from there it should be like building a kit.

OUTTRO

Improvements? Of course.  

How about a second FM input?  That would be easy to add but would take up space--maybe too much--on the front panel.  For now I'll use a CV mixer. 

The triangle to ramp conversion could be improved to distort less: perhaps use a JFET instead of a 2N7000 mosfet, include additional comparators, other things--but I like the way the one I have now sounds. For now it stays.

A rotary switch to jump between octaves? Sure, and you could use an unused RP2040 ADC for that.  

But I think at least for now, I'm done with this. Time to move on.

I know I complain about the WHY in AudioDIwhy.  But when something works--and works well--hey it's fun. 

That's the idea, right?

AD9833 Audio VCO--Works But not Finished

 I finally have the AD9833-VCO working! Eurorack format!

The fun starts with the AD9833 post here. I wrote a C library for it....then I did this thing with the AD9833, then this thing, then that thing, then something else--oh I have to link all those posts?

Nah, if you want to know the history of the function generator IC used in this VCO, please search this blog for "AD9833". 

This blog is chock a block full of posts about this handy little IC--I have written more about this function generator IC than I should have? Why? 

To cut my teeth on embedded C, SPI, UARTs, and everything else we know and sing. 

WORKS, BUT NOT FINISHED!

This has been a laborious project--as always, still, more work needed....

The 12-bit Seeed ADC buffer board--good for a lot of projects--may not be the right solution here. Best I can tell, 12 bit data gets lost in the A-D noise floor (I think?) and thus the audio output of the VCO is a bit jittery. I want to fix that. I could use a 14 bit ADC and just toss out the 2 LSB's. That might help?

Also the triangle to ramp PCB's ramp output (previous post here) a bit too buzzy sounding. There are ideas on Muff Wiggler about ameliorating that puppy.

For now it works, the VCO doesn't smoke, looks OK, tracks V/octave fine, and damn, I need to get this Rube Goldberg thing off my bench for a bit!

THE SIGNAL FLOW:

I mostly designed and built this VCO to see if I could figure out how to design and build this VCO. Makes sense right?  There are lots of designs out there for audio synthesizer VCOs that are a lot simpler. This isn't one of those.

How it works:

Input is a volt/octave CV, modulation CV, and a frequency and fine control.  

These are mixed, buffered and clamped by the buffer board that incorporates a SEEED XAIO RP2040 dev board (previous post here, the buffer PCB is a PCBWAY community project; PCBWAY sponsors this blog--thanks!--if you want to build one, you can get the gerber here).  

The RP2040 on the SEEED dev board is running embedded C (current code revision of the code is on Github, here).  

It uses a python frequency lookup table array creator--which I turned turned into a .h file for this project (github repo for the Python array frequency creator is here). 

I also used the AD9833 C library I wrote for AD9833 (github here) and debugged using UART (post here). SPI is used to drive an AD9833 (again, lots of posts about this IC, for the VCO I used this cheap breakout board).  

The AD9833 has a 600mV unipolar triangle output--so yet another PCB is used to convert the triangle to ramp and pulse/PWM and buffer the 3 signal outputs....post for this subcircuit is here, modwiggler forum thread about the concept and design of the converter begins here. 

Yes, this is a complex build!  To make it even harder, the build uses no hookup wire and is configured in Eurorack skiff format. That makes it harder to modify and troubleshoot, but, well, who likes things to be easy?

Build Photos:

Board fab was from this blog's sponsor, PCBWAY--please help out this blog and check 'em out.

testing the triangle to ramp converter....it works....

 

OUTTRO

I blew up a SEEED dev board getting this going, one AD9833 BoB was defective, and one SEEED board was DOA. A lot of swearing and head scratching has gone into this project so far.  

This experience has been pure DiWHY--such as, why am I building such a complex VCO when a 3340 based analog equivalent will probably sound better and be a hell of a lot easier to lay out and build?

Because it's there?

DiWHY masochists: show you can take the pain and get yer zips for BOMs, gerbers, PDFs for the schematics and boards, and Eagle CAD files, at Github here. 

If anyone wants to join in with further madness, message me through the MW forum and you can play along. or just grab the files and start modifying.  

In the meantime I am going to take some time off DiWhy--my pychiatrist fiance (amazing she accepted my marriage proposal right?) tells me I need a break. The Good Dr. is always right.

work on other projects for a few weeks or more to regain my DiWHY sanity. 

Then go back to this project. 

For instance, I already have a 14 bit ADC board to replace the 12 bit version used for this project. To skiff-ize the PCB, it uses a lot of tiny tiny SMD parts...should be a real pain in the butt to fabricate. Blah blah ginger blah blah?

....this project tied a lot of previous learning into one module, and getting it to perform better (better sounding ramp, better ADC performance, other improvements) will be good learning as well. I will say it yet again: in the words of immortal Emil Faber: "Knowledge is good". 

 

Update 3-5-23: newer version of this VCO is here--greatly improving the design--in spite of all the whining.

Back to work.

Improved SEEED RP2040 Buffer Board--Mutable Instruments Homage

Hi there, continuing to work on the AD9833 volt/VCO, it's raining endlessly here, I am in a crappy mood, and man I am getting tired of this damn VCO build. 

Ah yes. The RP2040-AD9833 audio VCO. Is it done yet? can we pretend it is?  Update 3-6-23: It's done and came out rel good! more about the "finished" VCO here.

For the ADC and analog buffer portion of the VCO I lifted design basics from Mutable Instruments, who make fantastic open source synth modules:

• MCP6004 low cost quad rail to rail op amp for analog input buffering and clamping
• Unipolar operation for the op amp
• Inverted input from buffer to the MCU (why not--saves parts--fix this in software--gotta love Mutable!). Everycircuit simulation of the idea is here.
• Zeners for most of the voltage regulation--cheap and simple
• a fifth 12-bit inexpensive ADC in addition to 4 provided by the RP2040 MCU (I'm not counting the on board ADC used to measure MCU temperature which isn't needed for the VCO)
• other general improvement and fixes to my initial design stupidity 

I did a post for version 1 of this same idea (here) but it sucked, this version irons out a lot of kinks.

Get this buffer board--a dev board for a dev board?--from my sponsor's PCBWAY's project page, here.

You will need the most excellent and very tiny SEEED XAIO RP2040 development board to make it go.

 

Some improvements to the previous version of this buffer board:

• Jumpers to enable digital or analog (JD0, JD1, JD2 on the schematic) for the the D0,1,2 MCU pins
• Ground pour for bottom PCB copper (imagine that)
• a 10K timmer and 96.7K resistor in series, along with a 33K resistor for the opamp's negative feedback, to get us very close to the necessary 3:1 ratio for incoming voltage to the ADC

Let's build it:

Happiness is a white box o' boards from this blog's trusty sponsor, PCBWAY:

Thanks as always to PCBWAY for sponsoring this blog....please help this blog out and check them out.

Running the default blink sketch the whole thing worked first time and drew 40mA for the positive rail. The current draw from the older version was more like 150mA. Wow!! There must have been a stupid mistake I missed on the last iteration of this board that was making it draw too much current.

Se habla blink? Claro que si.

We are ready to use this board for other projects!

More more MORE pcbs for the AD9933 VCO. Again: Are we done yet?

Onward....

Being a glutton for punishment I laid out pretty much the same board with a 14 bit ADC. Will it work more and better? We will see in the next few posts...but hopefully this damn VCO this board is going into will be done before the next global extinction event.  Update: With the VCO working--the 12 bit ADC seems to cut the mustard. This was actually a bit unexpected? So....for now the 14 bit PCB sits unpopulated, but it will probably see life--assuming it works--in a future project.

Until then: Don't breathe the fumes--always bite off more than you can chew--stay in vegetables--eat your school.  

Happy New Year--Happy New ToolChain--APIO and TinyFPGA-BX

Hard to believe it's already 2023. Time flies when you’re having fun--and flies faster when you're being geeky.  

A year or so ago I bought a nifty dev board--the TinyFPGA-BX. It gets good reviews, is well documented and relatively affordable ($38USD).  

I figured this board would be a good starting point for learning, then using, FPGA's. 

FPGAs are the cool ICs where you can create your own logic "from scratch".  More here. But I know zilch about using these parts for AudioDiWhy. And I see a lot of cool FPGA use cases out there.

Almost zero knowledge is almost never good. Let's start trying to change that....

The TinyFPGA is indeed....tiny....

The New Year started with a long weekend--which means--time to plug in this FPGA development board and install a Toolchain.

Hours of Fun! 

But! The FPGA paradigm--hardware, software, all of it--was brand new for me--I needed guidance. 

YouTube. Of course.  

Shawn Hymel has an excellent (as always) video series about FPGA's, I started there.

Part I summarizes what FPGAs are and what they are commonly used for.

Part II goes over setting up the toolchain for Icestick....a development board very similar to the TinyFPGA-BX. 

Good news….Both Icestick and TinyFPGA-BX are supported by APIO, a popular open source development platform for similar FPGA's. So I set out getting that going....Getting APIO working was the crux of the biscuit:

GO APIO!

I decided to install APIO on Windows, not Ubuntu. I thought it would be easier to find help if I got stuck--Shawn Hymel, as well as many other users online it seemed, used Windows for this toolchain.

Apio relies on Python.....I have Python 3.11 on my Windows system--the latest Python build as of this post.  

I also installed Apio 0.6.7, not the latest Apio build. Shawn recommended using this older version.

For editing Apio project files I used Notepad++ which has syntax highlighting for Verilog--nice. Hint: if you use windows, run, don't walk, and get Notepad++.  A million and one uses!

The proof of concept for the toolchain setup was to get get a blink going on the TinyFPGA but at a frequency faster than what is found in APIO's examples.  Getting the basic blink should be easy--just load up APIO's example. But would it blink faster, Scotty?

TOOLCHAIN BASICS

I followed the setup steps in part II of Mr. Hymel's video--as well as steps found on the Apio website. 

I won't repeat all that here, please watch the video and read the webpage.

I had to make a few changes; not sure if it was because I was not using an Icestick, rather a tinyFPGA; using Python 3.11 and not an older version; using an old version of Apio; or something else.

I was using a different FPGA dev board so I used this to initialize my FPGA board:

apio init --board TinyFPGA-BX

When I tried to build an the example Blinky project, Apio would throw an error I didn't record--something about an issue with Python's click module. 

(Aside: Python click looks totally cool! I didn't know about this module! I am going to use it in future python projects....)

I guessed Python 3.11 was too new for the 0.6.7 version of Apio? Speculation....

Based on this hunch I upgraded to current Apio--cmd as local admin:

apio upgrade 

It still didn't build! 

It threw a different error; Apio told me to add tools-os-cad-suite. Perhaps this tool added functionailty needed for the TinyFPGA-BX. Not sure. Guessing still.

Again, I didn't record what I used to install this add-on, but the error message in Apio told me the exact syntax needed to install the tools-os-cad thingy. 

Fixed? 

Yes! Afterward I could "synthesize" a simple "Blinky" example:

apio build

Progress!  Synthesis seemed to work!

UPLOADING BUILDS 

Once the blinky code was synthesized--like C getting compiled I guessed? getting the dev board to eat code was next up.

Unlike the Icestick, the TinyFPGA-BX did not use an FTDI chip for USB to Serial. Instead it used tinyprog--some of the FPGA's gates do the USB to serial translation, not an external IC. 

This must have been a ton of work for a very skilled FPGA developer....You can see python code used to call it here. Very cool stuff.

But the damn thing still wouldn't eat .v files:

--tinyfpga not found

However running tinyprog -m  from elevated command prompt, yes, the dev board was recognized:

C:\Users\audiodiwhy\Dropbox\FPGA\apio-projects\tinyfpga-bx\BlinkyCL>tinyprog -m

[

  {

    "boardmeta": {

      "name": "TinyFPGA BX",

      "fpga": "ice40lp8k-cm81",

      "hver": "1.0.0",

      "uuid": "482fefbb-c6ce-4e08-aab8-84f55c23f788"

    },

    "bootmeta": {

      "bootloader": "TinyFPGA USB Bootloader",

      "bver": "1.0.1",

      "update": "https://tinyfpga.com/update/tinyfpga-bx",

      "addrmap": {

        "bootloader": "0x000a0-0x28000",

        "userimage": "0x28000-0x50000",

        "userdata": "0x50000-0x100000"

      }

    },

    "port": "COM3"

  }

]

Hello? 

I found a support page here--others with the same issue. 

The workaround:

• run cmd as local administrator
• cd to the directory of the project
• run this instead from elevated cmd prompt: 

tinyprog -c COM3 --program hardware.bin   

COM3 had to match the com port found in the tinyprog -m output.

not sure why but--that worked!

MODIFYING THE .V FILE

In reboot mode the tinyFPGA had an LED-off fading to a LED-on, I wanted to create a more rapidly flashing LED to prove the toolchain worked.

Verilog isn't a programming language, rather a hardware description language.  Either way, I knew zilch about how to do anything useful. 

After making some random changes that made the LED go off (or change states so fast and slow it seemed like nothing was happening) I read a tiny sliver of how Verilog actually works. Imagine that! 

I eventually stole the fix from another web page, here.  

This .v file did the trick:

module Test (

  input CLK,    // 16MHz clock

    output LED,   // User/boot LED next to power LED

    output USBPU  // USB pull-up resistor

);

  // drive USB pull-up resistor to '0' to disable USB

  assign USBPU = 0;

  reg [19:0] counter = 0; // was [24:0]

  always @(posedge CLK) 

    counter <= counter + 1;

  assign LED = counter[19]; // was [19]

endmodule

From my limited understanding, [24:0] in the original Blinky sketch set up a 24 bit timer. I figured 19:0 would be faster since it's a 19 bit timer. It worked--the blinky blinked must faster.

UP AND OUT!

OK that's almost it for this time. 

I have a working toolchain for FPGA! 

I am still waiting for boards to come back from my loving sponsor, PCBWAY, (see, Wendy, I still got the plug in....)  But they aren't due back for another few days.....

So more coding, less fumes? If I have time, I will try to learn a few more things about Verilog.  

Onward! 

Until then, have a Happy Geeky New Year!

2023 Goals...

Reaching the end of the year quickly. My psychiatrist girlfriend and I are going on a much needed vacation. We will sit in the sun and ponder life's true meaning of course, but I  will be thinking about what she calls "my geeking". 

That's what I cover in this blog--my trail of breadcrumbs, as I try to teach myself CS and EE. 

Let's get a head start, what next for 2023?

DSP

....Yes it could happen. A friend from my synth audio group is a DSP professional and has offered to walk me through the basics. He already loaned me "A Digital Signal Processing Primer" by Ken Steiglitz but the math was way above my head--like trying to sight read a Chopin Etude. The sad thing: I was really good at math when I was about 20. Can you (re-) teach an old dog etc.?  

RP2040 Mach II

The RP2040/Pico dev board is a $4USD gift that keeps giving. There are aspects of this useful, fun, and superbly documented MCU/dev board that I haven't touched yet--DMA , its PIO feature set, and the 2040's timers.  I have ideas for projects that will use these components, looking forward to working more with this MCU.

FPGA

There's great FPGA technology coming out of the non-DiWHY (se habla "commercial") sector--UDO Super6 VCO's for instance. The FPGA train is leaving, I want to hop on. 

There are open source tool chains for some FPGAs (APIO)--installing a new tool chain is always fun.

Shawn Hymel, who along with Ben Eater has become a bit of a DIwhy hero to me, has an FPGA video tutorial (here). I will probably start there.

Stomp boxes?

I used to build them but they were never realiable enough to use at a gig. So I gave up on 'em. But they are fun....but I don't gig a lot any longer....but you can put dumb stickers on them. Whatever. Maybe now that I have gotten better at single board fab (skiff type designs in synthesizer modules--apply it to a stomp box--why not?

C to C++

For embedded systems I code almost exclusively in C. C gets the job done, but I find a lot of code online I want to use that's written in C++.  And I have learned from trial and error: if you can't read and understand code you are going to depend on, don't use it. I have dabbled with C++ and don't like it; its poor readability (to me anyway) drives me nuts. But in 2023 I figure it's time to hold my nose and get on with it.

RISC-V

I started learning RISC-V assembly language during Covid-19 house arrest. Really fun (the code, not the disease)--I only got as far as using a simulator. To motorize this pursuit, I picked up a few "Mango MQ-R" dev boards from AliExpress.  Maybe I can do a simple assembly language project with one of them.

Not this one! Just noticed when writing this post, I thought I bought the F113 version (RISC-V) but AliExpress sent me T113 (Arm A7).  Or maybe MangoPi soldered on the wrong processor? We'll know when we smoke the damn thing. Never again right? I always say that, then I buy more unreturnable crap.

???

So much more of course--I want to Euro-rack some of my previous Frac builds (it's time) but that's mostly manual labor.  There are a few projects I started in '21 or '22 that I put aside, I should get back into them.  

Also, I've had ideas for some analog projects, building a string machine, seeing if I can come up with a high fidelity preamp, who knows what else.

 

(??) 

The main thing, I think, is I want to leave myself open to finding rabbit holes and jumping in them. That is what makes this whole thing engaging. 

Happy New Year, fumers!