6-stage CD4013 clock divider

So, following on from my last post demonstrating an Arduino-based clock divider, I made another one with just dual-flipflop (CD4013) logic chips. This design divides into powers of two, from /1 to /32, using six flipflop units. Nothing fancy or ground-breaking - just implementing something I found on Wikipedia.

It seems that it needs the input clock pulse voltage to be reasonably close to the IC supply voltage. When I ran it at 12V supply with 5V input pulses it didn't seem to work very well at all. 6V supply with 5V pulses seems to work quite reliably. This can be improved by feeding the input clock line with a MOSFET.

Essentially this is an implementation of the cascading arrangement depicted here. The only parts not noted in that diagram are:

• The additional flipflops, which are wired in exactly the same way
• RESET and SET lines on each CD4013 must be tied low
• The usual power supply rails

Arduino clock generator + divider experiment

Lately I've been learning about modular synths. One of the common things modular folks use to control things is a pulsed clock. This afternoon Tiina and I wandered down to Redfern to check out a meeting of the New Sound Waves modular synth group. The guys there had synced up their modulars and assorted other equipment with a shared clock source and were collaboratively making music. Pretty cool stuff.

Anyway, I decided to try to make my own clock divider. Didn't take long to get something working, and you can see the results in the video above. The genuine Arduino Uno is generating a simple square wave on pin 13, which you can observe with the built-in LED. The Freetronics clone is triggering on the rising edge of the square wave and operating a clock divider with /1 through /8 outputs. The /1 through /4 divider outputs are attached to a little test-LED board I made a while back. You can see that it has a bug caused by my forgetting to reset the tick counter.

To actually use this in a modular synth it would need to tolerate inputs in the range -12V to +12V, maybe via a bunch of MOSFETs. It might be easier to just ditch the AVR and use flip-flops

Rescuing an "unhappy" EM406A GPS

I'm not sure of exactly what happened, but while I was mucking about with my datalogger this afternoon, the EM406A GPS sensor started emitting what looked like garbage in place of the usual NMEA sentences. A little googling revealed a thread on the Arduino forums which contained a link to Ken's blog post over at DIYDrones. I grabbed a copy of Ken's code and tried it out.

As the comments in the code indicate, some mucking about with the baud rate was indicated. Attempts at 57600 and 38400 seemed to make no difference, but after trying 9600 baud I got a single NMEA sentence followed by a bunch of binary data (presumably SiRF), and feeling encouraged at that result, I tried the magic at 4800 baud and also changed the configured baud rate (see lines 53-55 in the below code) to 4800. It worked, and now my EM406A is emitting NMEA sentences and no binary SiRF data.

Along the way I adjusted the code to take advantage of the extra USARTs available on an Arduino Mega2560 board. The GPS is connected to RX1/TX1, and some status messages are emitted to the usual Serial console. After attempting the rescue process, it also starts dumping the data stream from the GPS onto the Serial console so you can see immediately if it was successful or not.

Summary: happy and very relieved - didn't want to buy another sensor! Post a comment and don't forget to thank Ken if this was useful to you - this is his rescue code, not mine!

My highlights of 2013

1. March: Seeing Opeth live in concert again, at Enmore Theatre in Sydney. Mikael Akerfeldt appears to have his growl back. Hands-down the best gig I've ever been to, of any genre. Can't wait for their next tour (and mooted new album, also)
2. April-May: Visiting the UK and especially Finland with my friend Tiina. I'd visited the UK back in 1984 when I was a wee lad, but didn't really remember anything. Was great to go back. But... Finland was stunning. We spent two weeks exploring it. Definitely going back there. Also on the way back to the UK (we flew home from London) I ticked off another bucket-list item - we visited the original Legoland in Billund, Denmark. I'd wanted to go there ever since I saw pictures of it (I think in one of those Lego Ideas books published by Lego) back in primary school.
3. June: Visiting Japan very briefly, spending three nights in Tokyo, ostensibly to see Van Halen's concert at the Tokyo Dome. While there I caught up with an old friend who now lives in Tokyo, and ticked off another bucket list item - spending a few hours ogling all the wonderful things at the Toyota Automobile Museum near Nagoya. The Shinkansen (bullet train) to Nagoya was also pretty interesting.
4. October: Acquired a new motorcycle - 2013 KTM 990 SuperMoto R. Ludicrous fun. Sounds wonderful. Somewhat impractical fuel range. Completely unsuited to highway slab rides, but brilliant for sporty rides and generally being a hooligan, which is just what I'd wanted

sampling multiple analog signals asynchronously with Arduino

So while I was assembling a fellow #arduino denizen's synth project on a breadboard, he commented that Arduino's analogRead hadn't been fast enough to read the pots. After poring over the AVR ATmega328 datasheet for a while I was able to get an interrupt-driven analog-to-digital conversion happening. This is documented in many folks' blogs but most of the pages I've seen only demonstrate one, and I needed four. His acidmatic synth is now rather a lot of fun to twiddle, and I will keep hacking on it, and build a permanent version in an enclosure.

Stripped-down demo code follows. Note that this requires an analog reference signal to be wired up to the AVR. This can actually be done in software if you just want it to be set at Vcc or some other voltage visible to the microcontroller, but I was getting very tired and that part of the datasheet was not making any sense. On my 16Mhz ATmega328, the below code yielded somewhere north of 2000 samples per second per pot. Easily enough for this application.

PCF8574-based I2C LCD backpacks

So it seems that there's a lot of these about. A while back I picked up a bunch of cheap LCD backpacks on eBay, they look like this:

Like most of these cheap LCD backpack units, it utilises a GPIO expander chip. In this case, the chip used is a PCF8574. Most of the other I2C backpacks for Hitachi LCDs seem to utilise Microchip's MCP23008, which seems to be the little brother of the MCP23017 I've been playing with lately. So I had quite a hunt for some quick and easy code libraries to test out the backpacks with. I found one in Atlassian Bitbucket. I used version 1.2.1.

I then found this page which describes a number of the cheap eBay backpacks and clones. The third code example worked fine with the above library.

Unfortunately, after reducing the test sketch to merely the below, it was still gobbling 4768 bytes of flash. Unacceptably large, I think.

At some point in the past I'd picked up a bunch of black-on-green 16x2 LCDs for next to nothing. The total cost per LCD+backpack combo should come to easily less than $10 (AUD) each, including shipping. Pretty happy with that. They even work properly!

How I compile Stellaris projects under OSX

So I don't really know much about the TI Stellaris yet, having mainly used AVR chips to date. But I have a couple of the Stellaris Launchpads, and have managed to get the toolchain working under Mac OS X. I'm not going to repeat all the steps required for that here; you can use this page as a good starting point for that, and noting that you can save yourself a whole bunch of time/hassle by setting up MacPorts and doing this:

sudo port install arm-none-eabi-{gcc,binutils,gdb}

In my $HOME/Code/stellaris directory I have a single Makefile called Makefile.simple, and a separate subdirectory for each project. Its contents look like this:

CC=arm-none-eabi-gcc
LD=arm-none-eabi-ld
OBJCOPY=arm-none-eabi-objcopy
CPU=cortex-m4
STELLARIS_TOP=$(HOME)/build/stellaris/stellaris
CFLAGS_STELLARIS=-mthumb -mcpu=$(CPU) -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MD -I$(STELLARIS_TOP)
CFLAGS=-std=c99 -Wall -Os $(CFLAGS_STELLARIS)
LDFLAGS_LEFT=-T $(PROG).ld --entry ResetISR 
LDFLAGS_RIGHT=--gc-sections

$(PROG).bin: $(PROG).o startup_gcc.o $(PROG).ld
 $(LD) $(LDFLAGS_LEFT) -o $(PROG).bin $(PROG).o startup_gcc.o $(LDFLAGS_RIGHT)

$(PROG).out: $(PROG).bin
 $(OBJCOPY) -O binary $(PROG).bin $(PROG).out

clean:
 $(RM) $(PROG).bin $(PROG).out $(PROG).[od] startup_gcc.[od]

flash: $(PROG).out
 lm4flash $(PROG).out

You can see in the above that STELLARIS_TOP is set to the location in which I have unpacked (actually git clone...) StellarisWare. This is provided to gcc so that it can find C include files. Adjust as necessary if you are using my Makefile

In each project subdirectory I have a few files:

$ ls
Makefile       blinky.c       blinky.ld      startup_gcc.c

The Makefile merely includes ../Makefile.simple and specifies the name of this project:

PROG=blinky
-include ../Makefile.simple

The other files (blinky.ld and startup_gcc.c), at least at this learning stage, are the same for every project; I just copy them over from project to project.

To build my project, I just type make:

$ make
arm-none-eabi-gcc -std=c99 -Wall -Os -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MD -I/Users/jslee/build/stellaris/stellaris   -c -o blinky.o blinky.c
arm-none-eabi-gcc -std=c99 -Wall -Os -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MD -I/Users/jslee/build/stellaris/stellaris   -c -o startup_gcc.o startup_gcc.c
arm-none-eabi-ld -T blinky.ld --entry ResetISR  -o blinky.bin blinky.o startup_gcc.o --gc-sections

My project compiled and linked OK, so it is ready to send to the Launchpad with lm4flash:

$ make flash
arm-none-eabi-objcopy -O binary blinky.bin blinky.out
lm4flash blinky.out
ICDI version: 9270

Please let me know if you found this useful! I also use a similar Makefile structure for building and flashing AVR and MSP430 projects.