If I try the automatic upgrade on emonCMS, the following happens..
avrdude-original: Version 5.11.1, compiled on May 23 2012 at 11:08:25 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2009 Joerg Wunsch System wide configuration file is "/etc/avrdude.conf" User configuration file is "/root/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyAMA0 Using Programmer : arduino Overriding Baud Rate : 115200 avrdude-original: Using autoreset DTR on GPIO Pin 7 avrdude-original: stk500_getsync(): not in sync: resp=0xe0
However, If I run this, it works fine.
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATm ega328.cpp.hex
Looks like a baud rate issue - anyone else have this?
Re: RFM2PI v2 (ATMEGA328) Automatic upgrade - timeouts
That update routine is really configured for the emonpi rather than a rfm2pi, You could edit the update command usually located in the /home/pi/emonpi/Atmega328/update script
Change the "-b = 115200" to 38400 and also point it at the correct target hex file as it will try and upload the emonpi sketch.
The changes you make could get over written by future updates and may even fail to get used at all as I believe the emonpi software containing the firmware will be updated prior to uploading the new firmware, hopefully the local changes will prevent git from pulling in any changes without stalling the process.
Paul
Re: RFM2PI v2 (ATMEGA328) Automatic upgrade - timeouts
Ah, thats where I'm getting mixed up, how does the script detect that its an emonPi rather than rfm2pi ?
Does the emonpi firmware work on the rfm2pi ?
Re: RFM2PI v2 (ATMEGA328) Automatic upgrade - timeouts
No mixup :-)
Currently the emonPi settings are hardcoded so it will only work for the emonPi. Ideally the update script should use the hardware and firmware information in emonhub.conf [nodes] to construct the avrdude commandline but that's not yet implemented.
The emonPi uses the standard "uno" settings while the rfm2pi's use a different bootloader due to using it's internal 8MHz clock rather an external 16MHz xtal and that bootloader requires a baud of 38400.
This current update routine also causes a problem for user calibration values and any customisation of the sketches as it uses precompiled hex files, the next step is to compile the sketch locally at update/upload time, but that's quite involved.
For now just edit the update file directly with the corrected commandline or continue to do updates manually.It maybe better to go with the latter to avoid the hassle of upsetting git or over writing you edits, plus there is no check to see if the firmware has changed so every time you update emoncms and emonhub or the other emonpi files the hex file gets burned to the AVR regardless, which really isn't needed.
Paul