Last Thursday I was working on the project, trying to get the Bluetooth serial link working. I was having a lot of trouble… it just didn’t make sense; I could get something transmitted, albeit garbage, only if I choose a baud rate much lower than it should have been. Then of course later – after hours of fruitless effort – I was chatting to Rob online and he mentioned that the clock might not be properly configured. Sure enough, he’d left it on the default setting, the 8MHz internal oscillator with 1/8th divider. No wonder I couldn’t get anything to work via serial, given the clock rate was a sixteenth of what I was expecting. I should have thought about it earlier; I was starting to figure in that direction, but all too slowly…
Of course, when I went to change the clock, I messed it up. There’s half a dozen different options, with many suboptions of those. “External clock” was what we wanted, so I choose that. Whoops. The problem with electronic engineers is that they often say what they mean, not mean what they say. Obviously “external clock” is very generic, and is perfectly accurate. Unfortunately, in this case when they say “external clock” what they really mean to say is “external, single-pin input, digital clock with 2% tolerance”. Whoops. We’re using a crystal oscillator, so the correct setting is full-swing oscillator.
And of course the programming interface is retarded and doesn’t provide self-clocking, so once you’ve miss-configured the clock you can’t do anything, short of pulling apart the circuit and building the clock it’s expecting. Which is what Rob did the next day when I went round to his place to work on it. It took quite some time to get it working… even though the CRO said the signal was good when we simply provided one on one side of the crystal, the AVR disagreed. Only when the crystal was removed did it work, and even then only after a bit of tweaking. And then when we did set it to the correct thing, and solder the crystal back in, it didn’t want to work… long story short, the programming speed selected (~600Hz) was too slow, apparently… cranking it up into the kHz yielded correct results. Bizarre.
After that, we could actually get onto the work that was meant to be done the previous day – getting the Bluetooth connection working. Given the correct clock rate for the AVR, success was quick. Albeit fleeting… for some reason the Bluetooth module kept locking up. The test driver for it just wrote a static string to it in an endless loop. No matter what baud rate we used, it sooner or later locked up. The whole process was made all the more complicated by the fact that the only way to configure the Bluetooth module is by connecting to it via Zterm on my computer and entering the appropriate AT commands. I’ve now got those down pat, but it’s very frustrating trying to race the stupid module to reconfigure it before it locks up.
I’m still not sure what the stupid thing’s problem is… I suspect it’s a buffer overflow. There is a warning in the reference material somewhere about that; overflowing the internal data buffer will render the module unusable until it’s reset, which we can only do by hand by doing a full power-cycle. And even then it sometimes comes back up locked up, or otherwise acting strangely. But it certainly seems the most likely hypothesis; if we put in a significant delay, so that we’re only sending at hundreds of baud, and never more than a few hundred characters at a time, it seems to be reliable.
So the problem now is knowing when the buffer is approaching full… the transmission speed is going to be rather low while we’re in the air, with distance and interference, so buffer overflow certainly will be a problem. There doesn’t seem to be any real method for determining any status info like that… it doesn’t look good for our wireless connection. :(
