New optiboot; beta testers welcome...

I'm guessing that the "internal copies" of the bootloaders are chosen from somewhere, when compiling the OptiLoader sketch and uploading it onto the Arduino programmer.

The internal copies are chosen at the time the SOURCE is prepared (manually, by me (in the case of the official version.)) You don't need to have bootloader hex files anywhere else on your computer to use optiLoader.
And yes, the included hex files are 4.4 and should be the same as the "new" Unos have.

You can actually look at this in the optiLoader sketch, though it's a bit obscure. At the end are a bunch of data structures containing the hex files, that look like:

image_t PROGMEM image_328p = {
  {    "optiboot_atmega328.hex" }  ,
  {    "atmega328P" }  ,
  0x950F, /* Signature bytes for 328P */
  {    0x3F,0xFF,0xDE,0x05,0 }  ,
  {    0x2F,0,0,0,0 }  ,
  128,
  {
    ":107E0000112484B714BE81FFF0D085E080938100F7\n"
      ":107E100082E08093C00088E18093C10086E0809377\n"
      ":107E2000C20080E18093C4008EE0C9D0259A86E02C\n"
 //          ----------->=% snip ================
      ":107FE0001150E9F7F2DF1F91089580E0E8DFEE27F6\n"
      ":047FF000FF270994CA\n"
      ":027FFE00040479\n"
      ":0400000300007E007B\n"
      ":00000001FF\n"
  }
};

That line near the end that starts with ":02" is the version number. It breaks down to:

  len  addr type minVer majVer cksum
  :02  7FFE  00    04     04    79

It makes perfect sense, thanks for the explanation. I'll try this at my next opportunity!

Interesting... tried to compile optiLoader with both Arduino v0022 and Arduino 1.0, but get the following compilation error:

In file included from optiLoader.cpp:85:0:
optiLoader.h:25:24: error: variable 'image_328' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.h:25:35: error: variable 'image_328p' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.h:25:47: error: variable 'image_168' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.h:25:58: error: variable 'image_8' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.cpp:688:17: error: variable 'image_328' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.cpp:742:17: error: variable 'image_328p' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.cpp:796:17: error: variable 'image_168' must be const in order to be put into read-only section by means of 'attribute((progmem))'
optiLoader.cpp:850:17: error: variable 'image_8' must be const in order to be put into read-only section by means of 'attribute((progmem))'

Could this be a compiler issue? I'm running Fedora 16...

[daly@R0b0ty ~]$ avr-g++ --version
avr-g++ (Fedora 4.6.2-1.fc16) 4.6.2

[daly@R0b0ty ~]$ gcc --version
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)

How would I get around this?

Yes. In newer compilers, PROGMEM handling is changed significantly. And linux installs the compiler separately from the Arduino IDE, so which version you have is pretty random.

I'll take a look and see if I can come up with changes that work for multiple compiler versions...

Well I had been having problems with this but decided to build a new board with RTC too. Anyway the new board works perfectly first time

Using maniac bugs folder it uploads the boot loader from the Arduino IDE which was a surprise. Anyway thumbs up all round. It's now working perfectly

westfw:
Yes. In newer compilers, PROGMEM handling is changed significantly. And linux installs the compiler separately from the Arduino IDE, so which version you have is pretty random.

I'll take a look and see if I can come up with changes that work for multiple compiler versions...

Yup, 4.6 changed the handling of progmem significantly, and all for the better. It's easy to make the changes, and they still work with older toolset versions. Basically, we have to stop using prog_types and make all progmem variables const (which they should have been already).

And 4.7 is adding compiler-level support for progmem regions, I think?
(but going between 4.3 and 4.6, we probably only have to add the "const" in appropriate places.)

westfw:
And 4.7 is adding compiler-level support for progmem regions, I think?

Yup. They're awesome. But I'd argue they're irrelevant for Optiboot, until Arduino upgrades to 4.7. Because the new named regions aren't backward compatible, so code that uses them REQUIRES >=4.7.0.

westfw:
(but going between 4.3 and 4.6, we probably only have to add the "const" in appropriate places.)

Also have to remove the now-deprecated prog_char type and other prog_ types.

I still even have trouble for my IDE (both 22 and 1.0) to recognize the optiboot board. According to the instructions i do this:
To install into the Arduino software
1.Download the latest Optiboot zip file and extract it.
2.You will need to be using a recent version of the Arduino environment, version 18 or later.
3.Create a 'hardware' directory inside your sketches folder.
4.Copy the optiboot directory into the hardware directory.
5.Restart the Arduino software. New boards will appear in the Tools > Board menu.

But there are no new boards in the Tools > Board menu
Now I have done this for other boards and it always worked. If I look at the 'Optiboot' folder in my hardware folder, its structure is completely different from the ones that do work. Other folder (e.g. Attiny85) have a 'boards.txt' file in their folder and a folder called 'cores'. That folder then has a subfolder called Attiny85 again and only that folder then has all sorts of 'h', 'c' etc files in it. So not the optiboot folder: no 'boards.txt' no cores folder, it just has all of its files (boot.h, makeall, makebat, pin_def etc directly in that one folder.

So, Am I forgetting something? Is there anything in the 5 line instructions that was too difficult for me to understand?

Yes, I did close and restart the IDE.
Anybody a solution as it seems to work for all you guys and calls.
Tnx

Dear Pro's,

to get rid of all that external issues with getting the basement work....IDE a.s.o.

would you please add an AVR Studio .elf Production Bundle... for testing also please.
(very easy for somebody who knows the settings)

So, the Betatesting of the Optiboot would be more comfortable... because we have to test the bootloader, not the ide config :slight_smile:

Maybe, a Noob Dif .zip ala "extract this to the Arduino Rootfolder " would be helpfull as already mentioned...

Please add an verified .elf ...

Thank you very much!!!

ChrisS

(Would be great, in my case got an HV Programmer here, which i can't get work with Arduino Bootloader burning via IDE.
No Info on some Parameters like BOOTSZ, ... can't find LD_Section... )

I was aiming at setting up a parallel port to program a atmega8535 using avrdude.

Could that be integrated in this setup?

Has optiboot been tested on that chip?

thx.

Neither the Arduino environment nor optiboot currently support the 8535.

Is that a complicated porting project or just a case of digging the doc and setting up a few parameters?

Is there a guide to adapting optiboot to other chips in the family?

thx

It shouldn't be too complicated if the chip has the usual features. 8535 is pretty old.
There's no guide, but it's not very much code. Getting the fuses and code addresses and such right is probably harder than the code modifications.

Apologies first, if this doesn't belong here.

I have started a separate thread on my issues trying to get optiboot run on Attiny84. Arduino Forum
I have come to a dead end, although Luminet (Attiny84 based) is said to work, I couldn't get results. If someone has walked that path, please advice on any tricks that need to be pulled down the sleeve.

Thanks

I have found a bug in Optiboots software UART.
Basically, when compiled the inline assembler for getch() does something rather weird. Both the recieved char (what is returned to the variable ch) and the bit count (how many bits to recieve) both end up using the same register which means it doesn't correctly recieve chars, and in some cases it gets stuck in an infinite loop.

Here is my solution:

#ifdef SOFT_UART
  __asm__ __volatile__ (
    "1: sbic  %[uartPin],%[uartBit]\n"  // Wait for start edge
    "   rjmp  1b\n"
    "   rcall uartDelay\n"          // Get to middle of start bit
    "2: rcall uartDelay\n"              // Wait 1 bit period
    "   rcall uartDelay\n"              // Wait 1 bit period
    "   clc\n"
    "   sbic  %[uartPin],%[uartBit]\n"
    "   sec\n"                          
    "   dec   %[bitCnt]\n"
    "   breq  3f\n"
    "   ror   %[ch]\n"
    "   rjmp  2b\n"
    "3:\n"
    :
      [ch] "=r" (ch)
    :
      "d" (0), 
      [bitCnt] "d" (9),
      [uartPin] "I" (_SFR_IO_ADDR(UART_PIN)),
      [uartBit] "I" (UART_RX_BIT)
    :
      "r25"
  );
#else

Also, the TX pin should idle high, but it does not get set as such when it is set to being an output. The fix:

#ifdef SOFT_UART
  /* Set TX pin as output */
  UART_DDR |= _BV(UART_TX_BIT);
  UART_PORT |= _BV(UART_TX_BIT); //set high!
#endif

Thanks Tom!
Based on your hints I've just added support for ATtiny85 to optiboot.
As there is no hardware bootloader in ATtiny85, the code exceeds 512 bytes due to virtual boot partition implementation.
Bootloader seems to work well even with the factory calibrated RC oscillator. Still, one might need to adjust the OSCCAL register when the communication speed error exceeds some limits.

code.google.com/r/trnape-optiboot/source/detail?r=477b2646cc6a7cc19350bf67b50a1c5ce6c2649a#

I have a working version of optiboot as well for both tiny85's and tiny84's. As you say it does require the oscillator to be tuned, so I am currently working on including tinyTuner in the bootloader when you first burn it which will then callibrate the oscillator and store the calibrated value in program memory and apply it each time it loads.

My version of optiboot for the tiny's is 576 bytes, which is a bit smaller than the stock version as I made several other enhancements to make optiboot smaller - using unions in some places for example.

Once I have got the TinyTuner code added (it wont increase the size of the bootloader as it will be overwritten when you download the first sketch) I will release my bootloader, along with a partly rewritten Tiny core I am working on.

Just so you know, the OSCCAL value is not like the fuses; it is not sticky. The value is always set to the factory default on reset. You will have to store the value in EEPROM or Flash and then, ideally, transfer it to OSCCAL at the start of the bootloader.

In my case, I store the tuned value at the end of EEPROM (E2END) with some other configuration data and bracketed by guard bytes.

I have almost completed a bootloader which when you burn it includes TinyTuner. At the end of tinyTuner running, it saves the tuned value into the program memory as part of the bootloader, along with another byte which tells the bootloader to not run the tuning process again. Once tuned, the bootloader is unlocked and the tuning code is erased. From then on in, the OSCCAL value is set from the value stored in program memory.
I have got everything working apart from after the first program is downloaded using the bootloader it nothing works anymore and I haven't yet figured out why.
EDIT:
I know why it doesn't work, I am just trying to figure out how to make the compiler put a function in a specific place.
EDIT2:
Got it working! I now have a self rewriting bootloader which has tiny tuner build in, but takes up no more space than it did before.
(ATTinyCore/tiny/bootloaders/optiboot at master · TCWORLD/ATTinyCore · GitHub)