I have recently acquired some more hardware - a Tincan tools Trainer for xM and a Pandaboard. Sometimes I feel embedded should start with an 'A' - for ARM and Arduino.
Word of caution in the new kernels the serial ports on the xM appear at /dev/ttyO1. Look in /proc/tty/drivers - OMAP-SERIAL /dev/ttyO 253 0-3 serial.
You will need this little tid-bit to program the trainer. The programmer seemed to be atleast respond to avrdude when fresh out of packaging:
avrdude: stk500_getsync(): not in sync: resp=0x20avrdude -V -F -c stk500v1 -p m328p -P /dev/ttyO1 -b 57600 -U flash:w:blink.hex
avrdude: stk500_getsync(): not in sync: resp=0x20
It was not working anyway, but can I make it fail with 0x20 predictably ? So I got fancy and forwarded the serial port over the network. The beagle acts as a serial port server and the host machine acts as the client. This is plain tcp, but you can build an ssh-tunnel or whatever. The serial port is redirected with interceptty. The same failure was observed.
So I forked out some cash and got myself an ISP cable. This let me load the arduino bootloader using avrdude and the instructions here. After the first bootload, avrdude and avrgal can both push blink.hex to the arduino bootloader, but fail to perform further writes due to the lack of the software reset (stty -F /dev/ttyO1 hupcl). So I resorted to how the arduino visual IDE does things and eventually I used the Arduino.mk in /usr/share/arduino and built up a blink.hex which was significantly larger than the pure Makefile based one. This one supports loading and reloading via avrgal. The first attempt made an arduino bootsector virus as av500 put it.
Now that all is hunky-dory in the tincan + beagle-xM world, it is time to attach a few peripherals to the arduino and watch it squirm.
Word of caution in the new kernels the serial ports on the xM appear at /dev/ttyO1. Look in /proc/tty/drivers - OMAP-SERIAL /dev/ttyO 253 0-3 serial.
You will need this little tid-bit to program the trainer. The programmer seemed to be atleast respond to avrdude when fresh out of packaging:
avrdude: stk500_getsync(): not in sync: resp=0x20avrdude -V -F -c stk500v1 -p m328p -P /dev/ttyO1 -b 57600 -U flash:w:blink.hex
avrdude: stk500_getsync(): not in sync: resp=0x20
It was not working anyway, but can I make it fail with 0x20 predictably ? So I got fancy and forwarded the serial port over the network. The beagle acts as a serial port server and the host machine acts as the client. This is plain tcp, but you can build an ssh-tunnel or whatever. The serial port is redirected with interceptty. The same failure was observed.
So I forked out some cash and got myself an ISP cable. This let me load the arduino bootloader using avrdude and the instructions here. After the first bootload, avrdude and avrgal can both push blink.hex to the arduino bootloader, but fail to perform further writes due to the lack of the software reset (stty -F /dev/ttyO1 hupcl). So I resorted to how the arduino visual IDE does things and eventually I used the Arduino.mk in /usr/share/arduino and built up a blink.hex which was significantly larger than the pure Makefile based one. This one supports loading and reloading via avrgal. The first attempt made an arduino bootsector virus as av500 put it.
Now that all is hunky-dory in the tincan + beagle-xM world, it is time to attach a few peripherals to the arduino and watch it squirm.
No comments:
Post a Comment