Just spent a few quality hours helping one of my daughters solder a Blinky POV kit.

Sadly, not all the characters in the default messages are available in the programming web page. No ♥ as in the default messages, not even a ‘ which was annoying when her first attempt at a message included a contraction!

Blinky POV Kit :: Wayne and Layne Store

Michael K Johnson November 09, 2014 19:05

Of course, she has already managed to misplace it. That was quick. (Persistence of vis—squirrel!)

I hope it’s not the next foreign object I liberate from the vacuum cleaner hose!

Michael K Johnson November 09, 2014 19:28

Huh. It was actually put away in an appropriate place.

Having found it, I am sad to report that the bootstrap overwrites the program so there is no obvious way to restore the original program through the programming web site.

Richard Hughes November 10, 2014 04:46

+Michael K Johnson It’s amazing how many projects fail at bootloader + firmware updates.

Michael K Johnson November 10, 2014 06:01

+Richard Hughes Oh, I wasn’t clear. The Blinky is programmed by holding down its pushbutton while booting, which drops it into into a bootloader that loads its main program flash by holding it up to blinking squares on the screen. Very clever. The bootloader remains intact. (“bootstrap” was my error.)

I should be able to re-flash the original main program using the ICSP header and git@github.com:wayneandlayne/blinky.git

— I just wish there were an option on the web site to reprogram it with the original main program.

Using javascript and blinking squares on the monitor as a programming interface is clever. ☺

Joseph Pingenot November 10, 2014 12:20

+Matthew Beckler might be interested in this thread.

Richard Hughes November 10, 2014 12:25

+Michael K Johnson That’s very clever indeed. Given the ColorHug has a color sensor, I wonder if i could encode the firmware with a clock in just 3 colors :)

Michael K Johnson November 10, 2014 12:41

+Richard Hughes In some ways might be even easier for you, maybe? Blinky POV docs have to tell you to make sure monitor brightness is at 100% because sometimes monitor brightness is controlled by PWM. Would you be able to command laptop screen brightness to 100% to avoid the higher frequency noise?

At one data rate, I saw a tearing effect (most visible in the clock channel) that was correlated with a checksum failure. Unfortunately I don’t recall what that data rate was…

Matthew Beckler November 10, 2014 12:42

Thanks for the heads-up +Joseph Pingenot. I’m one of the guys at +wayneandlayne who created this kit. Always cool to see our stuff out “in the wild”, I hope you enjoyed the kit!

+Michael K Johnson, the heart symbol in the default message is created as a “pixel” message, not as a “text” message, so you could re-create it that way. The blinky code can handle multiple messages, so in the original pre-programmed chip, we created separate messages for “I”, the heart, and “Blinky POV!”, with each message set to “Advance to next message” as the end behavior.

That’s a good idea to have an easy way to restore the default messages, I’ll look into adding a button to the webpage for that. Surprisingly enough, you are the first person to suggest such a thing!

If you have a PIC programmer with the 5-pin ICSP header, we have our hex files here: http://www.wayneandlayne.com/projects/blinky/download/ - You want the “combined” hex files that contain both the bootloader and the user code, and also will reprogram the EEPROM with the original messages. Here is the direct link to the hex file you need for the POV: http://www.wayneandlayne.com/files/blinky/downloads/blinky_firmware_bootloader_pov_combined_v1.02.hex

We’re really proud of the optical reprogramming, but we certainly aren’t the first to do such a thing. Timex had a “DataLink” watch in the 90s that was also a PDA, where you could update your contacts in the thing by holding it up to your monitor, and the BBC Micro computer in the 70s (?) could “download” programs to cassette by taping a photocell to the corner of your television and tuning to one of the BBC channels (overnight?) when they’d transmit new programs to try. After having tons of trouble with a prior kit in a classroom computer lab setting, where the USB connection didn’t work well with the locked-down, no-admin-rights lab computers where we couldn’t install drivers (even for standard USB-CDC serial ports), we decided to try making a kit that wouldn’t require USB or drivers or anything like that, and this is what we came up with. If you have a browser and web access, you can reprogram the blinky kit (even works on tablets and smartphones).

More details on the kit design and workings are here: http://www.wayneandlayne.com/projects/blinky/design/

+Richard Hughes, I think we actually did a decent job with the bootloader and the reprogramming updates. In order to support bootloading using data from the optical sensors, we had to write our own bootloader from scratch, and added an extra record type to the standard Intel Hex file format to support the blinky messages that go into the EEPROM. Everything is checksummed to the nines, and we only burn the flash or EEPROM if the checksums match. We have separate sections in the flash space for the bootloader, the font table for the “text” messages, and the user code that reads the stored messages from EEPROM and displays them on the LEDs. One interesting easter-egg is that you can actually use the optical sensors to re-program the user code, not just the messages stored in EEPROM. It does take a long time though to transmit hundreds of bytes for a user program…

Richard Hughes November 10, 2014 12:52

+Matthew Beckler It looks a nicely done bit of hardware, well done. For ColorHug I actually implemented a bootloader as a 100% completely separate bootable target; only if a magic sequence is in the eeprom we re-init to firmware mode. This does mean we ship 2 complete USB stacks on one device (with two different USB device numbers), but also means it’s basically impossible to “brick” a ColorHug as the firmware can’t flash the bootloader, and only the firmware can set the magic in the eeprom. There’s a bit of magic when you redirect interrupts, but it basically works.

https://github.com/hughski/colorhug-firmware if you’re interested.

Matthew Beckler November 10, 2014 13:03

That’s a great idea to throw a magic cookie into the eeprom to control boot. Neither the blinky firmware nor the bootloader itself can update the bootloader since it’s in a fuse-protected code region, so we’re pretty immune to bricks as well. The most common issues we’ve seen are difficulties with getting the optical sensors to detect the difference between black and white squares on the screen. Usually it’s caused by having display brightness less than 100%, because most backlights use PWM to control brightness, which totally messes with the blinky programming.

The ColorHug looks like an awesome piece of hardware. Kudos for the first-level Linux support. I might just have to pick one up to help reduce the color difference between my laptop and external displays (although I did see the disclaimer about the Ferraris in your FAQ).

Michael K Johnson November 10, 2014 13:21

+Matthew Beckler Wow! Thanks for explaining how the the default message set is put together.

I’ve only done AVR not PIC so my only programmer is Tiny AVR. Not much use for PIC, between the different protocol and the need for 12V supply… ☺

Matthew Beckler November 10, 2014 13:35

There are a couple great cheap PIC programmers like the PICKIT2 and PICKIT3, they are roughly equivalent in price and features to the Tiny AVR (I have Adafruit’s USB tiny avr programme). Just like the avr programmers, the PICKIT programmers generate the required 12v internally.

Michael K Johnson November 11, 2014 06:38

+Matthew Beckler I’m a newbie, but I don’t think AVR needs 12V. I don’t see a charge pump on the TinyAVR I bought, and the supply voltage for the ICSP headers is labelled 5V (as shown at https://learn.sparkfun.com/tutorials/tiny-avr-programmer-hookup-guide/ under Board Overview; not labelled on the board itself). I doubt that’s why the TinyAVR is $20 and the PICKIT3 is $50 from reputable suppliers though. ☺

Matthew Beckler November 11, 2014 08:44

You’re right, most of the time AVR use their low-voltage programming method, but sometimes they get messed up and need the high-voltage to reset the fuses. I’ve used Jeff’s AVR Rescue Shield many times to fix the 8-pin AtTiny chips where I’ve messed up the fuses or needed to use the reset pin as GPIO. http://mightyohm.com/blog/products/hv-rescue-shield-2-x/

Imported from Google+ — content and formatting may not be reliable