Extrinsic Motivation: BASIC For Bluetooth

There’s a lot more to those fancy radio modules you use with your Arduino projects than meets the eye. Many of them are systems on a chip, complete with their own microcontroller and memory that can control your entire blinking LEDs project. Developing for these radio modules is a bit of a challenge, as the IDEs and compilers cost several thousand dollars. [Tim]’s entry for the Hackaday Prize looks at one of these Bluetooth LE modules – Texas Instrument’s CC2540 and CC2541 – and puts an embedded BASIC interpreter right on the chip.

[Tim]’s inspiration for this project came from looking at a few popular devices using the CC254X chip. Many of these included a microcontroller and the added costs, complexity, and power requirements that come along with an additional chip. This radio module could easily run any code an ATMega could, and adding another chip to a product seemed like a terrible waste, and certainly not in the spirit of open hardware and software.

The alternative is writing an interpreter for the CC254X chip. He’s chosen BASIC, but added a little bit of Arduino language syntax to make it even easier to develop on. Having already run through a few successful tests involving SPI, I2C and 1-wire devices, [Tim] has a basic system working, but [Tim] admits it does need a little rework to make it easier to use.

It’s a great project, and personally astonishing that it didn’t make the quarterfinal selection for The Hackaday Prize. [Tim] is still working on his project, though, in a great example of extrinsic motivation; he doesn’t need a trip to space to convince him to build something cool.

You can check out [Tim]’s two minute concept video below.


SpaceWrencherThis project is an official entry to The Hackaday Prize that sadly didn’t make the quarterfinal selection. It’s still a great project, and worthy of a Hackaday post on its own.

24 thoughts on “Extrinsic Motivation: BASIC For Bluetooth

  1. It has long struck me as odd why nobody has simply ported the arduino environment to these SoICs I have seen one project that measures water levels using ultrasonic. It uses an ultrasonic module that has a µC on it connected to an Arduino that is then connected to a Ti SoIC used as a radio module. The Ti SoIC could do everything itself if there was an Arduino port for it.

    1. Nobody has done jack with these TI chips since the binary blob BLE library only works with a $3000-a-seat IAR toolchain and they’ve been adamant about not porting to a familiar object format.

      It’s a shame too, since the CC debug interface is easy. The protocol is well documented and a Bus Pirate in Raw-wire 2 wire mode can speak to it.

  2. This is a cool project and would have been super awesome 1 year ago, but now the CC254X chips are being phased out, to be replaced by TI with a new ARM core family.

    Also if you want a fully featured, integrated, BLE chip that supports open source development – apart from the Bluetooth stack – the ARM Cortex M0 based Nordic nRF51822 is a much better option. It’s well supported in MBED and GCC and can even already support the full Arduino environment natively when using the RFduino module.

  3. This is a really well documented project, and the creator made the schematics and PCB available. I thought the stop motion video was creative too, almost like Wallace and Gromit. Unfortunately he didn’t show any flashy demos, his idea is practical (rather than whimsical) and the judges do not have the imagination to see what SPI, I2C are capable of without having it slapped in their faces.

  4. I ruled out these TI modules since the compiler is a few thousand dollars.
    There are a couple of modules with interpreters on already, but none of them offer the full features of the chip or BLE.

    The nrf51822 is a much better choice IMO.

    Hopefully TI will make its ARM BLE chips fairly open when it finally gets around to releasing them.

      1. I have researched that one too, I read about bugs and module supply issues which put me off!
        I don’t like the idea of these interpreters anyway, let alone a closed source one!

        1. They’ve come a long way in the last year. Their supply issues were a problem for us a year ago but have since been worked out, and their support is extremely responsive and the firmware has gotten significantly better.

          Of course, if you want to use IAR with the TI stack you’re welcome to use it on these modules and benefit from the FCC approval and ease of assembly. But their closed source interpreter makes life pretty easy, and they had to do it because their whole business model is around having great support for their products, and they were having knockoffs that tried to unseat them.

          1. That’s good to hear.
            I think I’m going to use the Laird BL600. Its an nrf51822 module with all the ticks in the right boxes. Can be programmed as a plain nrf51822 chip (free, royalty free, softdevice BLE stack with the $99 dev kit) or use the build in BASIC interpreter.

      1. The BLE libraries are provided as objects built for IAR, and I think IAR and SDCC runtimes aren’t compatible.

        Ti (unsurprisingly) won’t provide the source or the objects built for SDCC.

  5. 66
    [Tim] is still working on his project, though, in a great example of extrinsic motivation; he doesn’t need a trip to space to convince him to build something cool.
    99

    I don’t think you understand what extrinsic motivation means – if he *was* in the competition, then the competition/prize would act as extrinsic motivation. The fact that he is now no longer in the competition means he is *now* relying on intrinsic motivation.

  6. Cool. I wonder though, why so many projects like this use an interpreter?

    Why not a small virtual machine instead? Compilation could be done externally, reducing firmware and RAM requirements on the target machine. An external compiler could provide better error checking and optimization; possibly even convert at least a subset of multiple languages to VM pseudocode, if desired. And execution would obviously be faster.

    Sure, it’s nice to be able to just dump in a text file from any device and have it run. But having to compile first is hardly an inconvenience; especially now that compilation is often done in cross-platform languages, or even on the Cloud.

    And sure, there are projects using VMs out there, but they all lean towards the heavy side. Rather than a small virtual CPU implementation with a few select extensions for optimization, it’s always Java, Lua, etc. A Forth VM would be nice, and an external compiler would save you from actually having to program in Forth; but the Forth implementations I find are always interpreted on the target device instead.

    So why this apparent gap in the spectrum of possibilities?

      1. COBOL originally ran on pretty low-powered computers, mainframes with 4K or 8K RAM. If you tokenise out the 99.9% of overly-verbose code, there’s not a lot actually to it.

        You might have trouble miniaturising the tape drives, though.

Leave a Reply to GreenaumCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.