Friday, October 31, 2014

Halloween 2014

So, I went to switch my LED Display Light box from the Christmas display to the Halloween display. A simple job you might think. Of course, I ended up with a bunch of problems. For some reason switching the display always causes problems - mostly because I'm always doing it last minute. I wrote myself detailed instructions last year to help speed the process, but that didn't help.

A simplified list of what happened:
  • To reprogram the LED Display light box I need a USB cable ... of course I can't find a USB A to USB B full size cable (my normal one used for this is cool - it lights up orange! Something like this). So into the loft/attic to find one in the large stash of random (mostly useless) cables. 
  • For some reason CoolTerm wouldn't allow me to change RTS?!?! What?!?! On the embedded board (which uses an NXP LPC processor) DTR is used to drive the reset pin and the RTS is used to select programming mode or normal run mode). 
    • Try downloading the new version of CoolTerm (1.4.4 rather than 1.3.0). Doesn't help.
    • Try two other machines (with 10.8 and 10.9 on them) - they don't recognise the device at all.
    • Start to suspect driver on back Yosemite ... I'm not sure whether it's a built in driver or the FTDI driver (the board has a USB-Serial chip from FTDI on it). Downoad the FTDI VCP driver. Doesn't help.
  • Ok, so back onto the my wife's machine. Install the FTDI driver. Install CoolTerm. It recognises it the LED Display and RTS works! (So it sounds like it might be a problem with RTS and Yosemite (Mac OS X 10.10), assuming the FTDI driver installed ok).
    • Haven't got the Forth code on this machine. Off to my public GitHub area to download it.
    • Start to follow the instructions. Realise the command to erase isn't listed in my instructions. DOH! Go to the BV511 v1 Forth board instructions. So the command is 'new'.
    • After a couple of aborted copy/pastes (including convincing my machine that '.fth' files really are text.) I finally get the two big files onto the board. Does it work? Of course not.
    • I have a vague recollection of some problem to do with the port initialisation code. Of course, I don't remember exactly why or what, but the instruction hint at loading the second file in two halves, saving and testing after the first half. It might be that the Halloween code wasn't as mature as the Christmas code (something I never got around to fixing).
    • I try this ...and initially the code turns on / off all LEDs as expected. But not after a reboot. I try loading the rest of the code, and it doesn't work. I think maybe setting the top level command as the word to run on boot and rebooting will help (desperation? maybe). To do this you use 'save word-name', all the saves write from on-chip RAM to on-chip Flash. Something goes wrong during the save and it locks. Arrggg... Reboot ... Nope, the Forth engine doesn't come up with a command line.
    • Ok, back to my machine to reflash the chip. Of course, my lpc21isp programmer doesn't work because it was an ancient built. Get the latest code off SourceForge and compile it (by just typing make).
    • Try running the programmer with the basic BV511 hex file ... but it doesn't program - probably because the RTS control isn't working. 
    At this point, it's time for an early tea before we take the kids out in costume.

    There are three options going forward.
    • Reflash the board with the Forth firmware and just load the Forth code on.
    • Do the above but merge the code so we can switch between Halloween and Christmas with a single high-level file.
    • Switch the control board (the Forth-based BV511) for a Linux board - like a Raspberry Pi. There might be interesting I/O questions, and it isn't as quick a fix. However, it's likely to be much easier to update - and we can do it wirelessly via SSH.
    Sounds like there might be more of this story in the future.
    Newer›  ‹Older