1M baud Optiboot for mighty1284p

@CodingBadly mentioned this in the mighty1284p core refresh thread. I was able to make a 1M baud bootloader and it seems to work fine, but it required overriding an error check in the code: I commented out lines 276-278 in optiboot.c just as a quick-and-dirty.

Wondering if this is copacetic or if I'm missing anything. I looked for the change (issue) referenced below on Google Code but couldn't find it.

[quote author=Coding Badly link=topic=235521.msg1705456#msg1705456 date=1399019191]

[quote author=Jack Christensen link=topic=235521.msg1704546#msg1704546 date=1398955025]

That sounds interesting! Is it just a matter of recompiling the bootloader?[/quote]

Almost. There is a deficiency in the source code that forces a compilation error. Two lines overcome the problem. I'm waiting to here back from @westfw about merging the change.[/quote]

Oh man! I wish you had expressed an interest before digging into the source code. I may have been able to save you some time.

When I get to the other computer I'll post the necessary changes (just two lines). The change refines the test instead of eliminating it.

Wondering if this is copacetic or if I'm missing anything. I looked for the change (issue) referenced below on Google Code but couldn't find it.

I'm having trouble getting @westfw's attention so I can ask him how to proceed. (In his defense, I have not been putting forth much effort.)

This is the new section of interest...

#if 0
/* Switch in soft UART for hard baud rates */
/*
 * I don't understand what this was supposed to accomplish, where the
 * constant "280" came from, or why automatically (and perhaps unexpectedly)
 * switching to a soft uart is a good thing, so I'm undoing this in favor
 * of a range check using the same calc used to config the BRG...
 */
#if (F_CPU/BAUD_RATE) > 280 // > 57600 for 16MHz
#ifndef SOFT_UART
#define SOFT_UART
#endif
#endif
#else // 0
#if (F_CPU + BAUD_RATE * 4L) / (BAUD_RATE * 8L) - 1 > 250
#error Unachievable baud rate (too slow) BAUD_RATE 
#endif // baud rate slow check
#if (F_CPU + BAUD_RATE * 4L) / (BAUD_RATE * 8L) - 1 < 3
#if BAUD_ERROR != 0
#error Unachievable baud rate (too fast) BAUD_RATE 
#endif
#endif // baud rate fastn check
#endif

I added this towards the bottom...

#if BAUD_ERROR != 0
...
#endif

Ha, no worries, I didn't put much effort into it, hence the quick-and-dirty. I figured something more intelligent than eliminating the test could be done, but that's where I stopped to ask rather than digging further :blush:

I backed out my comments, put your change in, it worked like a champ! With a 28kB sketch, I see a 29% reduction in upload time vs. 115200 baud. So definitely worth doing. I added a boards.txt entry for my "Mighty Mini" board and I'll push an update with that and the new bootloader later after I review the ReadMe file a bit.

Thanks!

Excellent!

With a 28kB sketch, I see a 29% reduction in upload time vs. 115200 baud. So definitely worth doing.

It should be the same to somewhat faster than ISP. In theory it should be the fastest possible way to upload.

I added a boards.txt entry for my "Mighty Mini" board and I'll push an update with that and the new bootloader later after I review the ReadMe file a bit.

Nice!

Be aware that optiboot, and the protocol is uses, have VERY LITTLE error or sanity checking. If the major "upload" section starts dropping characters, it's not going to recover in any way; it'll just do something weird.

I'm not going with the 1Mb baudrate, I hate the mess and maintenance involved with water cooling the 1284P.

Initial bootload has to be done at a slower speed, yes? And then high is valid after that.

westfw:
Be aware that optiboot, and the protocol is uses, have VERY LITTLE error or sanity checking. If the major "upload" section starts dropping characters, it's not going to recover in any way; it'll just do something weird.

AVRDUDE's verification should (probably) catch this?

CrossRoads:
Initial bootload has to be done at a slower speed, yes? And then high is valid after that.

?? Just burn the 1M bootloader as usual, upload sketches as usual.

retrolefty:
I'm not going with the 1Mb baudrate, I hate the mess and maintenance involved with water cooling the 1284P.

No smoke or steam here yet :wink: Makes sense to me, especially once the sketches start getting larger. (I don't think I've uploaded anything that wouldn't fit on a 328 yet. Well maybe just barely too large.)

PS: If you want to try it, I just pushed an update to GitHub that includes a 1M bootloader, an entry in boards.txt for my "Mighty Mini 1284P" board, and general updates to the README file.

I was just jiven, for sure I'll give it a shot maybe after the ball game on TV. San Francisco Giants, best record in baseball so far. Yea I know it's early. But success is just finishing higher then the L.A. Dodgers, our rivals.

It does.

A few notes...

• I've been using 1 M trouble free for about two years (may be more; I lose track of such things) with my two Unos (and now my Bobuino).

• A failure would occur between the USB-to-serial converter and the processor. In the vast majority of cases this is a very short distance, with high quality "wires", that includes a ground plane.

• For a typical Arduino compatible board 1 M is a zero-error baud rate giving it a distinct advantage over the 3.7% error for 115200.

retrolefty:
I was just jiven, for sure I'll give it a shot maybe after the ball game on TV. San Francisco Giants, best record in baseball so far. Yea I know it's early. But success is just finishing higher then the L.A. Dodgers, our rivals.

Yeah so I figured! How's Lincecum doing this year? I like watching him pitch.

Had 11 Ks last night against Atlanta in a win.

Just tested out the Bobuino @ 1Mbit and it works fine, blink loaded in a ..... wait for it ..... blink.

Excellent, Jack. I'm happy to see the maniacbug 1284 stuff fixed, updated, and available. To me, a 1284 board, in a UNO form factor that can handle all the standard shields, is a killer - of course, I'm a little biased, having been using same in most of my projects for over a year now. But after all, so many libraries eat up a lot of code and RAM space on a 328 chip.

Here's my pet wish, to produce a real killer 1284 system. I've mentioned this before a couple of times in the past year in general, but with no traction :-(.

Since the 1284 bootloader is starting to be hacked, what I'd really like to see is a truly robust version that can be used for RF uploading of sketches using XBees or maybe even RN-XVs. This would entail sending code packets, returning ACKs back to the uploader, waiting a suitable time for the ACKs, and automatically performing re-transmits in case of errors. I imagine avrdude would also need a patch. This should also improve reliability with normal uploading, considering you're already going to higher baudrates as it is.

FWIW, with my system, I find that uploading to 328 boards fails almost 50% of the time, and I have to re-initiate. OTOH, it almost always succeeds on my 1284 boards, so the 1284 is already ahead in the game - for whatever reason.

So, whatdayathink, Jack?

oric_dan:
Here's my pet wish, to produce a real killer 1284 system. I've mentioned this before a couple of times in the past year in general, but with no traction :-(.

Since the 1284 bootloader is starting to be hacked, what I'd really like to see is a truly robust version that can be used for RF uploading of sketches using XBees or maybe even RN-XVs. This would entail sending code packets, returning ACKs back to the uploader, waiting a suitable time for the ACKs, and automatically performing re-transmits in case of errors. I imagine avrdude would also need a patch. This should also improve reliability with normal uploading, considering you're already going to higher baudrates as it is.

FWIW, with my system, I find that uploading to 328 boards fails almost 50% of the time, and I have to re-initiate. OTOH, it almost always succeeds on my 1284 boards, so the 1284 is already ahead in the game - for whatever reason.

So, whatdayathink, Jack?

Well I know that the Pololu Co. claims their Wixel wireless modules can be set up to upload sketches, monitor with PC serial monitor. etc, all wirelessly. Though $50 for the whole kit might be a little on the pricey size to become popular.

Yeah, I've seen that before. I was thinking of something like:

a. a little more open-source Arduino-generic, that would work with more radios in general, BT should also be possible.
b. all in all, a much more robust bootloader and avrdude. I think it's time.

I'm surprised the people who baby avrdude [the avrfreaks, I imagine] haven't recognized the limitations I mentioned.

oric_dan:
Yeah, I've seen that before. I was thinking of something like:

a. a little more open-source Arduino-generic, that would work with more radios in general, BT should also be possible.
b. all in all, a much more robust bootloader and avrdude. I think it's time.

I'm surprised the people who baby avrdude [the avrfreaks, I imagine] haven't recognized the limitations I mentioned.

Yes, Bluetooth interests me also now that my new laptop says it has it built in. However my earlier experimentation with a low cost BT slave module and using a cheap PC BT dongle was never very stable or workable on my old XP machine even trying several different BT drivers along with the default windows one, and not having a good working example to follow, I kind of gave up on that experimenter.

oric_dan:
FWIW, with my system, I find that uploading to 328 boards fails almost 50% of the time, and I have to re-initiate. OTOH, it almost always succeeds on my 1284 boards, so the 1284 is already ahead in the game - for whatever reason.

Are you doing RF uploads now? Is that 50% failure rate for RF uploads?

So, whatdayathink, Jack?

Not sure. I'm aware of the ability to do RF uploads, but that's about it, I've never gotten into it. I wasn't aware that bootloader mods were required, at least for the techniques that I've seen.