Pages: 1 2 [3] 4 5 ... 29   Go Down
Author Topic: Updating the mighty-1284p core  (Read 21555 times)
0 Members and 1 Guest are viewing this topic.
Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4093
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

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

Quote
You may need to get a better diff tool!

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

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

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

Quote
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:

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

* diff.txt (7.61 KB - downloaded 20 times.)
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2745
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2745
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4093
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17303
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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-grin
« Last Edit: May 01, 2014, 02:54:04 pm by retrolefty » Logged

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4093
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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-grin

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-grin ... jc
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

vermont
Offline Offline
Sr. Member
****
Karma: 8
Posts: 316
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?

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.
« Last Edit: May 01, 2014, 06:34:30 pm by john1993 » Logged

Offline Offline
Faraday Member
**
Karma: 68
Posts: 2818
The last thing you did is where you should start looking.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@Coding Badly
Quote
# Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]
Quote
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!
« Last Edit: May 01, 2014, 08:35:05 pm by LarryD » Logged

The way you have it in your schematic isn't the same as how you have it wired up! That goes for me too.

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 211
Posts: 13044
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 (http://www.wormfood.net/avrbaudcalc.php)...

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.

Quote
since i never saw much point to bootload blinks

+1.  Got it.

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

"More useful functions"?  Such as?
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 211
Posts: 13044
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Is anyone interested in an Optiboot built to communicate at 1 M baud (or 2 M)?
That sounds interesting! Is it just a matter of recompiling the bootloader?

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
...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...
Code:
#define LED_BUILTIN 13
...in the variants file.

No macro = no on-board LED.

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

Quote
Wasn't sure what this meant...

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

Quote
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.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 211
Posts: 13044
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

My suggestion at this point would be target 1.x first, then move it over to 1.5x

Excellent suggestion.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 211
Posts: 13044
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

My research led me to the conclusion that the current mighty-1284p core was based on 1.0.

That does seem to be the case.

Quote
So first, I wanted to understand the changes that were made to 1.0 in order to produce the current 1284p core.

The diffs against 1.0.5 are fairly small (few lines here; dozen there) and seem to be low risk (minor bug fixes; add support for another processor) so I suggest working against 1.0.5.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 211
Posts: 13044
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


I made some space on Google Code to track issues...
https://code.google.com/p/mighty-1284p-port-to-1-0-5/issues/list
Logged

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4093
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

No sweat!  The "modern" way to handle an on-board LED is with a macro...
Code:
#define LED_BUILTIN 13
...in the variants file.

No macro = no on-board LED.

Right, I was aware of LED_BUILTIN and surprised to see the mighty-1284p standard variant had "LED" not "LED_BUILTIN":

Code:
static const uint8_t LED = 7;

Seems that #define would be better in this case, to facilitate compile time decisions. @bperrybap mentioned const/macro issues earlier, but I see that Arduino v1.0.5 uses const.
« Last Edit: May 02, 2014, 07:45:09 am by Jack Christensen » Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4093
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

My research led me to the conclusion that the current mighty-1284p core was based on 1.0.

That does seem to be the case.

Very interesting, it appears that at least some of maniacbug's changes to 1.0 have made it into 1.0.5.

I tried something that I thought was totally mad. I cloned the mighty-1284p core, created a new branch, copied in the core files from a vanilla copy of 1.0.5, then ran a merge to bring in the 1284p changes. Surprisingly, git did the merge without conflicts. I've been running a somewhat complex sketch with it that includes Ethernet client, UDP (for NTP), an LCD display, an RTC, and one or two other small things. So far it runs fine.

So I'm thinking that I may have a 1.0.5 version of the mighty-1284p core at this point. I've started the process of reviewing the changes between 1.0, mighty-1284p, 1.0.5, and the new 1284p that I produced. So far things look reasonable but I have a ways to go yet.
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Pages: 1 2 [3] 4 5 ... 29   Go Up
Jump to: