I have been navigating around other topics to find how i can program my yun and have the sketch run with external power.
I found some things on the FAQ area mentioning that we need an 10k ohms at RX pin to make sure it dont run the bootloader code but the code i want.
This topic looks to be for other arduinos and i would like to confirm if this make sense for Yun.
It it is, I would like to understand better the reasons. What is the RX pin when we power up? Does it make the SW pointer go to my code instead of bootloader? Why the default is bootloader if we can move to the bootloader when load new SW from the arduino sketch interface?
Your sketch will run when it powers up, you shouldn't need to do any modifications that I know of.
Here's my understanding:
Reset or Power up happens
Bootloader looks for something trying to load a program (sketch) for a few seconds, if it sees this it loads the program into flash.
Bootloader exits and runs program in flash (if it didn't load a new one the last one is still in flash)
Various tricks are done to cause a reset on a running Arduino so this can happen by pushing a button in the IDE.
Do remember that the Leonardo part starts up quickly and the Linino part takes about a minute to be up and running after power up.
Be careful with your power supply it needs to be fairly close to 5V, I use a cell phone charger on the micro usb.
Well, then i have some problems on my side.
Pretty strange but the sketch is not starting with no modifications to the board.
I have been powering up by the Atmel USB connector with external USB charger.
Just saw in another post how to reset the mcu from Linino. I did it and then the sketch runs. Something is happening in the boot, because it confirms that the firmware is there since last programming.
Well, I don't understand your desire to bypass the bootloader, it just allows you to upload a sketch when the AVR is reset, if it doesn't receive an upload it runs the sketch that was last uploaded, the practical effect is a delay of a few seconds when powering up.
Try this simple example to see if we are on the same page-
Configure your Yun so you can upload a sketch over the WiFi (You have probably already done this)
Connect your Yun to a power supply like the cell phone charger
Open the Arduino IDE
In the Tools menu, select Board->Arduino Yun
In the Tools menu, select Port-> (Your Yun's Name) at 192.168.xxx.xxx (Arduino Yun)
Load the sketch under Examples->Basics->Blink
In the File menu, select Upload, watch the sketch compile and upload
The red LED should start blinking
Shutdown the Arduino IDE
Remove the power from the Yun, wait until you are satisfied it is shutdown, count to 5, whatever
Connect the Yun to power again, the LED should start blinking again
Does your Yun do this? Isn't this what you are asking for?
Hi, it starts properly on led blinking example boot up with external power.
I have a problem with my sketch, then.
I'll try to see what part of the code is causing the problem and post it back.
This sketch that is giving the problem have some code migrated from other plataform (mbed) and can be something related to the structure.
I was thinking of starting a new thread, but I think my problem is enough related to not be considered a threadjack
My problem is similar to OP in that my sketch run perfectly when uploading, but when starting from power up, it would not run, or rather not run correctly. After a lot of experimentation I discovered that the problem related to running a process executing the shell command "date". For some reason, when running the process 'too early' it return the date '20131020' instead of todays date.
If I insert a delay before Bridge startup, it still does not work correctly, but if I insert a delay after the Bridge startup I can get it to work. I have included my test code snippets below. Here are some results from many test runs:
Delay tries
0 577-623
20 41-63
25 15-31
30 1 (which means it got the correct date on first try)
I have no idea where the date '20131020' comes from, but it might be the first day I turned it on? Any suggestions for how to solve this problem in a cleaner way than a brute force delay?
You have two systems involved, it can be hard to get your mind wrapped around it. It takes my linino around 60 seconds to get up and connected to the WiFi. The time gets set some time after that when NTP syncs up with a server.
A good way to understand what is going on is to use the yunserialterminal sketch to watch the Boot up in the serial monitor. Upload the sketch, start the monitor, push the reset by the LEDs and watch the chatter.
Thanks for the reply.
Yes, I understand how the two systems interact, and I can see the problem. I was really asking if there is a way from the Arduino side to tell when the Linino side is 'ready'. I guess that is is really the NTP piece which is tripping me up, and I did not understand where the dummy date came from. So, while it feels a little kludgy I guess my approach of not accepting a date until is does NOT match the dummy date, is OK.
The problem is somewhat defining what 'ready' is. There is one thread Not able to log startup after cold boot - #3 by noblepepper - Arduino Yún - Arduino Forum that talks about when you can expect sdcards to be available in Linino, which refers to another which talks about when you can start using the bridge without interrupting the boot process of Linino, now we also want to know when the time is valid!
These are all issues that need to be dealt with, it just isn't easy to do outside of waiting for a set period which will inherently be too long if you ensure everything is 'ready'.
Guys... its really strange problem.
I got it working when removed interactions with linino but after some power cycling looks that the atmel code is not there anymore.
Ill need some more testing to identify the behavior.
For now just mentioning what I see so far.
Thanks