(no subject)

It's the first of May, which means it's exactly six months until NaBloPoMo and so it's the start of the month of photos!

So who's taking part? I know pleaseremove is considering joining in (and no, you can't cheat by searching through your collection - the point is to take it on the day you post it), but is anyone else going to take up the challenge?

Anyway, on with the photo. Today's is just a quick point'n'shoot of the view looking east from my balcony, taken a couple of minutes ago. The sea (for that is tidal) continues round to the right, but the view there is block by a great big lump of machinery.

Mystery Project 2

After a bit of umming and ahhing I've decided what to do for Mystery Project 2. It's going to use similar hardware to Mystery Project 1, but with two major differences in the protocol: this time the Bus Pirate is the master, and the protocol isn't one that the Bus Pirate firmware already supports.

I'll give you a couple of hints about the protocol: it uses a single shared data line with no separate clock, a little like Dallas 1-wire but with a 3.3V power line. It has a data rate of 250kb/s and a clock rate of 1MHz. It's reasonably well-documented and there are several implementations of it for various microcontrollers, but because it's a relatively fast protocol all the ones I've found bit-bang it in assembly. While this works, it's hardly efficient especially when your code has to sample an input pin or toggle an output every 1µs - on a 32MHz PIC that's every sixteen instructions! Needless to say, that's not particularly friendly and leaves little time for doing anything with the data.

Digging through the datasheets, I spotted the first potentially useful feature: Input Capture. This module will monitor a pin and save the value of one of the PIC's internal timers every time the pin changes state. Even better, it stores these values in a 4-level FIFO. This means that I merely have to read two values from the FIFO approximately every 4µs (with quite a lot of jitter tolerated), rather than sample the pin exactly every 1µs. This is much friendlier and I may even be able to write the code for this in C.

The second useful feature I found is the somewhat confusingly-named Output Compare. This does the opposite of Input Capture: whenever the PIC's internal timer reaches a certain value, the state of an output pin is changed. I was looking at this for some time thinking that it still required my code to be able to update the register for this every microsecond, until I had a moment and realised that the protocol I want to implement looks an awful lot like PWM. The Output Compare has a dedicated PWM mode, which buffers the duty cycle register thus allowing me to merely set it some time between each bit. No FIFO unfortunately, but even so my code merely has to update one register every 4µs. Result!