Wonder if the startup delay could be made zero maybe by looking at a pin on startup or how long the reset button is held. I guess the mode would have to stored in a byte of eeprom for subsequent power ups. Wouldn't this pretty much allow the boot loader to be used always instead of a programmer to load code. I am using a mini with about 10sec delay.
For the next version could the prefs include a font menu. The current font is very unfriendly for the eyeballs.
What? :-/
The latest bootloader already does not have a significant delay, and I guess the only way to totally eliminate such delay is to go barebone and not use bootloader at all 
Like Senso, I am not sure that I have understood leofls.
But, it is feasible to have the bootloader look for something to shorten the bootloader delay. My question is what?
If it is EEPROM, then existing programs which use EEPROM might break.
It can't be the Reset button as that is a physical piece of hardware that forces the microcontroller to reset and not run any code.
If it were a different button, then an I/O pin would be lost (and I run out of pins already).
So, leolfs, if you want a shorter bootloader delay, you could blow a new bootloader into your chip, and that would work. I believe Ladyada has a quick-boot bootloader, so you could start there.
But I can't think of any other hardware way you could do it without changing the board design, is a way which some folks (including me) might regard as a dis-improvement.
You might try to change the bootloader, so that it has a short delay, and maybe change avrdude (the upload program) so that it can force a reset back into the bootloader? All this stuff is Open Source, so you could do it.
[edit]What is the use case you are looking to fix?[/edit]
HTH
GB
Could you change the bootloader to look for some kind of header or footer byte sequence in the hex file (that could be appended or pre-pended to the file in the build process)? Unless I misunderstand where this delay occurs...
Could you change the bootloader to look for some kind of header or footer byte sequence in the hex file (that could be appended or pre-pended to the file in the build process)? Unless I misunderstand where this delay occurs...
No, the delay is well before that. It's to see if there is any valid activity on the serial receive line at all right after a power-up or reset. If there is and it's a proper signal, then the bootloader stays active servicing valid commands from AVRDUDE via the IDE connection. If there is no serial data activity after the delay period times out, then the bootloader jumps to the existing sketch already resident in memory.
I've noticed that lots of development boards use a simple switch or removable jumper to activate the bootloader or not on power-up or reset. While it does take up a digital input pin, it does eliminate a delay on programs starting.
Lefty
lots of development boards use a simple switch or removable jumper to activate the bootloader or not on power-up or reset. While it does take up a digital input pin, it does eliminate a delay on programs starting.
I'd really rather not use a pin, for the following reasons:
- I have two project which use 18 I/O's
- There are very few choices of pin which aren't a disaster.
Shouldn't be:
- pin 0 or 1, USB to serial connection
- SPI as they are used to blow firmware (pins 10, 11, 12, 13)
- ADC as they are too precious (and two are I2C)
- PWM as they are too precious, (3, 5, 6, 9, 10, 11)
- digital pin 8 on Timer1 (16 bit), that is timed input capture
- pin 2 (or 3) change-pin direct interrupts (their own ISR's)
- pin 6 & 7 are the analogue comparator pins AIN0 & AIN1
- pin 4 is PD4 XCK (USART External Clock I/O, i.e. uSrt)) & T0
(that's all of them, I think)
Losing these pin uses would reduce the value to me as a prototyping and physical computing platform - Arduino is so flexible its wonderful.
- All the pins go to shields which may use any pin permutation, so someone needs to worry about them
The biggest obstacle for me, is I haven't understood the Use Case. Without a clear need, I'd be worried to make any changes to a part of the interface that is so concrete and physical.
So, I'd like to understand the need.
A simple solution does exist; program the flash with a different bootloader. Ladyada does that, and it seems a robust, simple solution.
To facilitate that, I'd prefer to have the unused pins on the FTDI (USB to serial) wired up to a more convenient header so that it can be used in "bit-banging" mode to reprogram the Arduino, then folks who want a different bootloader can flash a new bootloader with minimal extra cost.
I'd like the unused FTDI header pins to have ground and +V in an 2x3 arrangement so a simple 6-pin to 6pin header is all that is needed to reprogram the board. It will cost a redesign of the PCB, but I think at least one attempt already exists by Solarbotics. (My only reservation is the pin layout is not a 2x3 match to ICSP header for an easy cable connection)
[edit]I did say I'd like the FTDI header to not need to be cleared of solder but I think that doesn't matter, and it protects the pads, and is probably easy to do, so cover them in solder![/edit]
That might satisfy use cases of people who want to reprogram the bootloader, or the whole board, without extra cost, or external hardware. It doesn't change the Arduino's more significant (IMHO) physical interface.
(It would satisfy my use case in that area when the functionality is in avrdude and the Arduino IDE :))
HTH
GB
leofs PMed me about my toastedBoot bootloader Google Code Archive - Long-term storage for Google Code Project Hosting. which is basically adaboot++. I mostly put it up on google code because there was no other home for modded bootloaders -- they were just zip files on people's web sites, which made it hard to find the "latest".
One adaboot feature is that it goes direct to the sketch on powerup and only waits listening to the serial on reset. That seemed to satisfy him which may be why we haven't heard anything more.
BTW, features I added to adaboot are:
-
if you double click the reset button, it waits a LOOONG time for a serial. This is very useful when your board is far away from the computer and you don't have the auto-reset feature (i.e. using a FTDI cable). Originally, I had it set up the opposite -- it would wait a long time by default, a double click would drop direct to the sketch. Unfortunately, the auto-reset feature of the standard Arduino actually resets the board more than once so I swapped it so toastedBoot would work on boards that support autoreset. But if you are using a clone you may prefer this other double-click behavior.
-
The pin 13 led fades in and out while the board is waiting for a sketch. This way you know it hasn't hung somewhere.
-
Code crunching -- I reworked the code a lot to make it smaller so that new features could be added in the same flash space.
On a slightly different topic:
I think that it would be possible to write a sketch that updated the bootloader. I mean why not? Its just writing to flash. The problem with this idea is that if the sketch was interrupted mid-write your board would be bricked -- you'd have to buy a $20 ICSP to recover it. So maybe its not worth the support calls it would generate. What do you think?
- if you double click the reset button, it waits a LOOONG time for a serial.
That's an interesting idea, how does it work? What survives a reset?
I think that it would be possible to write a sketch that updated the bootloader. I mean why not? Its just writing to flash. The problem with this idea is that if the sketch was interrupted mid-write your board would be bricked -- you'd have to buy a $20 ICSP to recover it. So maybe its not worth the support calls it would generate. What do you think?
A few things:
0. I think all techniques that reflash the bootloader brick the chip if the power fails at a bad point in time.
- Could you reduce the period of time when the system is vulnerable to power failure by downloading the bootloader (e.g. into RAM/EEPROM), and then blowing as quickly as practical from an on-chip copy?
A sketch to update the bootloader might be useful for leolfs use case (but I didn't understand it, so I may be wrong).
My favourite approach to flashing a chip is the FTDI bit-banging programmer "Burning the Bootloader without external AVR-Writer" which shows a technique for using the unused FTDI pins to program the ATmega.
If boards implemented that in an easy-to-connect way, and avrdude and the Arduino IDE supported it, then it would always be practical to recover a bricked-chip for minimal cost (a cable).
I assume we'll get Arduino/Freeduino boards like the Freeduino SB which implement an AVR programmer using only the FTDI chip. It makes perfect sense. Then reprogramming the bootloder may become a more natural activity.
A reflash-the-bootloader-sketch might be useful and good fun while we wait for everyone to make boards that way.
If your bootloader is very small, can you also include an ICSP programmer in the bootloader, so that one Arduino can program another? (like MegaISP and ArduinoISP but in the bootloader)
Then all anyone needs to bootstrap a new AVR-based board (including an Arduino) is an Arduino 
GB