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.

IMG_3625

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.

IMG_1322

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 PIC24

Drum machine version 1 PCBs for designed for PIC24.

How to fit a wide SSOP package into a skinny footprint.

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. Only 2mm holes on the PCB.

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.

IMG_3494

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.

IMG_3481

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.

About these ads

4 thoughts on “Drum machine progress : From prototype to version 2

  1. First of all I must say that this is a hell of a project for one project and you nailed it! Good job!

    My question is, would it be possible to place your audio samples on the sd card and use something like the VS1053 decoder and instead of placing the samples in the PIC memory to load then in realtime from the SD Card and “play them” through the decoder? Would this be a good solution for, lets say, edrum modules? Wonder if it could play with minimum delay those samples..problably using an eMMC would be better because of higher transfer rates altough sd card read speed is pretty high,

    Best regards!

    • Glad you like the project.
      I have played with the idea of having the samples loaded from the SD card, it’s be a really nice feature, but it runs up against lots of problems in this particular project.

      The main problem is in trying to get decent random read speed out of the SD card whilst also sharing the SPI port with the LCD and LED driver. I’m currently running all access to the SPI port in the main() line of the program. I’d need to run the SD card access using interrupts and DMA in order to get enough speed and this makes life much more difficult especially as the LCD uses a 9-bit format that couldn’t be converted over to DMA (as far as I know.) so you’d need to arbitrate between the SD card runing with DMA and the other devices… Plus it’s not just the speed of the SPI port, but also the overhead of the FAT file-system this adds complexity and also a lot of RAM requirements to keep 16 files open ready for random access.

      I have played with the idea of using a 4mb SPI Dataflash as a sample store (I even have a footprint for it in my current board). The idea being that on boot the program copies the necessary samples from the SD card into the Dataflash, each at known memory location. The advantage being that the program doesn’t need to use FAT or any of that stuff, it just accesses the data directly from a known address for a known length. This sort of works, but again the problem is sharing the same SPI port with the other devices whilst trying to get enough speed out of the thing.
      On paper I’ve played with the idea of a caching scheme that tries to ensure that the next sample for each instrument is always ready in a buffer in the PICs RAM, loading the buffers in the background. Possible, but again much more complex that having the samples in Prog-Flash where they are readily available with no delays.

      You could solve this by using a different PIC, one with more pins, that way you could dedicate an SPI port to just the SD card (or Dataflash). That would give you speed and access it using DMA with no worries about sharing it with other devices.

      That’s beyond where I want to go with the project at the moment. In order to keep this project more DIY-able I purposely chose to limit it to chips that are available in easy to use DIP format. This limits the number of GPIO and peripherals available on the PIC so rules out the idea of a dedicated SPI port for sample access.

      Anyway. It’d be a great feature, but so far not one that I’ve come up with a solution for.

      Cheers.

      Matt

  2. Matt, I’m truly thankful for your answer! I’m not quite (yet) ready for this type of projects, lots of work and study hours are to come!
    Related to polyphony with sounds coming from a sd card and an external codec chip do you believe that a dspic would be able to handle it or should I just simply jump up for something like the parallax microcontroller that is 32bit and multicore or maybe a teensy 3.1?

    And what about the capability to immediately play one or more sounds when we press,let’s say, one or more buttons?

    Sorry to throw off this questions at you.

    Regards,

    João Gonçalves.

    • Hi João,

      No problem, glad to help if I can.

      The answer depends on various things, the quality of the sounds, how many, and what else the MCU has to do at the same time eg. display output on an LCD.

      If you store the audio in a simple format on the SD card then reading it out any playing back is a really simple task that almost any MCU can handle.

      Probably the simplest audio format to use is 8bit PCM mono. You could adjust your sample rate to suit your needs. Higher sample rate sounds better but involves more data transfer. 8khz 8bit is pretty crappy, but can sound ok for spoken word and sound effects. 8bit at 16khz can sound ok for music (not great but ok). You could also use uLaw/aLaw compression to improve the dynamic range of the samples for better quality output.

      If you want to use MP3′s then you do need something more powerfull or a codec chip that can handle playing multiple streams.

      But assuming you keep it simple;

      If you want to polyphony then I guess it depends on how many concurrant sounds you want to play, what quality they are and also what else your application needs to do.

      A PIC32 like I’m using (or something similar) should easily be able to play multiple concurrent 8bit WAVs direct from the SD card when you press a button. (3 or 4, probably more, I’ve not tried it). Put the SD on it’s own SPI port and use a high speed (20Mhz or something)

      Best way to find out is to try it!
      :o)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s