Drum machine progress : From prototype to version 2

I’ve not posted in a long time so here’s a quick update on the progress of my drum machine. It’s come a fair way from the initial prototype documented in this post back in July 2012.

A sneak look at version 2 with a new 32bit PIC and a new larger LCD

My initial prototype was based on a fairly common PIC available in DIP format, the PIC24FJ64GA102 which has 64kb of flash and 8kb of RAM.  As I started to build up the firmware I quickly found myself running out of space in the program flash memory for storing the audio samples so I moved up to another PIC24, the PIC24HJ128GP502. This PIC has twice the flash (128kb) which should be plenty for storing some decent quality audio samples. It’s one of Microchip’s high-performance line and runs slightly faster at 40Mhz over the 32Mhz of the PIC24FJ64GA102. This is useful as it allows for a higher frequency PWM period which is therefore easier to filter out with a simple RC filter.

Remember this? It’s all getting a little bit shaky. If you press too hard the board flexes and the PIC resets…

My proto-board prototype was getting quite flaky after lots of use so to move things along I drew up a “proper” layout in Eagle CAD. To give the board a nice finish I used one of Dangerous Prototypes Sick of Beige templates as the footprint. These are a handy starting point for a layout and come complete with corner mounting holes and nice rounded corners.  I used the DP10080 template as it’s the largest that fits into the size limits of the free version of Eagle and also within the 100x100mm board size at Seeedstudio.

I wanted to keep the board fairly easy to assemble by hand and use components that are reasonably easy to get hold of. I also wanted to limit myself to using a chips that are also available in DIP format, the same as my prototype. The idea being that if required the board could be re-made as a through-the-hole layout instead of surface mount. So that meant sticking with hand solderable surface mount components, 805s for passives and a SOIC for the PIC.  The trickiest part was the MAX6957. The 20 port version of this chip is available only as a DIP or as a fine pitch SSOP. It’s still doable, but a bit of a pain as you will see.

The free version of Eagle has a board size limit of 100x80mm and I needed every millimeter to fit everything in and still have a layout that was reasonably ergonomic. I switched from one row of 16 to two rows of 8 step buttons which helped a lot.

I wish Eagle would increase their free board size to 100x100mm to match the sizes that most cheap board houses offer. It seems such a waste to not be able to use that extra 20mm.

Once I was happy with the layout I sent them off for manufacturing at Seeed and had them in my hands just before Christmas 2012, the plan being to spend some time over the holidays building up a board and trying to get further on with the firmware.

The PCBs came out really well but I did have a few problems with the layout due to oversights on my part. Silly things such as picking a narrow rather than wide package for the MAX6957 LED driver, selecting the wrong drill size for some of the mounting holes and one trace that was just plain wrong…  But nothing that couldn’t be fixed with the gentle application of pliers and fine wire.

Drum machine version 1 PCBs for designed for PIC24.

If you bend the pins until they are vertical you can fit a wide SSOP package into a skinny footprint.

3mm mounting holes on the LCD but only 2mm holes on the PCB. Luckily there’s enough clearance to drill them out.

I managed to get a version of the firmware working with the PIC24HJ128GP502 but was having real trouble trying to make full use of the 128kb of flash.  PIC24s have to use some tricks to address all that space, it’s not continuous and you have to specifically tell the compiler where to store large datasets and use special techniques to access the data in blocks of 32Kb.  I just couldn’t get my head around it and couldn’t get my code to work with more than a basic drum-kit of audio samples squeezed into a single 32kb block.

Nothing I tried worked and I tried everything I could find including lots of arcane pre-processing pragma things that I really didn’t understand such as declaring all my audio sample data as;
__psv__ signed char __attribute__((space(psv))) kick_1[]  ={...}
Bizzare!

I’m sure there’s a correct way of doing this but for the life of me I couldn’t find it and somewhere along the way Microchip released a DIP version of their new 32bit PICs.

These PIC32MX chips are the same price or cheaper than the PIC24s, they’re mostly pin compatible with similar PIC24 parts and you can program them with the Pickit3. Plus they are available in DIP format for easy prototyping. They also have loads of RAM and loads of program flash that can be accessed directly with no special tricks or messing around.

So. I switched to a PIC32. (Specifically a PIC32mx150f128b).  It has the same 128kb of program flash as the previous PIC24 but has 32Kb of RAM which gives me a lot of headroom for some new ideas. It also runs at 40Mhz which is great, but the main advantage right now is that I have full access to all the Flash and only have to declare the audio sample data as plain old const signed char, easy!

The conversion for the 16bit to 32bit pic was fairly straightforward, at least at first. I had to sweep my code for variables declared as unsigned int which of course are now all 32 rather than 16bit but other than some expected changes to the device config I had the core “hello world” version of my firmware compiling without errors fairly quickly.
However here’s where RTM comes in to play. Once I started to re-introduce the modules that make use of the PICs peripherals (SPI, UART and CCP) I started to run into problems.

I didn’t realise it but the pic32 series have a much more limited version of Peripheral Pin Select than I was used to with the PIC24. The PIC24s are great in this respect. Whilst you are laying out your board you can alter your periperhal connections for easy PCB routing knowing that PPS will allow you to re-map them to where ever they end up. The PIC32s are not so flexible, they do have PPS but each peripheral can only be connected to a small subset of the re-mappable pins and some functions such as SPI clocks are fixed to specific pins.  Not such a big deal if you start out knowing this but quite a pain for me with a circuit board made up for the PIC24!
That required some re-work… More pliers and fine wire.

Blimey, that’s a bit of a mess! You don’t want to see the other side… I really should have read the data-sheet before I assumed I could just drop the PIC32 in a PIC24 hole.

So the v1 turned out to need a fair bit of messing about to get it to work well with the pic32. Added to that I was missing decent test/debugging points which was really starting to drive me crazy every time one of those little test probe hook things popped off just because I looked at it wrong.

So after a bit of careful planning and with the one eye on the PPS section of the data-sheet I arrived at version 2 designed specifically with the PIC32 in mind and with lots of extra test points built in for all the signals that I needed to debug such as the the SPI bus with its MOSI, MISO, CLK and all the chip-select lines.

That’s a full row of test points up there. Just look, one for every device on the SPI bus! Can’t say fairer than that!

Even then I managed to screw it up just a little bit with one pad cutting right through another trace on the bottom of the board.  It was literally the last thing I did on the board before running the script to produce gerbers at 3am one morning. Luckily the offending pad was only for debugging so a quick snip saves the day.

So there you have it. A new board for a new PIC.

Next it’s the firmware but that’s for a different post.