I have added some commands to /etc/rc.local on my Yun.
wifi-live-or-reset
boot-complete-notify
# load the sketch
/usr/bin/merge-sketch-with-bootloader.lua /www/sd/sketch/sk.cpp.hex
/usr/bin/run-avrdude /www/sd/sketch/sk.cpp.hex
touch /www/sd/booted
#notif the phone
/usr/bin/php-cli /www/sd/notif_boot.php
# CURL
/usr/bin/curl http://domain/url_to_check
exit 0
the sketch merge etc.. is done.
the file "booted" is touched
the PHP file IS NOT EXECUTED
the CURL command is not DONE.
Why?
Do those commands run properly when you type them directly into the command line?
I'm concerned about this part:
allairgoo:
load the sketch
/usr/bin/merge-sketch-with-bootloader.lua /www/sd/sketch/sk.cpp.hex
/usr/bin/run-avrdude /www/sd/sketch/sk.cpp.hex
I'm a little surprised at loading the sketch on each boot, but do you really want to append another copy of the bootloader to the sketch each time that the unit boots? You're going to end up with a lot of redundant data in the file, and will be trying to program the same regions over and over during one boot session.
I would think you would want to do the bootloader merging only once, probably when the hex file is created or copied into place (however it is that the hex file comes into being on your system.)
Did you install php-cli? It is not install on the "stock" Yun.
It might be the same for CURL.
Jesse
YEP
php-cli and php are installed, working with no error , and launched by cron N times / day and producing results, datas and more.
root@arduino:~# php -v
PHP 5.4.5 (cli) (built: Jun 20 2014 10:47:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
root@arduino:~# php-cli -v
PHP 5.4.5 (cli) (built: Jun 20 2014 10:47:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
idem for Curl, I can CURL the URL manualy. But it's not launced via rc.local/
What do you mean with redundant loading ?
Pipe the output into log file.
/usr/bin/php-cli -v >/mnt/sda1/phpcli.log
Check log file time stamp after reboot.
ls -al /mnt/sda1/phpcli.log
allairgoo:
What do you mean with redundant loading ?
I guess you're talking to me in reference to this?
ShapeShifter:
I'm concerned about this part:I'm a little surprised at loading the sketch on each boot, but do you really want to append another copy of the bootloader to the sketch each time that the unit boots? You're going to end up with a lot of redundant data in the file, and will be trying to program the same regions over and over during one boot session.I would think you would want to do the bootloader merging only once, probably when the hex file is created or copied into place (however it is that the hex file comes into being on your system.)
Every time you run /usr/bin/merge-sketch-with-bootloader.lua /www/sd/sketch/sk.cpp.hex, you are taking the hex file, deleting the last line (trailer record) and appending the bootloader image (which includes it's own trailer record) then writing it back out to the original file. Run it once, and you get a file that has your sketch and the bootloader, and is ready to program into the processor. Run it a second time, and you get a file with the sketch and TWO copies of the bootloader. Do it every time you boot, and before long you have a file with your sketch and a hundred copies of the bootloader. That's what I mean about redundant.
I question whether you should really be programming the ATMega32U4 processor on every boot, but I really question the wisdom of appending the bootloader on every boot. It seems like a really bad idea to me.
I would add some conditional logic to see if the sketch .hex file changed since the last boot, and only add the bootloader and program the file if it had. For example, calculate a hash code or checksum of the file and compare it to a stored value, or just compare the modification date to a stored value. The stored value would be in a separate file on the disk, and if different from the value from the current file, the sketch file would be processed, uploaded, and the stored value file updated with the new hash/checksum/date (which is calculated after the file has been updated with the bootloader.)
ShapeShifter:
I guess you're talking to me in reference to this?(..)
I question whether you should really be programming the ATMega32U4 processor on every boot, but I really question the wisdom of appending the bootloader on every boot. It seems like a really bad idea to me.
I did this because when my Yun is OFF for one or 2 hours, if I switch it on the sketch is no longer active (REST commands unactive etc..) . It's possible I made it wrong.
sonnyyu:
Pipe the output into log file.Check log file time stamp after reboot.
results : new file created.
contents :
cat phpcli.log
PHP 5.4.5 (cli) (built: Jun 20 2014 10:47:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
allairgoo:
I did this because when my Yun is OFF for one or 2 hours, if I switch it on the sketch is no longer active (REST commands unactive etc..) . It's possible I made it wrong.
Yes, you almost certainly do have something wrong in your sketch. You should be able to load the sketch once, and it will run every time that power is applied. Reprogramming the sketch every time you boot is NOT the proper fix.
Perhaps posting your sketch (inside of code tags for readability) would give you some advice on what might be going wrong. Maybe that should start a new thread for that? But first, do you have something that looks like
while (!Serial)
in your setup function? That is something that appears in several examples, and many people copy that into their sketch without realizing that it will freeze the sketch until a serial port is attached. Maybe the times that it doesn't start up for you are the times you don't have the USB port connected and open?
Of course, since the REST API requires the use of the Linux services, is it possible that you're just not waiting long enough for Linux to fully boot (takes a minute or two) before trying to send the REST commands?
ShapeShifter:
But first, do you have something that looks likewhile (!Serial)in your setup function?
Of course, since the REST API requires the use of the Linux services, is it possible that you're just not waiting long enough for Linux to fully boot (takes a minute or two) before trying to send the REST commands?
No serial , or other things like that , and I have waited more than 10 minutes sometimes after reboot without . So i decided to put it via rc.local
to work perfectly : is there a way to have no cumul of bootloader ?
allairgoo:
to work perfectly : is there a way to have no cumul of bootloader ?
Just don't do the merge with bootloader command in rc.local. Do that command manually whenever you copy a new .hex file to the SD card.
But you really should try and figure out why your sketch is hanging or crashing (the two most likely reasons why it doesn't run sometimes.) There is something wrong and you are only masking the problem. It's a pretty safe bet that the problem is not the '32U4 "forgetting" the sketch, it's MUCH more likely that the sketch is starting up and something is going wrong to make it not respond sometimes. What will you do when the problem manifests itself differentially and reloading the code no longer helps?
My guess it's not the reloading of the processor that is making things work, but rather the resetting of the processor after the reload. Rather than hitting the processor with a sledgehammer each time, you might try just giving it a gentle nudge: instead of you reload code, try just putting "reset-mcu" in rc.local. That will reset the '32U4 once Linux has finished booting. If that works, maybe there is something in the way your sketch starts up that doesn't gracefully handle the longer delay needed for Linux to boot?
An even simpler test is to do nothing in rc.local, and when the sketch doesn't start up properly after a power up, just hit the 32U4 RST button that is next to the Ethernet port. If that brings the sketch to life it proves that the sketch is still there and it's not an issue with the sketch being "forgotten."
I still think you should post your sketch, someone may see a reason for your inconsistent running issues.
ShapeShifter:
try just putting "reset-mcu" in rc.local. That will reset the '32U4 once Linux has finished booting. If that works, maybe there is something in the way your sketch starts up that doesn't gracefully handle the longer delay needed for Linux to boot?An even simpler test is to do nothing in rc.local, and when the sketch doesn't start up properly after a power up, just hit the 32U4 RST button that is next to the Ethernet port. If that brings the sketch to life it proves that the sketch is still there and it's not an issue with the sketch being "forgotten."
I still think you should post your sketch, someone may see a reason for your inconsistent running issues.
i try right now with reset-mcu
unplug the 5v alimentation.
wait 2 minutes
sketch is working.
I will try this : automatic uploading of hex file from micro sd card at power up on Arduino Yun - Arduino Yún - Arduino Forum
allairgoo:
I will try this : automatic uploading of hex file from micro sd card at power up on Arduino Yun - Arduino Yún - Arduino Forum
@allairgoo,
you go multiple issues. Can you recap which are solved and which are still on going?
TIA
Jesse
jessemonroy650:
which are solved and which are still on going?
Thanks.
now:
my rc.local does nothing with the sktech : closed.
my rc.local is executing the scripts, php (notify my iphone) etc..closed
So if i want to re-upload the sketch via command line , the only command to use is, suppposing the .hex file is correct and not corrupted :
/usr/bin/run-avrdude /www/sd/sketch/sk.cpp.hex
allairgoo:
So if i want to re-upload the sketch via command line , the only command to use is, suppposing the .hex file is correct and not corrupted :/usr/bin/run-avrdude /www/sd/sketch/sk.cpp.hex
... AND assuming that the merge with bootloader command has already been done once on the .hex file.
If you never merged the bootloader to the sketch, then you will not be able to upload sketches using the USB port until such time that you have used the Linux command (or the web interface, or the IDE using the network) to load a .hex file that has been merged with the bootloader.
Thank you for this précision, in fact I never tried to program the arduino via USB.
I just want to make you aware of it. 8) Otherwise, if you do someday try to program from USB, you'll be back with a question about why it doesn't work. 