I ordered two FIT0441 brushless motors for use in v2 of my balancing robot. The DFRobot wiki page on the motor is incorrect so I thought I’d blog about it so someone else can find it 🙂
The motor comes with a 5 pin JST-SH cable with a white end and a black end. The white end goes to the motor. When looking from the back of the motor with the socket at the 6 o’clock position, the wires are:
- Blue (left most): PWM. Take to GND for full speed.
- Black: GND / Supply negative
- Yellow: Direction
- Green: encoder output. ~680 Hz at full speed
- Red (right most): 12V
Note that the black end has a completely different order.
To make the motor spin, connect 12V to Black and Red and short Blue to GND. To make it spin in the opposite direction, short Yellow to GND.
github.com/eriksl/esp8266-universal-io-bridge looks cool – it exposes the I/O of a ESP8266 wifi module including the GPIO, I2C, PWM, ADC, and UART via a line based telnet interface.
I’ve released a toy compiler for the PL/0 educational language at https://juju.net.nz/src/cgit.cgi/pl0.git/ or https://github.com/nzmichaelh/pl0.
I did this as, despite working with compilers for a fair part of my life, I’d never written one from scratch. I chose PL/0 as it was designed by a local legend, Niklaus Wirth, who is also the creator of Pascal and Modula-2.
We went to Maker Faire Bodensee on the weekend. The kids spent so much time with Paula Pongratz’s Post-apocalyptic jewlery that they missed most of the rest (heh).
Other standouts were the breadboard / pus pin based electronic organ from
Elektronikmuseum Tettnang and the marshmallow building challenge by Toolbox BODENSEE. I also want to have a look into the Minecraft smart-home, Nodebots, and Freifunk.
Someone recently mentioned that you can ‘hear’ a TV remote control by hooking a solar panel to a speaker and pointing the remote at it. It was a rainy weekend this weekend, so my son and I gave it a go:
The circuit is simple: a solar panel from a toy, a ~1 Hz RC highpass filter to get rid of the DC component, and an amplified speaker for the output. The noise is the code that the remote is sending to the TV which is roughly 700 Hz for one remote and 400 Hz for the other.
The next step is to see if you can send music over light. With a bit more circuitry, you can:
I used a LM386 to bias the LED to be normally on. The bias is set by a potentiometer on one of the differential inputs with the MP3 player on the other. Setting the bias too high or too low causes clipping due to the LED turning off or the amplifier hitting the 5 V supply rail. It sounds really good – well, at least as the small speaker lets it.
It’s taken a while (as you can tell from the date on the box), but here’s my web connected NeoPixel ring:
Chroma trail: a comet with a trail that cycles through the colours of the rainbow.
I had to turn the brightness down so the camera didn’t saturate, as you can see in the next one:
Raindrops: randomly coloured drops that fade away.
This is a WRTnode board running a Python server. The patterns are loadable Python code. For a limited time, the server is available here. Try /pattern for a list, and /pattern/name/run to run one.
Here’s my hack of the moment: text fading in on a OLIMEX 128×64 OLED display. The interesting bit is that this is a TTF font which is rendered by SDL2 into a buffer, dithered into black and white using Floyd-Steinberg error diffusion, and then written out using the Intel IoT upm display driver. Optimizing the bulk write routine got the frame rate up from ~4 FPS to ~15 FPS.
Here’s what I found out while trying to add buttons to the OpenWrt based Linkit Smart.
The flow is:
The DTS fragment is:
label = "btn2";
gpios = <&gpio0 2 1>;
linux,code = <0x102>;
<&gpio0 2 1> picks the second pin from the zeroth port i.e. GPIO 2 and
maps it to BTN_2. See
uapi/linux/input.h for the other key codes.
gpio-button-hotplug supports a limited number of keys. See the source for the
current list, which is
Also, the LinkIt uses a binary wifi driver which seems to be very sensitive to
the kernel version. I ended up reverting
to bring OpenWrt back to 3.18.21 to stop it crashing when the interface comes up.
I did a quick hack today and wrote a scrolling text app for an Adafruit 8×8 LED display I had lying about:
The app is written in C++ using the Intel
mraa I/O library (which looks pretty good) and running on a WRTNODE MIPS dev board with OpenWrt. The interesting bit is the text rendering: I started with a 6×8 bitmap font then added automatic width detection, blitting for rendering to the buffer, and blitting for rendering a scrolling window on the buffer to the display.
The next step is to add a web app so you can post messages from the Internet. What could go wrong?
I’ve been hacking on a personal project to make it easier to expose HTTP based devices that are behind a restrictive NAT or firewall. The code needs to run on a OpenWrt based MIPS board which limits my language choice – Python3 is out as it’s too big, and Go on MIPS32 via gccgo on OpenWrt is… tricky.
I ended up writing the app in C++ and I’ve been quite impressed with C++14 and the Boost libraries. Especially:
boost::optional for covering the optional results without having to use tricks like err == -1 or result == nullptr.
boost::algorithm::string for string splitting and trimming.
boost::asio for all of your event or blocking based network programming needs.
boost::program_options for command line option parsing and validation.
boost::asio::coroutine for a very readable implementation of Duff device based coroutines.
std::unique_ptr / std::shared_ptr for sane memory management.
Generous use of
using keep the code reasonably terse as well.
 I also have two of the $12.90 LinkIt Smart 7688 boards on their way. A good price for a 580 MHz Linux CPU on a DIP carrier with Wifi, RAM, and 32 MiB of flash.
 gccgo enables libffi, which assumes floating point registers, but the OpenWrt kernel turns off FP emulation by default and enforces it through binutils flags.