Updating the mighty-1284p core

Because it looks purty when you upload a sketch/burn a bootloader using ICSP.

Which is the only time I want to see a bootloader flashing my LED!

[quote author=Jack Christensen link=topic=235521.msg1725261#msg1725261 date=1400202983]
I'm not following ">128k". The MCU has 128kB, period. The bootloader comes out of that and so reduces the memory available for the user's code. I don't see an advantage to a 300 byte bootloader over a 500 byte bootloader.[/quote]

sorry for not making it clear that i started with m128 bootloader and trimmed down to make room for >128 feature on m2560. that was from another recent thread. they all end up about 512bytes. actually 1024 with optional debug monitor, bios, and other stuff that gets overwritten by big user programs. only the 512byte boot code is protected. i would like to start with as small an image as possible to add hooks and other gimmicks that need to be more permanent. anyway if you could crank out a no-led 57kbaid opti regardless of size it would be appreciated.

btw regarding led, it serves no purpose for a bootloader but is VERY helpful for diagnostics and applications. however i would love to find the moron who decided to hook it to ground. huge headaches there. so much so that i go to the trouble of rewiring to vcc on most of my pro-minis.

pico:
So remind me again why it is important, or even desirable, to have a bootloader flash a LED?

Awww heck I dunno, it's small potatoes I guess. I do like having the LED on board, a minimal bit of I/O, erm, well just /O rather. As for the bootloader flashing it, it's mildly useful as feedback or maybe more when I pull a chip out of the bin that's been there a couple months and can't remember whether it has a bootloader :wink:

I don't want no steenkin' bootloader flashing my LEDs!!!
(I actually tried to upload that statement to a Mega once, but it failed.)

Haha! Of course!

This place is getting like Burger King, bootloader, have it your way!

What difference does it make, since the hardware has to allocate 512 bytes for the bootloader?

Minimum bootloader size on a 1284 is actually 1k...

I'm relatively against adding additional .hex files to the optiboot repository, because they really obscure the change history (minor changes in source code change every line of a .hex file.) The Arduino/platform distribution can make different decisions, of course.
(Also, note that the 1.5.x directory structure breaks the "use the arduino compiler" feature of the optiboot Makefile :frowning: )

westfw:
(Also, note that the 1.5.x directory structure breaks the "use the arduino compiler" feature of the optiboot Makefile :frowning: )

I noticed that. It will probably be a while before I take another run at it but if I get it working I'll let you know.

I'm relatively against adding additional .hex files to the optiboot repository...

Given how easy it is to build what you want that certainly seems like a good idea.

For what it's worth, I believe a no-LED, 16 MHz, UART0, 115200 baud bootloader covers the majority of the m1284 boards.

Thank you for adding support for 1 M baud!

I'm completely with you on this.

+1. Thanks to westfw for all your outstanding contributions generally!

westfw:

What difference does it make, since the hardware has to allocate 512 bytes for the bootloader?

Minimum bootloader size on a 1284 is actually 1k...

I had the wrong table earlier (there is no 256b option) but I think I have the right one now for the 1284/P (26.8.17) the options are 512/1k/2k/4k ?

Yes:
BOOTSZ1 BOOTSZ0 Boot size Pages Boot reset Adress
1 1 512 words 4 0x0000 0xFE00
1 0 1024 words 8 0x0000 0xFC00
0 1 2048 words 16 0x0000 0xF800
0 0 4096 words 32 0x0000 0xF000

1K, 2K, 4K, 8K bytes

Ack I missed "words" again :blush: I stand corrected thank you!

except for those who prefer to use internal 8mhz clk where, unlike 57kbaud, 115k fails to provide reliable serial communication. internal clk usage is quite common in the avr world with significant advantages over crystal.

what ends up in the code suppositories isnt that important to me but it would be nice if someone uploaded a 57k no-led hex to one of these threads so i could pass it on to the many students and club members on my end who would benefit greatly.

ps: ignore that last. i just checked the other thread. thanks cb.

pps: yes, i often say bytes when i mean words. and versa visa.

john1993:
what ends up in the code suppositories isnt that important to me but it would be nice if someone uploaded a 57k no-led hex to one of these threads so i could pass it on to the many students and club members on my end who would benefit greatly.

"suppositories".... XD

John, it is very easy to build custom bootloader images.
It only takes a few minutes at most to build an image with the desired
capabilities.

While the feature combination you desire seems reasonable, given there are
are so many different combinations that people are wanting and given
how easy it is to create a custom image,
I think that it is reasonable to expect that students, club members or anyone else that wants to play
with alternate bootloaders should be capable of building their own images.

Plus by building it yourself, you know what you are getting. Vs some of what we are seeing
now where the code doesn't match the actual pre-built image.

--- bill

Bill, thanks so much for pointing this very bad situation out, I was not aware. I wonder how many of these I have lurking in my code that are actually out of range for the SBI and CBI instructions :fearful:

bperrybap:
As an important reminder about AVR direct port i/o,
the gcc compiler kludge that turns these

PORT |= bitmask;

PORT &= ~bitmask;



into atomic AVR SBR/CBR instructions when the port address and bitmask are
known at compile time,
only works if the port register address is within a certain range. (0x00 to 0x1f)
Not all ports in all the AVRs are in this range.
The implication of this is that when using macros that do port i/o like what is in the Ethernet library,
if you pick a pin that is on a port that is not within the special range,
the operation is no longer atomic since the gcc kludge is unable to generate bit SBR/CBR instructions
because the AVR chip does not support it.

This can and will create i/o register corruption if the same port register is being
updated at ISR level.

Sure enough:

        //ATmega328P
        DDRB |= _BV(DDB5);          //DDRB is 0x04
  84:   25 9a           sbi 0x04, 5 ; 4
        PCMSK0 |= _BV(PCINT0);      //PCMSK0 is 0x6B
  86:   80 81           ld  r24, Z
  88:   81 60           ori r24, 0x01   ; 1
  8a:   80 83           st  Z, r24
  8c:   fb cf           rjmp    .-10        ; 0x84 <main+0x4>

John, it is very easy to build custom bootloader images.
It only takes a few minutes at most to build an image with the desired
capabilities.

I went looking in the Playground for a how-to, and did not find it. A few statements are made about building a custom bootloader but a "standard process" is not represented - that I can find.
http://playground.arduino.cc/Main/CustomizeArduinoIDE

Ray

bperrybap:
it is very easy to build custom bootloader images.

its like with the avrdude situation. those who eat, live, and breath compiler find it hard to understand the ones that dont. in this case i was mostly looking for a stable website like arduino to host a simple hex file that others can be referred to. online sources like git, google, savana, etc can be insanely hard to navigate and decrypt for those unfamiliar. some of the guys i deal with dont even know how to unzip. how much better to just click and save.

haha... i see you caught my "suppository" dig. not everybody gets me.

mrburnette:
I went looking in the Playground for a how-to, and did not find it. A few statements are made about building a custom bootloader but a "standard process" is not represented - that I can find.

i also had trouble getting the stuff that comes with ide to work. all kinds of issues with paths and h files. last year somebody, i think it was either bill or bill, sent me a zip of the opti source and it just up an ran. the only think different iirc were a couple of new batch files and i think the rest were the same. if nobody else comes along ill see if i can find it.

part of my problem is i work on many different computers, some of which i dont have the option to install or configure. so its a great help for guys like bill, bill, coding badly, and the others to lend a hand.

Chips like the pic32 don't have this issue since their architecture uses
set/clear registers vs set/clear instructions.
set/clear registers is much better since not only can you use them
with run time data in higher level languages like C
but you can also set/clear multiple bits at time.

--- bill

bperrybap:

[quote author=Jack Christensen link=topic=235521.msg1726126#msg1726126 date=1400256066]
Bill, thanks so much for pointing this very bad situation out, I was not aware. I wonder how many of these I have lurking in my code that are actually out of range for the SBI and CBI instructions :fearful:

Chips like the pic32 don't have this issue since their architecture uses
set/clear registers vs set/clear instructions.
set/clear registers is much better since not only can you use them
with run time data in higher level languages like C
but you can also set/clear multiple bits at time.
[/quote]

I think I found a typo in the 1284P (et al.) datasheet. After the Register Summary table (section 30), Note 3 says:

  1. Some of the status flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on all bits in the I/O register, writing a one back into any flag read as set, thus clearing the flag. The CBI and SBI instructions work with registers 0x00 to 0x1F only.

But this seems to be contradicted in section 8.5:

Some of the Status Flags are cleared by writing a logical one to them. Note that, unlike most
other AVRs, the CBI and SBI instructions will only operate on the specified bit, and can therefore
be used on registers containing such Status Flags. The CBI and SBI instructions work with registers
0x00 to 0x1F only.

I checked the datasheets for a few other AVRs, namely ATmega328P, ATtiny84 and ATtiny85, and they all indicate the instructions operate only on the specified bit. So I wonder which the "most other AVRs" are.

I wonder which the "most other AVRs" are.

Probably everything whose part number starts with "AT90S"...

So where did we get up to with the discussion on whether the patched libraries should be added to the repository?