Thursday 31 July 2014

RF24 and ATtiny, now with added debugging!

Last time's throwaway comment about the potential to use plain-old Serial.print() instead of printf() for debugging RF24 on constrained platforms turned into an itch that had to be scratched. The latest versions of RF24 and RF24Network on the GitHub have a bunch of improvements:

  • RF24Debug (and RF24NetworkDebug) now extend the non-debugging classes,
  • Their constructors take a Print object which defaults to Serial,
  • Their implementations use plain-ol' Print.print() throughout,
  • An ATtiny example, tinypingpair, has been added.
You've seen it all before, but hey!
The upshot of all this is that simply replacing the declaration of RF24 by RF24Debug in your sketch causes all sorts of debugging to be written to the serial port, even on ATtiny!

A nice side-effect is that debugging can be directed at anything which implements the Print interface, for example, anything which extends Adafruit's GFX library, i.e., their LCD screens.

Note that tinypingpair with debugging now takes up 99% of the available space on my ATtiny development board (there would be slightly more room without a bootloader). In spite of that, this work remains useful, helping beginners get started with this nice combination of radio and microcontroller.

Update: I've just verified that debugging works on the Fraunchpad with the new scheme, noting the usual caveat about timeouts.

Tuesday 29 July 2014

RF24 with MSP430 revisited

Well it's taken longer than expected, but today the RF24 and RF24Network libraries are finally ready for use with MSP430. (Get them from GitHub as usual.)

The main improvement is to switch from using the C++-preprocessor to conditionally-compile debugging printf() statements, to explicitly configuring a debugging class into the sketch. For an example of its use, see the revamped pingpair sketch.

The advantage of this is that it allows other approaches to debugging, such as blinking LEDs (on platforms without serial ports) or using plain old Serial.print() on platforms too constrained to support printf(), such as the ATtinys. A secondary advantage is that it makes the mainline code easier to read.
MSP430 (with jumpers set for Hardware UART)

Note that the MSP430 has a fairly restricted serial port itself, at least compared to what we're used to from Arduino. A long description can be found here, but suffice it to say that, as shipped, you have to change jumpers to see anything output by Serial.print() and what you get is limited to 9600 baud. This means that the very act of debugging can cause some of the examples to timeout, so caution is required!

Linux users are rewarded with an additional set of problems to deal with, as documented here. Follow the instructions from the section "Fix a Linux kernel bug..." to rebuild the relevant kernel driver. (Note that there are some existing patches floating around the network which no longer work because this driver has seen some updates recently --- my kernel is version 3.11).

Once the driver was patched, I found that the serial port is best accessed using minicom as root. (Furthermore the first attempt at an upload usually fails for me, although the second and subsequent ones succeed.)

Finally note that a quick smoke test showed these libraries working on the Fraunchpad and Stellarpad too, although serial port issues prevented me seeing any debugging info on these targets.