Nevertheless, today I dived back into the game. Another thing that bugged me was the LED output. I want a 8×8 matrix in tri-color mode (using dual LEDs) and my first idea was to use two synced MAX matrix drivers. Unfortunately, it’s not possible to really sync them, and so the whole thing flickered like hell. Now I’ll go for the traditional route and implement the display using three 595 shift registers. My Arduino based prototype already works quite well, although I am well aware that this will be another challenge when running inside the half/seq code because the refresh routine must be extremely fast. I really need to dig into AVR assembler now.

Well, here’s the code, anyway:

Download audio file (i-left-my-cefi-at-home.mp3)

Here’s what you’re hearing: The drums and the base are coming from soft synths out of the sequencer, the arpeggio-chiptune-style sawtooth magick is done by a rather simple PureData patch I built to test both arpeggiation and polyphonic instruments. The Patch will be on Github shortly. I controlled PureData over the Midi Loopback device (IAC on OS X) and routed the sound back into the sequencer using Jack. I then first recorded the controller changes (Using my dear old friend mr. ozone) into the sequencer and then recorded the PureData output in an audio track. After some subtle adjustments, I bounced the whole thing to disk and used iTunes to adjust the id3 tags.

The experience was okayish with some more nightmare-style elements. The bad thing about doing all this stuff without proper measurement equipment (like a scope) is that you can only hope that nothing goes wrong. So you doublecheck every soldered connection and still, in the end, you miss that one connection that f**ks up the whole setup. What’s worse, you are always living in fear that you totally destroyed one vital component. When I started up avrdude for the first time, nothing happened. When I had successfully flashed the 644 for the first time, I went through quite a few “oh-no” moments:

• When I tried to figure out what was wrong, I somehow created a short circuit which forces the Mac hardware to temporarily disable the USB port. Luckily. no hardware was harmed so far.
• When I thought I had everything fixed, my Mac didn’t recognize the USBasp hardware anymore. Later I found out that the AVR of the USBasp was not sitting tightly enough in the socket.
• When I thought I had everything fixed, the Target (the 644) was responding with Device ID 0×0000 all the time (which is checked by avrdude and makes it bork). After some more or less random diagnosis shots, I found a loose connection on an adapter board I soldered earlier to connect the ISP header on the breadboard. And I thought I had them all checked (both optically and electronically) twice.
• When I thought I had everything fixed, I once more went through the “IC not sitting correctly in the socket” cycle.
• When I thought I had everything fixed, I learned that it’s a good idea to set the “Slow CLK” jumper on the USBasp, because the device runs on it’s own, slower oscillator as long as you don’t set the right fuses, even if the oscillator is connected. I thought that the internal oscillator should be fast enough to keep up with the USBasp, but no cigar.
• And suddenly, everything was working.

So, what’s next? Building a standard 5V power regulation circuit, building a permanent setup for the 644 with headers for ISP and UART (in the hope that the cable I got on ebay will arrive not before long), and then building Midibox DIN clones with the 74HC165 I have lying around and the Resistor networks I got today, so that I can read out some more rotary encoders.

And now I’ll get myself another shot of cranberry fusion. :)

There’s this one, very well defined interface, though, that just comes naturally with a microprocessor: The actual output pins. Now, having to create a hardware test harness for this kind of testing would involve a lot of additional hardware tweaking, building a test system, most certainly involving another microprocessor, instantly creating a very beautiful hen and egg problem.

So that’s why people write simulators. The only problem I see so far: Maybe I’m not looking hard enough but I can’t find a good way to connect to a tool like simulavr and doing the kind of tests I have in mind. It is more thought of as a way to debug your software using gdb or Insight and less of a way to actually to testing in an automated way (But I’ll have to double check on that: Documentation on simulavr is not exactly spectacular…)

So yesterday night I had a very crazy idea: Why not trying to implement the AVR instruction core in ruby. This doesn’t need to run in real-realtime: It only needs to be cycle-precise in a sense that I could say things like “pull pin 5 low, wait 5 cycles, see if the button input did have any effect”. I could imagine doing very low level, almost Unit-Test like things like doing assertions on looking up values in memory, but also very high level things like writing a simple emulation of an LCD display and beeing able to bind that simulation to a few pins and then checking the output result.

I mean, how hard can this be? The instruction set is not that complicated (it is RISC after all), the timing is simple and complex interfaces like i2c, SPI, UARTS, PWM-Outputs etc. could probably be faked away to reduce the complexity of the emulator.

The SRIO handler requires just only 75 uS to fetch the data from 128 digital input pins and to write out data to 128 digital output pins.

What this means is that he’s reading 128bits (from 16 74HC165 shift registers, all connected serially, IIRC) AND writing 128 Bits (into 16 74HC595 shift registers, all connected serially) all in these 75 µs.  That’s a little less than 300 ns per bit. If I read the 165’s datasheet correctly, to safely read a bit out of it, you’ll need about 30 ns. What comes on top is data processing like reading the register, shifting the bits into place, and stuff like that. Plus some setup time after (or before) pulling the latches. This still sounds rather simple but I’d bet it is one heck of a heavily optimized piece of PIC assembler.

Plus it’s a nice little benchmark for my own plans: For reading rotary encoders without using an external interrupt, you’d have to make sure that you read often, and read fast, to be able to do it in an interrupt service routine. That is not an as easy task as I thought: My simple arduino sketch with an ISR written in simple C didn’t quite cut the butter, as it totally jammed the controller. as in “Wait, there’s an interr–Wait, there’s an interr–Wait, there’s an interr–”.

Which brings me to the next problem: I guess I need a real AVR programmer now, so that I can start some non-Arduino stuff. Boy, I am hardcore :)

6 years forward, there’s a few new kids on the block. One of them is the pretty cool DOG-M series by Electronic Assembly, which is not quite cheap, very easy to integrate (because it almost looks like a Glass version of a large IC, so, it has pins), but also has a very cool extra: It has an SPI mode where you only need 4 pins (6 if you count GND and Vcc). When I found those suckers in the catalogue of my favorite electronics supplier, I could not resist and ordered one.

Well, the first display lasted about 2 days. When I tried to remove it from my breadboard, I learned the hard way that the glass housing has it’s drawbacks.

The second display got it’s own small PCB to live on, and is now added to my projects as I see fit.

The next problem (after solving the hardware, uhm, problems) was the software. Interfacing the display was relatively easy. I wrote some utility functions and it was pretty usable. But on second thought, beeing able to use it in the same, easy way as with the arduino LCDLibrary would be much better.

Anyway, while waiting for the LCD display which finally arrived on sunday (well, it arrived on saturday, but we didn’t pick up the notice that it’s been delivered to our neighbour, so I only fetched it on sunday, but I regress…), I implemented my first very crude version of a standalone drum sequencer. (Standalone in the sense that it has it’s own MIDI-output). It has 8 steps and 6 tracks plus Accent (ONLY 8 because I only had about 15 Buttons in Stock, plus it becomes increasingly hard to wire that stuff on a breadboard…so I’ll have to think about making that stuff semi-permanent on a prototyping board).

It works extremely well and although my timing code is super sloppy and unprecise, as it currently uses millis(), it is a quite good glimpse of the things to come. Sketch will be up on github soon.

Lessons learned:

• Reading the 74HC165 Shift register is pretty easy and super fast (I used inline asm to do a few nop’s instead of delay()) and there doesn’t seem to be any bouncing at all, which just might be the buttons I used.
• My first MIDI output code had some problems with the communication suddenly borking and things going haywire (Synth hangin’ up and stuff), this problem didn’t reoccur with the sequencer code
• I’ll have to look up the correct wiring of a MIDI-Out port since the arduino tutorial describes the wiring as “not according to specs”. IIRC, there should be an Optocoupler involved somewhere…
• I have still no good idea on how to implement MIDI-Clock in in the sequencer code. This will have to wait. I also don’t have an exact idea on how to implement exact BPM timing on a cool ppq level.
• I really have to write down all the cool ideas I have for the User Interface and the final sequencer features.
• I guess I will have to use a bigger ATMega later on, ideally one with two UARTS. I don’t really feel like implementing a soft UART.
• SD cards for saving would be super cool. The MIDIBox hacks using an EEPROM feel like a huge anachronism. Plus, saving on an SD card would make for easier debugging AND backup. (I shiver at implementing complex SysEx mechanisms for data transfer…blergh)
• I want to have one of these beasts. touch input would be cool, plus this looks like a simple way of implementing a graphics display with a small processor without using up too much memory and cpu power. Reichelt sells them for about 150 EUR…

I’ll try to spit out images, wiring diagram and arduino code for the drum seq, as it is kind of my really usable piece of hardware.

Git it here or go to the OSCpad page for more information.