Anonymous

Project:Nanode/Applications/Bootstrap config files: Difference between revisions

From London Hackspace Wiki
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Files modified in USBaspBootLoader, probably not yet correct (and should be in github anyway)
Files modified in USBaspBootLoader (and should be in github)


Warnings:
Don't use the 'make fuse' part. The default fuses used by the serial bootloader are fine and these don't make sense with the datasheet.  Just use 'make main.hex', or set up the PROGRAMMER macro and use 'make flash'. I haven't tried to add this build to the ALLHEXFILES target and it probably makes no sense to do so, as the changes I made to usbconfig.h won't generate valid output for the other targets.
This loader needs more work. At present, it :
* Doesn't do anything with the LED to indicate it's working
* Needs to be put into loader mode by grounding DIG7 and pushing the reset button
* Will go straight from programming into running, but needs DIG7 ungrounding before the next reset
So, to run dmi's dhcp webserver after installing this loader, you need to :
* add the arduino board description to {arduino root}/hardware/arduino/boards.txt
* load the sketch
* select the nanode target board
* link DIG7 to ground with a wire
* reset the board
* upload the sketch
The code will then start running, but you probably need to see the serial output. To do this :
* connect FTDI cable to serial port, but DO NOT connect the 5V line, or you'll backdrive the USB port
* open serial monitor
* remove the DIG7 link (or the reset will enter the loader again)
* reset the board (because the interesting stuff has already been printed)
This can probably all be improved. Suggestions as to how to do it without using a lot more port pins or hardware changes to the nanode board are welcome (currently, I'm thinking some sort of timeout after reset).
There's a possible bug in the loader : it doesn't seem to move the interrupt vectors back down to the app code after using them for the bootloader. I think this might get corrected by the arduino runtime, but it would be better done in the bootloader in case code is loaded that assumes the AVR is straight out of reset.


  <nowiki>
  <nowiki>