Little motes here and there

Since the internet of things is all the rage, I wanted to do some learning by doing, and set up an own small network to experiment a little. It seems that there are a lot of technologies to chose from, and that on all layers: Different radio technologies, different processors, different protocols and so on. I settled for now on SWAP as the protocol since it's easy enough, but I'm using the widely available NRF24L01+ chips for the radio layer. The CPUs are a mix of MSP430's, LPC1114's and STM32F0's, running either a bare metal program (MSP430 and STM32F0) or mbed (LPC1114).

It has been a very interesting experience so far, and in good hacker manner, doing things from first principle gives a lot of insights: How to get power consumption to the micro ampere level? How to build small and simple hardware designs? What are good antenna designs? What about quality of service, packet loss, etc? How to visualise data and use it in smart ways?

The biggest problem is however a very common one: What to actually build with all that stuff :)?

A Subjective Classification of MCUs

  • MSP430 (the smaller x2 series): Like a trusted friend or cosy small home. Limited, but things work as expected.
  • ATmega328: Crufty and rusty. Glad there are abstraction layers to hide that.
  • STM32: Shiny weapon of choice (with some rough edges here and there).

Newton Projects in Modern Times

I really like GitHub for easy hosting and version control of software project sources, but it is just not that easy to use for Newton NTK projects. Mark Mason's story of how he open sourced Dashboard is a great read about how he mastered the challenges of resource forks, lost sources, ancient version control systems and so on to get Dashboard onto GitHub. Even more, the stuff under the obsolete files folder is pretty hilarious ;)

tntk avoids these issues by being text based, but this comes at the loss of a graphical UI builder. I'm not too bothered by this, but it appears that the easiest way to go back in time and create Newton apps the way they were intended to be implemented is to get a fast and reliable PPC based Mac, install Classic, and head back to the future ;) - and don't forget to back up frequently!

Bluetooth related developments

Some updates from the Bluetooth side of things for the Newton: I have been able to compile Blunt 2 on Linux using mosrun, the excellent Mac OS enabled 68k emulator by Matthias Melcher. The only pieces missing are packing the compiled binary, and embedding it into a Newton package. This should finally allow to cover any scenario of Newton development without the need of Mac OS Classic.

I have also looked again into suitable Bluetooth modules, and it seems that the HC-05 module, some quite interesting options exist. The module can be purchased for 5-10$, it has an integrated antenna, and uses 3.3V as the power supply - it should be pretty easy to connect to the Newton's internal serial connector. By default, it is configured to act as a Bluetooth slave exposing a serial port profile, which is already quite useful: In this configuration, the Dock protocol can be run over Bluetooth without changes (only the internal serial port needs to be made visible to the Dock app). It won't allow establishing a connection from the Newton to any other device to use e.g. Neo and IC/VC, but for backup, syncing and package installation this would be good enough.

The HC-05 module should be reconfigurable though to use HCI as the Newton-side protocol, and this would make it a great candidate for Blunt. The only challenge is to implement a LPT to SPI converter and use the CSR tools to flip the configuration bit for HCI support.

Battery rebuild complete

Thanks to the awesome (both technically as well from an entertainment perspective) instructions by Frank Gruendel how to rebuild an Apple Newton batterypack, I managed to revive one of my old, flat packs. It took a while, and was at certain points quite frustrating, but definitely worth the effort. Frank is certainly right about the manufacturing tolerances, even with greatest care it seems that I managed to expand the pack in one or the other dimension to the point that the built in mechanism is not strong enough to push out the pack by itself. Thankfully, Frank has that problem also covered, and I can now enjoy 2500mAh of power :)

Power Options for the Newton

Well, options is maybe a bit overstated :) From my very first Newton on, I had been using battery packs which I can recharge with the Newton. But a couple of years back I changed my usage patterns so that I had the Newton pretty much all the time plugged in, and switched to Eneloop batteries, which I charged with a separate charger. Those batteries seem to be slowly dying now, and I'm contemplating changing back to internally chargeable batteries. This would fit my usage patterns probably better anyway, as I use the Newton nowadays mostly for journaling, idea collection and to hold reference data, not that much as an organiser which has to be switched on all the time.

Since my old battery packs are pretty much dead, I already ordered rechargeable batteries with solder tabs. Let's see how the battery pack hacking turns out!

Color coding for code

One project with potential Newton use is to add a simple serial port driver over USB to the Olimexino. This is mostly to understand how such a driver works in general, and if there is a possible way to add something similar to the Newton. There are of course integrated USB to serial chips already available, and solutions for the Newton, but maybe there are some other profiles which could be implemented.

The driver is written in Forth (for quick results). During development, logging is of course a useful feature. But there's a way not to do it, and that is to log in the interrupt handler code :). Maybe some color coding of code which is called in an interrrupt handler would be useful!

Rest in Peace, Hardy Marcia

With great sadness I read that Hardy Marcia, a long time Newton pioneer has passed away on May 13. His software for the Newton was very early on setting examples for functionality and usability, from which I learned a lot. It feels unfair that an obviously very great guy had to leave us early. Farewell, you will be missed.


Another interesting development board is the Olimexino STM32. It is compatible to the LeafLabs Maple, using a Wiring based library and simple IDE (very similar to the Arduino boards). I couldn't resist and had to bootstrap CoreForth on this board as well :)

Granted, this was a bit easier since I have CoreForth already running on another close relative (the STM32-P103, also from Olimex), so it just took a couple of hours to get the basic interpreter and compiler loop running. On the ARM SoCs it really just comes down to initializing the clocks, the GPIOs and the UART - afterwards, it's all native Forth!

Regarding the Arduino Due, I got the interface to the embedded flash controller working, and can now enjoy a very retro block editor with the ability to preserve all work over reboots. It's almost a full blown development system, just an ARM assembler for Forth is missing.

More toys

After changing my job last year, I have gotten much closer to hardware work, which definitely suits me. What started with CoreForth expanded into all sorts of experiments with SoCs and development boards. Initially, it was a bit difficult to settle on one development platform, but now that the Arduino Due is out, I couldn't resist and order one, to see if I can get CoreForth running on it! The chip itself seems very capable, lots of flash and RAM, and the Arduino form factor should make it easy to experiment.

Update: Seems it was easier than I thought, after digging through the data sheet of the SAM3X8E processor on the Due, I have CoreForth up and running. I pushed the changes to a separate branch on github for now, but will merge it to the main branch once I tested this a bit more.