BlueBasic: BASIC for Bluetooth

Okay, the persistent data store/file system just landed. It provides the basics - file open, close, read, truncate, append, write, etc. Currently I'm supporting four simultaneously opened files from a choice of 26 named files (A to Z). Files are organized as up to 255 records, each record being up to 250 bytes long (so, more space than there's FLASH to support).

More wiki pages to write now I suppose.

The first versions of BlueBasic ran the BASIC code out of RAM. This was simple, but undesirable. There's not that much RAM on these things, and using it for code didn't seem like the right thing. On the other hand, keeping the code in FLASH is tricky because the program is edited on device and FLASH isn't very flexible about constantly being changed.

Now, as of v0.5, I've finally added a flash storage system and moved the code into FLASH. This has a number of advantages. First, you now have 8K of memory for BASIC (rather than ~2K on the old RAM based version). Second, what you write always persists; if you reboot the device, or pull the power for a while, the code will still be right where you left it when you get back. The flash storage system manages the details of finding, writing, reading, erasing and compacting space (with all that fun wear leveling stuff).

Anyway, please check it out. There's still improvements here, but it all works. Next up, a proper way to persist data too.

Current thinking of using the LTC3532D-3.3 boost regulator to manage power (see http://download.siliconexpert.com/pdfs/2011/11/19/23/55/16/451/ltc_/manual/3525d33f.pdf). Expensive though. Open to other options still.

So. End of the week and here's where we are. All images on github are now fully OTA upgradable. If you flash one onto a device using the trusty CCDebugger, you can update them using the Console program without having to plug the board in again. Also, I've consolidate various other separate git projects under the common BlueBasic repository and added a few examples to try out.

Next weeks goals - move the BASIC program being run out of RAM and info FLASH (there's more FLASH after all). I'll need to write some FLASH management stuff which should be fun. I also need to add to the documentation (rather ignored this week) and begin the next hardware revision.

First - why does TI called it OAD when the rest of the world calls this OTA? Anyway, I consider OTAs to be a must-have for BlueBasic. First, if I make boards available as cheap as I possible can (a vague goal I have) but you have to run out and buy a $60 Ti CC Debugger to update them; well, that rather ruins the point of them being cheap. Second, it's useful to be able to update devices without having to physically plug-in. I have a few Arduino's around the house and in the yard, and some of them are not easily accessible (buried under the hot tub, embedded in a wall, etc.). Being able to update them remotely would be extremely useful (the Arduino boards from http://lowpowerlab.com let you do this - check his hackaday out here: http://hackaday.io/project/2197-The-Moteino-Framework).

So it's been a busy couple of days working out the OAD stuff from TI. There's a lot of info on the forums and in various docs they publish, but there's a whole ton of gotchas too, especially if you're building a smaller "loader" image which can update the much larger "main" image; which is what I need.

But, it finally works, although with much prodding. After these changes hit git, it's off to improve the console tooling to make this all magical.

This little wiring mess is the current hardware test hardness (you can see the BlueBasic board hidden at the back there). It contains a SPI device, an I2C device, and a 1-wire device. After getting all the basic protocols working, I think I need to rework the BASIC constructs a little to make it easier to use. Should keep me amused today.

So I now have 3 prototype board assembled (photo below) - 2x CC2541 and 1x CC2540. I can now use these for experimenting and software testing (I need to build some sort of automated test runner ... but more on that another day).

In the meantime I'm struggling with the question of power. The BLE module does best when powered near 2v (due to internal voltage regulation, powering it higher than that is just wasting watts). Realistically, nothing external is going to run that low, and would much prefer 3.3v. So what kind of power supply should I put on the board? If I assume a 3v supply (a coin battery or maybe a couple of AAs) I could boost that to 3.3v but will also have to buck it down to 2v. I don't want to have two power systems :-( Alternatively, I could just run the whole thing at 3.3v (boosted) but that's wasting energy. Another options is to run the BLE module directly from the battery, and just use to boost for external stuff.

At the moment, no ideal solution springs to mind. Still thinking ...

First boards just got assembled. First time I used my new T-962 SMT oven, and it all worked perfectly. Yes ... I'm a little surprised too.

Here's the first assembled board with a CC2541 running the latest BlueBasic build. Not much to look at yet, but still exciting. I plan to add a bunch of random peripherals to this board so I have a standard test device for SPI, I2C and OneWire devices.

Added my current Eagle schematics to a GitHub repository. Very simple stuff at the moment, and still tinkering with the layout. Here's the board schematic:

Declaring BlueBasic v0.3 today. Now have a good WIRE protocol, SPI and I2C support. Time to move to board testing and more docs.