Thoughtophone

I guess the cross platform part of this library is in it's infancy: Even though most of the ports have a class representing the SPI interface, they are all different classes, with different sets of methods. The interface should be a contract between the RF24 code and the hardware. I've forked the original and got a Chibios port working using this approach. I've also added something that implements a Chibios API - abstract sequential streams , which is so I can use some other Chibios utilities I use in the balancing robot. This is a little half baked and inefficient: I really need to use the RF24 interrupt signal, but it seems like a good idea to get it to work at all first. I should probably prove I have GPIO interrupts working in Chibios by porting one of the other examples first. Now I need to figure out how much I want to apply these changes to the other platforms. I'm most interested in the Raspberry Pi, since it's my current bridge hardware, but it'

I couldn't get pynrf24 to talk to RF24 running on an Arduino. I followed the link from pynrf24 to RF24, but actually there's a more active fork of RF24, with some support for plugging in new platforms. So now I've switched to this more active RF24 library . The general idea is to add Chibios support and submit a pull request. The getting started example didn't work until I explicitly set the channel to 0x60, which was a bit irritating - I spent the best part of an afternoon checking I could really get two devices talking to each other, rather than adding the Chibios support I need. The RF24 library supposedly also includes a python wrapper. I haven't managed to get it to talk to the python client as yet, so hopefully the python wrapper will prove convenient. I suppose what I should actually do is take all this into the office and show it will work there, in a noisier environment. There's one argument against that - and that is that so far I haven't b

Having struggled with the esp8266, I've decided the answer is something I have a little more direct control over. My first, and perhaps only target is the balancing robot. I've started off using pynrf24 : $ git clone https://github.com/jpbarraca/pynrf24.git $ cd pynrf24 This is hopefully the shortest path for me: I already have a python program that acts as the bridge between the browser and the balancing robot, so I'll just adapt it to communicate using the nrf24, and run it on Raspberry Pi. On the downside, my app is a twisted app, so I guess I'll have to write a twisted driver. I've connect the SPI pins as you would expect. CS0 is GPIO8 and it's connected to the NRF24 CS. I've connected GPIO24 to NRF24 IRQ. First thing I find is I need this library for SPI, Install it with pip: $ sudo pip install spidev A bit of compilation later, and I am ready to try some stuff: $ python Python 2.7.9 (default, Mar  8 2015, 00:52:26) [GCC 4.9.2] on li

Actually, if you search for nRF24L01+ arduino  you find a large entry in the Arduino playground . A little down the page is something that is not all that Arduino specific (although the examples are Arduino), or nRF24 specific: Radiohead . Sadly it doesn't support CC2500. It does seem like the nRF24 ecosystem is a great deal more vigorous than CC2500. Also, if I have to have a bridge to the PC, I could use a Bluetooth master and slave module - it's not like Linux would be a problem then, and as a bonus, I could still use a mobile phone as a controller. I've got some nRF24 devices on the way, but I also have some Bluetooth modules in older projects. Perhaps one of them supports master mode. I've also discovered a few variants of the nRF24: the nRF24LU1 and nRF24LE1 which include an 8051 micro controller and executable flash, with 4K RAM+USB and 1K RAM respectively. These can be programmed via SPI . I've exported the aforementioned to Github . Although you get a

I took my balancing robot into the office today, plugged a USB wifi dongle into my computer. I connected to the ESP8266 in AP mode. Sadly, it didn't work so well: the connection dropped regularly, about one in 3 packets got dropped, and the buffer overrun problem I previously thought only applied to TCP packets started happening to UDP: the tails of previous packets getting included at the end of new ones. OK - so I've eliminated Bluetooth completely because Linux is too crap at it. I've pretty much ruled out WiFi as too expensive, or too poorly implemented on the embedded side. What's left? Well, I have two CC2500 modules. On the embedded side, the SPI interface is fairly (very?) convenient. On a PC or a phone, not so much, although I could stick one in a box with a micro controller to get something usable for a pc. There's also the  nRF24L01+ which there are also cheap USB adapters for. The breakout boards seem to be available for £1, so it's probably w

I finally got around to tuning the new balancing robot a few days ago. It didn't go very well: I set KP and moved onto KI, but it started simply to fall over. Then I realised the battery was starting to drain: that was the problem. The charge had just leaked out over a week or so. I'd actually anticipated this, and added a little divider network to the motor board, to let me test the battery with an ADC, so I decided to add the required code. The resulting commit is here . There are a lot of choices when doing ADC conversion in the STM32F4: If you want to sample as fast as the device can go, you can collect the data with a callback. You could also trigger conversions periodically, using a general purpose timer. Both of these require hardware resource assignment: Owning the ADC device, and also a general purpose timer in the second case. The STM32F411 only has one ADC, although it's pretty fast and can cycle through 16 channels. It's also a bit quirky though: You c

A few weeks ago, I thought it would be fun to make some fairy wings as a Halloween costume for Sarita. Of course, they needed to glow :). I've finished adding to optical fibre and LEDs to one of the wings. Here it is showing off a cycling rainbow: It uses one of these neopixel strips , which I'm controlling with an Arduino mini. That's so I only need a single 5V supply. I thought about an ESP8266 - some sort of remote control would be neat, but this project has already proved sufficiently complicated. I've coupled the fibres by making an acetal block with 4mm holes to match the spacing of the leds. In this picture it's just held in place with cable ties, but that seems to work OK. The fibres are 2mm side glowing, and there are 2 per LED. I bought 10m which is going to be just enough. Now I just have to make the other wing, and figure out how to make it wearable before next weekend. Not sure I'll manage that, but at least I made this video.

I've mentioned I'm not that impressed by NodeMCU. Part of the problem is the underlying ESP8266 firmware. Why can't I have a simple send frame method and pick my own IP stack? I also can't really be bothered with another tool chain: I have arm-none-eabi already. I also want enough peripherals not to need another micro controller. The EMW3165 is billed by hackaday as an ESP8266 killer . It seems to tick all the boxes above: I already use the STM32F411 it's based on. I've got a couple of modules to play with, most people are using st-link to upload firmware, and the wifi runs on a separate Broadcom chip which you communicate with via SDIO: it can't be that hard to get up and running. There's very little by way of structured documentation though: I want to know the SDIO wire protocol for communicating with the WiFi chip. No luck yet. Actually I think this is pretty much a dead end: You need to accept a Broadcom license to get WICED and there's

My current balance bot sort of works, but it's surprising it does: it's centre of gravity is actually only about 60mm above the motor axis. The whole thing ways 320g. The 6 AAA batteries only weigh 70g, so despite being right at the top, the don't affect the centre of gravity much. 6 AA batteries would weigh about 180g. That would add a 34% to the overall weight, and move the centre of gravity much higher. Seems like a dramatic increase in weight: it would be nice to be a bit more incremental. More AAA batteries isn't really worth considering: they only weight 12g, vs 30g for an AA. 4 AA would deliver much less power/torque, so that's no good. There's no middle ground, in other words. I'm also going to make the whole thing a bit taller: I need more space to add more sensors in any case. Last time I made the frame, I needed an elaborate jig to get it square and it actually didn't work that well. This time, I decided to use some short bits of a

I want to be able to control my balancing robot just from my phone, but the phone can't be a UDP server - so the robot must be. UDP servers in NodeMCU seem to be limited to one client at a time: you create a server, and bind the receive event to get datagrams sent to it. When you call send on the server socket, it sends the data to the last client to send something to the server. If you create a client UDP connection, the server will stop receiving datagrams, and the client won't receive any either. The client will be able to send datagrams though. I guess this is a bug. It took me a great deal of messing around to get to this point, but now I have a little test harness for it, and a fairly generic UDP serial server . I'm pretty sick of NodeMCU by now. Time to figure out how to build my own firmware.

I previously posted about a DRV8835 dual motor driver. In my new balancing robot, I've used a a TB6612FNG instead, basically because the board is a tiny bit bigger, so I can use PCB card guides to hold it. Pololu and Sparkfun both make carrier boards which are nearly identical. If you use the TB6612FNG like an LM293D, then it drive/breaks rather than drive/coasts. For lots of things, this works well: the relation between speed and PWM pulse width is more linear. I'm not sure how it interacts with PID though: the torque applied depends on the speed. When the speed is low, the torque is higher. That tends to happen when the bot is close to upright and balance. That sounds sub-optimal. It turns out that if you just set the PWM pins on the TB6612FNG high, it then behaves just like a DRV8835 - i.e. you can choose between drive/break, and drive/coast. You again need two PWM pins, but these STM32 boards have plenty of timers, each able to drive 4 PWM outputs, so that's fine.

I've built a new balancing robot. Unlike the last one it actually works a bit, which is nice. I've been working on it for quite a while, and neglecting to post about it, which leaves me with the dilemma of what to write about first. One of the most annoying things about the previous development experience was using Bluetooth. Specifically Linux Bluetooth support. The main reason for using a Bluetooth serial module was it's low cost. Now you can pick up a ESP8266 WiFi module for less than £2. Since WiFi is so much better supported than Bluetooth, it seems like a no-brainer. There are quite a few different formats out there, and I've bought a few different ones. At the high end are the NodeMCU boards. These include a usb serial adapter, and require the least fiddling around to get going. I recommend you get one, because what you are going to find immediately is you need to flash whatever you buy with a newer firmware. The flashing tools will just work with one of

There is now an accurate way to do PWM on the Raspberry PI: pi-blaster . I decided, to make things easier than using a micro controller, to use a Raspberry Pi to control my aquarium light. I've tried using a few other PWM libraries, but pi-blaster is the first one not to flicker. Here's the little python script I wrote. I should try submitting a pull request to change pi-blaster to use sockets, and conform to the LSM by putting it's socket in /var/run or similar, but the pipe interface is a good idea compared to having to have a binding to each scripting language.

I've got a reasonably small date-time library working in Picobit. I started off with SRFI-19 , but found it's reference implementation used floating point numbers for Julian day, and used Julian day to calculate conversions between UTC and the Gregorian calendar. Trying to figure out if I could change this to integer arithmetic didn't seem that easy. Instead, I found a ground up integer method in Joda-time, and used that instead. It's calculation is incredibly easy to understand, once you get over the fact that it's pulled to pieces into several subclasses and helpers, to the extent that you wonder why everyone doesn't do it the same way. I got to simplify it even more, because Picobit gives you more latitude with arbitrary precision. The result is fairly like SRFI-19 but ignores leap seconds, and therefore the distinction between TAI and UTC , replacing them with time-real. This makes all the more sense given that most microcontroller projects will probably

If I'd been paying attention, I'd have noticed that Picobit's memory access primitives emulate big-endian byte ordering. This sort of makes sense in the case of constants and the byte code: It makes picobit's images portable. I'm not actually interested in this, however: I build binaries for specific platforms. Even if I was, it's preferable not to do this for RAM. After a bit of hacking and debugging I've made RAM access native endian. Actually I've only tested it on little endian systems: X64 and ARM in little endian mode (which is the default for Chibios). I have a very limited performance test: 11 queens. The difference this makes varies depending on the optimisation settings. Picobit suggests -Os. I've also tried -O2. These are the results for amd64: -O2 -Os Size Time Size Time Native-endian 53040 3.119 49864 6.340 Big-endian 56848 3.733 50192 7.908

A college pointed out Picolisp  because of my work on Picobit. The paper  mentions Picobit and discounts it because a foreign function interface would be difficult to implement. This isn't exactly true: I've been linking Picobit programs into ARM executables, and that certainly means I could link actual function addresses should I want to: I could generate C code containing a vector of the foreign function references, and link this into the resulting program. Once I have done this, I can define a foreign function primitive that uses the vector to call them. This will certainly be some work, but not as much work as writing Picolisp! That isn't what I'm currently planning to do, however. I plan to copy Unix and define a limited set of operations for IO, define device numbers and route these calls to an appropriate driver according to the device number. One of the calls will be ioctl, which will allow arbitrary scheme data structures. I could use python's approac

I've got multiple return values and apply working in Picobit, and that means Picobit can compile SRFI-1. This post to remind myself what I am trying to achieve, because this has been a long detour. I'm actually trying to get the time library in SRFI-19 working. It needs SRFI-6: string ports, SRFI-8: receive and by extension multiple values support. This is nothing to do with SRFI-1, other than it seemed like a good candidate for testing multiple values. My multiple values work like this: I created a 'values' type, which is just a wrapper around a list. (values ... ) returns one of these. Two primitives: (#%apply-call proc values) and (#%proc-jump proc values) apply a proc to values (jump is for tail calls). To get the two different primitives to be called in the right places, I added a new AST node type specifically for apply, and then matched it in the compilation phase. Having looked into SRFI-6, I now realise I don't have R5RS io primitives. Some of the nam

I now have a scheme program that sets and gets the time from a TinyRTC connected to the STM32F4 discovery board. It's actually fairly neat. See examples/stm32f4-discovery-flash.scm  and tinyrtc.scm . I couldn't get it to work for ages, because I'd forgotten I needed to configure the pins in open drain mode, as well as configuring I2C mode. I'll have to go back and hack on the generated use-pin code so it does that automatically. That's pretty exciting though. Using map to convert lists from binary to BCD is a neat demonstration of the relevance of scheme, as is the fact that I'll eventually be able to automate pin configuration with some simple rules.

I've finally got source code references for Picobit byte code. It's proved enormously frustrating. My first approach attached the original syntax references to the structs used in the AST. After I'd done all this, I found only 2/3 of the tests passed. I made what seemed like a reasonable assumption: the front end uses lots of incomplete pattern matching on the structs. I'd tried to update all the patterns, but perhaps I missed some. I went back and replaced the front end approach with a dictionary from AST nodes to syntax. The result was exactly the same! This was worthwhile though: the pretty printing of the AST now matches in the original and new versions, so I can capture that and prove the front and is unchanged. I have a script which captures the AST and the assembler output for each test file. Now I can just run meld with the two output directories as arguments... There's one instruction I'm just not emitting: goto-if-false. Turns out that's ju

One of the error prone parts of working with the various STM32 micro controllers is that you must configure a peripheral, and in addition, configure specific pins to express that peripheral. This isn't exactly an end product quality issue: it's just a time waster when playing with an evaluation board. If you get it wrong, it doesn't complain: it just doesn't work. Examples often don't explain the relationship between pin settings and peripherals, so you end up endlessly returning to the datasheet, and a table called the alternate function mapping. This doesn't seem to be published in a machine readable format. I thought I would have a quick go at extracting it. I tried tabula extractor , but the results weren't that good. Looking a little further down the list I found pdf-table-extract which the author wrote to extract data from ST Micro datasheets! I haven't tried it yet.

I added some I2C primitives, and to do this I wrote a few helpers to access vectors from Chibios. Then I though: I need a simple way to test this, so I added support for Serial over USB. This didn't work, and when the micro-controller crashed. it took the Linux USB driver with it, and I had to reboot. That precludes using the debugger - since it connects via USB too. So now I have a double defence: The micro-controller dev board is connected to the raspberry pi via USB, and also via serial: the pi has a 3.3V serial port which is perfect for this. You can read some instructions  here . You don't have to reboot though: just do $ sudo init q instead to get init to reload it's configuration. If I have to reboot the pi to get USB access back that will be OK, but using the serial port makes that unlikely anyway. I still haven't used the debugger. My problem turned out to be a cut and paste error: Picobit passes arguments to primitives in 4 global variables. This mak

I was looking at the Small Scheme Stack a little more than a year ago. I couldn't find the source, so I contacted the authors asking them if it was available under an open source license. Marc Feeley got back to me, asked a few questions about the scheme I planned to use, and suggested Picobit . At the time I abandoned that idea, and finally got around to looking at Picobit about a week ago This afternoon, I've managed to embed it in Chibios. It's already been ported to a specific ARM board, but I wanted to embed it in Chibios to avoid writing a lot of drivers. I've now got a little scheme program that flashes a led on and off on an STM32F4 Discovery board. You can see the fork of picobit here . It's a work in progress: my build in particular is a bit of a mess. Chibios wants your makefiles to follow a fairly rigid structure, and Picobit's makefiles are a little complicated: copying details about the memory map from the vm build across to the compiler. I thi

I decided to buy this because I wanted to try some milling. I still haven't tried that, but I thought I would mention it anyway - there's quite a lot to like about it as a drill: Up to about 4K RPM, this machine is as quiet as a dentists drill. It's also really quiet actually drilling wood or aluminium (all I've tried so far). Certainly you'll be tempted to just wear ear plugs or skip ear protection completely. At 6K, it's still quieter that the drill it replaces, but you are going to want to put those ear defenders on again. You can get a chuck that fits for less that a fiver. They might be exaggerating by calling it super precision but given how quiet the whole set up is, it must be pretty good. It's easy to switch it out for the collet holder as needed. The collar fits very well, and this makes a noticeable difference to accuracy. I had two goes at buying this. First time was an Amazon marketplace seller using Amazon for fulfilment. It duly arriv