Do you know where your boot_page_erase_short() is?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

__boot_page_erase_short()

I can't find its definition in boot.h. And there are plenty of versions of boot.h in Arduino's directory tree.

I find others with similar names but not the _short version. I have a guess of how "short" differs from "normal", but frustrated I can't find the needle in the haystack.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I Google that I get only two hits, this thread and also this page:

https://github.com/jimgallt/Arduino-bootloaders/blob/master/optiboot-jim...

See line 180 so it's something specific to the Optiboot bootloader. Maybe PM westfw about it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks... I'm giving optiboot a sorely needed house cleaning and face lift. The code has been hacked so much it's like a hoarder's house. I'm done with this remake and ready to test. Also adding wireless over the air programming of the AVR, adapted from work done by Moteino, but now targeting the Anardino mini-wireless boards. And fit in 1KB whereas it had grown to be 110% of 1KB, aka 2KB of boot segment space.

that __boot_page_erase_short() still eludes me. I will ask some prior authors. My guess is that the _short for it (and the same for its cousins for read/write) - may have to do with using memory mapped I/O rather than IN/OUT. Not sure. This is some macros hiding somewhere.

I may have to use grep on windows 7. Oh my.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I say westfw is the current maintainer of Optiboot, he's bound to know about that Asm macro.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am looking at [url=https://code.google.com/p/optiboot/downloads/detail?name=optiboot-v5.0a.... 5.0A[/url] and in bootloaders\optiboot\boot.h I find

#define __boot_page_erase_short(address)        \
(__extension__({ \
__asm__ __volatile__ \
( \
"out %0, %1\n\t" \
"spm\n\t" \
: \
: "i" (_SFR_IO_ADDR(__SPM_REG)), \
"r" ((uint8_t)__BOOT_PAGE_ERASE), \
"z" ((uint16_t)address) \
); \
}))

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah that's pretty much the same as line 180 I linked to above. I think the question here is what is the implication of the word "short" in the name here? Is it simply that it's only two opcodes? Or something about it being 16bit addressing?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know, Cliff.

But the title of the thread is "Do you know where __boot_page_erase_short is?". And in hist post recent post

stevech wrote:
This is some macros hiding somewhere.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there's a "_short" macro too for read and write.
Mystery.
People who wrote, added-to optiboot went to a school where there were demerits for commenting code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find the ways this thread takes very confusing.

First thing to clear up: Can we assume that you now find the definition of __boot_page_erase_short() in boot.h? (E.g.: Are we looking at the same code?)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan, you are confusing things. The Asm macro is NOT in boot.h, it's private to Optiboot.

I will say again for the 3rd and last time: contact westfw, he is the current maintainer of Optiboot.

Actually, tell you what, I'll PM him about this thread.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry; I was out of town picking up my daughter from college.

optiboot has its own copy of boot.h (in the same directory as optiboot.c), under the theory that this will save enough space to make it worthwhile. There's a comment at the top of the file:

Quote:
**
** "_short" routines execute 1 cycle faster and use 1 less word of flash
** by using "out" instruction instead of "sts".

This pre-dates my involvement. Even if it's a good idea overall, I think using the same filename as the avr-libc boot.h is a bad idea, exactly because of this sort of confusion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Johan, you are confusing things. The Asm macro is NOT in boot.h, it's private to Optiboot.

From my vista:

I'm just getting more confused. I find the macro in a header file named exactly boot.h . This is a header file in the Optiboot repo that I was looking in. I am not talking ablut the boot.h in avrlibc (although the Optiboot file seems to be a rework of the one from avrlibc. Follow my link above to actually see what file I am talking about, and to see the sought for macro.

So... When I say "optiboot" I am referring to this: https://code.google.com/p/optiboot/ . One of the members is wes@gmail.com, and I assume that is westfw. The last change there seems to be this June 2013.

You are looking at Github and a repo for "Arduino-bootloaders". The last update of the file you are linking to is May 31, 2011. The last activity overall there seems to be in June 2011.

Also, the source trees are very different in those two repos. I speculate that it is the one with the most recent changes, and that has "Optiboot" in it's name that is the Optiboot repo.

I still don't understand if Steve currently has a problem finding the macro, or if he has a problem interpreting it. Or what..?

And if I am still confusing things, then I'd like to know the details of what you are seeing that I am missing. :D

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry. As westfw says:

Quote:

I think using the same filename as the avr-libc boot.h is a bad idea, exactly because of this sort of confusion.

I read your "boot.h" as the one in AVR-LibC. Because I was looking at it in a Git viewer I didn't even realise the Optiboot people had been stupid enough to copy a system header and keep the same name. :oops:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The code has been hacked so much it's like a hoarder's house.

Sniff. I'll have to admit that adding features reduces the clarity of the code, especially since in such minimally-sized programs, it tends to result in a lot of compile-time conditionals. :-(
(and it's not like you can get away with actually removing any code, even if you don't know whether it has ever worked. Sigh.)

Quote:
Also adding wireless over the air programming of the AVR, adapted from work done by Moteino, but now targeting the Anardino mini-wireless boards. And fit in 1KB whereas it had grown to be 110% of 1KB

Does your new version still fit in 512 bytes without the wireless code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
The code has been hacked so much it's like a hoarder's house.

Sniff. I'll have to admit that adding features reduces the clarity of the code, especially since in such minimally-sized programs, it tends to result in a lot of compile-time conditionals. :-(
(and it's not like you can get away with actually removing any code, even if you don't know whether it has ever worked. Sigh.)

Quote:
Also adding wireless over the air programming of the AVR, adapted from work done by Moteino, but now targeting the Anardino mini-wireless boards. And fit in 1KB whereas it had grown to be 110% of 1KB

Does your new version still fit in 512 bytes without the wireless code?

That code works but a lot of people have stuck in patches and code that kind of messes up the original! So I did a face lift then adding the unattended self-reprogramming of new AVR code that comes in wirelessly, then stored in an ext. flash, then it reboots and the additions to the loader install the new AVR code in program memory. So the bootloader sees the new code in the flash chip and installs it. A library included in the user's application does the actual wireless download of new code and stores in in the flash then reboots to install it via the bootloader.

My case at hand is using the HopeRF RFMxx radios, either 433MHz or 915MHz (No. America), or 868MHz, and RadioHead's (RH)protocol stack. One could use cellular or WiFi or Bluetooth just as well.

The RH stack has options for wireless topologies: star, static routes, and meshing, with reliable datagrams (error detection/correction). I'm adding this code download as an application, outside the protocol stack itself so that RadioHead proceeds to evolve without a fork'd special for this wireless firmware updater.

Yes, it fits in 512 bytes though I haven't run it. The version for the wireless download fits in 1KB, about 970 bytes now. The wireless download isn't really wireless - the bootloader writes the AVR's program memory using an image stored in an external flash chip (a $0.50 chip with about 16MB, not an SD card). The amazingly low cost Anarduino miniwireless card has a mega328P/16MHz, flash chip for both user data logging and programming image storage, plus a clock chip and FTDI chip for serial.

Again, the user app, with a library for the radios above and RH, downloads the new AVR code and writes to the ext. flash chip for the bootloader to use to reprogram the AVR, instead of code coming from the serial port. And this is remote/unattended, as the wireless boards might be in a hard to access place as in HVAC or security or some such, and may be using the RH mesh protocol (multi-hop).

Happy to collaborate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah; so you're working with https://github.com/LowPowerLab/DualOptiboot as well? The people making "Wildfire" (http://shop.wickeddevice.com/product/wildfire/ ) are interested in adding that "boot from external serial memory" capability...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Ah; so you're working with https://github.com/LowPowerLab/D... as well? The people making "Wildfire" (http://shop.wickeddevice.com/pro... ) are interested in adding that "boot from external serial memory" capability...

I'm not directly collaborating with LowPowerLab (Felix), but indirectly yes. The Anarduino miniwireless board is what I'm working with right now. It is similar to LowPowerWireless functionally but is mass produced and amazingly priced. The approach is to adapt and use RadioHead so the remote programming method isn't radio dependent and do the error correction in the protocol stack, not at the application level. And use a different approach to storage management in the external flash chip, to include a CRC16, and optional encryption of the transmission that may pass over the Internet then over short range wireless such as the 433/868/915MHz modules (100's meters). The PC/Linux/MAC host that triggers the updates will use an app that will work on PC/MAC/Linux.