Posts Tagged ‘ISRs’

WTPA2 Proto Starting to Pwn

Monday, September 20th, 2010

So the first iteration of WTPA2 has some dumbass mistakes — bus problems during flashing hardware (missing pullups), some switch latch goofiness, and turns out all those RC filters in the encoder datasheet really ARE a good idea. However, once all the traces got cut and the little merce-resistors got in place, the thing works great. The VCO is spot on. More importantly, so is the FLASH MEMORY! The SST flash kinda sucks in that it’s not fancy and requires you to manage erasing-before-writing and demands paying attention to buffering and stuff, but you can totally turn off WTPA2 and turn it back on and keep playing with that perfect burp sound you made.

Logic analyzer bus-sniffing.

Also, equally excitingly, the ISR has gotten A LOT FASTER — this proto recorded and played back just fine at 45kHz. A lot of this had to do with taking some very good suggestions from Olivier over at Mutable Instruments (of the Shruthi-1 fame) who is a great programmer and shamed me out of much laziness in my code.
As if that wasn’t enough, I finally licked the lion’s share of the noise sources that plagued WTPA1. I’d always been really careful about analog signal routing, but I’d been pretty cavalier about ignoring the hell out of some of the “Analog Noise Cancelling Techniques” in the Atmega datasheet. Turns out I traced most of the noise back to on-chip activity which had to do with reading and writing to the SRAM (toggling GPIOs) while the ADC conversion was taking place. I moved some of the accesses around and that NAILED it. Like, totally duh!

Also, re: the picture — I bought one of those Saleae Logic analyzers the moment they started supporting Linux because it seemed like a cool toy. But it’s actually really useful and works great! In addition to actually seeing what’s going on over the bus (as attached here) it’s REALLY handy for timing ISRs. Like, you toggle a pin high when you vector, and then low again when you exit. I always did this with a scope, but the logic analyzer is great because it records a lot of them and you can analyze variation, see what happens between several different calls, use many channels, etc etc.

Anyhoo, WTPA2 had an exciting week. It may take a break for a minute as I have a really busy winter coming up, but still, good time.

WTPA Firmware Rev 3 Released!

Thursday, April 1st, 2010

OK. I finished shoe-horning necessary functions into this beast. Somebody tell me something that needs to change or this beta becomes legit by tomorrow.
There are a whopping 12 bytes left in memory, and the OS has had a lot of fat trimmed.

Here’s beta 4 (final):

And here’s the R3 changelog, so if you don’t know, now you know:

Firmware Version 0x03:
Wed Sep 2 09:37:49 CDT 2009

— Hardcoded explicit bank start address variables into define statements. They are constants in our current system; this will prevent them from being overwritten, save us some RAM and some cycles.
— Sample Start / Window / Endpoint editing, realtime adjustment. Samples with will reverse when the start point is put after the endpoint.
— Separated the “bail” command for FX and loop adjustments in MIDI
— Re-number MIDI CCs
— Added MIDI option to edit samples with wide range or tighter resolution (editing pot is an 8-bit value, MIDI is 7)
— Added “edit mode” which sucks. But allows you to stop holding down three buttons while you edit a sample.
— Removed some un- or underused softclock (timer) and Uart functions — we’re running low on flash memory.
— Divided AudioHandler routines into bank-specific routines for ISR speed BUT
–> this means we are way over memory. So, got rid of intro sequence, debug mode, all sawtooth stuff, removed some timer functions, changed MIDI handling (don’t recognize bytes we don’t use anyway), changed LED blink functions (all blink times the same)
–> Also kilt the random number init code. Changed pinning in multiply-output mode.


WTPA v1.0 Stuffed With Code Like So Much Stove Top

Wednesday, April 15th, 2009

No pretty pictures today. The hex for WTPA is up to >10kB, which is quite possibly the most code I’ve ever crammed onto an 8-bit part.

The feature list is full and then some, and the ISRs are beginning to suffer speed wise. When the sampler is cranking out multitimbral stuff at high rates you can hear the audio bog down, which I guess is ideologically in line with the “crusty first” aesthetic, but it bugs the anal programmer in me.

In the waning hours before Bent this means going through all the pristine, general ISRs and doing what I can to save cycles, avoid divides, replace conditional branches with jump tables, etc etc. This usually means the code gets ugly, at least for me.

Tomorrow (this morning, I guess) the proper board Rev comes in — that means I’ve got to make a new WTPA and take pretty pictures, and write the manual. Lots of stuff to do before Saturday…

Oh, and did I mention the limited edition video-synthesis daughter board I’m making for WTPA? Come see it in New York at Secret Project Robot on the 25th.

WTPA v1.0 Up and Running, And Hosed (a little). Also Dorkbot.

Thursday, April 9th, 2009

Oh Snap! There’s the goofy silkscreen I promised last time. But don’t worry, it gets better :-)

So I’ve done my best with the above Still-Life-With-Nerd collage to try and convey, in a meaningful visual way, all the cool stuff that’s happened with WTPA since last week. One really perceptually-difficult-to-convey-yet-great thing is that I’ve put my proper rent-paying clients on hold for the time being to make room for this project full time. It’s scary, but it feels really good! And as rebellion goes I suppose it beats buying a Camaro.

Outside of that, the BOARDS ARE HERE! Sort of.

The bad news is, I found a copper bug (my fault) pretty much right away. With as many hardware revisions as I’ve done this was really embarrassing. It led to a natural dilemma — it was a small bug that could be easily fixed with an exacto knife and some jumper wires, so should I you pass that fix off to you, the kit builder, or should I pony up for an ENTIRE NEW SET of boards so that they’d be perfect?

I debated, then reordered them. This also allowed me to fix a half a dozen little cosmetic and noise-floor / routing things that I wasn’t happy with anyway. I wasn’t nuts about dropping another grand on boards, but I’d be less happy knowing that the final kits were going out half-assed. You can’t pay too much for pride :-)

Silver Lining: This now allows me to sell bare boards, which a ton of people have asked for. Originally I hadn’t planned to do this, but now I can sell the flawed boards (for cheap) with an errata sheet to those among you who are exceptional broke asses and not mess up the math and parts counts for the complete kits. It’s a small consolation, but it’s better than making them drink coasters.
Cosmetically, the boards are flawless! I got a not-quite-perfect board from PCBCart before this (for another job) and let them hear about it, and they bent over backwards to make this one dead-on.

Taiwan Alpha also came through — the pots (all 2000 of them) showed up from China early and perfect.

Then there was Dorkbot which was a blast. Above you can see me in front of a page of C code (looks like the ISR) apparently casting some kind of spell.

People geeked out, I gave away some free PCBs, I laughed, I cried, it was better than Cats.

Finally, social business done, it was back to the Fortress of Solitude with some espresso and a dream. Two great things have come out of this so far:


WTPA now has a banked sample system! This means that instead of holding a loop, WTPA can hold an arbitrary number of loops (theoretically, anyway) and can do anything it is able to do to any or all of those loops independently and all at the same time.
Practically speaking, I’ve pinned that “arbitrary” number at 2 :-). There was a lot that went into this! A huge portion of the code had to be re-written — basically all the audio and memory handling parts. The audio system now grabs data from the ADC and passes it to however many “virtual samplers” for recording, and then sums together whatever output they have before putting it back onto the DAC. Better still, the different banks can use different clock sources! Meaning that you can be triggering events with midi and controlling pitch arbitrarily one one bank, and twiddling knobs and generally being a caveman on the other, with a totally independent samples.
By far the hardest part though was having to wrap my head around implementing a memory manager (ever think you’d have to write malloc? Me neither) which was quite challenging. To be honest, I copped out a little, and it is because of this that WTPA uses only two banks for now.

All this cool functionality also has a totally new (and much more intuitive, I think) menu system. Finally, I’m in the midst of getting rid of “modality” in WTPA so that there’s no such thing as “MIDI mode” and “Manual Mode”. Anything you can do with WTPA you can always just do, without mucking around in a menu.


I crunched the money numbers! As of today, I know exactly how much all this crap has cost me, and therefore how much these magic beans will cost YOU, dear reader. I’m not spoiling the surprise, but I will say that although I have definitely screwed up some estimates in my time, I was pleasantly surprised with how this one came out. And you should be too.

I’ll keep you all posted on the nerdy revelations better for this last week. Don’t expect total coherence or an Infinite Jest command of grammar, but I got you. Oh, and I think I’m going to LA to talk about WTPA at the end of the month, so if you’re on the West Coast come say hi! More details on that to come.



WTPA v0.95 ISR Speed Characterized, Code Revs, H/W Changes

Thursday, January 8th, 2009

Online in 2k9, my ducks.

So sometimes, contrary to common blogline belief there are times when I’m quite busy even when I’m not posting. This New Year / Holiday period was one of them. There are some big advances on the WTPA front:

First, all circuits and modes are totally functional. The resampling problem I was having had two roots. First (and lesser of the two) the input impedance of the AVR’s A/D converter is actually a lot lower than I ever realized. In the datasheet Atmel recommends that you don’t drive the ADC with anything less than a 10k impedance but I actually found that an input resistance as small as 470 Ohms still
produced a noticeably smaller waveform at the ADC input pin than driving the pin directly from the output of an opamp. This was easy (though annoying) to fix — it requires another op-amp section and a redesign of the summing amp into the resampling ADC input. The only unfortunate thing about this is that it will drive the cost of the final device up for you, dear customer, and this kit is already, as they say in France, tres cher.
Still, I made a decision a long time ago that when I design things for me (as opposed to the toy world) I will always err on the side of badassery rather than cost, because I can. And because everybody wants to be a baller, right?

The other (more significant) problem was a Read-Modify-Write issue in the audio ISR. OMGWTFBBQ, was it hard to find! When is a NOP not just a NOP? When it lets you sync an output port you’ve just written to with its input latch. Weird, weird bugs from that one, to be sure. And fixing bugs in my code is, like, totally free!

In other important news I bothered to scope out the speed of the audio IRQs and compare them to the old WTPA. As I had hoped, there was mondo improvement on that front:

  • WTPA 0.9, Time in IRQ:
    • Recording / Playback: 22-24uS
  • WTPA 0.95, Time in IRQ:
    • Recording: 5.8uS
    • Playback: 7.5uS
    • Resampling/Overdubbing: 9.0uS

This means that we could now sample at 44kHz (CD quality — remember CDs?) without breaking a sweat if we wanted to! Of course, I’m not sure how much good that would do us since the ADC on the AVR is already “not-so-accurate” at the paltry 24kHz I’ve got it set to now. But hey, the headroom is there if you all want to get your overclock on.
Practically this means that the processor now actually has some time to get some work done other than audio, which is good.

So the final hardware related issue in this animal is the jitter generator. The way it was originally designed the jitter generator used a PRBS white noise source to mess up the clock signal, and it worked! Sort of.
It became apparent that when the “jitter” control was at maximum, the knee frequency of the filter on the white noise became the dominant interrupt frequency. In English: The fastest noise waveform actually determined the clock frequency in a totally deterministic sounding way.
Since this frequency was different than the clock frequency, you would hear a “jump” in sample rates when adjusting the jitter. This sucked. Right now I’m trying to get the jitter to mess up clocks of all frequencies equally well without inserting a dominant frequency of its own. Meaning a jittered-up 600Hz clock will still have a frequency of 600Hz, it will simply have a totally random duty cycle. (You know, like peak-to-peak displacement, like Wikipedia says under “Jitter”).
After fiddling around with another analog solution (pictured above) and then with some circuit sketches using AND gates and JK flipflops I realized that the best way to do this (everybody all together now) was IN SOFTWARE. I can’t decide if it’s sad or not that it always seems to be that way. Anyhoo, once I’m done with that it’s time for new boards.
Oh, and my birthday is coming up in a little less than a week. Send me naked pictures, or LOLCATs or something. Xoxoxox.