Updating the mighty-1284p core

Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]

This seemed to be the best and simplest 'fix' for people having problems with serial data problems on the first uart pins. Problem was sensitive to board layout and there were other hardware fixes that were effective, but simply using the full swing option seems to be the best method and doesn't cost anything and is board agnostic.

Lefty

I'm using Mighty 1284p 16MHz using Optiboot ... the board I designed maps the pins according to the standard variant.

Gents-

I'm not sure it will help, and sorry if this was posted before (I didn't follow any linked threads) but I was doing some searches today and ran across a blog posting that has new core files for the 644P/1284P based on 1.5.6-R2.

The posting was at http://www.leonardomiliani.com/2014/core-per-atmega644p1284p-aggiornato-per-lide-1-5-6-r2/?lang=en

Just thought it might be useful.

Regards,

Brad
KF7FER

Those are fine.

FYI, I'm currently using the low-power XO and was unable to reproduce the serial data reset issue, even when running at 16MHz and 3.3V. I tried 115200 and 230400 baud for the serial data. But maybe the DIP is more sensitive to this issue than the TQFP that I'm using, so go with what's safest. Then again Robert I don't believe has seen it on his boards with the DIP either, so I really don't know what to think.

It does help. Thank you.

Is anyone interested in an Optiboot built to communicate at 1 M baud (or 2 M)?

Is anyone interested in an Optiboot built for a no-LED board?

You may need to get a better diff tool!

The bad news is WinDiff finds changes in nearly every file. The good news is that the vast majority of the changes appear to be additions to the 1.0.5 standard core which should have no bearing on the '1284 processor or add new features. I found just one "conflict" that should be easy to get past.

Is the goal to use the standard core source files?

I find I don't care much about the bootloader LED blinking, as I bootload and then install Blink right off the bat to show the serial interface is working.
Are there many serial things that run at 1 or 2M? I could see that being handy for Arduino/Aruino comm's vs messing with I2C or SPI.
Would be nice to not have to mess with adding 1284 variant back in every time an IDE is downloaded.

CrossRoads:
I find I don't care much about the bootloader LED blinking, as I bootload and then install Blink right off the bat to show the serial interface is working.

Excellent point. I can't recall even once checking for the bootloader to blink the LED.

Are there many serial things that run at 1 or 2M?

In my house there are. :smiley:

The first thing I do when I get a new board is change the bootloader baud rate to 1 M. So all my Arduinos use 1 M baud. 8)

The theoretical upload limit is essentially reached at 1 M. In other words, it's faster uploading at 1 M using a bootloader than using a dedicated ISP programmer.

Whenever I build applications that transfer data between a PC and an Arduinio I always use 1 M.

I could see that being handy for Arduino/Aruino comm's vs messing with I2C or SPI.

I've found the higher baud rate to be generally very handy.

Would be nice to not have to mess with adding 1284 variant back in every time an IDE is downloaded.

I don't think we will be able to get to that point. In the past, the Arduino policy has been to only include genuine Arduino products with the IDE.

I think we will be able to reduce the "core" to six files. The "core" will use the source code from the IDE (will always be up-to-date).

I loaded up 1.5.6r2 and then added this 1284/644 new core offered at this site to a hardware folder in a new user sketch directory. However it resulted in only offering one type of 1284 board, using ISP and running at 1Mhz! This is even though the added boards.txt file defines many different 1284 configurations. So doesn't seem to be a working correctly, at least for me. I didn't even try to modifiy the boards.txt or add a boburino variant or to attach my 1284p board, but did validate a blink compile.

That sounds interesting! Is it just a matter of recompiling the bootloader?

Is anyone interested in an Optiboot built for a no-LED board?

Either way is fine with me. I sort of like the idea of an on-board LED but can live without it too. I didn't check well enough before designing my board, and ended up with it on pin 7 per the mighty-1284p "standard" variant (which is SCK, as is pin 13 on an Uno, which I thought made some amount of sense). But this does violate the Arduino pin 13 convention for the LED.

You may need to get a better diff tool!

That is one possibility :wink: Another is that I shouldn't type in the file names manually! How about these (diff output also attached):

Arduino.h
Print.cpp
WInterrupts.c
WString.cpp
WString.h
wiring_analog.c
wiring_private.h

The bad news is WinDiff finds changes in nearly every file.

Really? I probably wasn't clear, I was comparing the 1.0 core files to the core files from the mighty-1284p repo, I just get the seven files above.

Is the goal to use the standard core source files?

Wasn't sure what this meant, but if it refers to the comment in your subsequent post, then yes that sounds absolutely brilliant:

diff.txt (7.61 KB)

mrburnette:

bperrybap:
Just ordered a Sleeping Beauty.
I'll be using it to test out my openGLCD library on several different IDEs, including pre 1.0 and 1.5.x
So Jack, I'll be joining you and others over in your 1284p core thread, as soon as I get the board in.

--- bill

Bill, et al:
Is it feasible to run pre-1.0 on the 1284? We are having a discussion over on the 1284 side about 1.0.5r2 and 1.5.x as to where the effort should be places first. Nothing has been mentioned about pre-1.0 builds.
I must plead ignorance to the size of the pre-1.0 community that is still active.

Feasible? That may depend on your views. Different peoples view of what is feasible vary.
Possible? Yes - but with caveats.

Currently I test my library on about 10 different IDE versions, including versions with Teensy add ons
and chipKit versions, on Linux and Windows. So I see quite a bit of the issues
that crop up with respect to different IDE versions.

I would say trying to support pre 0019 is very difficult and not worth it as there
were some major changes in the core functionality at that point.
Some of the issues relate to things the Arduino team developers did in the core
files like improper header file include order, or attempting to outsmart the compiler
in attempt to gain performance - this would be the macros that re-define many of the
math functions. These types of things can and do break.
The linux users tend to be biggest victims of this as pre 1.0.3 the avr-gcc tools were not
included with the IDE so the linux users could end up with newer compiler tools than
than the Windows users. There are issues with the pre 1.x (I think even 1.0 has the issue)
and the newer gcc tools.

Most of these can be worked around, but it sometimes requires the user to patch
a core header file to fix the problem.
In the case of a 1284p core, most of the problems should be able to be fixed in the 1284p core files.
There are also some features that can be backported. For example, the F() macro.
My library will add F() support when using my library as it detects the environment in use
and adds the capability in if it is missing. Since I'm only adding support to my library files,
it only works with my openGLCD functions, vs if it were done in the core it would
work for all users of the Print class.

The main reason that I support pre 1.x at this point is that the chipKit stuff
has not fully upgraded their core to 1.0 and even when they do I doubt that they will
decide to break things like the Arduino team has done.
i.e. They will take measures just like Paul did in his Teensyduino core to ensure that most of the pre 1.x libraries
still continue to work with the post 1.0 IDE tools.

Having dealt with the compatibility issues across many of the IDES, I don't think it would be that big of a
deal to support 0022 and 0023 if that is desirable.
(Although I admit, I've not worked with any of communications and IP layer stuff - so I don't know
what issues lurk there)

In terms of the 1.x vs 1.5x support.
I'm not sure what the current state of that is. I know about 9+ months ago there
were some heated discussions on the developers list, about the new core & library "format".
After a long discussion, I think the Arduino team (at least the ones that matter) reached
an epiphany and realized the importance of not breaking compatibility with existing libraries and cores.
This was a major change from their thinking that lead to the 1.0 library debacle and was a HUGE
win for everyone. Prior to that, it was looking like there was going to be 1.0 library situation
all over again in that 100% of existing libraries would have had to be modified to work with the newer 1.5x IDE.
I haven't looked recently at the 1.5x core and library issues, since existing 1.0 libraries can now work "as is",
but my take is that things kind of went on hold or at least on the back burner
and that there are still desired changes that will start dropping in at some point.

My suggestion at this point would be target 1.x first, then move it over to 1.5x
and maybe the changes are simple enough that a single package can be created
that supports both.

--- bill

Jack,
In terms of comparing files and looking for changes, I think you need to be looking
at a more recent version of the IDE files than 1.0
There were lots of changes that went in during 1.0.3 and they have continued
to update things, so I'd be looking at the latest 1.0.5x core files.

Also, make sure to look at the variant files as that is where some of "nonsense" has been occurring lately.
macros vs const values and the names of macros and variables are being changed in there.

That is the subtle kind of stuff that really hurts.
I wish they hadn't used such simple names for their defines.

--- bill

bperrybap:
Jack,
In terms of comparing files and looking for changes, I think you need to be looking
at a more recent version of the IDE files than 1.0
There were lots of changes that went in during 1.0.3 and they have continued
to update things, so I'd be looking at the latest 1.0.5x core files.

Also, make sure to look at the variant files as that is where some of "nonsense" has been occurring lately.
macros vs const values and the names of macros and variables are being changed in there.

That is the subtle kind of stuff that really hurts.
I wish they hadn't used such simple names for their defines.

--- bill

Hi Bill, my aim would indeed be to update the mighty-1284p core to 1.0.5. My research led me to the conclusion that the current mighty-1284p core was based on 1.0. So first, I wanted to understand the changes that were made to 1.0 in order to produce the current 1284p core. Having that understanding, the next step would be to apply those changes (adjusted as and if necessary) to the corresponding 1.0.5 core files.

That's the process that I've used in the past, but it has been some time, so if I'm missing a better approach, I'd certainly be happy to learn.

jc

I can only add that I have been running the mighty-1284p core in arduino 1.0.5r2 for a couple of weeks with no errors or major problems seen. We know the INPUT_PULLUP option doesn't work (no compiler errors, but it simple doesn't seem to turn the pull-up on) and who knows if the extra timer, second uart, extra user interrupts work or not, but It shouldn't be an insurmountable task?
so says a hardware guy... :smiley:

retrolefty:
I can only add that I have been running the mighty-1284p core in arduino 1.0.5r2 for a couple of weeks with no errors or major problems seen. We know the INPUT_PULLUP option doesn't work (no compiler errors, but it simple doesn't seem to turn the pull-up on) and who knows if the extra timer, second uart, extra user interrupts work or not, but It shouldn't be an insurmountable task?
so says a hardware guy... :smiley:

Same here. It was INPUT_PULLUP that tipped me off that maybe some things were less than current, but no real issues found. I'd have to say I have fairly low mileage on it so far, but have not run into any issues. I did a brief test of attachInterrupt() with INT2 and didn't have any trouble (see this thread for details).

I did find that slave select for Ethernet ended up on an unexpected pin (PB2, pin 2 for the standard variant). Not sure what I think of that yet. It appears that moving it would require mods to the Ethernet library which I would much rather avoid. Still, PB2 isn't a pin I might have chosen because it's also INT2. INT0 and INT1 share RXD1 and TXD1 respectively, so the external interrupts don't fare well due to Atmel's pin mapping. Well there are always compromises.

"Neither a hardware guy nor a software guy" :smiley: ... jc

having reworked optiboot for several avrs (including m128 and m1284) i prefer the classic arduino rate, 57k. slightly slower loads but in my case has proven most trouble free for a variety of reasons.

since i never saw much point to bootload blinks, that and other redundant code was deleted to make room for more useful functions. however an led is VERY helpful for diagnostics and applications so id never consider a board w/o one. in fact, after 10nf bypass, its one of the first things hooked up to even my "stripped-duinos" which are little more than bare chips.

@Coding Badly

Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]

bobuino.bootloader.low_fuses=0xF7

You helped me out of a previous situation where I experienced 1284 problems on a bread application.
THANK YOU!
Others have not see the problem probably do to a different circuit layout, ground plane etc.
This points to my following conclusion, if several people have seen the problem and others not, there must be something borderline or on the verge of not working.
Since a slight change in layout fixes the problem, we are playing with a situation which can/could raise it's ugly head as a bug or intermittent.
I for one will always use full swing (at a small cost of power) as it totally solves the problem, besides I have enough problems laying in wait.
Thank you Coding Badly and Crossroads!

john1993:
having reworked optiboot for several avrs (including m128 and m1284) i prefer the classic arduino rate, 57k. slightly slower loads but in my case has proven most trouble free for a variety of reasons.

In which case 38400 and 76800 are far better choices (WormFood's AVR Baud Rate Calculator Ver. 2.1.1)...

16 MHz
Baud   UBRR  UBRR    Error
-----  ----  ------  -----
38400  25    0x0019  0.2    <<
57600  16    0x0010  2.1
76800  12    0x000C  0.2    <<
1000K   1    0x0001  0.0

1 M is a zero-error baud rate for 16 MHz boards. Unless the USB-to-serial converter is physically separated from the board it is an excellent choice.

since i never saw much point to bootload blinks

+1. Got it.

that and other redundant code was deleted to make room for more useful functions.

"More useful functions"? Such as?

[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.

...ended up with it on pin 7 per the mighty-1284p "standard" variant (which is SCK, as is pin 13 on an Uno, which I thought made some amount of sense). But this does violate the Arduino pin 13 convention for the LED.

No sweat! The "modern" way to handle an on-board LED is with a macro...

#define LED_BUILTIN 13

...in the variants file.

No macro = no on-board LED.

Another is that I shouldn't type in the file names manually! How about these (diff output also attached):

Still short. But don't sweat it. As soon as I have time (probably tomorrow) I'll post a complete diff with some comments to get us started.

Wasn't sure what this meant...

Yeah. The terminology is lacking which makes it difficult to explain.

but if it refers to the comment in your subsequent post, then yes that sounds absolutely brilliant:

It does. The "core" would essentially be a boards.txt that has a reference to the core that comes with the IDE and some variants.