All Things Start Small

For the past days, I've been able to test most of my planned circuit board on a breadboard, along with some very basic rewrites of the libraries.

I'm happy to say that I've encountered no problems with the design or code so far, which is in no small part thanks to Majenko on the Chipkit forums for supplying a very readable overview of the I/O pins of the Max32. Of course, this information was available in the datasheet, but he simply presented it in a way the Digilent people really should have done from the start. Super awesome and did indeed explain why I had some trouble in the past! 

1) Image courtesy of Majenko, hopefully it's alright to post it here. Red/orange buttons with white labels are non-exclusive pins and will conflict with the others if used. Green are alternate names and purple ones are unique. Interrupts, SPI and I2C are shown as well.  

As for code, I've designed both DMD and SD reading to run via interrupts, meaning that while the DMD is receiving data or the SD card transmitting the MCU is free to process other stuff.

For me that means I can handle I/O and solenoids at the same time as a row is being rendered (most likely with a ratio/factor since there's no point in updating switches at 14KHz). It also means I can process SD card data simultaneously as I'm building the render buffer instead of waiting for data to be ready, locking the game loop until done, and then building the frame...

I'm thinking that since the hardware will most likely be rolling a lot of thumbs now, I've upped the artwork to use 16 colors instead of 8. I also did a few tweaks to the Python scripts that generates the artwork and found a lot that could be optimized, leading to some pretty nice results:

2) Top: Old generator.  Bottom: New generator.

The old version didn't really under perform here, but there are way more troublesome images in the library. Like this one:

3) Top: Old generator. Bottom: New generator.

Some videos and images will probably need to be handled separately (i.e with non-default options) but ultimately this means that material that was about to get removed might now be inserted instead.  It all depends on how it looks in the machine of course as previews are good and all, but if it looks like crap in the machine it's got to go. :) 

I haven't hooked up the screen to my breadboard, so I cannot test it for real just yet - but in theory it should run at very acceptable refresh rates since the SD card load only increased 25% (3bit -> 4bit and has been heavily optimized now) along with the fact that the rendering doesn't block the MCU anymore.  

Awesomesauce!