Having gotten one of the Vocore’s LEDs to blink from the command line, I decided that a simple C program to do the same thing would be useful, just to make sure that the cross-compiler has been set up correctly and that everything is working properly.
Having a program that just blinks an LED is pretty useful, just to verify that you can successfully run your code. If you’ve managed to cross-compile a test program like this, then copy it to the target hardware and see it working - then you can start building whatever you like with a degree of confidence.
So I’ve put the code for the Vocore blink program on GitHub just in case… NOTE: it’s designed to work without any additional electronics if you have the dock attached.
The project includes a simple Makefile which (hopefully) should work in most cases. As long as you have an OpenWrt build environment set up for the Vocore you should just be able to type
make and you will then have the program cross-compiled and ready to be copied onto the device. Doing something like:
scp ./blink firstname.lastname@example.org:/ should copy the program over to your Vocore. Once you’ve done that, you just need to
ssh into the Vocore and run it.
Oh, you’ll probably need to make sure that the program has been marked executable with
chmod, otherwise you’ll probably get a Permission denied message. I used
chmod +x blink to do that.
My tiny Vocore Linux machine has arrived from China. Cool! So far all I have not done much more than boot it up and check that I can log in and stuff. Oh, and I tried the web-based interface too. It seems to be working fine. A Linux box about the size of a postage stamp, what’s not to like?
Mine has the dock attached to it, so I’m just using a USB cable to power the device. I tried to power it off a USB socket on my MacBook … but there wasn’t enough current to allow the wifi to start. Some lights flashed on the Vocore initially, but then it went off a few seconds later. I think that this means that there is not enough current to allow the wifi to start operating… But when I ran it of a dedicated USB power supply it was fine.
Because I have the dock, I used an ethernet cable to connect to the Vocore, which means my laptop can remain connected to my home wifi and I can still use the Vocore with its default settings.
But when sitting in front of the command prompt I got as far as making some LEDs go on and off with commands like these:
echo 255 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness
echo 0 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness
The advantage of doing that is that they use an LED which has already been connected up on the dock … so I didn’t need to wire anything up. I’m going to try the same thing in a little C program next. Blinking an LED is an ideal little test program
The next thing that I’ll do is try my own minimal webserver, which might be useful if I start running out of space. So that’s next on my agenda.
Apart from that, I’m not really sure what I’m going to use it for. I’m sure I’ll think of something...
I thought that I'd lost this code, but now I've found it in a dusty corner of my hard disk. It works with the
USB LED Driver that I
wrote some time ago. It's a different clock plugin, where each digit scrolls into view as if the clock had
four rotating wheels for displaying the numbers.
If you're using my driver, then you might like to give this a try, I certainly like it.
All you need to do is extract the .cs file from the zip here and put it in the folder where the driver is installed
(usually C:\Program Files\Hobbsindustries\LED USB Matrix Driver). The next time you start the driver you should
see the extra option as an available plugin. Enjoy.
So, one of the things that I wanted to do with the Raspberry Pi was to control the GPIO pins from C# (Mono). What I decided to do was to write a shared library in C and then use native library interop from Mono to call the C code.
Anyway, the first step was to write the library in C and then call it from another C program. What I have done is basically copy the example from here, but write the actual GPIO access as a shared library. Currently, I'm simply copying the resulting .so file into /lib.
It wasn't that hard to do, I was quite surprised. Here is the working library running on a Raspberry Pi:
When I've had a bit more time to play with it and tidy up some things I will post the source code, probably in a few day time I expect. But the next step is to check that it works from Mono, but I don't see any reason why it shouldn't.
In the past few months several people have contacted me to ask if I could update my LED USB Message Board driver so that it works on 64 bit machines, especially Windows 7. So I have finally gotten round to that.
It actually took me longer to find the source code than to fix it for 64 bit machines :-) It was one of those seemingly counter-intuitive problems. I had to tell Visual Studio to target x86 machines when compiling to make it work on 64 bit computers. This is because the USB code that I'm using is 32 bit only, so changing the compiliation to target x86 means that a 64 bit machine will know to run the code in 32-bit mode. Easy when you know how.
It might mean this driver has a limited shelf life, I'm probably not going to re-write a specific 64 bit version. So if Microsoft stop allowing 64 bit machines to run 32 bit code then the driver will stop working. But for now it works. It even means that I can use my own LED display again, since I've been running Windows 7 64 bit for ages...
My LED driver page is here.
So how would you know that your code is running? Just about the simplest thing that you can do with a microprocessor is flash an LED on and off. So we'll start with that. You'll need to attach an LED and a resistor in series from pin 28 of the ATmega168 (assuming that you have the DIP format). So take a wire from pin 28 on the ATmega and attach it to the positive pin of an LED. Then attach the negative pin of the LED to one wire of the resistor. Finally, attach the other wire on the resistor to Ground. When the program code turns on pin 28, power will flow through the LED through the resistor and then to Ground. So the LED will come on. Cool.
Obviously LEDs are diodes, so they only go one way round (the resistor can go any way round). The purpose of the resistor is to limit the current and prevent the LED from burning out. The exact resistor value does not matter in this case, anything from 200 to 1,000 (1k) Ohms should be fine. The lower the value of the resistor the brighter the LED will be.
Don't forget to also wire up the other basic pins on the Atmega (I've blogged about that before). Now we can get to some code. I've put the source code here: http://www.codehosting.net/blog/files/led_blink.zip
Extract the contents of the zip file to a folder and open the files using Programmers Notepad from WinAVR. Connect up your usbtiny programmer, ensure that the power is on and we're ready to go.
Go to the Tools menu of Programmers Notepad and click on [WinAVR] Program. The program should compile, get loaded onto the microprocessor and the LED should start to blink! Woo-hoo.
NOTE: I have also used the "ponyser" serial port programmer. This can be used as an alternative, by changing these lines of the makefile:
Put a # at the start of line 202 and remove the # from line 201:
AVRDUDE_PROGRAMMER = ponyser
#AVRDUDE_PROGRAMMER = usbtiny
Remove the # at the start of line 206 and make sure that the COM port matches the one you're using:
AVRDUDE_PORT = COM1
Finally remove the # from the start of line 227:
AVRDUDE_FLAGS += -P $(AVRDUDE_PORT)
You should now be able to use a serial port programmer instead (my example uses COM1).