These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.
Most content on this site is licensed under the WTFPL, version 2 (details).
Questions? Praise? Blame? Feel free to contact me.
My old blog (pre-2006) is also still available.
See also my Mastodon page.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
(...), Arduino, AVR, BaRef, Blosxom, Book, Busy, C++, Charity, Debian, Electronics, Examination, Firefox, Flash, Framework, FreeBSD, Gnome, Hardware, Inter-Actief, IRC, JTAG, LARP, Layout, Linux, Madness, Mail, Math, MS-1013, Mutt, Nerd, Notebook, Optimization, Personal, Plugins, Protocol, QEMU, Random, Rant, Repair, S270, Sailing, Samba, Sanquin, Script, Sleep, Software, SSH, Study, Supermicro, Symbols, Tika, Travel, Trivia, USB, Windows, Work, X201, Xanthe, XBee
While trying to track down a reset bug in the Pinoccio firmware, I
suspected something was going wrong in the dynamic memory management
(e.g., double free, or buffer overflow). For this, I wrote some code to
log all malloc
, realloc
and free
calls, as wel as a python script
to analyze the output.
This didn't catch my bug, but perhaps it will be useful to someone else.
In addition to all function calls, it also logs the free memory after
the call and shows the return address (e.g. where the malloc
is called
from) to help debugging.
It uses the linker's --wrap
, which allows replacing arbitrary
functions with wrappers at link time. To use it with Arduino, you'll
have to modify platform.txt to change the linker options (I hope to
improve this on the Arduino side at some point, but right now this seems
to be the only way to do this).
When working with an Arduino, you often want the serial console to stay open, for debugging. However, while you have the serial console open, uploading will not work (because the upload relies on the DTR pin going from high to low, which happens when opening up the serial port, but not if it's already open). The official IDE includes a serial console, which automatically closes when you start an upload (and once this pullrequest is merged, automatically reopens it again).
However, of course I'm not using the GUI serial console in the IDE, but minicom, a text-only serial console I can run inside my screen. Since the IDE (which I do use for compiling uploading, by calling it on the commandline using a Makefile - I still use vim for editing) does not know about my running minicom, uploading breaks.
I fixed this using some clever shell scripting and signal-passing. I
have an arduinoconsole
script (that you can pass the port number to
open - pass 0 for /dev/ttyACM0
) that opens up the serial console, and
when the console terminates, it is restarted when you press enter, or a
proper signal is received.
The other side of this is the Makefile I'm using, which kills the serial console before uploading and sends the restart signal after uploading. This means that usually the serial console is already open again before I switch to it (or, I can switch to it while still uploading and I'll know uploading is done because my serial console opens again).
For convenience, I pushed my scripts to a github repository, which makes it easy to keep them up-to-date too:
Last week, I got a fancy new JTAGICE3 programmer / debugger. I wanted to achieve two things in my Pinoccio work: Faster uploading of programs (Having 256k of flash space is nice, but flashing so much code through a 115200 baud serial connection is slow...) and doing in-circuit debugging (stepping through code and dumping variables should turn out easier than adding serial prints and re-uploading every time).
In any case, the JTAGICE3 device is well-supported by avrdude
, the
opensource uploader for AVR boards. However, unlike devices like the
STK500 development board, the AVR dragon programmer/debugger and the
Arduino bootloader, which use an (emulated) serial port to communicate,
the JTAGICE3 uses a native USB protocol. The upside is that the data
transfer rate is higher, but the downside is that the kernel doesn't
know how to talk to the device, so it doesn't expose something like
/dev/ttyUSB0
as for the other devices.
avrdude
solves this by using libusb, which can talk to USB devices
directly, through files in /dev/usb/
. However, by default these device
files are writable only by root, since the kernel has no idea what kind
of devices they are and whom to give permissions.
To solve this, we'll have to configure the udev
daemon to create the
files in /dev/usb
with the right permissions. I created a file called
/etc/udev/rules.d/99-local-jtagice3.rules
, containg just this line:
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2110", GROUP="dialout"
This matches the JTAGICE3 specifically using it's USB vidpid (03eb:2110,
use lsusb
to find the id of a given device) and changes the group for
the device file to dialout
(which is also used for serial devices on
Debian Linux), but you might want to use another group (don't forget to
add your own user to that group and log in again, in any case).
I recently got myself an Xprotolab Portable, which is essentially a tiny, portable 1Msps scope (in hindsight I might have better gotten the XMinilab Portable which is essentially the same, but slightly bigger, more expensive and with a bigger display. Given the size of the cables and carrying case, the extra size of the device itself is negligable, while the extra screen size is significant).
In any case, I wanted to update the firmware of the device, but the
instructions refer only to a Windows-only GUI utility from Atmel, called
"FLIP". I remembered seeing a flip.c
file inside the avrdude sources
though, so I hoped I could also flash this device using avrdude on
Linux. And it worked! Turns out it's fairly simple.
Run avrdude, for both the application and EEPROM contents:
sudo avrdude -c flip2 -p x32a4u -U application:w:xprotolab-p.hex:i
sudo avrdude -c flip2 -p x32a4u -U eep:w:xprotolab-p.eep:i
I'm running under sudo, since this needs raw USB access to the USB device. Alternatively, you can set up udev to offer access to your regular user (like I did for the JTAGICE3), but that's probably too much effort just for a one-off firmware update.
Done!
Note that you have to use avrdude version 6.1 or above, older versions don't support the FLIP protocol.
I've been working on my own binary clock for a while now. I've managed to get the PIC microcontroller from Microchip working for some time now. After being busy with other stuff I slowly resurrected this project. Since the microcontroller part is mostly done (the software works, for the limited prototype hardware I have so far), I am focussing on the actual casing for the clock now.
The casing of the clock has a big influence on the rest of the hardware (and thus software) design. The basic idea of a binary clock is to have 3 rows of 6 LEDs each, one row for hours, minutes and seconds, each representing a binary number. Since representating a binary number isn't limited to leds but anything that can represent on and off, 1 and 0.
I'll settle for leds for now since they are easy to use and give pretty lights. The exact form is not decided yet. I had this idea of making the clock a very flat box, probably black, with 18 small (1cm) squares that illuminate (something like the TIX Pattern clock, but smaller). For that I would need white leds and colored, halftransparent plastic to put in the squares.
So I went shopping today and returned with a bunch of stuff. I got some fully transparent and half transparent sturdy plastic from a hobby shop, I got some colored half transparent plastic from a carrying folder and a handful of leds in yellow, green, blue and white. I also returned with a toy gun (full metal, so nice and heavy!) for lextalionis perhaps, liquid latex that is hopefully fit for making LARP weapons and looking for a box of pins, a nice 1000 page book about hardware design of game consoles, but that's beside the point.
I also found a box meant to hold sewing accesoires. It is a half-transparent plastic that contains 18 compartments (or 17 really, since one panel is missing). When I saw it I got a vision of the backside of the box, every compartment being one bit of the clock, with leds inside.
It turned out this idea actually seemed to work out nicely. I haven't been able to try this with multiple compartments lighting up at the same time, I expect I need to add some extra (light) shielding between the compartments. Also, I need LEDs with a bigger angle. Since my leds focus the light in a tight angle, only a part of the compartment backside is lit. If I put the led within a compartement, only a small circle of light appears at the outside. I need to put the LED about 10cm from the backside to get full coverage, which is impractical and reduces light strength.
Though this design seems to be quite nice, there are two main disadvantages to it. First, when it is turned off, the clock will probably look butt ugly. After all, it's not more than a plastic bogs when the lights are off. Second, the box is big. It's way bigger than needed to hold the leds, wiring and other electronics. I would say somewhere between 95% and 99% of the space is unused. Not so nice.
I'll get some wider angle LEDS first and then I'll see if I'm gonna build it like this. For now the box serves as a way better storage for a bunch of resistors, leds and other electronic components than the small glass bowl that used to contain my electronic junk.
As noted above, I was envisioning some sort of black box containing coloured squares that could light up. I tried this design using a few layers of paper (not black, but you didn't see the difference with the lights off) with a hole in them. I put a coloured piece of plastic with a white light behind it. This was not very succesful. The white light is so bright, you barely saw the blue colour of the plastic. When using uncoloured plastic, the light was just too bright to look in.
The other approach, using half-transparent uncoloured plastic squares, with coloured LEDs behind then, worked out better. The red, yellow and green leds had the advantage of being less bright (nicer to the eye). The blue led looked nice, but was still a little bright.
All leds suffered from the same problem as with the box design above: Their viewing angle is too small. I had to put the leds at a distance of around 5cm from the paper, which is way more that the thickness I had in mind. Also, due to this focussing the center of the square is brighter than the edges.
This looks like a very promising design. I need to get a decent piece of (black) wood, plastic or cardboard to do some more tests once I can get my hands on some wide angled LEDs.
Note to self: Get a cheap digital camera, since conveying these ideas in words is crappy ;-)