News

Our Life With The Due

In our recent adventures to build a new prototype synthesizer, that supports a multimode VCF, LFO, and also all the goodies from the SuperPiggy experiment, we were on the look-out for a powerful prototyping platform.. We finally chose the Arduino Due. This post describes our recent experiences with the board.

The Arduino Due is the long awaited follow-up of the ever popular Arduino prototyping board. It was released last year to a somewhat chilled audience. It was expensive, at that time a whopping 80 euros, but it featured everything the previous top model had to offer + a processor that is for most tasks 5 to 10 times as fast, a truly huge memory and two real DAC’s. There were differences, though. The main one was the GPIO and PWM voltage. It had dropped from 5 to 3.3 V. This was a drawback in terms of compatibility. And there are more. Most of them we will discuss here in this post. Some of these will be well-known, others not so much.

First off, the IDE that supports the Arduino Due is currently still in Beta. One thing we really noticed was uploads to the board are slow and non-interruptable. That’s about the only thing that’s slow about the Due, though. The thing executes fixed point arithmetic like nothing else. And yes, it also has a decent 32 bit divide instruction 😉

The pins are not only 3.3 volts, but they also cannot source as much current as the old Arduino could. There are even reports of burned out pins, although we have not personally experienced this. Some people report burning out their DACs. In any case, it’s wise to use external amplifiers (a simple transistor may suffice in many cases) to make sure you always have enough power..

A huge convenience of the old Arduino and the AVR microcontroller it hosts, is the fact that it features built-in pull-up resistors. Just set your pin to the INPUT_PULLUP mode and presto, you can hook up a button without any peripheral hardware. On the Due, it’s different. It does have the internal pull-up resistors but they’re as good as useless. Instead of 10 kOhm, we’re now talking about 100-150 kOhm. This means a huge amount of voltage will be divided and there’s a good chance only with minimal interference, that a 0 is read instead of a 1. There are remedies against this: shielding, modifying your read-out functions (f.e. only if it’s 50 times 0 in a row, then it’s a real 0..). But in a prototyping environment shielding is a hindrance, and modified read-outs might still be error-prone. Long story short, get out those 10 kOhm resistors 😉

Another thing is the PWM pins. There are 12 of these, and all of them support 12 bit PWM instead of just the old 8 bit. Also, you can clock these pins pretty high. The Arduino Uno maxed out at about 62 kHz. The Due can do about 300 kHz @ 8 bit resolution. To change this frequency, you need to hack a header file:
Contents/Resources/Java/hardware/arduino/sam/variants/arduino_due_x/variant.h

PWM pins come in two groups:

  • PWM
  • Timer Counter (TC)

Only pins 6, 7, 8 and 9 are PWM, the rest is TC. PWM can do more like “dead time”, which is required for motor control. For signal processing, however, the TC pins will do fine. Change PWM_FREQUENCY and TC_FREQUENCY to 300000 in that header file and all should be super zappy. Also notice that this DOES NOT break the timing based Arduino calls like delay() or micros(). This is a big advantage over the Uno!

Another oddity we discovered is that GPIO pin 53 is always high for some reason. If any Arduino hackers are reading this.. Do you know why? In any case, with so much GPIO pins, we really didn’t care about that last little piggy that stayed at home 😉

All in all, the Due is a nice piece of work. Probably things will become better when the final IDE is released, but on the hardware front you do need to watch out for the occasional caveat.

The Due is now available for 40 euros and a Chinese clone is about 20, if you can handle the long shipping time..

Firmware again, MIDI again

The Piggy’s firmware was updated to version 1.2. Download. It now features Decay time and Sustain level setting via MIDI. For the rest the ADSR quality checking has been improved with additional unit testing.

But speaking of MIDI.. one of the trickier parts in the firmware.. We did our own Software UART for the MIDI implementation. It just was the right thing to do. MIDI over USB was possible, but required fooling around with special drivers on every platform (Mac, Linux and Windows), and quite possibly also depending on the OS version. An unmanageable software thundercloud seemed to loom over our heads. So, the answer would have to reside with the Arduino itself. The Arduino’s hardware UART was already used by USB, and so the idea for a software MIDI UART was born.

The implementation wasn’t straightforward. And that’s typically the case where high speed interrupts (max 31,250 interrupts per second!) are involved. We chose to measure the time passed between rising and falling edges. Divide by 32 usec and you have the number of elapsed bits. For this to work, interrupt code has to be -fast-. And interrupt code is notoriously hard to debug. For that reason the interrupt only encodes runs: {bit-value, nr-of-bits}, {bit-value, nr-of-bits}, etc, etc. That’s the low-level layer. A layer on top of that, which is more complex, decodes the runs, which then gives us the real bits as they were communicated. Another layer on top of that strips away the start/stop bits and reverses bit order (crazy UART stuff). This is a very tidy way of doing things, and you wouldn’t expect it to work at such high interrupt frequencies, and with so little RAM (2k).

Software UART layers:

  1. interrupt: checking the time between signal edges and encoding runs
  2. decoding runs: we now have the bits as they were sent
  3. decoding bytes: strip off start/stop bits and reverse bit order to get the byte values

In the end, the communication took only a few percent CPU and manages to read all MIDI data correctly. It took a good couple of days, but it was worth it.

Recently, a friend asked. Hey.. software UART? Doesn’t that already exist? The blunder of dozens of wasted hours immediately crossed our minds. Checking what was already done on the Arduino:
NewSoftSerial library

This is actually already a follow-up of an original, which was said to make timers unstable and so forth. But still, we quote: “NewSoftSerial requires nearly 100% CPU time while transmitting or receiving data.”.

Ok, the stubborn folks at Tasty Chips apparently didn’t do too bad then.

With all respect towards the developers at Teensy, of course. They were brave enough to make a full-fledged UART including writing, not just reading. But for the Piggy, a dedicated, newly developed software UART was the best choice. 😉

Arduino performance

In the recent days we’ve been working on getting the Piggy’s firmware optimized to make squeeze out every last drop of performance and create even better sounds. Part of the optimization is to get the modulation frequency as high as possible, so that also at high pitch, fat FM sounds are possible.

The Piggy is part analogue (VCA, VCO, filter), but also has digital components. It has, for instance, a second digital oscillator (inside the Arduino) which is used for frequency modulation. The modulation oscillator has to follow the pitch of the analogue VCO, which can get quite high. A few kiloherz is nothing special.

In order for the frequency to be high, the code needs to run quickly. Typically, we want everything to be done in 300 microseconds, and then a new cycle can begin. But doing this proves a little harder than first thought. The Piggy uses the Arduino’s micro controller, the Atmel AVR. This baby runs at 16 MHz and has the potential to run instructions in a single clock cycle, so only 62.5 nanoseconds! This should be a walk in the park then, right? I mean, we’re only talking about a single oscillator and one envelope?

Well, it would be that easy, if it weren’t for the fact that the AVR is 8 bit. This means numbers (16, or 32 bit, which are typically needed for precision applications) need to be handled in multiple steps. For instance, a multiplication of two 16 bit numbers is actually 4 8-bit multiplies. Think A x B = (a + c) x (b + d) = ab + cd + cb + cd. That means 4 terms. for 32 bit numbers this is actually 16 terms, and all of those need to be added too. So, watch out with bigger numbers and multiplies. They can take a couple of microseconds in the worst case.

But even worse, the AVR, in the tradition of all 8 bit processors, does not have a divide instruction. Instead, it’s typically done by a software long division routine. It turns out a full 32 bit divide takes no less than 50 microseconds (!!). We measured this using GPIO on the oscilloscope and using a special benchmark program (run division 10000 times and print the elapsed time). This is completely deadly to the performance. In such cases the following optimizations may be in order:

  • Resort to shifts.. use powers of two (2,4,8,16..) and the compiler will replace the div routine by a simple shift. This almost completely frees up the 50 microseconds.
  • In case you cannot use a power of two, then you can perhaps pre-calculate the inverse and multiply with this at run-time. This will be 10 times faster or more.
  • Avoid division altogether. Sometimes there are smart algorithms for this (for instance the Bresenham line algorithm).

In case of designing a synthesizer it’s important to understand that division is typically required for envelopes. The rest is primarily linear signal processing, with perhaps a non-linear look-up table based operation here and there.. This can be solved with cheap operations. Envelope data does not need to be computed for every sample, it can be done at something like 500 or 1000 Hz.

So, you can put envelope processing in a background task, and let modulation run in the foreground. But that’s something for another post 😉

Superpiggy prototype

Just assembled and tested the follow-up of the Piggy. It’s the … yes, very obvious name here … “Super piggy”, or Super Arduino Piggyback Synthesizer.

Like previously announced it features an enhanced VCO, which can also do rectangle wave with variable duty cycle and 4 additional potmeters for hands-on ADSR control. The result is a bit “chiptune” like but with the low-pass resonant filter, of course.

Buttons and LEDs are used to select and display VCO mode, and loopable ADSR. See the screenshots below. Yes, there’s our logo on the PCB, finally 😉

IMG_8926

IMG_8925

IMG_8921

New firmware / New synth design

Yet again another firmware version: the mighty 1.1.2. This one kicks the bugs out:

  • Pitch wheel doesn’t interfere with note on/off commands anymore.
  • Release time doesn’t get lost in space anymore.
  • Unit tests are added and expanded to safeguard the quality of all the state machines in the code: MIDI decoding, envelope processing, etc.

Bigger news: the direct follow-up of the piggy is already in the making. The code name is Super Piggy, remember it.

Features:

  • Next to the SAW oscillator it will get a PWM mode, with adjustable pulse width!
  • No less than four additional pots (pot lovers, rejoice!) for ADSR or LFO envelope.
  • Oscillator mode and ADSR/LFO controls are switchable by pushbutton and indicated by leds

The layout:
superpiggy_board

PCB’s are expected to be on their way from China to Tasty Chips headquarters in a week or two (planned to be earlier, but Chinese New Year tends to get in the way ;)) Stay tuned!

Scroll to top

Now shipping pre-orders. Dismiss