Arduino Forum

Using Arduino => Microcontrollers => Topic started by: JChristensen on Apr 24, 2014, 04:39 pm

Title: Updating the mighty-1284p core
Post by: JChristensen on Apr 24, 2014, 04:39 pm
It was brought up in another thread (http://forum.arduino.cc/index.php?topic=235402.msg1693642#msg1693642) that the mighty-1284p core (https://github.com/maniacbug/mighty-1284p) was a couple years behind. I'm not claiming to know what I'm doing here, but I did clone the repo and took a look through the commits. There are only a handful of the core files that are changed. Most of the changes concern the pins files, boards.txt, bootloader, etc., as opposed to the code in the "cores" directory. And the changes to those core files that are modified are not extensive.

I'm not in a position to make any promises, and I will continue to think about it, but it seems that an update would not be a huge amount of work. My purpose for this post was just to give that assessment of the situation and see how that matches with others' perceptions.

The core files that have changes are:
Code: [Select]
cores/standard/WInterrupts.c
cores/standard/wiring_private.h
cores/standard/Arduino.h
cores/standard/Print.h
cores/standard/wiring_analog.c
cores/standard/WString.h
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Apr 24, 2014, 08:18 pm
I use the 1284, so a refresh would be nice although I have had no issues under 1.0.5r2.

Ray
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 25, 2014, 04:46 am

Will you be targeting 1.0, 1.5, or both?
Title: Re: Updating the mighty-1284p core
Post by: westfw on Apr 25, 2014, 04:51 am
The "core" hasn't updated much, so probably there isn't a lot of "need" for an update to the 1284 core, either.
An add-on version compatible with 1.5 build system would be nice, if that has "finalized."  (but last I looked, it wasn't great for targets that wanted to share some of the "core" core code. (although perhaps one shouldn't care, and just do a separate set of core files anyway?))
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Apr 25, 2014, 04:07 pm

Will you be targeting 1.0, 1.5, or both?


I haven't had any need to go to 1.5 as of yet, actually been avoiding it. So I'd start with 1.0.5 (if and when I decide to do anything at all that is ;)) ... What are your thoughts on that?

Trying to think through what the process would be. How does this sound:

1. Produce a diff between the 1.0 core files and the mighty-1284p core files.
2. Review these vs. the 1.0.5 core files and make the corresponding changes.

That's a fairly manual approach. Wondering if I can use Git to just to a merge between the mighty-1284p core files and those of 1.0.5.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Apr 25, 2014, 04:58 pm


Will you be targeting 1.0, 1.5, or both?


I haven't had any need to go to 1.5 as of yet, actually been avoiding it. So I'd start with 1.0.5 (if and when I decide to do anything at all that is ;)) ... What are your thoughts on that?
<...>


Just my opinion, but I see little issues with 1.0.5 and eventually 1.5.x will rule.  Would the effort not be more appropriate to 1.5.x and then to back-port to 1.0.5 anything that is "critical"?  I run 1.5.x on the UNO and Mega fine (and Pro Mini and Nano) and without issue.  But for Pro Micro (Sparkfun), I have been using 1.0.5r2.  I was successful in using the Attiny core (tiny85) with 1.5.x, so I've moved that profile over, too.  My belief is that 1.0.5 is drying-up on the vine.

Ray
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on Apr 25, 2014, 05:11 pm



Will you be targeting 1.0, 1.5, or both?


I haven't had any need to go to 1.5 as of yet, actually been avoiding it. So I'd start with 1.0.5 (if and when I decide to do anything at all that is ;)) ... What are your thoughts on that?
<...>


Just my opinion, but I see little issues with 1.0.5 and eventually 1.5.x will rule.  Would the effort not be more appropriate to 1.5.x and then to back-port to 1.0.5 anything that is "critical"?  I run 1.5.x on the UNO and Mega fine (and Pro Mini and Nano) and without issue.  But for Pro Micro (Sparkfun), I have been using 1.0.5r2.  I was successful in using the Attiny core (tiny85) with 1.5.x, so I've moved that profile over, too.  My belief is that 1.0.5 is drying-up on the vine.

Ray



Just my opinion, but I think the download arduino page ( http://arduino.cc/en/Main/Software ) is pretty clear that 1.5.x is a beta release to add support for the newer 32 bit boards and while still supporting 8 bit avrs, the current 1.0.5r2 is the current 'official' release for 8 bit arduino boards.

There will come a time most likely when both flavors will be combined into a single official release but most likely given a newer number as in 2.0. So my vote would be to use the 8 bit only 1.0.5x version to be the one to refresh the now old 1284 adaption.

Lefty
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 28, 2014, 08:01 am
What are your thoughts on that?


Downloads of the Tiny Core are nearly split in half (55% for 1.5).  In theory a core will work unmodified with both IDE versions but I have had terrible luck getting the Tiny Core to work that way.  So, I decided all new work would be against 1.5 and I would only do maintenance against 1.0.

It was not a huge effort to get the Tiny Core working with 1.5.  (A big thank you goes out to the Italians!)

The two IDE versions run well side-by-side so it isn't too much to ask of the audience to "just use version 1.X".

In other words, it really does not make much difference which IDE version is targeted but the initial effort should be against just one version.

Quote
Trying to think through what the process would be. How does this sound:
1. Produce a diff between the 1.0 core files and the mighty-1284p core files.
2. Review these vs. the 1.0.5 core files and make the corresponding changes.
That's a fairly manual approach.


It is but I suspect the changes are fairly minimal and, in my experience, it usually pays off to put eyeballs on the source code.  (The OpenSSL folks could certainly have used a few more eyeballs on their stuff!)

Quote
Wondering if I can use Git to just to a merge between the mighty-1284p core files and those of 1.0.5.


And provide you with a diff.

I'm assembling my Bobuino so I can hopefully more actively participate.  I should be done tomorrow (Monday) evening.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 29, 2014, 06:31 pm

My Bobuino is assembled.  No smoke.  No big mistakes soldering.  Time to bootload it.


What did you# use for a bootloader?  Something from the mighty-1284p core?


# "You" meaning anyone reading this post who has tried to install a bootloader on a '1284 based board.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Apr 29, 2014, 07:20 pm

What did you# use for a bootloader?  Something from the mighty-1284p core?


I used Optiboot.

Works fine, except I was a bit surprised that it blinks pin 0 (PB0) when the reset button is pressed. The pins file (https://github.com/maniacbug/mighty-1284p/blob/master/variants/standard/pins_arduino.h#L52) indicates the LED is on pin 7 (PB7, SCK) so that's where I put the LED on my board. Minor issue, I might recompile the bootloader if it keeps me up nights :D

Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 29, 2014, 07:35 pm
I used Optiboot.


Did you build it yourself or find a ready-to-use copy?

At 115200 baud?
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on Apr 29, 2014, 07:44 pm

I used Optiboot.


Did you build it yourself or find a ready-to-use copy?

At 115200 baud?



https://code.google.com/p/optiboot/downloads/list
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on Apr 29, 2014, 07:51 pm


What did you# use for a bootloader?  Something from the mighty-1284p core?


I used Optiboot.

Works fine, except I was a bit surprised that it blinks pin 0 (PB0) when the reset button is pressed. The pins file (https://github.com/maniacbug/mighty-1284p/blob/master/variants/standard/pins_arduino.h#L52) indicates the LED is on pin 7 (PB7, SCK) so that's where I put the LED on my board. Minor issue, I might recompile the bootloader if it keeps me up nights :D




That's maybe the results of the pins_arduino file your using then the bootloader? My boburino board the bootloader (optibot) blinks the same pin that the blink sketch uses?
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 29, 2014, 07:51 pm

A big thank you to @westfw!

Ouch.  That's a little embarrassing...
Quote
Members arduino.tiny, westfw
Your role Owner

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Apr 29, 2014, 11:03 pm

I used Optiboot.


Did you build it yourself or find a ready-to-use copy?

At 115200 baud?


The one that came with maniacbug's core. Which if I'm reading things right, doesn't match the source code, at least as far as which pin the LED is on. Maybe that's the only difference.

Yes, 115200 baud.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Apr 30, 2014, 03:43 am
I'll post the one I use, blinks SCK just like an Uno. Is on a different computer. Just 3 quick flashes I think.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on Apr 30, 2014, 07:48 am

The Bobuino has the on-board LED on SCK / B7.  Where is the LED on other boards? Jack, did you also put the LED on B7?
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Apr 30, 2014, 02:05 pm

The Bobuino has the on-board LED on SCK / B7.  Where is the LED on other boards?


Unknown.

Quote

Jack, did you also put the LED on B7?


Yes. (But I'm not necessarily married to the idea, my boards are just for prototyping and testing.)
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 12:35 am

Jack, have you been using the Bobuino board entry to program your board?
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 02:08 am

I suggest these fuse settings for '1284 boards...

Code: [Select]
bobuino.bootloader.low_fuses=0xF7
bobuino.bootloader.high_fuses=0xD6
bobuino.bootloader.extended_fuses=0xFD


# Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]
# Boot Reset vector Enabled (default address=$0000); [BOOTRST=0]
# Boot Flash section size=512 words Boot start address=$FE00; [BOOTSZ=11]
# Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]
# Serial program downloading (SPI) enabled; [SPIEN=0]
# Brown-out detection level at VCC=2.7 V; [BODLEVEL=101]

Thoughts?
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 01, 2014, 02:42 am
Quote

# 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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 01, 2014, 02:53 am


Jack, have you been using the Bobuino board entry to program your board?


I'm using Mighty 1284p 16MHz using Optiboot (https://github.com/maniacbug/mighty-1284p/blob/master/boards.txt#L3) ... the board I designed maps the pins according to the standard variant (https://github.com/maniacbug/mighty-1284p/blob/master/variants/standard/pins_arduino.h).
Title: Re: Updating the mighty-1284p core
Post by: Brad Burleson on May 01, 2014, 03:07 am
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 (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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 01, 2014, 03:22 am

I suggest these fuse settings for '1284 boards...


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.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 06:15 am
Gents- I'm not sure it will help ... 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.


It does help.  Thank you.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 06:17 am

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?
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 06:31 am

The core files that have changes are:
Code: [Select]
cores/standard/WInterrupts.c
cores/standard/wiring_private.h
cores/standard/Arduino.h
cores/standard/Print.h
cores/standard/wiring_analog.c
cores/standard/WString.h



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?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 01, 2014, 07:51 am
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.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 01, 2014, 08:20 am
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.

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


In my house there are.   :D

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.

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

Quote
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).
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 01, 2014, 03:57 pm

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


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.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 01, 2014, 04:37 pm

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 ;)  Another is that I shouldn't type in the file names manually! How about these (diff output also attached):

Code: [Select]
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).
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 01, 2014, 06:40 pm


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


Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 01, 2014, 06:53 pm
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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 01, 2014, 08:05 pm

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
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 01, 2014, 09:51 pm


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...  :D
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 01, 2014, 11:20 pm

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...  :D


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 (http://forum.arduino.cc/index.php?topic=236028.0) 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"  :D ... jc
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 02, 2014, 01:32 am

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.
Title: Re: Updating the mighty-1284p core
Post by: larryd on May 02, 2014, 03:32 am
@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!
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 05:57 am
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?
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 10:26 am


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: [Select]
#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.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 10:29 am
My suggestion at this point would be target 1.x first, then move it over to 1.5x


Excellent suggestion.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 10:33 am
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.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 10:42 am

I made some space on Google Code to track issues...
https://code.google.com/p/mighty-1284p-port-to-1-0-5/issues/list
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 02, 2014, 02:42 pm

No sweat!  The "modern" way to handle an on-board LED is with a macro...
Code: [Select]
#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 (https://github.com/maniacbug/mighty-1284p/blob/master/variants/standard/pins_arduino.h#L52) had "LED" not "LED_BUILTIN":

Code: [Select]
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.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 02, 2014, 04:30 pm

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.
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 02, 2014, 05:16 pm

In which case 38400 and 76800 are far better choices


from the standpoint of divisor error thats true.  unfortunately few (none) of the official boards use those so not an option for me because i like same baud for all projects. 1m or, for that matter, anything over 115k also ruled out because not available on most computer/os. mostly i like 57k because its much friendlier from a hardware standpoint (cable capacitance, jitter, etc) and no big download time gain beyond that.

"More useful functions"?  Such as?


auto adjust baud so same rate for different crystals, bios table so user can call useful boot routines (ie serial and specially flash write which cant be done from app), osccal calibrate for internal rc clk,  debug monitor to dump and poke memory, and a few other less useful ones that dont come to mind atm.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 02, 2014, 11:13 pm

A 1 M baud, no LED, serial 0 bootloader for the m1284.

The boards.txt entry I'm using...

Code: [Select]
##############################################################

bobuino.name=Bobuino
bobuino.upload.protocol=arduino
bobuino.upload.maximum_size=130048
# bobuino.upload.speed=115200
bobuino.upload.speed=1000000

# bobuino.bootloader.low_fuses=0xff
# bobuino.bootloader.high_fuses=0xde
# bobuino.bootloader.extended_fuses=0xfd

# Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]
# Boot Reset vector Enabled (default address=$0000); [BOOTRST=0]
# Boot Flash section size=512 words Boot start address=$FE00; [BOOTSZ=11]
# Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]
# Serial program downloading (SPI) enabled; [SPIEN=0]
# Brown-out detection level at VCC=2.7 V; [BODLEVEL=101]

bobuino.bootloader.low_fuses=0xF7
bobuino.bootloader.high_fuses=0xD6
bobuino.bootloader.extended_fuses=0xFD

bobuino.bootloader.path=optiboot
bobuino.bootloader.file=optiboot_atmega1284p.hex
bobuino.bootloader.unlock_bits=0x3F
bobuino.bootloader.lock_bits=0x0F
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino

##############################################################
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 03, 2014, 12:26 am
447 bytes. amazing. i didnt think it could be trimmed down that  small with c. i had to go asm route to get there. guess the led stuff takes up more room than i thought.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 02:55 am

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.


What is that conflict?


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


We may be able to do better than that. I spent a fair amount of time today reviewing 1.0 (upon which the current mighty-1284p core was built) vs. mighty-1284p vs. 1.0.5 vs. the new 1284p core I built (reply #44).

I came to a startling conclusion. Namely, the current 1.0.5 core (cores) files (i.e. arduino-1.0.5\hardware\arduino\cores\arduino) are sufficient to support the ATmega1284P the same as the current mighty-1284p core. I think all the necessary changes have worked their way into the cores files since 1.0.

I think all that is needed to program an ATmega1284P with v1.0.5 is a bootloader, pins file, and a boards.txt entry. I wouldn't be surprised if ATmega644/A/P/PA worked as well.

Next would be to test this.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 03:38 am

Next would be to test this.


As the quickest way to test this,

1. I used my current mighty-1284p installation. I deleted all the files from sketchbook\hardware\mighty-1284p\cores\standard

2. Into the now empty folder, I copied the files from v1.0.5, arduino-1.0.5\hardware\arduino\cores\arduino

Initial testing found no problems and included trying:

Various digital I/O
The eight analog inputs
The eight PWM outputs
External interrupts 0, 1, 2
My sketch with Ethernet/UDP/LCD/RTC
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 03, 2014, 04:24 am


Next would be to test this.


As the quickest way to test this,

1. I used my current mighty-1284p installation. I deleted all the files from sketchbook\hardware\mighty-1284p\cores\standard

2. Into the now empty folder, I copied the files from v1.0.5, arduino-1.0.5\hardware\arduino\cores\arduino

Initial testing found no problems and included trying:

Various digital I/O
The eight analog inputs
The eight PWM outputs
External interrupts 0, 1, 2
My sketch with Ethernet/UDP/LCD/RTC


Well played! I followed your instructions and then uploaded this:

Code: [Select]

void setup() {
  // put your setup code here, to run once:
pinMode(13, INPUT_PULLUP);
}

void loop() {
  // put your main code here, to run repeatedly:
 
}


And was rewarded with a dimmily lit pin 13. So INPUT_PULLUP appears to work.

Lefty
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 04:32 am

So INPUT_PULLUP appears to work.


Thanks for testing that! I did verify that it compiled but then in all the excitement forgot to actually try it  :D
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 03, 2014, 05:40 am
Looking over the IDE release notes, I see some references to the 1284P in ARDUINO 1.0.1 - 2012.05.21, but nothing new mentioned after that.
http://arduino.cc/en/Main/ReleaseNotes
Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 06:44 am

I came to a startling conclusion. Namely, the current 1.0.5 core (cores) files (i.e. arduino-1.0.5\hardware\arduino\cores\arduino) are sufficient to support the ATmega1284P the same as the current mighty-1284p core. I think all the necessary changes have worked their way into the cores files since 1.0.


Great detective work! ++Karma.

It is surprising, if indeed this has been slipstreamed in, that there isn't any record of it, as suggested by RetroLefty. Who got the changes in, I wonder? These things don't just "happen"!

Anyway, all will become clear in due course, I imagine.

In the meantime, I was testing this out using the SPI library's example sketches, and I came across this bug in bobuino/pins_arduino.h (lines 36-38):

Code: [Select]

extern const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS];
extern const uint16_t __pcmsk[];
extern const uint8_t digital_pin_to_timer_PGM[NUM_DIGITAL_PINS];


Not sure if if I am using the latest version of the bobuino files, but these lines caused the linker to complain:

Code: [Select]

In file included from C:\arduino\Arduino ERW 1.0.5\libraries\SPI\/SPI.h:15,
                from C:\arduino\Arduino ERW 1.0.5\libraries\SPI\SPI.cpp:12:
C:\arduino\Arduino ERW 1.0.5\hardware\mighty-1284p\variants\bobuino/pins_arduino.h:38: error: previous declaration of 'const uint8_t digital_pin_to_timer_PGM [32]' with 'C++' linkage
C:\arduino\Arduino ERW 1.0.5\hardware\arduino\cores\arduino/Arduino.h:134: error: conflicts with new declaration with 'C' linkage


when using the standard Arduino 1.0.5 core files (which is what I was testing), but also complained equally loudly when using the original 1234p "standard" core.

Having a quick look though bobuino/pins_arduino.h showed the extern declarations simply shouldn't have been there, as the actual arrays were actually defined later in that file.

Anyway, the easy fix is just to delete those three lines, of course.

I had a look at the standard/pins_arduino.h to see if the bug was also there, but it wasn't.

Is this an old bug, and I am using outdated files?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 03, 2014, 08:26 am
I've been using this one,  has a couple tweaks (commented) that seems to fix the SPI problem.
http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h
Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 09:37 am

I've been using this one,  has a couple tweaks (commented) that seems to fix the SPI problem.
http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h


Code: [Select]

extern const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS];
extern const uint16_t __pcmsk[];
// comment next line to solve SPI problem?
//extern const uint8_t digital_pin_to_timer_PGM[NUM_DIGITAL_PINS];  


Yes, I can see it comments out one of the three lines I mention above.

The SPI lib only trips on the first one, but the other two will cause similar problems if the linker has cause to try to resolve those symbols.

The proper fix is just delete all three. Those extern declarations shouldn't be there if the actual array definitions are in the same file. "extern" is to tell the compiler that the actual definitions are in a different source file, but don't worry,  I promise the linker will sort it all out later. I Cross my heart! :-)

Edit:

Noticed the bug fix a few lines later:

Code: [Select]

// #define analogPinToChannel(p)    ( (p) < NUM_ANALOG_INPUTS ? NUM_ANALOG_INPUTS - (p) : -1 )
#define analogPinToChannel(p)       ( (p) < NUM_ANALOG_INPUTS ? (NUM_ANALOG_INPUTS-1) - (p) : -1 ) // test to see if A0-A7 are off by 1


yep, that commented version is definitely incorrect, as 0 would map to 8, rather than 7.

the new version looks the real deal. I'll fix this in my file.

Is this file currently in/going to be in to version control somewhere?
Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 10:12 am
Just noticed this line:

Code: [Select]

#define analogInputToDigitalPin(p)  ((p < NUM_ANALOG_INPUTS) ? 21 - (p) : -1)


This looks like it may be incorrect.

If p = 0, it returns 21, which is PA0 (or A7), but I suspect it should be returning  14, which is PA7 (or A0)

if so, the macro should be

Code: [Select]

#define analogInputToDigitalPin(p)  ((p < NUM_ANALOG_INPUTS) ? 14 + (p) : -1)


which would make it consistent with this macro

Code: [Select]

#define digitalPinToAnalogPin(p)    ( (p) >= 14 && (p) <= 21 ? (p) - 14 : -1 )


which does what I'd expect.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 01:06 pm

Great detective work! ++Karma.

It is surprising, if indeed this has been slipstreamed in, that there isn't any record of it, as suggested by RetroLefty. Who got the changes in, I wonder? These things don't just "happen"!


Thank you! As lefty found in the release notes, it appears that the changes were made in 1.0.1 and submitted by maniacbug. I think the actual changes to the core files were quite minimal, and consisted mainly of adding INT2, and maybe some fixes for analogRead(). Some changes in the maniacbug core seem unrelated to the 1284p, e.g. changes to Wstring.cpp, and I wonder if some improvements weren't developed in parallel and maybe independently to some extent.

Then there were a couple changes that I couldn't make much sense of and didn't dig into, for example removal of the PROGMEM attribute in the following declarations in Arduino.h -- 1.0.5 still has PROGMEM.

Code: [Select]

diff --git a/arduino-1.0/hardware/arduino/cores/arduino/Arduino.h b/mighty-1284p/cores/standard/Arduino.h
index ebd374a..2e35a35 100644
--- a/arduino-1.0/hardware/arduino/cores/arduino/Arduino.h
+++ b/mighty-1284p/cores/standard/Arduino.h
@@ -123,14 +123,14 @@ void loop(void);

// On the ATmega1280, the addresses of some of the port registers are
// greater than 255, so we can't store them in uint8_t's.
-extern const uint16_t PROGMEM port_to_mode_PGM[];
-extern const uint16_t PROGMEM port_to_input_PGM[];
-extern const uint16_t PROGMEM port_to_output_PGM[];
+extern const uint16_t port_to_mode_PGM[];
+extern const uint16_t port_to_input_PGM[];
+extern const uint16_t port_to_output_PGM[];

-extern const uint8_t PROGMEM digital_pin_to_port_PGM[];
-// extern const uint8_t PROGMEM digital_pin_to_bit_PGM[];
-extern const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[];
-extern const uint8_t PROGMEM digital_pin_to_timer_PGM[];
+extern const uint8_t digital_pin_to_port_PGM[];
+// extern const uint8_t digital_pin_to_bit_PGM[];
+extern const uint8_t digital_pin_to_bit_mask_PGM[];
+extern const uint8_t digital_pin_to_timer_PGM[];

// Get the bit location within the hardware port of the given virtual pin.
// This comes from the pins_*.c file for the active board configuration.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 02:40 pm
I may be learning some things the hard way here, and I may not be the first to have come this way. I just noticed that all the entries in maniacbug's boards.txt file have something similar to

Code: [Select]
#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard


It looks like if the first line above is un-commented and the second is commented, then the sketchbook\hardware\mighty-1284p\cores directory can just be deleted and this will cause the cores files from the Arduino distribution to be used.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 03:16 pm

Then there were a couple changes that I couldn't make much sense of and didn't dig into, for example removal of the PROGMEM attribute in the following declarations in Arduino.h -- 1.0.5 still has PROGMEM.


My guess would be the arrays were changed form progmem to sram storage because the larger 1284p memory available made it less important to preserve sram, and probably the tradeoff being a performance boost in functions that used those table values for look-ups. Debatable in its merits, but not unjustifiable. It would be interesting to see if there is a material performance benefit in some situations.


It looks like if the first line above is un-commented and the second is commented, then the sketchbook\hardware\mighty-1284p\cores directory can just be deleted and this will cause the cores files from the Arduino distribution to be used.


That's what I was doing to test using the Arduino 1.0.5 core with the bobuino/pins_arduino.h. Seems to work fine so far.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 03, 2014, 04:42 pm

I may be learning some things the hard way here, and I may not be the first to have come this way. I just noticed that all the entries in maniacbug's boards.txt file have something similar to

Code: [Select]
#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard


It looks like if the first line above is un-commented and the second is commented, then the sketchbook\hardware\mighty-1284p\cores directory can just be deleted and this will cause the cores files from the Arduino distribution to be used.


To this hardware type guy the below entries types always seemed to be 'software magic' to me, but I assumed it was directions for the pre-processor and/or compiler and/or linker to force the correct files to be used. I haven't looked at the latest board.txt file entries in 1.5.x but with all the new board types using so many different chips types I guess it is the only practical means to allow the user to just select his/her board type and everything still works transparently. I would sure hate to have to design something in hardware with that kind of flexibility.  :D

Quote

bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 03, 2014, 06:39 pm
Quote
Quote
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino


This boards.txt is parsed by the GUI and ensures all the right "pieces" are passed to AVRDUDE via the command prompt.

Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 03, 2014, 06:48 pm

Quote
Quote
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino


This boards.txt is parsed by the GUI and ensures all the right "pieces" are passed to AVRDUDE via the command prompt.




Surely AVRDUDE cares nothing about those values. The earlier various upload values in the boards.txt are used by AVRDUDE, but these have to do with the compilation before the uploading is even called?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 03, 2014, 07:21 pm
Quote
This looks like it may be incorrect.

If p = 0, it returns 21, which is PA0 (or A7), but I suspect it should be returning  14, which is PA7 (or A0)

That was done so that the analog pins can go straight out from pin to header - ADC7 is pin 33, 6 is 34, etc with ADC0 at 40.
The swap allows ADC7 to be A0 and ADC0 to be A7. A0 is the header pin closest to the power header, A6 and A7 get added to the opposite end and extend the analog header.
This keeps the 8 signals from having to criss cross each other in the routing from pin to header.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 03, 2014, 07:24 pm


Quote
Quote
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino


This boards.txt is parsed by the GUI and ensures all the right "pieces" are passed to AVRDUDE via the command prompt.




Surely AVRDUDE cares nothing about those values. The earlier various upload values in the boards.txt are used by AVRDUDE, but these have to do with the compilation before the uploading is even called?



As mrburnette said, the boards.txt is not looked at or used by any of the gcc tools or the bin utils.
The Arduino IDE looks at it, parses it and uses the information to determine what to pass on the command line
when calling tools like gcc or avrdude. Different pieces of information are used by the different tools.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 03, 2014, 07:42 pm


Then there were a couple changes that I couldn't make much sense of and didn't dig into, for example removal of the PROGMEM attribute in the following declarations in Arduino.h -- 1.0.5 still has PROGMEM.


My guess would be the arrays were changed form progmem to sram storage because the larger 1284p memory available made it less important to preserve sram, and probably the tradeoff being a performance boost in functions that used those table values for look-ups. Debatable in its merits, but not unjustifiable. It would be interesting to see if there is a material performance benefit in some situations.


I would bet that guess is incorrect.
Those are just the external declarations. They are not the data initializations.
If you look at the actual initializations, down in the pins_arduino.h you can see that the
the actual data arrays are still initialized as PROGMEM.

The use of PROGMEM on the external declaration won't matter to the linker as the linker
is just going to resolve the address. The PROGMEM stuff is a big kludge for the AVR
composed of some fancy gcc section macros that sit outside the actual compiler and linker.
i.e. the gcc compiler and linker know nothing of split address spaces or the different AVR memories.


I have no idea why they removed the PROGMEM in the external declaration but
my guess would be that it was either done as an early attempt to get ready for the processors that don't use PROGMEM.
By doing the external declarations without PROGMEM, it will work for AVR as well as the more "normal"
processors like ARM, and PIC32.
Or perhaps it was trying to squelch some of the warnings that you get in g++ from the AVR PROGMEM kludges.
Or maybe the previous external declarations with PROGMEM have issues with newer versions of the compiler?

Whatever the reason, it does not appear to me that data itself is moving from AVR progmem to RAM on the 1284 core.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 07:49 pm

Quote
This looks like it may be incorrect.

If p = 0, it returns 21, which is PA0 (or A7), but I suspect it should be returning  14, which is PA7 (or A0)

That was done so that the analog pins can go straight out from pin to header - ADC7 is pin 33, 6 is 34, etc with ADC0 at 40.
The swap allows ADC7 to be A0 and ADC0 to be A7. A0 is the header pin closest to the power header, A6 and A7 get added to the opposite end and extend the analog header.
This keeps the 8 signals from having to criss cross each other in the routing from pin to header.


No; I know what you are referring to, with the backwards enumeration of A0-A7 relating to PA7 to PA0, but this macro error has nothing to do with that.

analogInputToDigitalPins(x)  should take the "logical" (or "Arduino") analog pin numbers 0-7 (as in A0 - A7, not PA0-PA7) and maps them to "logical" Arduino digital pin numbers D14 - D21.

So, since the analog and digital pin equivalents are

A0 = D14 (PA7), A1 = D15 (PA6) ... A7 = D21 (PA0)

we want

analogInputToDigitalPins(0) = 14
analogInputToDigitalPins(1) = 15
:
analogInputToDigitalPins(7) = 21

The current macro definition

Code: [Select]

#define analogInputToDigitalPin(p)  ((p < NUM_ANALOG_INPUTS) ? 21 - (p) : -1)


doesn't do this, instead it does

analogInputToDigitalPins(0) = 21
analogInputToDigitalPins(1) = 20
:
analogInputToDigitalPins(7) = 14

which is backwards. (I think you must have been thinking of the backwards logical to physical enumerations, and forgot this was a logical to logical enumeration.)

In any case, to do the correct mapping, the macro should simply be

Code: [Select]

#define analogInputToDigitalPin(p)  ((p < NUM_ANALOG_INPUTS) ? 14 + (p) : -1)


Title: Re: Updating the mighty-1284p core
Post by: pico on May 03, 2014, 07:59 pm

I would bet that guess is incorrect.
Those are just the external declarations. They are not the data initializations.
If you look at the actual initializations, down in the pins_arduino.h you can see that the
the actual data arrays are still initialized as PROGMEM.


Well, if they've only changed the declarations and not the definitions, as you say, I wouldn't be taking the other side of your bet! ;-)


Whatever the reason, it does not appear to me that data itself is moving from AVR progmem to RAM on the 1284 core.


Well, if the definitions do still say PROGMEM, as you say, then I agree, no.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 03, 2014, 09:40 pm
Well somehow this 'upgrade' has caused the old analog pin assignment problem to reappear where reading from analog pin A0 or 14 only really sees voltage applied to shield pins A1 or 15. This was 'solved' back when by the changes CrossRoads showed in the bobuino variant pins_arduino  file that he posted below. Don't understand how changes to the core files would change that but that's what I'm seeing at the moment. So if anyone does this IDE upgrade and is using the Bobuino through hole board, they might want to check out their analog pin addressing.

Lefty
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 11:11 pm
All,

I created a development branch v1.0.5 in my repo and made it the default:
https://github.com/JChristensen/mighty-1284p

@lefty, yours (below) is the first issue (https://github.com/JChristensen/mighty-1284p/issues/1). I should be able to appropriate the use of a Bobuino board to test. I did check all eight analog inputs with my board (using the mighty_opt variant) and all was well, but I will double check that too.


Well somehow this 'upgrade' has caused the old analog pin assignment problem to reappear where reading from analog pin A0 or 14 only really sees voltage applied to shield pins A1 or 15. This was 'solved' back when by the changes CrossRoads showed in the bobuino variant pins_arduino  file that he posted below. Don't understand how changes to the core files would change that but that's what I'm seeing at the moment. So if anyone does this IDE upgrade and is using the Bobuino through hole board, they might want to check out their analog pin addressing.

Lefty
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 03, 2014, 11:56 pm

Is this file currently in/going to be in to version control somewhere?


It is now (see previous post).

I've just started wading through the analog and SPI issues for the bobuino variant, but if someone wants to send a pull request, that'd be grrrreat :D

PS: Or I can just grab Crossroads' file (http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h) and comment out lines 36 and 37.

PPS: No, that doesn't work. We lost a change from the mighty-1284p core in wiring_analog.c that was needed for the bobuino variant. I was using the mighty_opt variant which doesn't require it, which is why I didn't notice during testing. I was not aware of the reverse analog mapping on the bobuino. We may have to have a change to wiring_analog.c.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 04:32 am

PS: Or I can just grab Crossroads' file (http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h) and comment out lines 36 and 37.


Actually all three lines 36-38.

You don't want to comment them out, you want to delete them entirely, those extern declarations should never have been there in the first place. I picked them up in my version of bobuino/pins_arduino.h when trying to compile the SPI lib;  It complained about the first declaration, but the other two are equally problematic, and will trip up anything trying to resolve those symbols as well.


PPS: No, that doesn't work. We lost a change from the mighty-1284p core in wiring_analog.c that was needed for the bobuino variant. I was using the mighty_opt variant which doesn't require it, which is why I didn't notice during testing. I was not aware of the reverse analog mapping on the bobuino. We may have to have a change to wiring_analog.c.


Both the bobuino/pins_arduino.h file I had, and the later one CR linked to, had the correct reverse logical analog to physical analog pin mappings. But they both had an incorrect analogInputInputToDigitalPin() macro, which also did an unnecessary "reverse" mapping (see my posts above with the correction for this macro.)

But if you *really* prefer, I'll do the pull request thing for bobuino/pins_arduino.h
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 04, 2014, 04:58 am

Actually all three lines 36-38.

You don't want to comment them out, you want to delete them entirely, those extern declarations should never have been there in the first place. I picked them up in my version of bobuino/pins_arduino.h when trying to compile the SPI lib;  It complained about the first declaration, but the other two are equally problematic, and will trip up anything trying to resolve those symbols as well.


Will do, thanks.

Quote

Both the bobuino/pins_arduino.h file I had, and the later one CR linked to, had the correct reverse logical analog to physical analog pin mappings. But they both had an incorrect analogInputInputToDigitalPin() macro, which also did an unnecessary "reverse" mapping (see my posts above with the correction for this macro.)


I do not believe that analogInputToDigitalPin() is actually used anywhere, so maybe it should be deleted as well.

digitalPinToAnalogPin() and analogPinToChannel() are both used, and seem to be correct in Crossroads' current file (http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h). Whether analogRead() is given a pin number (A0-A7) or a channel number (0-7) the reverse mapping occurs.

Quote

But if you *really* prefer, I'll do the pull request thing for bobuino/pins_arduino.h


Hold off for now. My plan is to take a copy of Crossroads' current pins file, and delete the three lines as above. Then I will copy the 1.0.5 core files to mighty-1284p/cores/bobuino. Finally, I will modify wiring_analog.c to work with the bobuino board. I guess all the core files need to be copied even though only one needs changes. No huge deal but if you know of a more elegant approach, please let me know!
Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 05:06 am

Quote

But if you *really* prefer, I'll do the pull request thing for bobuino/pins_arduino.h


Hold off for now. My plan is to take a copy of Crossroads' current pins file, and delete the three lines as above. Then I will copy the 1.0.5 core files to mighty-1284p/cores/bobuino. Finally, I will modify wiring_analog.c to work with the bobuino board. I guess all the core files need to be copied even though only one needs changes. No huge deal but if you know of a more elegant approach, please let me know!


LOL. While you writing this I have forked and committed the changes on my local branch, and was just about to submit the pull request. But if you want me to hold off, fine. (Edit: Too late! You've got a pull request. :-)

If the analogInputsToDigitalPin() macro really isn't ever going be used, then just delete it. But if it is going to stay, for backwards compatibility with older libs or whatever, then obviously it should be corrected.

I'd suggest fixing rather than deleting, since unused macros incur no overheads.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 05:34 am
Uh... guys... Be very careful about removing and/or changing things.
My openGLCD library currently uses the analogInputToDigitalPin() macro to be able
to automagically detect which 1284 core variant is being used at compile time.
I look at the digital pin # for analog pin 0,
24 == "standard"
31 == "avr_developers" or Sanguino
21 == "bobuino"

I have to do this to be able to properly create compile time pin mapping tables for
my avrio routines that do AVR raw port i/o.


--- bill

Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 05:39 am

I look at the digital pin # for analog pin 0,
21 == "bobuino"


That should be 14, not 21. The fixed version of the macro (above and in the pull request) will correct that.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 08:40 am


I look at the digital pin # for analog pin 0,
21 == "bobuino"


That should be 14, not 21. The fixed version of the macro (above and in the pull request) will correct that.


That's an issue for me, because now depending on which version of the 1284 core users are using, I get two different
answers for the bobuino variant and I have no way of telling which version of the core they are using.
I can probably check for either 21 or 14 since those numbers don't collide with 24 and 31 for the other two variants.
I don't really need the actual mapping. What I need is just a way to detect between the cores & variants.
It sucks that there isn't a pair of defines for the core & variant that are available to the code being compiled.
It would make things so much simpler.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 04, 2014, 08:45 am

My openGLCD library currently uses the analogInputToDigitalPin() macro to be able
to automagically detect which 1284 core variant is being used at compile time.


A much better choice would be to use a "board" #define.  1.5.x automatically creates one if one is not provided in boards.txt.  For 1.0.5 it is a trivial matter to include the same #define in the variants header file.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 09:10 am


My openGLCD library currently uses the analogInputToDigitalPin() macro to be able
to automagically detect which 1284 core variant is being used at compile time.


A much better choice would be to use a "board" #define.  1.5.x automatically creates one if one is not provided in boards.txt.  For 1.0.5 it is a trivial matter to include the same #define in the variants header file.


Not really.
I know that you can go in and add board specific compiler defines when using 1.5 and I've considered that option.
However, there are issues with that, the main one being it requires users to go in and muck with their
boards file.
There are also defines that the 1.5x IDE creates based on the board names in the boards file but that
really isn't what is needed either.
Many boards can and do use the same core and variant.
When doing pin mappings the actual Arduino IDE board type is not what is important.
It is the actual core and variant that matters.
So even if a board specific define or multiple defines were added to the boards file that is sent to the compiler
for each board type, the defines can't be board specific but rather need to indicate which core and variant
are in use.


If you step way back,
there is a much better way to handle all this pin mapping data that would allow better compile time
optimizations. It does require some slight changes to the way the pin data is declared. If it were declared
slightly differently, then it becomes possible to actually reach down in to the data tables at compile time under
certain circumstances. (gcc is smart enough to do this).
The changes are very minimal and have zero impact on any existing code.
I've brought this up a few times with the Arduino team but so far have not gotten any interest.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 02:44 pm
I just emailed this to Jack, and thought I'd share it here as well:

I have been testing some more with the Arduino core today, and have been testing with some fairly demanding stuff. No problems detected so far -- all very smooth. Surprisingly so, in fact.

With the latest bootloader version (I assume it is the lastest -- it is the one Jack has included in the github distribution), it feels like working with a great big Uno.

I think this stage of the project (1.0.5) is progressing very well. Thanks to Jack for taking the initiative on this -- it needed it, I think.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 03:44 pm

I think all that is needed to program an ATmega1284P with v1.0.5 is a bootloader, pins file, and a boards.txt entry. I wouldn't be surprised if ATmega644/A/P/PA worked as well.

Next would be to test this.


I did some testing with a 1284 (not 1284p) and discovered something interesting: The avr-gcc disrtribution doesn't recognise/support the 1284 as a valid -mmcu option.

It's OK with -mmcu=atmega1284p, but try it with -mmcu=atmega1284 (e.g., change boards.txt so that "bobuino.build.mcu=atmega1284p" becomes "bobuino.build.mcu=atmega1284"), and you get:

Code: [Select]

unknown MCU 'atmega1284' specified
Known MCU names:
  avr2
  at90s2313
  at90s2323
  at90s2333
  at90s2343
  attiny22
  attiny26
  at90s4414
  at90s4433
  at90s4434
  at90s8515
  at90c8534
  at90s8535
  avr25
  ata6289
  attiny13
  attiny13a
  attiny2313
  attiny2313a
  attiny24
  attiny24a
  attiny4313
  attiny44
  attiny44a
  attiny84
  attiny25
  attiny45
  attiny85
  attiny261
  attiny261a
  attiny461
  attiny461a
  attiny861
  attiny861a
  attiny43u
  attiny87
  attiny48
  attiny88
  at86rf401
  avr3
  at43usb320
  at43usb355
  at76c711
  avr31
  atmega103
  avr35
  at90usb82
  at90usb162
  atmega8u2
  atmega16u2
  atmega32u2
  attiny167
  avr4
  atmega8
  atmega48
  atmega48a
  atmega48p
  atmega88
  atmega88a
  atmega88p
  atmega88pa
  atmega8515
  atmega8535
  atmega8hva
  atmega4hvd
  atmega8hvd
  at90pwm1
  at90pwm2
  at90pwm2b
  at90pwm3
  at90pwm3b
  at90pwm81
  avr5
  atmega16
  atmega16a
  atmega161
  atmega162
  atmega163
  atmega164a
  atmega164p
  atmega165
  atmega165a
  atmega165p
  atmega168
  atmega168a
  atmega168p
  atmega169
  atmega169a
  atmega169p
  atmega169pa
  atmega16c1
  atmega16hva
  atmega16hva2
  atmega16hvb
  atmega16m1
  atmega16u4
  atmega32
  atmega323
  atmega324a
  atmega324p
  atmega324pa
  atmega325
  atmega325p
  atmega3250
  atmega3250p
  atmega328
  atmega328p
  atmega329
  atmega329p
  atmega329pa
  atmega3290
  atmega3290p
  atmega32c1
  atmega32hvb
  atmega32m1
  atmega32u4
  atmega32u6
  atmega406
  atmega64
  atmega640
  atmega644
  atmega644a
  atmega644p
  atmega644pa
  atmega645
  atmega645a
  atmega645p
  atmega6450
  atmega6450a
  atmega6450p
  atmega649
  atmega649a
  atmega649p
  atmega6490
  atmega6490a
  atmega6490p
  atmega64c1
  atmega64m1
  atmega64hve
  at90can32
  at90can64
  at90pwm216
  at90pwm316
  at90scr100
  at90usb646
  at90usb647
  at94k
  avr51
  atmega128
  atmega1280
  atmega1281
  atmega1284p
  atmega128rfa1
  at90can128
  at90usb1286
  at90usb1287
  m3000f
  m3000s
  m3001b
  avr6
  atmega2560
  atmega2561
  avrxmega2
  atxmega16a4
  atxmega16d4
  atxmega32d4
  avrxmega3
  atxmega32a4
  avrxmega4
  atxmega64a3
  atxmega64d3
  avrxmega5
  atxmega64a1
  avrxmega6
  atxmega128a3
  atxmega128d3
  atxmega192a3
  atxmega192d3
  atxmega256a3
  atxmega256a3b
  atxmega256d3
  avrxmega7
  atxmega128a1
  avr1
  at90s1200
  attiny11
  attiny12
  attiny15
  attiny28
diagnostic6_r3.cpp:1: error: MCU 'atmega1284' supported for assembler only



Nice list; includes

  atmega644
  atmega644a
  atmega644p
  atmega644pa

and

  atmega1284p

but definitely no atmega1284, oddly enough.

I suspect this is just a avr-gcc oversight. However, it does have some awkward implications if you want to use  a 1284 chip; if you want to program using an ISP programmer rather than the bootloader, avrdude will complain the signature is wrong if it is expecting a 1284p (which you have to specify if you want the sketch compilation to proceed.)

Of course, you can upload the built .hex file manually via avrdude using the -p m1284 switch, if your avrdude.conf is up to date; the one distributed with 1.0.5, for example, appears to not have the m1284 part defined (easy to add, though.)

But a bit of fiddling around and a waste of time if you need to do that very often. A one step process becomes two.

Interestingly, using the bootloader appears to be more forgiving.

First of all, since there is no compilation involved in "burning the bootloader", it will burn the 1284p bootloader onto a 1284 chip using, e.g.,  "bobuino.build.mcu=atmega1284" without complaint. (Or, just burn manually using avrdude with -p m1284, of course.)

Secondly, and more importantly, when uploading a sketch compiled as 1284p to a 1284 chip via the 1284p bootloader, it all just goes through without complaint -- the bootloader neither knows nor care what the actual chip signature is, it would seem.

So, to summarize, support for the 1284 with the bootloader programming option is very close to seamless, but not so if you are using "Upload using programmer" an ISP programmer.

I've got a 644 chip I'll have a play with as well, and report back with any the compatibility issues.

Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 04, 2014, 04:42 pm
Quote

Secondly, and more importantly, when uploading a sketch compiled as 1284p to a 1284 chip via the 1284p bootloader, it all just goes through without complaint -- the bootloader neither knows nor care what the actual chip signature is, it would seem.


I believe this a long tradition with most (all?) arduino bootloaders in that when AVRDUDE asks the bootloader for the chips signature bytes that it doesn't actually read the chips signature bytes but rather just lies to AVRDUDE by responding with signature bytes that are hard coded in the bootloader. So once you do get a arduino bootloader installed on a AVR chip the IDE will not have problems with normal bootloader uploading.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 04, 2014, 05:51 pm
Quote
The avr-gcc disrtribution doesn't recognise/support the 1284 as a valid -mmcu option.

Is '328 still not covered as well?  We see tons of forum questions with issues with that versus 328P.
I don't know why avrdude.conf can't have a '328 section added:

Supplied with 1.0.5:
Code: [Select]

#------------------------------------------------------------
# ATmega328P
#------------------------------------------------------------

part
    id = "m328p";
    desc = "ATMEGA328P";
    has_debugwire = yes;
    flash_instr = 0xB6, 0x01, 0x11;
    eeprom_instr = 0xBD, 0xF2, 0xBD, 0xE1, 0xBB, 0xCF, 0xB4, 0x00,
  0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF,
  0x99, 0xF9, 0xBB, 0xAF;
    stk500_devcode = 0x86;
    # avr910_devcode = 0x;
    signature = 0x1e 0x95 0x0F;

Copy what's there, delete P and change the signature line, then add 5V Uno with 328 as a board type.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 04, 2014, 06:00 pm

I believe this a long tradition with most (all?) arduino bootloaders in that when AVRDUDE asks the bootloader for the chips signature bytes that it doesn't actually read the chips signature bytes but rather just lies to AVRDUDE by responding with signature bytes that are hard coded in the bootloader. So once you do get a arduino bootloader installed on a AVR chip the IDE will not have problems with normal bootloader uploading.


I just used this scheme to install a optiboot version for a sanguino 644p (optiboot_atmega644p-4-5.hex, downloaded from google code) on the 644 chip, and works fine. It looks like a 644p for bootloader programming purposes.

Seems to be working fine so far.

If you change the mcu type to it's real identity, you get

Code: [Select]

avrdude.exe: Expected signature for ATMEGA644 is 1E 96 09              Double check chip, or use -F to override this check.


that bootloader is such a liar! ;-)

This makes it a pain if you want to swap between using the bootloader and ISP programmer though.

Maybe there should be an option to enable the -F avrdude option in the boards.txt file for each variant.

A syntax enabling additional general option settings, like

Code: [Select]

bobuino.upload.options="-F"


where <variant>.upload.options is a string of one or more space separated options passed to avrdude, in addition to the default options.

Edit: Could be used to address those 328 vs 328p annoyances as well, of course.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 04, 2014, 06:16 pm
Quote
Not really.
I know that you can go in and add board specific compiler defines when using 1.5 and I've considered that option.
However, there are issues with that, the main one being it requires users to go in and muck with their
boards file.


@bill,
I have ported over a few board profiles to 1.5 and my belief is that the A-team intends on each variant to be fully encapsulated, such that reliance on a separate core essentially does not happen unless that core is the default arduino core.  So,
Quote
Many boards can and do use the same core and variant.

Really should not be an issue as the authors for the boards.text must fully encapsulate the 1.5 environment for the user.  The end-user would make no changes or edits.  The only thing lost here is disk space... A few megabytes donated to the better good of the user community.

Ray
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 07:38 pm

Quote
Not really.
I know that you can go in and add board specific compiler defines when using 1.5 and I've considered that option.
However, there are issues with that, the main one being it requires users to go in and muck with their
boards file.


@bill,
I have ported over a few board profiles to 1.5 and my belief is that the A-team intends on each variant to be fully encapsulated, such that reliance on a separate core essentially does not happen unless that core is the default arduino core.  So,
Quote
Many boards can and do use the same core and variant.

Really should not be an issue as the authors for the boards.text must fully encapsulate the 1.5 environment for the user.  The end-user would make no changes or edits.  The only thing lost here is disk space... A few megabytes donated to the better good of the user community.

Ray

I think you guys are not seeing the issues yet.
The issue relates to a combination of the poor implementation of the digital i/o routines
combined with the current declaration of the Arduino digital pin mapping tables.
Libraries that want to get faster i/o currently have to step outside the arduino core i/o routines.
Since each variant within a core has the ability to have its own pin mapping, any code that wants
to do direct AVR port i/o, which today means bypassing the AVR pin mapping tables in the variant file,
must know which variant is being used because it must recreate a parallel set of mappings that exactly match.
And therein lies the problem.
Just knowing the Arduino board name,  or the processor type, or which core,  or even the variant name
doesn't get you there.
You must know which core, and which variant within that core is in play since that is what uniquely
identifies the variant file which specifies the pin mapping tables that are being used.
That includes some board makers that create their own cores such as:
http://www.e-gizmo.com/KIT/gizDuino%20X.html

Currently,  the openGLCD code can fairly accurately compile-time detect the core and variant that is in play but it
requires looking at many different defines and macro declarations that are unique
to certain cores and variants.
It isn't pretty.
This is required because there is no other way to get this information.

My comment about adding defines to the board files was that with 1.5 it is possible
to add pre-processor defines to the board file that can be unique to each board type.
The idea there would be to add a core and variant define to each board type so that
it could be known at compile time, since the IDE does not currently communicate this information
to the code being compiled.
The problem, as I mentioned, is that it requires the user to make these changes
which is not a good dependency.

My comment about many boards using the same core/variant relates to trying to detect
which core & variant are in play simply based on the board name.
The code could look at the board name but that now
requires having conditionals for every board which is a mess and does not scale since
every time a user creates his own board, he would have to go in and modify a library to
support it.

What is needed is to know the core and the variant that is in play.
And currently, this information is not passed to CPP even on 1.5x


More background:

For AVR, I have created a set of extensive compile time macros (AVRIO) with an API that looks similar to the
Arduino digital i/o routines, but are also capable of doing multi-pin i/o in single instructions
if the pins selected allow it (same port, and in proper order).
This is WAY beyond what simple macros like the digitalWritefast() stuff do.
My AVRIO macros take care of everything all at compile time and automagically can adjust to nibble or even bit i/o
if that is the best that can be done given the pins the user selected.
However, to make all the magic work, the AVR pin mappings must be known at compile time.
The issue is that because of the way the Arduino pin mapping tables are currently declared,
the compiler can't reach down into the tables to grab the mappings at compile time.
Because of this, anyone that wants to create faster i/o by doing direct port i/o must resort
to creating parallel mapping tables that can be used at compile time.

There is a way to declare the data differently so that it could be used the way it is used today,
at run time, and also allow the compiler to reach down into the tables at compile time.
The alternate declaration would not affect ram usage or any of the existing code.

But without this change to the data table declarations, any code that wants to do fast i/o
has to create parallel tables.

For those unaware of gcc's ability to look into data tables at compile time,
let me explain a bit further.
gcc is smart enough to be able to reach down inside static const data tables at compile time.
The current arduino pin mapping tables are not static const tables and can't be given
the way the current digital i/o APIs (and i/o macros) are defined.
However, what can be done is to play a few pre-processor games by adding a macro to the declaration that can
be turned on/off which allows that data tables to be declared with and without a static const declaration.
The point of that would be that for the core code they would get the exact same declaration that
they are currently getting.
If the magic define/ifdef is flipped, then the macro gets turned on and the data table becomes a static const data table.
That would allow code such as mine to be able include the tables and reach down into the very same data tables
at compile time to allow compile time optimizations without having to create parallel data tables.
Existing core & sketch code does not have to be modified and would still work.
This change would offer the best of all worlds in that smart code could to things at compile time.
Even smarter code could then fall back to the core code when compile time optimizations are not possible.
In the ideal world this would all be handled in the core code so that it is totally transparent to the users
sketch code and libraries. That way everything simply gets faster i/o whenever possible.

My openGLCD library uses AVRIO to do fast i/o on AVR platforms.
There is also a compile time i/o layer that sits on top of AVRIO that determines if AVRIO can be used
or whether other core & variant specific routines must be used or whether to finally
fall back to using the Arduino Core digital i/o routines.
All this happens at compile time.
This allows the openGLCD i/o code to compile time select the best i/o routines for
a variety of platforms, including AVR, AVR with Teensy, Teensy with ARM,
chipkit pic32, etc..

--- bill

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 09:23 pm

Quote
The issue relates to a combination of the poor implementation of the digital i/o routines
combined with the current declaration of the Arduino digital pin mapping tables.
Libraries that want to get faster i/o currently have to step outside the arduino core i/o routines.
Since each variant within a core has the ability to have its own pin mapping, any code that wants
to do direct AVR port i/o, which today means bypassing the AVR pin mapping tables in the variant file,
must know which variant is being used because it must recreate a parallel set of mappings that exactly match.
And therein lies the problem.


Digesting the above, I believe your concern is toward libraries that would "wish" to provide enhanced capabilities for different board types?  So, a ProMicro/Leonardo may get one treatment but a Teensie 32U4 based biard may get another treatment?

Essentially yes, however,
while it often does appear to boil down to board types, it isn't really about board types at all.
It is about which core and which variant within that core is currently being used.
A given board type selected in the IDE ends up determining which core and which variant is used
based on the boards file.
The library offering the enhance capabilities needs to know which core and which variant
is being used, not which board is being used, to provide the enhancements.

The problem with board/board-type/board-name is it really doesn't mean anything.
It is merely a name assigned to a group of parameters in the boards file.
That name could be anything and users can add their own so there is no bounds
on the names to check for. i..e many boardnames can all use the same core & variant.
However, when it comes to core & variant, there is a bounds and the code
can choose which of those combinations to enhance.



Quote

I can understand why a library author may wish this, but allowing the compiler to automatically invoke such enhancements may be a support nightmare.  Would not it be simplier to overload the library instantiation to provide for an optional user-input string specifying the board name?    Maybe you and the board maker would want to "enhance" but I, the software author, may not wish such feature.

I don't understand your comment.
particularly: "allowing the compiler to automatically invoke such enhancements may be a support nightmare"
Are you saying you want a way to disable this?
That is easy, and in fact my library has a way to disable all the faster i/o capabilities and revert back
to the slow Arduino core code routines.

The board name doesn't provide the information needed.
What has to be known at compile time is the pin mapping.
The pin mapping is based on which core and which variant within that core is currently being used.
Because it has to be known at compile time (and that means compile time of the library code not the sketch code)
then it is not possible for the user code to specify anything since it is outside the library compilation unit.

In terms of support, things actually get simpler
if the declarations for the pin mapping data were changed.
The messy support nightmare that we have today with creating parallel data tables
could disappear because there would only be a single source of the pin mapping data that could
be used at both compile time and run time.
None of the AVR "fast" macros would need to create their own parallel data anymore
as they could reach into the same pin mapping data at compile time.
Lots of things could start to get simpler since some of the complexity in these types of macros goes away
since  since the code could compile time reach down into the variant data table
vs having to create its own parallel data tables.

And in the ideal case, this type code is moved into the core so that the core i/o simply works better/faster.
I mean why push all this work into the libraries, when it could be done in the core?
In fact you can already see some of this happening.
Paul, has added some macros in Teensy that transparently sit on top of the Ardino digital i/o
routines. These transparently speed up i/o significantly when constants are used.
Currently his macros are doing the parallel data method vs the compile time data method.

In my case even faster bit i/o isn't quite good enough. I need byte and nibble i/o.
The current Arduino i/o APIs don't support this.
The AVRIO routines I have, can automatically compile time optimize the 8 i/o pin accesses to create
single instruction byte access when the conditions allow for it.
i.e. if the user selects pins for the 8 glcd data bits that are all consecutive and in the same port,
it will do a single byte access vs 8 individual i/o operations to set the pins.


--- bill




Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 04, 2014, 10:21 pm

I just emailed this to Jack, and thought I'd share it here as well:

I have been testing some more with the Arduino core today, and have been testing with some fairly demanding stuff. No problems detected so far -- all very smooth. Surprisingly so, in fact.


No one was more surprised than me! :D

Quote

With the latest bootloader version (I assume it is the lastest -- it is the one Jack has included in the github distribution), it feels like working with a great big Uno.

I think this stage of the project (1.0.5) is progressing very well. Thanks to Jack for taking the initiative on this -- it needed it, I think.


I want to thank all you guys for the encouragement. This is my first attempt at a core so all input, guidance, bitching, etc. are appreciated!

My next task is to get up close and personal with the pin mapping macros in the pins files for each variant. I know the bobuino is broke with regard to analog input mapping but I think I have a good understanding of what has to happen. Unfortunately I think the fix will require mods to wiring_analog.c which is disappointing because things were just so clean without the core files. Even so, if that is the only file needing mods, then that is still a pretty good deal. The aim is to keep the mappings operating the same so as not to break external libraries that depend on them (I was not aware they were used that way, TY bperrybap).

I do have a couple questions maybe youse can help with.

@Coding Badly -- you said something earlier that made me wonder, is there a straightforward way to include only those core files that need to be changed? It's no big shakes to include them all, it's only about 40 files to the tune of 200kB, but it would be more elegant to not have those files that are identical to the Arduino core.

@pico -- I'd like to understand the lineage of the pins file in your pull request.  Is it (a) a modified version of Crossroads' latest file (http://www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h), (b) a modified version of maniacbug's file (https://github.com/maniacbug/mighty-1284p/blob/master/variants/bobuino/pins_arduino.h), or (c) something else?

It's looking like a busy week here around the ranch, so I don't know how much bandwidth I'll get, but will try to keep progress going as I can; patience is appreciated.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 04, 2014, 10:57 pm
Jack,
It may not be possible to keep all things working if changes are needed.
i.e. if there really is an issue with the analog to digital pin mapping, then fixing it might break a few things.
While I haven't looked at it in quite some time, I seem to have some very vague memories of those mappings
being very funky and not just for the 1284.
Many of the the low level mapping macros are very seldom used and typically not used by sketches, so
I don't think the impact is a big one should something need to be changed/fixed.

One thing to consider, is  how many people are using the 1284 core?
Then of those, how many are using the bobuino core?
Then of those, how many are using the analog mapping macro?
My guess is that the numbers start to get quite low.
One possible solution, if it allows you to use the standard IDE core would be document that the mapping
macro takes an analog channel # vs an Arduino Analog pin #.
Ugly but probably would work, and might be "good enough".

If you want to change/fix it,
my library isn't actually using the mapping macro to get to a pin and then using that pin #.
It is only using the macro to try to detect which core/variant is in play at compile time.

I'd love it if there were some kind of define in the variant files or handed in on the command line
that uniquely identified the specific core/variant. That would make my life so much easier.
Maybe some kind of define(s) could be added to all the 1284 core variant files in the updated release
that can be tested?
Maybe even a version number somewhere?
That way I can check for it and require that users upgrade their core to the more recent version.

This is a general problem with "Arduino".
The arduino team until recently didn't consider that the IDE and things like 3rd party cores and 3rd party libraries
are not all necessarily tracking in sync with each other.
They don't see this issue since they release all their stuff, all cores & all libraries,  all at once.
3rd party guys don't have that luxury.
In my mind the revision of the IDE is separate from the revision of any given core,
which is separate from the revision of any library.


--- bill




Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 04, 2014, 11:26 pm
Bill, just to be clear, when I said "fix", I meant "make it work like it does in maniacbug's current core". My perception is that there are probably more of Crossroads' boards out there than any others, agree or disagree? I'm not terribly up on the "Sanguino", does that come into play here?

Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?

Just a strawman:

Code: [Select]
#define CORE_NAME_MIGHTY_1284P
#define CORE_VARIANT_BOBUINO
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 04, 2014, 11:36 pm
Quote
Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?


I use both cores!  I have 3 Bob's and 2 built maniac's with 2 boards to populate.

I am personally not feeling good about "my" code using different defines to pass intelligence to a library.  It seems "wrong". 

Bill is vocal about his libs (understood why!), but users with diverse hardware should not be asked to modify source code beyond #include <library>.  I would much rather just create a new boards,txt and subordinate the pins_ and core files. 

Going down the #define road will have users such as myself having to deal with the issues ofv3rd party products in source code.  Sounds like a backward move to me.

Ray
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 04, 2014, 11:39 pm
Quote

I'm not terribly up on the "Sanguino", does that come into play here?


Looking at the Sanguino web site ( http://sanguino.cc/ ) they haven't updated their software mods since IDE version 18, so I suspect it's not a very active product anymore if available at all and that was just a 644P based board.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 04, 2014, 11:52 pm

Bill is vocal about his libs (understood why!), but users with diverse hardware should not be asked to modify source code beyond #include <library>.  I would much rather just create a new boards,txt and subordinate the pins_ and core files. 


I didn't get that would require users to modify source code, what did I miss?
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 05, 2014, 12:00 am

Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?
Just a strawman:

Code: [Select]
#define CORE_NAME_MIGHTY_1284P
#define CORE_VARIANT_BOBUINO



Jack, are the #defines not in the user's sketch?

Ray
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 12:01 am


Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?
Just a strawman:

Code: [Select]
#define CORE_NAME_MIGHTY_1284P
#define CORE_VARIANT_BOBUINO



Jack, are the #defines not in the user's sketch?

Ray


No, they'd be in the pins_arduino.h files.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 12:33 am
diff.txt (7.61 KB - downloaded 6 times.)


The version on github...
https://github.com/maniacbug/mighty-1284p/blob/master/cores/standard/Arduino.h

...does not have INPUT_PULLUP defined.  But that difference is missing from your diff file.

Are you working against this version...
https://github.com/maniacbug/mighty-1284p/
https://github.com/maniacbug/mighty-1284p/archive/master.zip
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 05, 2014, 01:00 am
Quote
No, they'd be in the pins_arduino.h files.


No problem then with approach.

Ray
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 05, 2014, 01:01 am


Bill is vocal about his libs (understood why!), but users with diverse hardware should not be asked to modify source code beyond #include <library>.  I would much rather just create a new boards,txt and subordinate the pins_ and core files. 


I didn't get that would require users to modify source code, what did I miss?

I'm not following it either.

Ray, the question of where the defines live, seems to be indicating
some confusion or misunderstanding over the issue as well as the build process.
The code in the libraries has to know certain things at compile time.
Anything put in the sketch is not seen by the library code when the library
code is compiled since the library modules are separate compilation units.

I use and test against MANY cores and variants within those cores
and I never have to modify any source code or change any includes when building sketches.
I simply change the board type in the IDE, click the verify or upload button and
presto magico the code gets built for that board.
But under the hood in order for the library to select all the i/o optimization code for that "board" it has
to know what core and what variant within that core the code is being built for at compile time.

Creating new boards.txt or pins_ or core files doesn't solve that.

Again, it isn't about knowing the board type, or even the core,
the issue is that the library code must know the core and variant within
the core at compile time so that it can create the parallel pin mapping tables
that match what is in the pins_arduino.h variant file.


--- bill

Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 05, 2014, 01:18 am
@ Bill,

NP.  My concern was unfounded as I thought the proposal was to be implemented in the user sketch which I thought awkward.  Behind the scenes is of no concern ... Hence, I have no concern with defines added to pin_arduino.h

I have written a few libs for personal use and I understand/appreciate what is attempting to be accomplished in this thread.  My interest being driven from an investment in multiple 1284p-pu boards.


Ray
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 01:31 am

diff.txt (7.61 KB - downloaded 6 times.)


The version on github...
https://github.com/maniacbug/mighty-1284p/blob/master/cores/standard/Arduino.h

...does not have INPUT_PULLUP defined.  But that difference is missing from your diff file.

Are you working against this version...
https://github.com/maniacbug/mighty-1284p/
https://github.com/maniacbug/mighty-1284p/archive/master.zip


Correct but remember that my diff file is Arduino 1.0 compared to maniacbug/mighty-1284p and INPUT_PULLUP was added in 1.0.1. I have confused a couple people now with my method and I've been told that I should be comparing to 1.0.5. But my aim was to understand the changes that maniacbug made to 1.0 to produce his core. Then I could verify that they were applied to 1.0.5 properly. Old habits die hard and maybe I'm not taking full advantage or putting proper trust into the VCS but I want to understand where changes came from, and what they were made to before I apply them to something else (i.e. the more recent release).
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 01:40 am

My interest being driven from an investment in multiple 1284p-pu boards.


Very interested to have you test then! Make no mistake, the goal is that an upgrade from the current maniacbug core to our new core should introduce no more issues than upgrading from Arduino 1.0 to 1.0.5 would have.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 01:59 am
Just pushed an updated v1.0.5 branch to GitHub. The only change was to bobuino/pins_arduino.h; this consisted of @pico's changes (removed problematic extern declarations; fixed analogInputToDigitalPin() macro) plus the current analogPinToChannel() macro from www.crossroadsfencing.com/BobuinoRev17/pins_arduino.h.

I believe this is the correct pins file to move forward with for the bobuino variant, but is a necessary but not sufficient condition; as I indicated before, changes to wiring_analog.c will probably be needed. That's the next stop, but I'm about done for the day I think.  Have a great week, gents!
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 05, 2014, 03:03 am
I see issues with the wiring_analog.c in both the official AVR core and in the maniacbug core.
They are different but none the less are due to assumptions being made on the pin mappings.

In my opinion the variant should have the freedom to scramble around the pins in any
fashion it wants.
To accommodate this, the wiring_analog.c code needs to always use macros
for conversion of pins and make no assumptions as to how pins are mapped
or how analog pins are mapped to channels.

I believe it could all be handled if the code properly used the variant macros:
analogPinToChannel()
digitalPintoAnalogPin()

Stuff like this would be No No:
Code: [Select]

if (pin >= A0) pin -= A0;

if (pin >= 24) pin -= 24; // allow for channel or pin numbers




While it could be conditional depending on the existence of the appropriate macro,
and then the macros used if they exist,
I think it might be easier and clearer to always use the macro and require it
to be defined in the variant files.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 03:15 am

A summary of the differences I have found between maniacbug's core and the 1.0.5 core...
Code: [Select]
arduino.h - a few additions and some essentially irrelevant changes
cdc.h - irrelevant; the processor does not have a USB pad
hardwareserial.cpp - bug fix for the ATmega8, head and tail made unsigned, various bug fixes for ISR names, bug fix in RXC_vect, bug fix in RX_vect, add support for UCSRC, add support for line parameters (e.g. parity), change flush semantics, add bool operator
hardwareserial.h - ditto
hid.cpp- irrelevant; the processor does not have a USB pad
main.cpp- irrelevant; the processor does not have a USB pad
new.cpp - add support for arrays
new.h - ditto
print.cpp - add a typecast (probably to eliminate a warning), add support for inf and nan
print.h - add check for NULL
stream.cpp - minor change to findUntil, add readString, add readStringUntil
stream.h - change scope of various things, add readString, add readStringUntil
tone.cpp - change to conditionally compile on USE_TIMER instead of processor specific sections, tone should be on timer 2 for the m1284
usbapi.h - irrelevant; the processor does not have a USB pad
usbcore.cpp - irrelevant; the processor does not have a USB pad
usbdesc.h - irrelevant; the processor does not have a USB pad
winterrupts.c - add section for the m32u4, use the ISR macro instead of the deprecated SIGNAL macro
wiring.c - use the ISR macro instead of the deprecated SIGNAL macro, add support for 20 MHz to delayMicroseconds, add support for timer 4 / m32u4
wiring_analog.c - change the way pin numbers are mapped to channels (analogPinToChannel is only used for the t85 family), add support for timer 4
wiring_digital.c - add support for INPUT_PULLUP, add support for timer 4
wiring_private.h - add support for a few more processors
wstring.h - add support for c_str
malloc.c, realloc.c, sectionname.h, stdlib_private.h - only in the 1.0.5 core


As far as I can tell, the only difference that needs attention is...
Code: [Select]
wiring_analog.c - change the way pin numbers are mapped to channels (analogPinToChannel is only used for the t85 family), add support for timer 4
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 05, 2014, 03:22 am
I think by smell the soup is almost ready!  8)
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 03:31 am


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.

What is that conflict?


False alarm.  Sorry about that.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 03:39 am


I came to a startling conclusion. Namely, the current 1.0.5 core (cores) files (i.e. arduino-1.0.5\hardware\arduino\cores\arduino) are sufficient to support the ATmega1284P the same as the current mighty-1284p core. I think all the necessary changes have worked their way into the cores files since 1.0.

It is surprising, if indeed this has been slipstreamed in, that there isn't any record of it, as suggested by RetroLefty. Who got the changes in, I wonder? These things don't just "happen"!


That appears to be exactly what happened starting about two years ago.  For example, here is the introduction of the analogReference constants...
https://github.com/arduino/Arduino/commit/eb380de9726d90d937f2d70d4b94bb60578316c7#diff-c826156f3b969283481ce550d55631a7

As far as I can tell David Mellis did the bulk of the work as part of adding the concept of "variants".

Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 03:51 am
Unfortunately I think the fix will require mods to wiring_analog.c which is disappointing because things were just so clean without the core files.


There is a high probability that changes like that can be merged into 1.5.x.  Christian has been especially amendable lately.   :D

I have no idea how he is with 1.0.5 changes but it's fairly easy to find out.

Quote
@Coding Badly -- you said something earlier that made me wonder, is there a straightforward way to include only those core files that need to be changed?


As far as I know, no.  A "core" is an all or nothing proposition.

Quote
It's no big shakes to include them all, it's only about 40 files to the tune of 200kB, but it would be more elegant to not have those files that are identical to the Arduino core.


I see two (complementary) ways to deal with the problem...
1. Get Christian to merge the changes.
2. Maintain a Github repository with the m1284 specific changes on a separate branch that's occasionally merged with the official core.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 05, 2014, 03:56 am
#3: Just let me at wiring_analog.c  with my soldering iron?
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 04:54 am
I'm not quite following all the issues mentioned in this thread. However, I thought I'd comment, given my webpage was cited. I designed an ATmega 1284 pcb a little over a year ago, and have been using it since then on approx 90% of my projects. Love the chip, and not had any problems using IDE v.1.05 - my boards.txt file looks as follows:

##############################################################
tredicip.name=Tredici-1284P
tredicip.upload.protocol=arduino
tredicip.upload.maximum_size=130048
tredicip.upload.speed=115200
tredicip.bootloader.low_fuses=0xff
tredicip.bootloader.high_fuses=0xde
tredicip.bootloader.extended_fuses=0xfd
tredicip.bootloader.path=optiboot
tredicip.bootloader.file=optiboot_atmega1284p.hex
tredicip.bootloader.unlock_bits=0x3F
tredicip.bootloader.lock_bits=0x0F
tredicip.build.mcu=atmega1284p
tredicip.build.f_cpu=16000000L
#tredicip.build.core=arduino:arduino
tredicip.build.core=standard
tredicip.build.variant=tredici


FWIW, I discovered I had modified the page cited back in October, but never uploaded it. The new page includes section 10, regarding 1- 1/2 dozen libraries I had tried with the chip, and the various mods/etc I needed to make to use them.
http://www.ot-hobbies.com/resource/ard-1284.htm
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 05, 2014, 05:03 am
There's a bunch of Bobuinos out there.  On the order of 50-60 assembled kits & boards. I have 25 more kits ready to go, and am close to releasing a new version of the Original Bobuino with SD card, RTC, RS232 buffer for 2nd serial, some proto area to aid in adding RF modules, to ease assembly for my wife & I.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 10:08 am
Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?


There are two that will help transition to 1.5...

[font=Courier New]ARDUINO_ARCH_AVR [/font]is defined for AVR based boards

[font=Courier New]ARDUINO_AVR_{tag} [/font]is defined for the selected board where {tag} is the "board ID" (the text before the first dot from the boards.txt entries).  For example, for the Original Mighty 1284p 16MHz (https://github.com/maniacbug/mighty-1284p/blob/master/boards.txt#L58) the board ID is MIGHTY which makes the #define [font=Courier New]ARDUINO_AVR_MIGHTY[/font].  For the Bobuino board the #define is [font=Courier New]ARDUINO_AVR_BOBUINO[/font].
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 10:16 am
Correct but remember that my diff file is Arduino 1.0 compared to...


Ah.  Got it.

Quote
But my aim was to understand the changes that maniacbug made to 1.0 to produce his core.


No sweat.  Just want to make certain nothing gets missed.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 05, 2014, 10:19 am
#3: Just let me at wiring_analog.c  with my soldering iron?


XD
Title: Re: Updating the mighty-1284p core
Post by: pico on May 05, 2014, 12:06 pm

I'm not quite following all the issues mentioned in this thread.


Arguably, far and away the most significant piece of take home info, is that you might want to try changing

#tredicip.build.core=arduino:arduino
tredicip.build.core=standard

to

tredicip.build.core=arduino:arduino
#tredicip.build.core=standard

and see how you go.

By some great sleuthing documented in this thread, it has been determined that almost all the important changes in standard "Mighty" core have since found their way into the standard Arduino 1.0.5 core.

Looks like some relatively minor tidying up still to be done, but the 1284p core will very soon be caught up to 1.0.5!


Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: mrburnette on May 05, 2014, 05:37 pm

There's a bunch of Bobuinos out there.  On the order of 50-60 assembled kits & boards. I have 25 more kits ready to go, and am close to releasing a new version of the Original Bobuino with SD card, RTC, RS232 buffer for 2nd serial, some proto area to aid in adding RF modules, to ease assembly for my wife & I.


I have no idea about the population of the Wayne Chu "Sleeping Beauty" board, but I recently came into 2 of these to go with my 3 Bobuinos.  Interestingly, the download of the support files from Wayne's site http://www.rasmicro.com/Sleeping_Beauty/ (http://www.rasmicro.com/Sleeping_Beauty/) also downloads the Bobuinos profile too: In the ZIP the two boards share the same "standard" set of core files which, according to Readme, are sourced from http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/
(http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/).

(I completely missed this connection until I saw two Bobduino listed  in my Arduino GUI boards list!)

Diff'ing the two core directories proved the core files are identical.
...\Documents\Arduino\hardware\maniacbug-SB-1284p\cores\
...\Documents\Arduino\hardware\mighty-1284p\cores\
Assumption... if Bobuinos are happy, the Sleeping Beauty should be happy, too.

Diff'ing the pins_arduino.h files is a PDF attached... just for completeness for anyone interested and unfamiliar with SB.

Ray
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: pico on May 05, 2014, 06:06 pm

Diff'ing the two core directories proved the core files are identical.
...\Documents\Arduino\hardware\maniacbug-SB-1284p\cores\
...\Documents\Arduino\hardware\mighty-1284p\cores\
Assumption... if Bobuinos are happy, the Sleeping Beauty should be happy, too.


Ray,

The schematic for the SB shows a substantially different pin mapping for the SB compared to the Bobuino (I've attached a snip below). Are you saying that the SB folks are suggesting using the Bobuino pins_arduino.h file? If their published schematic is correct, that will never work...

But perhaps I am misunderstanding what you are saying.

Edit: OK, I see from your diff file you are aware the pins_arduino.h files are very different. But I still don't understand what you are getting at... just that the SB guys are using unmodified 1.0 core files, and have only written a new pins_arduino.h?
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: mrburnette on May 05, 2014, 07:15 pm

Ray,
...
Edit: OK, I see from your diff file you are aware the pins_arduino.h files are very different. But I still don't understand what you are getting at... just that the SB guys are using unmodified 1.0 core files, and have only written a new pins_arduino.h?


So what I observed is that SB is shipping a set of core files that are identical to Bobduino and the only difference is that they have a unique pins_arduino.h ... the ZIP archive SB supplies includes a boards.txt file that also maps in the Bobduino board type and uses a common set of core files (excepting the aforementioned pins_arduino.h of which there are one for Bobduino and one for Sleeping Beauty.)  Said core files for Bobduino are same core files for Sleeping Beauty.
boards.txt as supplied by downloading SB support files:
Code: [Select]

##############################################################

bobuino.name=Bobuino
bobuino.upload.protocol=arduino
bobuino.upload.maximum_size=130048
bobuino.upload.speed=115200
# 0xfe = low power crystal, 16 MHz?
bobuino.bootloader.low_fuses=0xff // fe?
bobuino.bootloader.high_fuses=0xde
bobuino.bootloader.extended_fuses=0xfd
bobuino.bootloader.path=optiboot
bobuino.bootloader.file=optiboot_atmega1284p.hex
bobuino.bootloader.unlock_bits=0x3F
bobuino.bootloader.lock_bits=0x0F
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino

##############################################################
sleepingbeauty.name=Sleeping Beauty
sleepingbeauty.upload.protocol=arduino
sleepingbeauty.upload.maximum_size=130048
sleepingbeauty.upload.speed=115200
# 0xfe = low power crystal, 16 MHz?
sleepingbeauty.bootloader.low_fuses=0xf7 // changed by R.S.
sleepingbeauty.bootloader.high_fuses=0xde
sleepingbeauty.bootloader.extended_fuses=0xfd
sleepingbeauty.bootloader.path=optiboot
sleepingbeauty.bootloader.file=optiboot_atmega1284p.hex
sleepingbeauty.bootloader.unlock_bits=0x3F
sleepingbeauty.bootloader.lock_bits=0x0F
sleepingbeauty.build.mcu=atmega1284p
sleepingbeauty.build.f_cpu=16000000L
#sleepingbeauty.build.core=arduino:arduino
sleepingbeauty.build.core=standard
sleepingbeauty.build.variant=sleepingbeauty

##############################################################

I found it strange that SB in the ZIP would include the Bobduino and would encapsulate it within the Sleeping Beauty directory structure.  

Point is, if one already has a Bobduino installed as CrossRoads specifies, the SB installation will create two Bobduino entries.  But the cores files used by the two Bobduino entries is also the same core file used by Sleeping Beauty.  
Code: [Select]

C:\Users\owner\Documents\Arduino\hardware\maniacbug-SB-1284p>tree
Folder PATH listing for volume SYSTEM
Volume serial number is 0031002D 49E8:2F05
C:.
????bootloaders
?   ????optiboot
?   ????standard
????cores
?   ????standard
????examples
?   ????MiscFunctions
?   ????SleepingBeauty1284P
?   ????SpeakerFunctions
????HexBackUp
????variants
   ????bobuino
   ????sleepingbeauty

C:\Users\owner\Documents\Arduino\hardware\maniacbug-SB-1284p>


core files installed by installing Bobduino as CrossRoads specifies:
Code: [Select]

C:\Users\owner\Documents\Arduino\hardware>tree mighty-1284p
Folder PATH listing for volume SYSTEM
Volume serial number is 49E8-2F05
C:\USERS\OWNER\DOCUMENTS\ARDUINO\HARDWARE\MIGHTY-1284P
????1MBAUD_m1284
????bootloaders
?   ????optiboot
?   ????standard
????cores
?   ????standard
????variants
   ????avr_developers
   ????bobuino
   ????standard

C:\Users\owner\Documents\Arduino\hardware>


The files in ...\cores\standard are identical in both installations.

So, my thinking is that any core changes made to Bobduino and tested OK will also be OK on the Sleeping Beauty.  I am assuming here that the supplied pins_arduino.h file is excluded from this core refresh initiative.  It is my opinion that pins_arduino.h (or .c) are the board designer's responsibility - even if there are errors.  Of course, what I am looking for is an agreement on this premise of exclusion.

Ray
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 07:57 pm
If you look in \variants\bobuino, you'll see the only useful file is pin_arduino.h (the .ods file is vestigial), and all it specifies is the chip pin to header mapping. This has nothing to with which boot loader is installed, or the basic functional compilation of code, only with the header mapping. The compilation business, and any differences, are specified in the boards.txt file.
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: JChristensen on May 05, 2014, 08:04 pm

So, my thinking is that any core changes made to Bobduino and tested OK will also be OK on the Sleeping Beauty.  I am assuming here that the supplied pins_arduino.h file is excluded from this core refresh initiative.  It is my opinion that pins_arduino.h (or .c) are the board designer's responsibility - even if there are errors.  Of course, what I am looking for is an agreement on this premise of exclusion.


The current bobuino/pins_arduino.h file from the refresh initiative (https://github.com/JChristensen/mighty-1284p/blob/v1.0.5/variants/bobuino/pins_arduino.h) is a combination of Crossroads' current file plus changes made by pico; it is not the same as in maniacbug's current mighty-1284p core. But more changes are coming as there are issues with the bobuino variant.

I do not intend to address additional boards in the refresh until we get an initial version out that supports the current three variants (avr_developers, bobuino, standard). After that I hope to add my Mighty Mini 1284P board and a 1MHz version of Optiboot; adding the Sleeping Beauty board is a possibility too if there is demand for it.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 05, 2014, 08:09 pm

If you look in \variants\bobuino, you'll see the only useful file is pin_arduino.h (the .ods file is vestigial), and all it specifies is the chip pin to header mapping. This has nothing to with which boot loader is installed, or the basic functional compilation of code, only with the header mapping. The compilation business, and any differences, are specified in the boards.txt file.


Why, of course!
This thread runs deeper and the dialog centers around testing of changes to the core that are being made and published in an alpha fashion right now.  There are a variety of boards using AVR 1284 chips.  The question to the working team was simply that two different boards are using the same core and the only difference is in the pins_arduino.h mapping.  Must each be tested?  Or, can only one be tested?  Who really owns the pins_arduino.h (and .c for some AT_tiny) ... this is not a technical question so much as a political one.

Ray
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: mrburnette on May 05, 2014, 08:19 pm


I do not intend to address additional boards in the refresh until we get an initial version out that supports the current three variants (avr_developers, bobuino, standard). After that I hope to add my Mighty Mini 1284P board and a 1MHz version of Optiboot; adding the Sleeping Beauty board is a possibility too if there is demand for it.


Jack,
Thank you, that is all I needed to know.  Somewhere down the line, a decision is going to have to be made about pin mappings and ownership of the mapping process, that is, the pins_arduino.h (and .c for AT_tiny).  At this moment, I still think that the mapping file should be defined as outside-the-scope of the core refresh initiative.

@CrossRoads:
You may wish to contact the Sleeping Beauty author, Wayne Chu, and discuss the inclusion of your Bobduino files within his ZIP distribution.  As i stated earlier, I was initially unaware of this until I discovered 2 separate Bobduino entires on 1.0.5r2 and started looking for the cause.  As changes are made to your official release of Bobduino core files, it would be easy for an end-user to become confused with multiple entries in their GUI. (Issue runs much deeper, IMO.)

Ray
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 08:29 pm
Quote
Who really owns the pins_arduino.h

I think the obvious answer is , the guy who made the new board owns pins_arduino.h - unless the header pinout exactly matches one of the originals. And he just supplies this plus his boards.txt file with the board. If the header pinout matches one of the originals, he just says select that board in the IDE.

Otherwise, maniacbug will have to add a new variant to the github repository for each new board. And if you've been paying attention, you'll see m-b is MIA completely. Eg, he's never even addressed the bugs I discovered in the bobuino variant 1-year ago, and mentioned on my page cited earlier.

https://github.com/maniacbug/mighty-1284p/issues/5

And/or someone in central-receiving would have to add a patch to files-centrale for every new board in creation.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 05, 2014, 08:31 pm

Adding a couple #defines seems mostly harmless. If there is a consensus among those participating in this thread, I'd be all for it. What format would work best?


There are two that will help transition to 1.5...

[font=Courier New]ARDUINO_ARCH_AVR [/font]is defined for AVR based boards

[font=Courier New]ARDUINO_AVR_{tag} [/font]is defined for the selected board where {tag} is the "board ID" (the text before the first dot from the boards.txt entries).  For example, for the Original Mighty 1284p 16MHz (https://github.com/maniacbug/mighty-1284p/blob/master/boards.txt#L58) the board ID is MIGHTY which makes the #define [font=Courier New]ARDUINO_AVR_MIGHTY[/font].  For the Bobuino board the #define is [font=Courier New]ARDUINO_AVR_BOBUINO[/font].



I know that the 1.5x IDE sets those types of defines and passes them in.
But in reality knowing the board usually isn't what is really needed.
Can you make things work? Sometimes, but not in all cases.
Like I've been saying all along what often really matters is the variant within the core.

For example, suppose the code triggers on a particular board, but then the user goes in and creatse a few extra board
types to be able to do things like have a proper board type than can fully use the flash when ISP programming
vs bootloader programming.
Currently, it takes a different board type to do this since the board indicates the available flash size and it is just a bit bigger
when not using a bootloader.
Or perhaps I want to automate using an ISP programmer so I can just push the upload button vs using the
upload using programmer.
That too currently requires a new board type.

So the problem becomes, code that wants to do special optimizations based on the variant,
can't reliably use the board to detect the variant since many boards can all be mapping to the same core/variant combination.

I really wish there were defines for ALL the information:
- core
- variant
- boardname

That way everything that people might want/need would be available.
As it is today, 1.x provides nothing, and 1.5x IDE only provides the core and the boardname.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 08:48 pm


I'm not quite following all the issues mentioned in this thread.

Arguably, far and away the most significant piece of take home info, is that you might want to try changing
#tredicip.build.core=arduino:arduino
tredicip.build.core=standard

to
tredicip.build.core=arduino:arduino
#tredicip.build.core=standard

and see how you go.


Thanks pico, now I begin to understand. Maniac-bug added the \cores\standard\ files to the library because \cores\arduino in previous incarnations of the IDE didn't include handling of ATmega1284 chips - as I discovered a year ago ...
http://www.ot-hobbies.com/resource/ard-1284.htm#lack2

My 1284 code compiles ok after making the change to my boards.txt file, so I assume it will run alright too.

EDIT: also, I had no idea what Jack was talking about in his opening post, because as I see it, the necessary changes for the 1284(P) chips had already been included in IDE v.1.05 - and they work, since I've been using that IDE for over a year now - although many of the libraries still need fixing, as I noted,
http://www.ot-hobbies.com/resource/ard-1284.htm#lib2
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 05, 2014, 09:00 pm

Quote
Who really owns the pins_arduino.h

I think the obvious answer is , the guy who made the new board owns pins_arduino.h - unless the header pinout exactly matches one of the originals. And he just supplies this plus his boards.txt file with the board. If the header pinout matches one of the originals, he just says select that board in the IDE.
GeeWhiz...
"own" was meant in the context of this thread not in some philosophical property sense.  I am not going to rehash all of the dialog before...

Otherwise, maniacbug will have to add a new variant to the github repository for each new board. And if you've been paying attention, you'll see m-b is MIA completely. Eg, he's never even addressed the bugs I discovered in the bobuino variant 1-year ago, and mentioned on my page cited earlier.
People do become ill.  His blog has been idle for 2 years as has his forum presence.  Or, maybe he ran off with his neighbor's wife before getting back to you on those errors.  Based upon all of his previous involvement and activity, I fear something has occurred beyond his control and I simply respect his previous effort and products for Open Source.
https://github.com/maniacbug/mighty-1284p/issues/5

And/or someone in central-receiving would have to add a patch to files-centrale for every new board in creation.
I love sarcasm.... I sometimes use it too.


Ray
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 09:04 pm

People do become ill.  His blog has been idle for 2 years as has his forum presence.  Or, maybe he ran off with his neighbor's wife before getting back to you on those errors.  Based upon all of his previous involvement and activity, I fear something has occurred beyond his control and I simply respect his previous effort and products for Open Source.
https://github.com/maniacbug/mighty-1284p/issues/5


I suppose he's just gotten on to other things ... and there are only so many hours in a day. Hopefully, Crossroads mentions not to use the buggy maniac-bug github bobuino variant when he sells his boards, and supplies something correct.
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: oric_dan on May 05, 2014, 09:19 pm

But more changes are coming as there are issues with the bobuino variant.


BTW, I had mentioned some of these to m-b a year ago, in case you hadn't seen it,
https://github.com/maniacbug/mighty-1284p/issues/5
Title: Re: Updating the mighty-1284p core: Bobuinos & Sleeping Beauty
Post by: JChristensen on May 05, 2014, 10:09 pm

Jack,
Thank you, that is all I needed to know.  Somewhere down the line, a decision is going to have to be made about pin mappings and ownership of the mapping process, that is, the pins_arduino.h (and .c for AT_tiny).  At this moment, I still think that the mapping file should be defined as outside-the-scope of the core refresh initiative.


Thanks, I'm just trying to keep scope creep to a minimum for now. Other boards and ownership are very good topics for discussion though and whatever conclusions we come to should be documented in the core's ReadMe file. I think I pretty much agree that the designer of a board is responsible for the pins file, but we also need to consider what happens if that person drops out of the picture for any reason (maybe the answer is do nothing, and I'd be ok with that too).

Having said that, given the approach we're taking here, I feel some obligation to not have the refresh introduce errors or unexpected changes, so am taking on some responsibility to make changes to the pins files to achieve that end. This is partly because either I'm not sure of who the owner is, whether they are available, etc (the exception being Crossroads of course ). I would have started with maniacbug but I'm assuming he's not interested at this point. But that only leaves two variants to deal with besides the bobuino so it's not a super big deal.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 05, 2014, 10:30 pm
Quote
Hopefully, Crossroads mentions not to use the buggy maniac-bug github bobuino variant when he sells his boards, and supplies something correct.

Yes, I have the pins_arduino.h I use myself on my website.
I'll post a link to new cores or whatever comes out of this when it's all done.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 10:43 pm
All, I just pushed an update (https://github.com/JChristensen/mighty-1284p) that should be ready for some serious testing. I think I've done fairly exhaustive analogRead() testing on all three variants and I think all is well, but of course I'll feel better with second opinions.

Summary of changes.

1. Copied the vanilla core files from 1.0.5 back in as wiring_analog.c needed to be changed. Put them into a directory called cores/mighty. (maniacbug's version used cores/standard, but I found that confusing since there is a board variant named standard.)

2. Modified the wiring_analog.c file so that it always uses the analogPinToChannel() macro for ATmega1284/P and for 644/A/P/PA. Therefore, analogPinToChannel() is required to be present in every pins_arduino.h file in the core (this was not previously the case). The vanilla wiring_analog.c code uses only the analogPinToChannel() macro. By rewriting the analogPinToChannel() macros, it was unnecessary to use additional macros and only a single line was changed in wiring_analog.c. (The maniacbug core version of wiring_analog.c also used the digitalPinToAnalogPin() macro. Where they existed before in the pins_arduino.h files, I have preserved the analogInputToDigitalPin() and digitalPinToAnalogPin() macros unchanged, in case they are used by libraries, etc.)

3. The avr_developers and standard pins_arduino.h files had NUM_DIGITAL_PINS defined as 31, these were changed to 32.

4. In all variants' pins_arduino.h files, "static const uint8_t LED" was changed to LED_BUILTIN to be consistent with Arduino v1.0.5.

5. All entries in boards.txt files were changed to point at the mighty core (.build.core=mighty).
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 10:53 pm
I guess there is no easy way to fix the standard libraries that are part of the IDE. ???
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 10:59 pm

I guess there is no easy way to fix the standard libraries that are part of the IDE. ???


Unsure, but not that I know of. I will probably make a minor change to the Ethernet library to straighten out the SS pin.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 05, 2014, 11:40 pm
Jack;

I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.

Lefty
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 05, 2014, 11:44 pm
I just discovered that I could copy the Ethernet library from the IDE directory over into the \libraries subdirectory in my sketch folder, so there are now 2 identical libraries, and the 1284 code compiles ok without error.

The following compiler msg indicates that the compiler went to the IDE directory to get the SPI library, which was not cloned, but got the Ethernet library code from the cloned version in the sketch subdirectory.
Code: [Select]

-IC:\winapps\ArduinoIDE\arduino-1.0.5-windows\libraries\SPI
-IC:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet
-IC:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet\utility C:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet\EthernetUdp.cpp -o


LATE EDIT: btw, the reason the Ethernet library worked here at all was because I had previously patched the library residing in the IDE directory so it would work with the 1284. So, the patched version was the one copied to the sketch folder. I've patched all the libraries residing in my current IDE v.1.05 directory.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 11:48 pm

I just discovered that I could copy the Ethernet library from the IDE directory over into the \libraries subdirectory in my sketch folder, so there are now 2 identical libraries, and the 1284 code compiles ok without error.


Very good to know, thanks! I think I'll take the same approach.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 05, 2014, 11:50 pm

I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.


Appreciate the testing and feedback! I just recently started playing with the 1284P so the whole thing is really just a self-serving project  ;)
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 06, 2014, 12:06 am

EDIT: also, I had no idea what Jack was talking about in his opening post, because as I see it, the necessary changes for the 1284(P) chips had already been included in IDE v.1.05 - and they work, since I've been using that IDE for over a year now - although many of the libraries still need fixing, as I noted,
http://www.ot-hobbies.com/resource/ard-1284.htm#lib2


(Having trouble keeping up with all the posts here.)

It is certainly possible that we have just re-discovered the wheel. If nothing else (assuming the current commit is substantially correct) we now have a 1.0.5-based core that supports three variants with very minimal changes and have made improvements to the pins files. Two of the three variants in the core required a small change to a core file, the popular bobuino being one of them.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 04:33 am

with very minimal changes


If the core changes required are really going to boil down changing one line of code in one core file (wiring_analog.c), then a user installing the "Mighty" stuff over a 1.0.5 installation could simply copy an updated version of wiring_analog.c over the "official" distro one as part of the new "Mighty 1284p" install. Either manually, or as part of the unzip process. Basically a documentation fix to the "Mighty" distribution.

And if a 1.0.6 ever surfaces, the requisite fix to wiring_analog.c will already be there, one would assume.

Then, (if all turns out as expected), we are in the happy position of simply having to require a hardware developer to provide a new pins_arduino.h for every new variant with an ever more imaginative pin mapping that arrives on the scene!  SB, Goldilocks, FooBoard1284p9000 etc. can just add their pins_arduino.h file, and the appropriate required addition to boards.txt (too bad there isn't a nice modular why of adding to boards.txt at the variant level. A little boards.txt with a single entry in the bobuino directory under variants, for example.)

Oh well. Nothing's perfect! ;-)

But this is looking pretty good.

Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 06, 2014, 04:49 am
The whole boards.txt, both the IDE and the user's hardware folder addition, now results in a board selection menu list from hell. I just spent a bunch of time adding #'s in from of every line for the board types I don't have (or want) and haven't even started with the IDE's main copy. I applaud the Arduino developers policy of still supporting even the >6 year old original board, but with all boards they have added over the years, plus any 3rd party boards added via user's hardware method, we now have a almost unmanageable list to deal with. Be nice to have the IDE offer a means to "check list" on or off the board types to be displayed from the main menu board selection menu.

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 06:44 am


EDIT: also, I had no idea what Jack was talking about in his opening post, because as I see it, the necessary changes for the 1284(P) chips had already been included in IDE v.1.05 - and they work, since I've been using that IDE for over a year now - although many of the libraries still need fixing, as I noted,
http://www.ot-hobbies.com/resource/ard-1284.htm#lib2


(Having trouble keeping up with all the posts here.)

It is certainly possible that we have just re-discovered the wheel. If nothing else (assuming the current commit is substantially correct) we now have a 1.0.5-based core that supports three variants with very minimal changes and have made improvements to the pins files. Two of the three variants in the core required a small change to a core file, the popular bobuino being one of them.

This is why I was confused with the first 8 pages of this thread. I thought we had it all pretty much straightened out a year ago - as per the comments on my web page, and also the issue I posted to the maniacbug github page. The fixes back then to the Bobuino pins_arduino.h file fixed the analog issues, as far as I know. I've been using those fixes for a year now, as well as the bootloader, boards.txt, and standard core info from maniac-bug's github page. I suppose there may be something else flukey somewheres that I've not seen.  But then, over the past year, I've probably also written 50X more code for the 1284 than anyone else around here too, and not seen problem one, so ???


If the core changes required are really going to boil down changing one line of code in one core file (wiring_analog.c), then a user installing the "Mighty" stuff over a 1.0.5 installation could simply copy an updated version of wiring_analog.c over the "official" distro one as part of the new "Mighty 1284p" install. Either manually, or as part of the unzip process. Basically a documentation fix to the "Mighty" distribution.

And if a 1.0.6 ever surfaces, the requisite fix to wiring_analog.c will already be there, one would assume.

Then, (if all turns out as expected), we are in the happy position of simply having to require a hardware developer to provide a new pins_arduino.h for every new variant with an ever more imaginative pin mapping that arrives on the scene!  SB, Goldilocks, FooBoard1284p9000 etc. can just add their pins_arduino.h file, and the appropriate required addition to boards.txt (too bad there isn't a nice modular why of adding to boards.txt at the variant level. A little boards.txt with a single entry in the bobuino directory under variants, for example.)

Personally, I think that's already been dealt with. No additions, no "appended" lists. Each person with a new variant can simply create a new folder to put in \hardware in the sketches directory. I only have the one for my own board, and none of the other 1284 variants, so only it shows up on the IDE boards list, rather than a uselessly long pile of them.

Also, thinking about it, I like the way maniac-bug used
Code: [Select]
#tredicip.build.core=arduino:arduino
tredicip.build.core=standard

This allowed him to implement core fixes for the 1284 without having to muck with the main IDE directories, and use them exclusive of their ever being fixed in the IDE. Better than making one-on-one patches to the IDE yourself. Wait for the next version.

Also, as I just indicated to Jack, it should be possible to patch the necessary standard libraries for use with the 1284, and clone them to the \libraries subdirectory in the sketch directory. To me, preferable to patching the IDE libraries themselves [although that's what I've actually done over the past year].


The whole boards.txt, both the IDE and the user's hardware folder addition, now results in a board selection menu list from hell. I just spent a bunch of time adding #'s in from of every line for the board types I don't have (or want) and haven't even started with the IDE's main copy. I applaud the Arduino developers policy of still supporting even the >6 year old original board, but with all boards they have added over the years, plus any 3rd party boards added via user's hardware method, we now have a almost unmanageable list to deal with. Be nice to have the IDE offer a means to "check list" on or off the board types to be displayed from the main menu board selection menu.

I would simply save a copy of the primary boards.txt file in the IDE, and then edit out all of the unused boards. Similarly for the boards.txt file in the  1284 folder in \hardware in the sketches directory, like I mentioned above.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 06:56 am

Personally, I think that's already been dealt with. No additions, no "appended" lists. Each person with a new variant can simply create a new folder to put in \hardware in the sketches directory. I only have the one for my own board, and none of the other 1284 variants, so only it shows up on the IDE boards list, rather than a uselessly long pile of them.


That's fair enough if you are going to be using the standard Arduino core arduino:arduino, but...


Also, thinking about it, I like the way maniac-bug used
Code: [Select]
#tredicip.build.core=arduino:arduino
tredicip.build.core=standard

This allowed him to implement core fixes for the 1284 without having to muck with the main IDE directories, and use them exclusive of their ever being fixed in the IDE. Better than making one-on-one patches to the IDE yourself. Wait for the next version.


to do this you have to be under the "mighty" variants folder. (edit: Or maybe not. It might work to specify "mighty-1284p:standard" as the alternative perhaps.)

Matter of choice, I suppose, as to how the developer would prefer to handle things.

I suppose it needs discussing whether it is even desirable and necessary at this point to maintain a separate "mighty" core.  If the answer, on balance, is "no", then it makes the choice more or less automatically.



Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 07:24 am

Also, as I just indicated to Jack, it should be possible to patch the necessary standard libraries for use with the 1284, and clone them to the \libraries subdirectory in the sketch directory. To me, preferable to patching the IDE libraries themselves [although that's what I've actually done over the past year].


And perhaps, moving forward, the patched libs should become the proper focus of the 1284p support repository under version control.

The core is now fixed, but the libs still aren't... and libs matter, obviously, if you want full support for the chip.

Your changes and contributions to this would make an obvious starting point for this effort, if you were agreeable.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 07:47 am


Personally, I think that's already been dealt with. No additions, no "appended" lists. Each person with a new variant can simply create a new folder to put in \hardware in the sketches directory. I only have the one for my own board, and none of the other 1284 variants, so only it shows up on the IDE boards list, rather than a uselessly long pile of them.


That's fair enough if you are going to be using the standard Arduino core arduino:arduino, but...

Ummm, as I see it, they're ALL going to be using the same core and likely the same bootloader, since those are tuned to the chip, and not the header mapping. The only unique parts for specific boards are in the boards.txt and pins_arduino.h files.

Quote


Also, thinking about it, I like the way maniac-bug used
Code: [Select]
#tredicip.build.core=arduino:arduino
tredicip.build.core=standard

This allowed him to implement core fixes for the 1284 without having to muck with the main IDE directories, and use them exclusive of their ever being fixed in the IDE. Better than making one-on-one patches to the IDE yourself. Wait for the next version.


to do this you have to be under the "mighty" variants folder. (edit: Or maybe not. It might work to specify "mighty-1284p:standard" as the alternative perhaps.)

What I did was clone the maniac-bug folder, rename it, and keep the cores, but delete all the unused variant subdirectories and boards from the boards.txt file. Shows up as:
\hardware\tredici\
\hardware\tredici\variants\tredici
\hardware\tredici\cores\standard
\hardware\tredici\bootloaders\optiboot

That's all. Then it's customized for my one board, and the others are gone.

Quote
Matter of choice, I suppose, as to how the developer would prefer to handle things.

I suppose it needs discussing whether it is even desirable and necessary at this point to maintain a separate "mighty" core.  If the answer, on balance, is "no", then it makes the choice more or less automatically.

You can keep a "mighty" core as a template, but then it can be customized by the board builder, as I did. Then you don't need a central repository.

Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 07:57 am

You can keep a "mighty" core as a template, but then it can be customized by the board builder, as I did. Then you don't need a central repository.


Going forward, we would expect the "template" will be the standard Arduino core.

As a board builder, I don't think I would be too keen on having to maintain my own set of core files. But then again, that's why I did choose to follow the "bobuino" pin definitions. ;-)

But if it is decided a separate "mighty" core is to be maintained in parallel for "hot fixes" or whatever, I'd just opt for the "mighty-1284p:standard" option in boards.txt to choose between them, rather than have a copy in a separate variants directory, as you describe.

But to each their own. :-) If you had to have a patch that pertains to your particular board only, that might be the only sensible way.

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 07:57 am


Also, as I just indicated to Jack, it should be possible to patch the necessary standard libraries for use with the 1284, and clone them to the \libraries subdirectory in the sketch directory. To me, preferable to patching the IDE libraries themselves [although that's what I've actually done over the past year].


And perhaps, moving forward, the patched libs should become the proper focus of the 1284p support repository under version control.

The core is now fixed, but the libs still aren't... and libs matter, obviously, if you want full support for the chip.

Your changes and contributions to this would make an obvious starting point for this effort, if you were agreeable.


Eventually, all the library fixes need to filter back to the IDE library directories, the same way as the 1284 core fixes are currently being taken up in newer versions of the IDE. Ardunio-Centrale [ie, the IDE coders] needs to fix the standard libraries too. These library fixes have nothing whatsoever to do with different 1284 boards [which can be handled by board-builders in their boards.txt and pins_arduino,h files], only with the 1284 "chip" support.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 08:03 am

These library fixes have nothing whatsoever to do with different 1284 boards [which can be handled by board-builders in their boards.txt and pins_arduino,h files], only with the 1284 "chip" support.


Yes, I appreciate that, which is why the modified libs need to be made available for use by all 1284p boards, until those changes percolate through to the official distributions.

Exactly analogous to what's actually happened with the core files since maniac bug released his first patched versions after 1.0.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 08:04 am


You can keep a "mighty" core as a template, but then it can be customized by the board builder, as I did. Then you don't need a central repository.


Going forward, we would expect the "template" will be the standard Arduino core.

As a board builder, I don't think I would be too keen on having to maintain my own set of core files. But then again, that's why I did choose to follow the "bobuino" pin definitions. ;-)

But if it is decided a separate "mighty" core is to be maintained in parallel for "hot fixes" or whatever, I'd just opt for the "mighty-1284p:standard" option in boards.txt to choose between them, rather than have a copy in a separate variants directory, as you describe.

But to each their own. :-) If you had to have a patch that pertains to your particular board only, that might be the only sensible way.


The core has nothing to do with board header pinouts, so only "one" core needs to exist, as I already indicated. And that can be in the IDE, once all the files [and libraries too] have been properly patched by the IDE coders for the 1284 chips.

I didn't make any changes to maniac-bugs cores\standard files, I only added a boards.txt and pins_arduino.h file for my own board header mapping.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 08:10 am
In that case, why did you bother to replicate these?


[\hardware\tredici\cores\standard
\hardware\tredici\bootloaders\optiboot


You could have just referred to the core files from your boards.txt as "mighty-1284p:standard", presumably.

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 08:20 am

In that case, why did you bother to replicate these?


[\hardware\tredici\cores\standard
\hardware\tredici\bootloaders\optiboot


You could have just referred to the core files from your boards.txt as "mighty-1284p:standard", presumably.

You can see my entire boards.txt file in reply #109. All I really did was rename the maniac-bug directory as \tredici, and eliminate all the unneeded variants. I didn't change the core or bootloader directories or files.

[goodnight now].
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 08:24 am
So these three official libs:

Quote

•Ethernet library = needs fixing ... as of IDE v.1.0.5, file "w5100.h" still requires Fix #1 listed above.
•Servo library = needs fixing ... file "Servo.h" requires Fix #1 listed above
•SD library = needs fixing ... both "S2dCard.h" and "Sd2PinMap.h" require Fix #1 listed above,
plus the latter file requires more serious attention.


and this third party lib:

Quote

•ElecFreaks ColorLCD library = needs fixing ... file "ColorLCDShield.cpp" requires Fix #1
listed above (note - this fix also applies to the Sparkfu ColorLCDShield library).


are the only ones that you've identified with incompatibilities that need specific fixes as of now?

Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 08:27 am

I see, you didn't make a copy, you just renamed mighty-1284p folder and deleted the stuff you didn't want.


[goodnight now].


Goodnight. :-)
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 02:34 pm

Can you direct me to the post that describes the core file change you made. I'm lost in regards the first 8 pages of this thread.


At this stage, the only core files change is

wiring_analog.c, line 49.

Code: [Select]

if (pin >= 24) pin -= 24; // allow for channel or pin numbers


has become

Code: [Select]

        pin = analogPinToChannel(pin);


The best way to keep track of all the changes is probably to just go directly to the github repository pages:

https://github.com/JChristensen/mighty-1284p/

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 06, 2014, 02:58 pm

Can you direct me to the post that describes the core file change you made. I'm lost in regards the first 8 pages of this thread.


I know, I get lost too. But first I just want to say that I was unaware of your efforts. I'm not sure what might have been done differently but I only became aware, like you say, after about eight pages of discussion. I've only been using the 1284P myself for a very few weeks so I am a newbie at that if not so much at other things.

The entire history is actually fairly short. I started with maniacbug's core since it was, as far as I knew, the most popular for the 1284P. Research revealed that it was built on Arduino 1.0. Also we discovered that most of the changes that he made (some of which are unrelated to the 1284P per se) had worked their way into subsequent Arduino releases. An effort began to refresh it to the 1.0.5 level.

The first attempt simply removed the cores directory and pointed the boards.txt entries at the Arduino 1.0.5 core. This was the first commit of the refreshed core. This worked for the standard variant, but not for bobuino. Further, the bobuino pins file had errors and was not the file that Crossroads currently distributes.

The second commit made changes to the bobuino pins file. Some of these addressed issues already documented on your site. However, we realized that changes to wiring_analog.c were necessary as well to support the bobuino board.

The third commit simply added the vanilla 1.0.5 cores files back in.

The fourth and last commit (as of now) is described in detail in reply #130 (http://forum.arduino.cc/index.php?topic=235521.msg1710385#msg1710385). It's still early and testing is ongoing but AFAIK the three variants from the maniacbug core are working. The core has been refreshed to the 1.0.5 level and required but a single change (https://github.com/JChristensen/mighty-1284p/commit/b9caa6c406abe6ce31afcaa4193c68f4b7336c07#diff-1) to the core files. This is a significant accomplishment and I want to thank everyone again that participated because it would not have happened without their support and guidance.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 06, 2014, 04:34 pm
These two IDE standard libraries that oric-dan documented on his site are pretty popular.
Quote

Servo library = needs fixing ... file "Servo.h" requires Fix #1 listed above
SD library = needs fixing ... both "S2dCard.h" and "Sd2PinMap.h" require Fix #1 listed above,
plus the latter file requires more serious attention.


While it's probably beyond the scope of this refreshing effort as first defined, to also look at the IDE's standard libraries, it would certainly be useful for many. I can't believe I must have never tried a servo on my bobriuno board, and I have a Adafruit RTC/SD data logging shield that I use at times but must not have tried it out on the 1284P. I seriously own too many arduino board types. I must have a couple of dozens between all the nano, pro-mini, megas, as well as pre-Uno based standard boards, you know the ones with the funny names.  ;)
Title: Re: Updating the mighty-1284p core
Post by: pico on May 06, 2014, 06:02 pm

While it's probably beyond the scope of this refreshing effort as first defined, to also look at the IDE's standard libraries, it would certainly be useful for many.


I agree. Ideally, for the 1284p variant boards to be considered first class Arduino citizens, the standard libs and their example sketches should all be expected to work after installing the files from the repository. The job might reasonably be considered half done if the core is up to date, but the libs aren't.

As a start, the list of libs that are known to be problematic should be part of the mighty-1284p-1.0.5 documentation, as per oric_dan's documented list on his site. Next, the fixed versions of the libs, where available, should be made part of the repository download, with instructions on how to install.

I think providing lib fixes when they are available, and providing caveats when they aren't, would be a reasonable "stretch" goal for the update project. (sorry, too many KS projects! :-)
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 06, 2014, 08:34 pm
The core has been refreshed to the 1.0.5 level and required but a single change (https://github.com/JChristensen/mighty-1284p/commit/b9caa6c406abe6ce31afcaa4193c68f4b7336c07#diff-1) to the core files.


Perfect.  Let me know if you want help trying to get Christian to merge the change.

Thank you for your great work, Jack!
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 06, 2014, 08:51 pm

So these three official libs:

Quote

•Ethernet library = needs fixing ... as of IDE v.1.0.5, file "w5100.h" still requires Fix #1 listed above.
•Servo library = needs fixing ... file "Servo.h" requires Fix #1 listed above
•SD library = needs fixing ... both "S2dCard.h" and "Sd2PinMap.h" require Fix #1 listed above,
plus the latter file requires more serious attention.


and this third party lib:
Quote

•ElecFreaks ColorLCD library = needs fixing ... file "ColorLCDShield.cpp" requires Fix #1
listed above (note - this fix also applies to the Sparkfu ColorLCDShield library).

are the only ones that you've identified with incompatibilities that need specific fixes as of now?


Yeah, whatever it says on my webpage. I did all that checking last summer+fall. I don't recall exactly which additional changes might be required in the SD library, re the comment above, as I've never actually used it.

All of the RFM12 radio libraries have serious bugs when it comes to using 1284. Might work with the Sanguino or standard 1284 pinout, but require multiple changes for Bobuino or any other pinout similar to UNO.  The jeelib library has literally "dozens" of bugs, and most of these were carried through when the lowpower-labs guy forked it. They both work ok with 328 chips, but not much else. The basic problem is they don't rely on pins_arduino.h, but use dedicated pin assignments, mix Arduino and chip callouts throughout the code, and force use of INT0 as an interrupt from the radio, whereas you typically will need to use INT2 with the 1284 for a UNO-like header arrangement.

So, good luck if ever trying to use the RFM12 libraries with the 1284.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 12:32 am

Perfect.  Let me know if you want help trying to get Christian to merge the change.


Thank you, Mr. Badly :D  ... I assume I just need to fork the repo, make the change to wiring_analog.c (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c), and submit a pull request?

Quote

Thank you for your great work, Jack!


No problem, it was fun and I learned some things. More to come I am sure. Thank you for your usual fine help! That goes for everyone else as well.
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 07, 2014, 01:51 am


Perfect.  Let me know if you want help trying to get Christian to merge the change.

Thank you, Mr. Badly :D  ... I assume I just need to fork the repo, make the change to wiring_analog.c (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c), and submit a pull request?


Yes with one addition.  Having an "issue" to work against is very helpful (also essentially required; I don't think Christian will merge without one)...
https://github.com/arduino/Arduino/issues/new

I suggest keeping it very brief (one or two sentences) and include a link to this thread.

I have no idea how to do it but issues and pull requests can be bound together which I suspect is helpful for Christian.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 01:54 am

Yes with one addition.  Having an "issue" to work against is very helpful (also essentially required; I don't think Christian will merge without one)...
https://github.com/arduino/Arduino/issues/new

I suggest keeping it very brief (one or two sentences) and include a link to this thread.

I have no idea how to do it but issues and pull requests can be bound together which I suspect is helpful for Christian.


Great, thanks, I'll figure it out!
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 01:58 am

Jack;

I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.

Lefty


Lefty, sounds like Issue #1 (https://github.com/JChristensen/mighty-1284p/issues/1) can be closed. Agree?
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 07, 2014, 02:10 am


Jack;

I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.

Lefty


Lefty, sounds like Issue #1 (https://github.com/JChristensen/mighty-1284p/issues/1) can be closed. Agree?


Yep, that dog won't ever hunt again.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 02:45 am

Yep, that dog won't ever hunt again.


Haha, well sometimes these things do have the annoying ability to come back from the dead, but I'll close it anyway. Thanks!
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 03:07 am
Anybody in this thread playing with the Sleeping Beauty?
I'm about to starting testing it with openGLCD and noticed there are some severe issues
with the SB variant file that is included in the SB core.
I'd like to go ahead and add a SB variant to the mighty 1284 core so SB doesn't need to have it's own core.
I'll go ahead and fix it to work with Jacks repository and then generate a pull request.
Just checking to see if anybody else has already done this before I go off and fix it.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 07, 2014, 03:10 am

Anybody in this thread playing with the Sleeping Beauty?
I'm about to starting testing it with openGLCD and noticed there are some severe issues
with the SB variant file that is included in the SB core.
I'd like to go ahead and add a SB variant to the mighty 1284 core so SB doesn't need to have it's own core.
I'll go ahead and fix it to work with Jacks repository and then generate a pull request.
Just checking to see if anybody else has already done this before I go off and fix it.

--- bill



Bill,

http://forum.arduino.cc/index.php?topic=235521.msg1710018#msg1710018 (http://forum.arduino.cc/index.php?topic=235521.msg1710018#msg1710018)

Ray
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 03:20 am

Anybody in this thread playing with the Sleeping Beauty?
I'm about to starting testing it with openGLCD and noticed there are some severe issues
with the SB variant file that is included in the SB core.
I'd like to go ahead and add a SB variant to the mighty 1284 core so SB doesn't need to have it's own core.
I'll go ahead and fix it to work with Jacks repository and then generate a pull request.
Just checking to see if anybody else has already done this before I go off and fix it.

--- bill


Bill, no immediate plans for a Sleepy Beauty here (plate already full), but go for it. What sort of issues are you seeing?
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 03:35 am
Ray,
I saw that post earlier but that isn't related to the question I had.
The question I had is that the SB variant file in the SB core is currently broken.
I'll fix it if nobody has already (which it sounds like nobody has)
but I'd also like to get it added to the mighty core.

Jack,
I haven't dug in yet to verify everything yet but one glaring error is the
digitalPinToAnalogPin() macro.
Clearly this is broken:

Code: [Select]
// #define digitalPinToAnalogPin(p)    ( (p) >= 14 && (p) <= 21 ? (p) - 14 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 21 ? (p) = 7 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 20 ? (p) = 6 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 19 ? (p) = 5 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 18 ? (p) = 4 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 17 ? (p) = 3 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 16 ? (p) = 2 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 30 ? (p) = 1 : -1 )
#define digitalPinToAnalogPin(p)    ( (p) == 31 ? (p) = 0 : -1 )


This is easily fixed with a proper ternary.
I have no idea what the author that did this was thinking.
It also shows up pretty obviously if you go in and turn on verbose output which
also causes the IDE to stop throwing away all the warnings.
(I think hiding warnings by default was pretty lame)

There may be other issues, yet to see.
I'll be testing it on openGLCD which does all kinds of crazy core/variant detection
and pin mapping stuff.

--- bill

update: 2014-05-05 20:43 CST
There are more issues, that relate to the analog<->digital pin mapping macros.
I think before it didn't matter. Now these macros must be correct since they are being used.
The different macros don't use the same mappings and also don't match the const defines for things like A0 to A7.
I'll have to go through the schematic and the data tables to verify that everything is correct.




Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 03:53 am

Jack,
I haven't dug in yet to verify everything yet but one glaring error is the
digitalPinToAnalogPin() macro.
Clearly this is broken:


Bill, I have a hard time saying it's broken, because I can't be completely sure what it's really supposed to do. This was one of the more frustrating parts of refreshing the 1284p core. These pin mapping macros are confusing at best. We have digital pin number, ADC channel number, analog pin or input number (AI labels in the pins files), etc. Some documentation would be appropriate.

Anyway, this doesn't seem like unreasonable behavior to me, but what were you expecting it to do?

Code: [Select]

//Tools > Board > Bobuino
#include <Streaming.h>    //http://arduiniana.org/libraries/streaming/

void setup(void)
{
   Serial.begin(115200);
   Serial << "DP\tAP" << endl;
   for (int p = 0; p < 32; p++) {
       Serial << p << '\t' << digitalPinToAnalogPin(p) << endl;
   }
}

void loop(void)
{
}

--------OUTPUT--------
DP AP
0 -1
1 -1
2 -1
3 -1
4 -1
5 -1
6 -1
7 -1
8 -1
9 -1
10 -1
11 -1
12 -1
13 -1
14 0
15 1
16 2
17 3
18 4
19 5
20 6
21 7
22 -1
23 -1
24 -1
25 -1
26 -1
27 -1
28 -1
29 -1
30 -1
31 -1
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 04:11 am
Jack,
That table you showed is isn't for the SB variant.
The SB variant is very broken in the SB variant file.

Issues:
For one you can't have multiple definitions of the same macro, it must be a single ternary
so as is, it isn't even valid C code.

The actual macros are not too complicated.
digitalPinToAnalogPin() takes a arduino digital pin number and returns the analog pin number or -1 if not possible
analogPintoDigitalPin() takes a arduino analog pin number and returns the digital pin number or -1 if not possible.
analogPinToChannel(p) takes arduino analog pin number and returns the AVR channel number or -1 if not possible.

Note that this means that users of the macros must check for -1 to ensure that the conversion
actually happened.

The problem with the SB variant is the macros are all "broken".
And by that I mean
- digitalPinToAnalog() macro technically isn't  valid C code
    It may compile (with warnings) but in no way is it close what was intended and in some cases won't even compile when used.
- analogInputToDigitalPin() isn't returning the proper mappings.
   (doesn't match the A0 to A7 const definitions)

--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 05:10 am

- digitalPinToAnalog() macro technically isn't  valid C code
   It may compile (with warnings) but in no way is it close what was intended and in some cases won't even compile when used.


Maybe he/she meant this?

Code: [Select]

#define digitalPinToAnalogPin7(p)    ( (p) == 21 ? 7 : -1 )
#define digitalPinToAnalogPin6(p)    ( (p) == 20 ? 6 : digitalPinToAnalogPin7(p))
#define digitalPinToAnalogPin5(p)    ( (p) == 19 ? 5 : digitalPinToAnalogPin6(p) )
#define digitalPinToAnalogPin4(p)    ( (p) == 18 ? 4 : digitalPinToAnalogPin5(p))
#define digitalPinToAnalogPin3(p)    ( (p) == 17 ? 3 : digitalPinToAnalogPin4(p))
#define digitalPinToAnalogPin2(p)    ( (p) == 16 ? 2 : digitalPinToAnalogPin3(p))
#define digitalPinToAnalogPin1(p)    ( (p) == 30 ? 1 : digitalPinToAnalogPin2(p))
#define digitalPinToAnalogPin(p)    ( (p) == 31 ? 0 : digitalPinToAnalogPin1(p) )


Strictly for LOLs!. :-)

(I wonder what the default nesting limit for macros is?)

Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 05:17 am
On a more serious note, any thoughts on Lefty's and my proposal that patched official libs should be part of the repository, where those libs need fixing to work with the new "mighty" core?
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 05:28 am

Jack,
That table you showed is isn't for the SB variant.
The SB variant is very broken in the SB variant file.


Sorry, my bad.

Quote

Issues:
For one you can't have multiple definitions of the same macro, it must be a single ternary
so as is, it isn't even valid C code.

The actual macros are not too complicated.
digitalPinToAnalogPin() takes a arduino digital pin number and returns the analog pin number or -1 if not possible
analogPintoDigitalPin() takes a arduino analog pin number and returns the digital pin number or -1 if not possible.
analogPinToChannel(p) takes arduino analog pin number and returns the AVR channel number or -1 if not possible.


Yep, am aware but I thought the "analog pin" concept a bit sketchy. Three names for one pin seems like more than is needed. The original intent of analogRead() was that the argument was a channel number. Allowance for using a pin number was added, OK, I can see that in the name of an easier to understand API. I'm not sure why the "analog pin/input" concept is really needed. I see it as additional confusion for a beginner to delve deeper into the hardware. But maybe beginners don't use 1284Ps. Whatever, I'm over it, it's all good, thanks :D

On another topic, I wanted to ask about openGLCD and whether it was getting along with the refreshed core, specifically these pin mapping macros in the pins_arduino.h files.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 05:40 am

On a more serious note, any thoughts on Lefty's and my proposal that patched official libs should be part of the repository, where those libs need fixing to work with the new "mighty" core?


I was thinking about having a look at the Ethernet library next. I was trying to find this "Fix #1" in the quote in Reply #151 (http://forum.arduino.cc/index.php?topic=235521.msg1710777#msg1710777), anyone know where that is, and a description of the issue as well?
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 05:45 am

I was thinking about having a look at the Ethernet library next. I was trying to find this "Fix #1" in the quote in Reply #151 (http://forum.arduino.cc/index.php?topic=235521.msg1710777#msg1710777), anyone know where that is, and a description of the issue as well?


Yes!

http://www.ot-hobbies.com/resource/ard-1284.htm#fuses2

It looks like oric_dan's done the hard yards on this one.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 05:47 am


I was thinking about having a look at the Ethernet library next. I was trying to find this "Fix #1" in the quote in Reply #151 (http://forum.arduino.cc/index.php?topic=235521.msg1710777#msg1710777), anyone know where that is, and a description of the issue as well?


Yes!

http://www.ot-hobbies.com/resource/ard-1284.htm#fuses2

It looks like oric_dan's done the hard yards on this one.


Huh? Fuse settings? To fix an issue with the Ethernet library?
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 06:09 am

Huh? Fuse settings? To fix an issue with the Ethernet library?


Scroll up to "1. Lack of 1284(P) Support in Arduino Libraries" .

Or just use http://www.ot-hobbies.com/resource/ard-1284.htm (or even http://www.ot-hobbies.com/resource/ard-1284.htm#lack2) instead.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 06:10 am



On a more serious note, any thoughts on Lefty's and my proposal that patched official libs should be part of the repository, where those libs need fixing to work with the new "mighty" core?


I was thinking about having a look at the Ethernet library next. I was trying to find this "Fix #1" in the quote in Reply #151 (http://forum.arduino.cc/index.php?topic=235521.msg1710777#msg1710777), anyone know where that is, and a description of the issue as well?

I don't remember off the top of my head, but my webpage suggests you might look in file w5100.h in the Ethernet library.


Spent some time over there, looks like it's the same thing I ran into, namely the SS pin assignment. "Fix #1" sounded like something more specific but I'm good. Just wanted to ensure it wasn't a different issue than the one I'd already seen.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 07, 2014, 06:33 am
Is the GLCD library much different than Henning Karlsen's library?
I sent him a Bobuino awhile back at DocEdison's request and Henning added 1284 support in.
http://www.henningkarlsen.com/electronics/library.php?id=51
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 06:37 am

Spent some time over there, looks like it's the same thing I ran into, namely the SS pin assignment.


Yes, that's entirely it.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 08:19 am

On another topic, I wanted to ask about openGLCD and whether it was getting along with the refreshed core, specifically these pin mapping macros in the pins_arduino.h files.


For openGLCD testing. I'm just starting to test it.
The only 1284 h/w I have is the Sleeping Beauty board that I just got.
My first quick attempt failed gloriously because of the bugs in the SB variant file.
I should be able to get that all fixed tomorrow as its all pretty simple stuff.
After that is fixed, I can add in the parallel mapping tables for the SB variant.
Then it should "just work".  ;)
While I'm fixing the SB variant, I'll go have a look at the macros in the other 1284 variants
and verify that the mappings & macros in each them are all consistent.


Is the GLCD library much different than Henning Karlsen's library?
I sent him a Bobuino awhile back at DocEdison's request and Henning added 1284 support in.
http://www.henningkarlsen.com/electronics/library.php?id=51



openGLCD is a totally different animal.
I use my AVRIO package to do the direct port i/o.
https://code.google.com/p/mcu-io/ (https://code.google.com/p/mcu-io/)
It abstracts all the pin i/o for any AVR processor without the overhead like
the Arduino core code.
It does multi-pin raw i/o using a different internal pin numbering scheme.
I have to convert from the Arduino pin#s to AVRIO pin numbers to make that happen.
In order to do that, I have to know which core & variant are in play to compile time
select the proper mappings.
Once the proper mappings are selected at compile time, the AVRIO package boils
everything down to do the raw port i/o using the fewest number of instructions.
It all happens automagically using macros like:
digitalWrite8pins(p0, p1, p2, p3, p4, p5, p6, p7, data);

The pins can be specified using Arduino pin #s or pin numbers using PIN_pb
where p is a port and b is a bit.
i.e.
PORT_D3 would be the pin associated with PORTD bit 3

etc...



--- bill

Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 03:20 pm

For openGLCD testing. I'm just starting to test it.
The only 1284 h/w I have is the Sleeping Beauty board that I just got.


So is the library ready to test for Bobuino variants? I should have some new boards (RFX "Big Bob" :-) arriving tomorrow, or Friday at the latest, and this looks like it would be some interesting software to put things through their paces.

I know I've got a TFT screen sitting in a drawer that's currently not being used... most challenging part may be finding the datasheet for it though!

The AVRIO stuff sounds interesting.



Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 07, 2014, 03:25 pm

On a more serious note, any thoughts on Lefty's and my proposal that patched official libs should be part of the repository, where those libs need fixing to work with the new "mighty" core?


Just a validation question and a comment:
- As I understand, the proposal involves copying an official lib, making a modification(s), and then putting this in the user library as the current GUI 1.0.5r2 picks user libraries over production libraries.  So, 2 library structures, not mutually exclusive.

- If the 1284P made this decision and implemented it, that would preclude any other AVR uC from using that methodology...   Example, if the tiny13 guys needed such a scheme?

Does anyone know if such a decision has been made collectively by any group in the past?  Does such a decision fit into the overall concept of user libraries?  

Rambling thoughts.

Ray

Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 03:59 pm

- As I understand, the proposal involves copying an official lib, making a modification(s), and then putting this in the user library as the current GUI 1.0.5r2 picks user libraries over production libraries.  So, 2 library structures, not mutually exclusive.


I would think that whether the user chooses to replace the official lib, or to put it under their sketches folder in the user library, would be ultimately up to them to decide. I just think it's important to make the "fixed" versions of the libraries downloadable along with the core files.


- If the 1284P made this decision and implemented it, that would preclude any other AVR uC from using that methodology...   Example, if the tiny13 guys needed such a scheme?


If conflicts occurred, I would hope they could be resolved in an amicable manner, such as merging code, rather than resorting to fisticuffs. ;-)


Does anyone know if such a decision has been made collectively by any group in the past?  Does such a decision fit into the overall concept of user libraries?  


Personally, I take a pragmatic view. If it works,  it works. Whatever "the overall concept of user libraries" is, I will leave that to the philosophers. :-)

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 04:54 pm


For openGLCD testing. I'm just starting to test it.
The only 1284 h/w I have is the Sleeping Beauty board that I just got.


So is the library ready to test for Bobuino variants? I should have some new boards (RFX "Big Bob" :-) arriving tomorrow, or Friday at the latest, and this looks like it would be some interesting software to put things through their paces.

I know I've got a TFT screen sitting in a drawer that's currently not being used... most challenging part may be finding the datasheet for it though!

The AVRIO stuff sounds interesting.


bobuino support is there. It compiles, but I didn't personally test it on actual h/w.
Sanguino support was tested by another forum member and the bobuino
support uses a slightly different pin mapping.
The current version of openGLCD is done as a source compatible replacement for GLCDv3  for which it is a superset.
As such, the main support is ks0108 with some other support for a few other monochrome displays so
it may not support the TFT you have.



--- bill
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 05:13 pm
I was getting ready to submit a pull request for the change to wiring_analog.c when I noticed something funny. This is from the current Arduino commit (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c#L40) which is past the point when the v1.0.5 distribution was built but this is the code being distributed with v1.5.6.

I can still go ahead with the pull request but does anyone else think this is not quite right?

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif


For the 1284P et al., this would result in

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin);
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 05:38 pm

I can still go ahead with the pull request but does anyone else think this is not quite right?


That definition for analogPinToChannel is only used if the macro analogPinToChannel has not already defined (it's under a #elif that relates to #if defined(analogPinToChannel) ), so if the definition is already there from the variants pins_arduino.h file, it shouldn't be a problem.

FWIW, that definition looks to be from the "standard" pins_arduino.h variant

Code: [Select]

#define analogPinToChannel(p)       ((p) < NUM_ANALOG_INPUTS) ? (p) : ((p)  >=  24) ? ((p) - 24) : -1


so I guess that is assumed as the default here, if no macro is defined.

So for the 1284P with a macro analogPinToChannel defined, this results in

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin);


which is what we want.

But for a 1284p without the macro analogPinToChannel defined, we would get as a default

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

if (pin >= 24) pin -= 24; // allow for channel or pin numbers


which (in general) is not what you would want. But it is reasonable guess as a default.

So, in short, looks fine to me.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 06:26 pm

I was getting ready to submit a pull request for the change to wiring_analog.c when I noticed something funny. This is from the current Arduino commit (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c#L40) which is past the point when the v1.0.5 distribution was built but this is the code being distributed with v1.5.6.

I can still go ahead with the pull request but does anyone else think this is not quite right?

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif


For the 1284P et al., this would result in

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin);
if (pin >= 24) pin -= 24; // allow for channel or pin numbers



Jack,
I think both are incorrect & incomplete
and will not work with the existing 1284 variants.
This is where things may start to get really sticky.
The analogRead() API is documented as taking a pin number,
yet this code is trying to accommodate what it is calling "analog channel number".
(Ok the analogRead() docs mention "channels" at the top, but everything else uses the term "pin")
http://arduino.cc/en/Reference/analogRead (http://arduino.cc/en/Reference/analogRead)
If there is not a 1 to 1 mapping between the naked analog pin numbers and the
analog channels, then I think this becomes unsolvable.
Since if you say get passed a 0 or a 6 what is that?
Is it an analog channel number or a naked analog pin number.
(They aren't necessarily the same)
I believe that it is probably better to assume that the comment about
"analog channel number" is an overstep that assumed a one to one mapping
and that the argument passed to analogRead() is either an analog pin number or a digital pin number
and NOT an analog channel number.
This makes things solvable and should work the way users expect and will still work
the way the analogRead() documentation is written
as that documentation calls it an analog pin number and not an analog channel number.

It also ensures that when using analogRead() with the An constant vs a naked constant
that the same pin is being addressed, which is what I think most people would assume.
example:
analogRead(A0) and analogRead(0)
analogRead(A7) and analogRead(7)
Should address the same pin.


To ensure that, you can never do simple subtraction math to flip between
two pin number spaces. You must use the mapping macros.

And when using the macros, a uint8_t type will end up with a value of 255
when the mapping failed so depending on how the code is written, that may have to be tested.

I would not assume that the user passes in a proper/valid pin number and would assume that
it could be any value, including bogus values that are outside both the analog and digital pin numbering
spaces.

I can offer updated code to handle it, but it will be a few hours before I can get to it.
I don't think it is that hard,or that it will take that long to do,
but it will take a bit of thought to handle all the possible combinations:
- pin argument number is way too large (outside both number spaces)
- pin argument is analog pin number (naked constants for analog pin numbers: 0, 1, 2, ... 7 )
- pin argument is a digital pin number (for A0, A1, ... A7, etc...)

And the final solution should work for all processors not just the 1284
as they all have the same issue to deal with.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 06:40 pm

Jack,
I think both are incorrect & incomplete


Both what? There is only one version of code that Jack has put up there.

The second code box is what he though the pre-processor would leave if a 1284p was defined (but which isn't the case if the analogPinToChannel macro has been defined.)

For the 1284P with a macro analogPinToChannel defined in pins_arduino.h, this results in

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin);


which is what you want. If it's not what you want, you change the definition in pins_arduino.h.

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 06:48 pm


Jack,
I think both are incorrect & incomplete


Both what? There is only one version of code that Jack has put up there.

The second code box is what he though the pre-processor would leave if a 1284p was defined (but which isn't the case if the analogPinToChannel macro has been defined.)




I guess I misunderstood the post.
I was assuming that second code block was the new proposed code for the 1284 core.
But I guess it was just showing the code for the 1284.

Regardless, I don't believe that it will work correctly for the reasons stated above.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 07, 2014, 06:53 pm


bobuino support is there. It compiles, but I didn't personally test it on actual h/w.
Sanguino support was tested by another forum member and the bobuino
support uses a slightly different pin mapping.
The current version of openGLCD is done as a source compatible replacement for GLCDv3  for which it is a superset.
As such, the main support is ks0108 with some other support for a few other monochrome displays so
it may not support the TFT you have.

--- bill

Hi Bill, I've always had some trouble trying to decipher library code, and this is a somewhat naive question.

However, in regards the following, I had always thought that the purpose of having pins_arduino.h files customized for specific boards was so you didn't need to have board-specific code as follows in the libraries in the first place. Mainly the idea is to have chip-specific code in the libraries as pertaining to different internal architectures, but not board-specific code as pertaining to header mapping - since that's the purpose of pins_aruino.h.

This seems to me to be the case in all of the standard libraries included with the IDE that I examined for the 1284 chip, but not necessarily so in 3rd party libraries [jeelib to me being the classic example of complete and total muckup in this regards]. What am I missing here?

https://bitbucket.org/bperrybap/openglcd/src/62cf1693feba0a451fdf56ce823d404e7e28c1ac/include/glcd_arduino_io.h?at=master
Code: [Select]
#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega1284__)  
#ifndef analogInputToDigitalPin // original Sanguino core had no analogInputToDigitalPin()
#define GLCD_CORE_SANGUINO
#else
/*
* Now must check which mighty1284p core variant
* Look at the pin number of the first analog pin to distinguish
*/
#if (analogInputToDigitalPin(0) == 24 )
#define GLCD_CORE_MIGHTY1284P // avr mighty1284p "standard" pin mapping
#elif (analogInputToDigitalPin(0) == 31 )
#define GLCD_CORE_SANGUINO // avr mighty1284p avr_developers pin mapping (SANGUINO)
#elif (analogInputToDigitalPin(0) == 21 )
#define GLCD_CORE_BOBUINO // avr mighty1284p "bobuino" pin mapping
#endif
#endif
Title: Re: Updating the mighty-1284p core
Post by: pico on May 07, 2014, 06:59 pm

Regardless, I don't believe that it will work correctly for the reasons stated above.


Well, here's what would be returned by analogPinToChannel if the Bobuino variant was selected:

Code: [Select]

#define analogPinToChannel(p)       ((p) < NUM_ANALOG_INPUTS) ? (7 - (p))  :  ((p)  >=  14 && (p) <= 21) ? (21 - (p)) : -1


which case exactly does this fail in your opinion? It covers two input ranges, 0-7 and 14-21. Everything else return as -1. That looks fine to me, but perhaps I'm missing something?
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 07, 2014, 07:37 pm



bobuino support is there. It compiles, but I didn't personally test it on actual h/w.
Sanguino support was tested by another forum member and the bobuino
support uses a slightly different pin mapping.
The current version of openGLCD is done as a source compatible replacement for GLCDv3  for which it is a superset.
As such, the main support is ks0108 with some other support for a few other monochrome displays so
it may not support the TFT you have.

--- bill

Hi Bill, I've always had some trouble trying to decipher library code, and this is a somewhat naive question.

However, in regards the following, I had always thought that the purpose of having pins_arduino.h files customized for specific boards was so you didn't need to have board-specific code as follows in the libraries in the first place. Mainly the idea is to have chip-specific code in the libraries as pertaining to different internal architectures, but not board-specific code as pertaining to header mapping - since that's the purpose of pins_aruino.h.

This seems to me to be the case in all of the standard libraries included with the IDE that I examined for the 1284 chip, but not necessarily so in 3rd party libraries [jeelib to me being the classic example of complete and total muckup in this regards]. What am I missing here?


SPEED.
While the Arduino core digital i/o implementationworks, it is simply awful.
The main reason is the way the AVR instruction set and internal architecture works combined with the way
the arduino API is defined and the actual code implementation.
The current Arduino core code looks up everything run time vs doing more at compile time when conditions allow.
The AVR chose to do bit set/clr instructions vs have bit set/clr registers.
This works but only works for single bits and the information has to be known
at compile time in order to generate the AVR bit set/clr instructions.
The avr-gcc compiler has a hack in it for this.
If the memory address is in a specific range and the bitmask  are known
at compile time, the compiler will convert that to bit set/clr instructions.

What you are seeing is that the 3rd party libraries what want higher performance,
have to step outside of using the core digital i/o routines to get it.
By doing so you can literally gains 100's of times performance increases.

Most libraries do this by creating parallel mapping information that can be accessed at compile time.
This is what AVRIO needs.
My library is smart enough to look at the core and variant and if parallel mapping data is
available for that combination, AVRIO can be used which will convert everything to raw port i/o.
The catch is that you have to create parallel mapping data that exactly matches the data tables
in the pins_arduino.h header.
In my code, If that core and variant don't have parallel mapping data, then the code will drop back using the much
slower Arduino core digitalWrite()/digitalRead() functions.
So in my case the code will always work it just works much faster if I have added
support for the specific core & variant.
Most libraries don't have a real i/o mapping layer and are hard coded to  specif
cores & variants which makes them difficult to get working on other platforms.

On a glcd, it takes thousands of i/o accesses to control the pixels, and the difference
between using the arduino core routines and raw port i/o is VERY noticeable.

There is another way to do the raw port i/o that uses the data tables.
It grabs the pointers and bit maskes at run time during initialization and then uses
them later rather than doing the lookups every single time which is what
digitalRead()/digitalWrite() do.
It offers significant performance gains over using digitalWrite()/digitalRead()
however it issn't as fast as direct raw port i/o.
I call that mode "indirect raw port i/o".

But as I said before, there is a way to make the data in pins_arduino.h available at
compile time to smarter code that wants to use it,
but it requires playing some games with the declarations.
So far, I've not been able to get anyone interested in doing these small changes.

--- bill

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 07, 2014, 07:51 pm
I think I had it right. Let's assume both __AVR_ATmega1284P__ and analogPinToChannel are defined, which will be true for any variant using the refeshed core. So,

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)  // TRUE
#if defined(__AVR_ATmega32U4__) // FALSE...
if (pin >= 18) pin -= 18; // allow for channel or pin numbers  // ...so this line not included
#endif  //end #if defined(__AVR_ATmega32U4__)
pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) // FALSE
if (pin >= 54) pin -= 54; // allow for channel or pin numbers // not included
#elif defined(__AVR_ATmega32U4__) // still FALSE (why bother checking twice)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers // not included
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__) // TRUE...
if (pin >= 24) pin -= 24; // allow for channel or pin numbers // ...so this line included
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers // not included
#endif //end #if defined(analogPinToChannel)

//so I end up with

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined
if (pin >= 24) pin -= 24; // allow for channel or pin numbers // ...so this line included


My whole point was that the change as I implemented it in v1.0.5 could be the same, but then analogPinToChannel gets called twice:

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);    // once
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
pin = analogPinToChannel(pin);  // twice
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif


Another possibility would be to completely remove the test for the 1284P et al. But it sure seems like the 1280, 2560, and 32U4 are still going to have issues. But maybe that's not my problem.

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 07, 2014, 08:30 pm
Bill, as regards library speedups, this may be counter-intuitive to historical trends, but it occurred to me that rather than chase after every custom board that comes down the pike, why not publish a note for how someone can either

a. modify the tiny part of the library that pertains to pin mapping of their personal variant [it's obviously not all that hard to do using the library code as a template], or else

b. add a conditional line at the start of the library .h config file saying something to the extent:
Code: [Select]
#if defined( CUSTOM_PINOUT )
#include custom_map.h
....


Then the new board can have it's own pin remapping in < custom_map.h >, and also include a line saying < #define CUSTOM_PINOUT > at the start of the sketches. Sounds perferable to me compared to what people are currently doing. Then, the monkey is on the back of the guy designing the new board, and you don't have to chase down a patch for every variant.
Title: Re: Updating the mighty-1284p core
Post by: teding on May 07, 2014, 09:54 pm
With my ebay "Improved Sanguino PCB" , with 1284P.
Running might-optiboot, and the last update from your github. I have no problem running
Jeelabs RM12 lib en ethercard lib   :)


Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 07, 2014, 10:57 pm
I was getting ready to submit a pull request for the change to wiring_analog.c when I noticed something funny. This is from the current Arduino commit (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c#L40) which is past the point when the v1.0.5 distribution was built but this is the code being distributed with v1.5.6.

I can still go ahead with the pull request but does anyone else think this is not quite right?


Is the following correct?
Code: [Select]
#define NUM_DIGITAL_PINS            32

If yes then nothing about the snippet you posted is correct for the m1284 family.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 12:48 am
oric_dan,
I've spent the past several years dealing with the issues of Arduino pin mapping.
I've been through pretty much all the various ways of handling it and
there are several ways to deal with it.
As far as turning the existing pin data into a ternary, goes, that is pretty much I already do,
but given the wimpy IDE environment and environments like Windows that don't
come with real development tools,  there is no way to automate it for other users,
so currently I'm doing it and including it with the library.
But since it is based on the data tables, it usually doesn't need full testing since
the data is essentially the same.

The biggest issues relate to the API itself and its semantics.
If the API were slightly different, many other and better optimization methods
would be available especially if the semantics were SET and CLR vs set the pin
to a value. This would make a HUGE difference on the non AVR hardware that
has built in set/clr hardware support.

The indirect port i/o method is portable.
In fact in another library I'm involved with it is used on multiple platforms
including the pic32 chipkit boards with no need for any parallel mapping tables.
That said it doesn't offer the performance of direct port manipulation particularly on the AVR
because the AVR does not have atomicity except when using bit set/clr instructions.

With direct port i/o you end up with
a single bit set/clr or a full byte write instruction
Either of those happens in a single instruction of 125ns with a 16mhz clock.

When using indirect port i/o you end up with:

- fetch the interrupt mask register
- save the current interrupt state to memory/register
- mask interrupts
- fetch the address of the port register from memory to register
- fetch the contents of the port register using the memory address just fetched.
- fetch the pin bitmask from memory to "porvalue" (register)
- OR/AND the bitmask that was just fetch into the contents of the "portvalue"
- write the "port value" back to the port register using the memory address fetched
- fetch the saved interrupt state
- store the previous interrupt state in the interrupt mask register.

As you can see even though it is still WAY faster than the core i/o it is a lot
more instructions than a single instruction to set/clr a bit.
In many cases it is good alternative to going all the way to full port i/o.
The win is even bigger for multi-bit i/o like byte operations since the full byte
can be written to all at once vs having to set/clr individual bits.
One really big difference when using indirect port i/o is that the pins
can be set run time by the sketch. Which means that sketch and library can use the Arduino  typical library
constructor object to set them vs, having to set them in a separate config file outside the sketch.

And while it can be made to be portable, it really is not a walk in the park either.
You still often have to add some tweaks for each core  but at least it is only for each core vs core/variant.
This is because different processors have different register widths and layouts and in order
to make it work you have to create a layer that maps the port register and mask to a type
that matches the width of the register in the micro-controller.

Currently, my approach is to included full raw port i/o support for certain core/variant combinations.
For all others, the code drops back to the slow built in Arduino core digital i/o routines.
That ensures that the code works on all the boards regardless of core/variant.


As I said few times already, my preference with all this stuff would be change the declarations in the variant files so
that smarter that wants to could reach down into the data tables at compile time while still allowing
the existing code to access the data at run time.
This solves the parallel data table issue for compile time once and for all and ensures
that both compile time and run time are using the very same data tables.


--- bill


Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 12:50 am

Then the new board can have it's own pin remapping in < custom_map.h >, and also include a line saying < #define CUSTOM_PINOUT > at the start of the sketches. Sounds perferable to me compared to what people are currently doing. Then, the monkey is on the back of the guy designing the new board, and you don't have to chase down a patch for every variant.

library modules and sketch modules are separate compilation units.
Any defines or data you put into the sketch is not available to the library modules at compile time.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 08, 2014, 12:58 am
Bill, thanks for both of your posts, and especially the long explanation re port I/O. Will take a bit to mull over. And has given me some ideas to play with. Thanks again.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 02:21 am

I think I had it right. Let's assume both __AVR_ATmega1284P__ and analogPinToChannel are defined, which will be true for any variant using the refeshed core. So,

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)  // TRUE
#if defined(__AVR_ATmega32U4__) // FALSE...
if (pin >= 18) pin -= 18; // allow for channel or pin numbers  // ...so this line not included
#endif  //end #if defined(__AVR_ATmega32U4__)
pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) // FALSE
if (pin >= 54) pin -= 54; // allow for channel or pin numbers // not included
#elif defined(__AVR_ATmega32U4__) // still FALSE (why bother checking twice)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers // not included
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__) // TRUE...
if (pin >= 24) pin -= 24; // allow for channel or pin numbers // ...so this line included
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers // not included
#endif //end #if defined(analogPinToChannel)

//so I end up with

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined
if (pin >= 24) pin -= 24; // allow for channel or pin numbers // ...so this line included


My whole point was that the change as I implemented it in v1.0.5 could be the same, but then analogPinToChannel gets called twice:

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);    // once
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
pin = analogPinToChannel(pin);  // twice
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif


Another possibility would be to completely remove the test for the 1284P et al. But it sure seems like the 1280, 2560, and 32U4 are still going to have issues. But maybe that's not my problem.

Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif



Jack,
I don't think you can really call analogPinToChannel() twice can you?
The 1284 conditional code is only used if the macro is not defined, but then
it attempts ot use it. Something seems off here.

Also keep in mind that  the analogPinToChannel() macro on other variants works differently
than it does with the 1284 core variants.
The 1284 variants  will return the analog channel when passed an analog pin # or a digital pin number.
The leonardo expects to be passed a valid analog chanel number and will return garbage on anything else.

Not sure how to handle that.
Should the leonardo macro be updated, or should this code be updated to assume
that analogPinToChannel only supports analog pin #s?
While not required, my preference is to make analogPinToChannel() always work the same
as I'm not a fan of the same function working differently in different situations.


I don't like leaving out the 1284 conditional when the macro is not defined as it looks
to end up using the 328 pin mapping should the macro not exist whenever a 644/1284 based core exists.
(Again that issue of processor type vs core)
Maybe instead, leave the conditional there, but then inside the 1284/644 code,
use a #error if analogPinToChannel() is not defined so that it would require the macro always exist
for 1284/644 cores.

i.e. something like:
Code: [Select]
int analogRead(uint8_t pin)
{
        uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
        if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
        pin = analogPinToChannel(pin);    // once
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
        if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
        if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
#if !defined(analogPinToChannel)
        #error missing analogPinToChannel() macro
#endif
#else
        if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif


Or maybe it would be easier to read if the main ifdefs were all the processor ones
and then inside each processor section, either assume it exists, or check for the macro and either use it
or not.
This might be easier as then you could only modify the 1284/644 section and leave
all the others alone.

now I'm off to go fix the SB variant macros and fix openGLCD to be able
to tell the difference between bobuino and SB.

--- bill

Title: Re: Updating the mighty-1284p core
Post by: pico on May 08, 2014, 02:30 am
Jack (and Bill),


I think I had it right.


No, still not reading it right. I think you are getting distracted by the relative unreadability if the pre-processor directives.

Let's assume both __AVR_ATmega1284P__ and analogPinToChannel are defined, which will be true for any variant using the refeshed core.


Let's rewrite the if/else if/else block in C pseudo-code and you will see immediately why the 2nd block isn't included.

Code: [Select]
int analogRead(uint8_t pin)
{
       uint8_t low, high;

       if (defined(analogPinToChannel))  { // TRUE
               if ( defined(__AVR_ATmega32U4__)) { // FALSE...
               if (pin >= 18) pin -= 18; // allow for channel or pin numbers  // ...so this line not included
               }  //end #if defined(__AVR_ATmega32U4__)
       pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined
        }

        /* Note that if defined(analogPinToChannel)) is true, none of the conditionals after here are evaluated, it's all "don't care"... */

        else if (defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)) { // FALSE <- A: Doesn't matter, true or
               //  false, this is not evaluated if  main if block evaluates true
       if (pin >= 54) pin -= 54; // allow for channel or pin numbers // not included
        }
        else if (defined(__AVR_ATmega32U4__)) { // still FALSE (why bother checking twice)   <- A: it doesn't, this is the first time
                //  it is checked if analogPinToChannel is not defined
       if (pin >= 18) pin -= 18; // allow for channel or pin numbers // not included
        }
       else if (defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__) ) { // TRUE...
       if (pin >= 24) pin -= 24; // allow for channel or pin numbers // ...so this line included <- A: No, it's not. Like all the "else if"s,
               // this is not evaluated if  main if (defined(analogPinToChannel)) block evaluates true
       }
       else {
       if (pin >= 14) pin -= 14; // allow for channel or pin numbers // not included
       } //end #if defined(analogPinToChannel)


so we end up with

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

pin = analogPinToChannel(pin); // this line included because analogPinToChannel is defined


if analogPinToChannel is defined, but

Code: [Select]

int analogRead(uint8_t pin)
{
uint8_t low, high;

if (pin >= 24) pin -= 24; // allow for channel or pin numbers


if analogPinToChannel is not defined, but __AVR_ATmega1284P__ is.

Everything in the "else if" (#elif) blocks are  fallback for the case where analogPinToChannel is not defined, otherwise are ignored.

So, as I said originally, this looks basically fine.

Edit: The only slightly odd thing is the way they override the analogPinToChannel macro definition for __AVR_ATmega32U4__ if it is defined, but someone had their reasons I suppose. But whatever they are, they don't concern us directly...
Title: Re: Updating the mighty-1284p core
Post by: pico on May 08, 2014, 02:46 am

Jack,
I don't think you can really call analogPinToChannel() twice can you?
The 1284 conditional code is only used if the macro is not defined, but then
it attempts ot use it. Something seems off here.


analogPinToChannel() doesn't get called twice. it gets called once, and only if it is defined. See above.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 08, 2014, 03:09 am
@pico, thank you and apologies all around for being stupid :smiley-red: One of those situations where I can read something 100 times and get it wrong every time. I'd actually begun testing it and had convinced myself that I'd made a mistake, and I still couldn't see it. Sheesh.


Is the following correct?
Code: [Select]
#define NUM_DIGITAL_PINS            32


NUM_DIGITAL_PINS is 32 for all three variants in the refreshed core, but where does that come into it?


If yes then nothing about the snippet you posted is correct for the m1284 family.


Now that I (ahem) understand it, I think it's OK for the 1284s and 644s. The first snippet is the current code from the Arduino repo (https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring_analog.c#L40).

So maybe I just cancel the issue, it looks like a pull request is not needed for 1.5.6. Will there ever be a 1.0.6, and if so will it use the current 1.5.6 code? If so then it looks like "do nothing" -- but the refreshed core will need to retain the analogRead() mod. Thoughts? Agree?


I don't think you can really call analogPinToChannel() twice can you?


I don't see why not. Not to say that it makes sense or will give the desired result, but nothing fundamentally wrong with doing it. But like Bill pico says, that's not what's happening.

Quote

The leonardo expects to be passed a valid analog chanel number and will return garbage on anything else.


That reads as though I have to give analogPinToChannel() a channel number. If I already have the channel number, then why call it at all? The 32U4 looks funny because there are two tests, but I have to believe it works, so am not going to worry about the Leonardo right now ;)

Next time feel free to kick me in the head sooner :smiley-zipper:
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 08, 2014, 03:34 am
NUM_DIGITAL_PINS is 32 for all three variants in the refreshed core, but where does that come into it?


It doesn't.  I made a mistake.  I'll get back to you later tonight...
Title: Re: Updating the mighty-1284p core
Post by: pico on May 08, 2014, 03:37 am

So maybe I just cancel the issue, it looks like a pull request is not needed for 1.5.6. Will there ever be a 1.0.6, and if so will it use the current 1.5.6 code? If so then it looks like "do nothing" -- but the refreshed core will need to retain the analogRead() mod. Thoughts? Agree?


Sounds good to me. :-)
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 08, 2014, 04:22 am

NUM_DIGITAL_PINS is 32 for all three variants in the refreshed core, but where does that come into it?


It doesn't.  I made a mistake.  I'll get back to you later tonight...


What? And it's only May? There must be something going around...   :D
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 04:34 am


I don't think you can really call analogPinToChannel() twice can you?


I don't see why not. Not to say that it makes sense or will give the desired result, but nothing fundamentally wrong with doing it. But like Bill pico says, that's not what's happening.
Correct. I had a brain failure and miss typed what I meant to say:
Because of the combination of ifdefs,
"I don't think you really call analogPinToChannel() twice do you?


Quote

The leonardo expects to be passed a valid analog chanel number and will return garbage on anything else.


That reads as though I have to give analogPinToChannel() a channel number. If I already have the channel number, then why call it at all? The 32U4 looks funny because there are two tests, but I have to believe it works, so am not going to worry about the Leonardo right now ;)


Man... another VERY bad typo on my part
(I'm really screwing up today )
That should have read:
... leonardo expects to be passed a valid analog pin number

(The value is directly used as an index into a mapping data table.)

The difference is the bobuino analogPinToChannel() macro works with either the analog pin # or
the digital pin # of the same pin.
The Leonardo analogPinToChannel() will give you garbage if you give the digital pin number.

The 32u4 (leanardo variant) code has a hard coded translation to convert from a digital pin # to an analog pin # then
call analogPinToChannel() to translate the analog pin # to the analog channel number.
Since it is currently not a 1 to 1 mapping the macro is defined so you must use it/call it but
you can't call it more than once.

I updated the SB analogPinToChannel() macro to work like
the bobuino version where it also supports the digital pin number
since the new code I'm seeing in analogRead() for the 1284 seems to be depending on that
behavior.

BTW,
I've got the SleepingBeauty up and running with openGLCD with AVRIO raw port i/o working.
There were several mapping macro errors in the SB variant file.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 08, 2014, 04:49 am

...
BTW,
I've got the SleepingBeauty up and running with openGLCD with AVRIO raw port i/o working.
There were several mapping macro errors in the SB variant file.

--- bill


Bill,
Will you post/link the correction?

Thx,
Ray
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 05:02 am
Here is a zip of the boards.txt and SB variant file I'm using.
--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 08, 2014, 07:03 am
Boards day! :-)

I've just made up a "Big Bob" board to test, installing just enough components on to get it going, and so far so good!

Pic 1 shows it in a fairly minimalist config, just one  voltage regulator (for the 3v3 rail), and USB/TTL header so it can be powered via USB (USB also provides the power to the 5V rail). The two jumpers configure the power so that the 5V rail is tied to Vin (so the 3v3 regulator gets power), and ties Vcc for the 1284p to the 5V rail (could optionally tie to 3v3 rail, or even Vin if required.)

Pic2 shows it with the CP2102 USB/TTL board plugged into the header, and also a nRF24L01+ radio attached. Posing beside a Due for size comparison. (Actually, he doesn't really look that big. Maybe I'll end up calling him "Bare Bones Bob", or something. Anyway, he's certainly looking skinny here. ;-)

Serving up web pages nicely via my TCP over nRF24L01+ RFXduino gateway -- more testing to be done, but it's looking good! :-)

And all running the latest hot-off-the-press 1284p core code, of course! ;-)

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 08, 2014, 01:55 pm

Boards day! :-)

I've just made up a "Big Bob" board to test, installing just enough components on to get it going, and so far so good!


Nice looking board, is that a Crossroads design?

Edit: Answered my own question, I'd missed this thread (http://forum.arduino.cc/index.php/topic,236897.0.html) somehow. Nice work, pico!

Funny the things that Google comes up with sometimes. If Robert ever moves to California, this (http://www.zillow.com/homedetails/1284-Crossroads-Dr-Tracy-CA-95377/35963204_zpid/) has to be the place for him!
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 08, 2014, 09:08 pm
Nice find Jack!

I have another version of the original Bobuino ready to order, letting it ruminate a day or so before I place the order in case I forgot anything.
Like the original, it has DS1307, SD card RS232 buffer, CR2032  battery backup, 1284P-PU, 5V regulator, 3.3V regulator, Uno style header for shields. FTDI chip has been replaced with FTDI module and off board header like my 1284 Duemilanove.
ICSP header moved to  the correct spot.  Extra  IO pins brought out to a header.
Prototype area for installing 433 MHz Rx or Tx module, or nrfl2401 module, or a 20-pin DIP.
Headers have 2nd row of adjacent pins for jumper wires over the header, and Gnd for connecting buttons. Analog also has +5/Gnd to support pots or sensors needing power.
Battery holder moved to the top of the board so it can sit flat. Extra power pads added so external DC/DC module can be easily wired in.
I'm looking forward to sourcing them, have a commitment for 5 already. Assembly will have better yield for hand assembly as we're not putting FT232R directly on the board; I lost 5 boards trying to get those on last time and reworking them and just wrecking the boards. These will be much easier.
Will post a pic later tonight. I'm debating making the board wider and adding holes for screw terminals too as an option.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 08, 2014, 11:35 pm
So I just noticed this bit of nastiness in the Ethernet library.
Down in util/w5100.h
Code: [Select]
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  inline static void initSS()    { DDRB  |=  _BV(4); };
  inline static void setSS()     { PORTB &= ~_BV(4); };
  inline static void resetSS()   { PORTB |=  _BV(4); };
#elif defined(__AVR_ATmega32U4__)
  inline static void initSS()    { DDRB  |=  _BV(6); };
  inline static void setSS()     { PORTB &= ~_BV(6); };
  inline static void resetSS()   { PORTB |=  _BV(6); };
#elif defined(__AVR_AT90USB1286__) || defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB162__)
  inline static void initSS()    { DDRB  |=  _BV(0); };
  inline static void setSS()     { PORTB &= ~_BV(0); };
  inline static void resetSS()   { PORTB |=  _BV(0); };
#else
  inline static void initSS()    { DDRB  |=  _BV(2); };
  inline static void setSS()     { PORTB &= ~_BV(2); };
  inline static void resetSS()   { PORTB |=  _BV(2); };

#endif


This is in the latest 1.5x code as well.

That really should be replaced with:
Code: [Select]

  inline static void initSS()    { portMode(SS, OUTPUT); };
  inline static void setSS()     { digitalWrite(SS, LOW); };
  inline static void resetSS()   { digitalWrite(SS, HIGH); };


But even if you make that change, it won't work on all the
mighty 1284 variants.
SB and bobuino define SS as pin 10 where as the developers and the standard variant define SS as pin 4.
Not sure why they would pick 4 over pin 10, my guess is that it was just picked it by leaving it's position on
the 1284 pin mapping diagram.

So if a shield is used, that expectes SS to be on digital pin 10,
then it would not work on developers or standard variants
since the shield will be looking at digital pin 10 and those variants tell the s/w
that SS is on digital pin 4.

For better pin compatibility with existing UNO shields, perhaps 10 is a better
choice for SS than 4.

--- bill



Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 08, 2014, 11:58 pm

So I just noticed this bit of nastiness in the Ethernet library.


Yep, that's what caused the issue I had with the SS pin. I just took the direct approach and did the following. Works fine with my board which uses the standard variant. Seems like it would work for the others too. (Does anyone else think "standard variant" sounds odd? :D)

Code: [Select]
private:
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
  inline static void initSS()    { DDRB  |=  _BV(4); };
  inline static void setSS()     { PORTB &= ~_BV(4); };
  inline static void resetSS()   { PORTB |=  _BV(4); };
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 09, 2014, 01:13 am
Jack,
I'm guessing that "fix" you did worked for you because you are using a variant the mapped PB4 to digital pin 10.
It wouldn't have worked for the mighty 1284 standard or developers variants which map PB4 to digital pin 4.

After going back and reviewing the actual Ethernet shield schematic,
I realized that this seems to have been made more complicated than it needs to be.
The Ethernet shield hardwires the Ethernet SS to D10.

All those conditionals and direct port i/o code are simply
trying to set the pin hooked to the D10 shield header pin
without using the variant mappings and the core library.
If you do raw port i/o, to always get it right, you have
know the actual core and variant.
Just knowing the processor type is not enough.
(again that  issue of having to know the core & variant).

If the core digital i/o routines are used, all those issues
can be avoided.


So I would think that code could be:
Code: [Select]

/*
* The SS signal for the Ethernet is hardwired to pin D10
*/
  inline static void initSS()    { portMode(10, OUTPUT); };
  inline static void setSS()     { digitalWrite(10, LOW); };
  inline static void resetSS()   { digitalWrite(10, HIGH); };


Nothing special has to be done for any core / variant combination.
It is D10 and is always D10 as the shield hardwires the SS for Ethernet to D10.

Although I'm not sure what  core / variant these are for:
Code: [Select]
defined(__AVR_AT90USB1286__) || defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB162__)

But if it is being used on an UNO shield form factor it too would have to use D10 for the ethernet SS pin
since that is how the Ethernet shield is hardwired.

There is an issue of timing, as the time to set the SS pin will increase
from 125ns to about 5.5us
Not sure if that matters.

If it does, and raw port i/o is needed, then the conditionals will need to be much smarter
to account for the core / variant combination.
For sure there is an issue for the different variants in the mighty 1284 core
since different mighty 1284 variants map D10 differently.
(arg..., that issue of having to know both the core & variant pops up its ugly head again)


--- bill

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 09, 2014, 01:27 am

Jack,
I'm guessing that "fix" you did worked for you because you are using a variant the mapped PB4 to digital pin 10.
It wouldn't have worked for the mighty 1284 standard or developers variants which map PB4 to digital pin 4.


Actually the standard variant maps PB4 to D4. My fix unconditionally causes the Ethernet library to use PB4 (for 1284P), which is the hardware SS pin, regardless of variant. This is what I wanted and while it seemed reasonable to me, now that I think about it a bit more, it's probably not universal. Plus I am not using an Ethernet shield which gives me more flexibility.

The Ethernet shield also uses D4 for the slave select signal for the SD card. So things could get complicated. Can't be all things to all people.

PS: A better solution might be to modify the Ethernet constructor to include an argument specifying which pin to use for SS. It could have a default value for backwards compatibility. As for using digitalWrite to drive it, I'd much prefer direct port manipulation for performance reasons, I think that's important for the Ethernet library. Could be that is why it is the way that it is now.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 09, 2014, 02:31 am


Jack,
I'm guessing that "fix" you did worked for you because you are using a variant the mapped PB4 to digital pin 10.
It wouldn't have worked for the mighty 1284 standard or developers variants which map PB4 to digital pin 4.


Actually the standard variant maps PB4 to D4.
Yes, that Is also what I said.
My fix unconditionally causes the Ethernet library to use PB4 (for 1284P), which is the hardware SS pin, regardless of variant. This is what I wanted and while it seemed reasonable to me, now that I think about it a bit more, it's probably not universal. Plus I am not using an Ethernet shield which gives me more flexibility.

The Ethernet shield also uses D4 for the slave select signal for the SD card. So things could get complicated. Can't be all things to all people.
The use of D4 shouldn't be an issue as I'm assuming that the SD code uses the core i/o
routines to drive it.

PS: A better solution might be to modify the Ethernet constructor to include an argument specifying which pin to use for SS. It could have a default value for backwards compatibility. As for using digitalWrite to drive it, I'd much prefer direct port manipulation for performance reasons, I think that's important for the Ethernet library. Could be that is why it is the way that it is now.


I went back and reviewed the SPI h/w in the AVR.
It is intertwined with the SS pin.
So when using h/w spi, which the ethernet code does, the AVR SS pin can't be used as generic pin
for something else.
While the ethernet library s/w could be re-done to use a programmable pin for the ethernet SS pin the real SS pin
would have to remain an output in master mode and an input in slave mode and couldn't be used for anything else.
So that means if the Ethernet pin were not the same as the SS pin, two avr pins would be used.
Because of this I think adding the ability to configure the Ethernet SS pin may not be that useful and
hard-coding the pin based on the processor type is the way to go
since it must be set at least to the proper direction even if it isn't used for the actual SS of the device.

So he is my latest thinking.
Since the SS pin is intertwined with the h/w SPI operation then it is ok to select the pin based on the
processor type.

The drawback to the way the SPI h/w in the AVR works, is that variants like the mighty 1284 standard
and developers can not be used on an UNO form factor board with an eithernet shield.
This is because the AVR SS pin (PB4) is mapped to digital pin 4 and the ethernet shield uses digital pin 10
for its SS.
So 1284 core board makers and users that want better UNO shield compatibility
will want to use the bobuino or the SBeauty pin mappings.

So this is a long way of saying, I agree with you Jack that the raw port i/o is ok but
the mighty 1284 variants standard and devlopers are not recommended on UNO form factor
boards because of incompatibilities with the pin mappings of existing UNO shield.

Maybe all you guys already new that....
(I'm just starting to play with the 1284)

--- bill


Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 09, 2014, 03:04 am
Bill, thanks for the research and input. Guess I'll stick with what I have as long as it works for me ;)  I also did see on the Ethernet Shield page that they mention that with the Mega the hardware SS pin is not used for the slave select signal to the shield but has to go unused. Not a huge deal losing a pin on a Mega I guess!
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 09, 2014, 03:16 am
The whole software pin abstraction concept often is limited by internal hardware limitations of the AVR. It would be nice if things could be remapped via EEPROM or other internal chip functions to deal with the internal pin overloading when using many internal hardware peripherals.

For example, so far my main gripe with the 1284P is that if you want to utilize that very nice 2nd UART, you are prevented from using 2 of the 3 user interrupt pins. If they hadn't added that third user interrupt pin it would mean you could not use any user interrupts and the 2nd UART in the same sketch. That sucks!

Lefty

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 09, 2014, 03:57 am
You'll notice that the so-called Ethernet SS-pin nastiness does not really exist.

First off, they use the same nomenclature for "all" of the boards called out in w5100.h, and secondly, this file is not going to pertain to any of the 1284 variants other than Bobuino, because the Ethernet shields are **hardwired** to plug into UNO headers, and not whatever header arrangements are used on the other 1284 variants. IE, they'll not plug in, except to UNO, mega style boards. Plus the SS pin on those shields is also hardwired. So, the existing w5100.h file matches the shield. And all you need do is add what I called Fix#1.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 09, 2014, 04:42 am

The whole software pin abstraction concept often is limited by internal hardware limitations of the AVR. It would be nice if things could be remapped via EEPROM or other internal chip functions to deal with the internal pin overloading when using many internal hardware peripherals.

For example, so far my main gripe with the 1284P is that if you want to utilize that very nice 2nd UART, you are prevented from using 2 of the 3 user interrupt pins. If they hadn't added that third user interrupt pin it would mean you could not use any user interrupts and the 2nd UART in the same sketch. That sucks!

Lefty

I think whichever engineer at Atmel it was who sat down and choose to hardwire INT0 and INT1 to the same pins as the 2nd UART must have been on Drogues that day, or some other moon of Saturn.

If you want remappable peripherals, you can always switch to a PIC24 or PIC32 chip.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 09, 2014, 04:47 am

You'll notice that the so-called Ethernet SS-pin nastiness does not really exist.

I am not understanding what you were trying to say.

The Ethernet SS issue relates to using an Ethernet shield with UNO style headers.
It happens anytime the  core & variant combination does not map the SS pin to D10.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 09, 2014, 05:11 am
Quote

I think whichever engineer at Atmel it was who sat down and choose to hardwire INT0 and INT1 to the same pins as the 2nd UART must have been on Drogues that day, or some other moon of Saturn.

If you want remappable peripherals, you can always switch to a PIC24 or PIC32 chip.


If I can't do it on a 8 bitter, then I'm not doing it all.  8)
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 09, 2014, 05:19 am

Quote

I think whichever engineer at Atmel it was who sat down and choose to hardwire INT0 and INT1 to the same pins as the 2nd UART must have been on Drogues that day, or some other moon of Saturn.

If you want remappable peripherals, you can always switch to a PIC24 or PIC32 chip.


If I can't do it on a 8 bitter, then I'm not doing it all.  8)

Although, I think if you willing to leave AVR behind,
I think an UNO form factor with a PIC32MX250f128B would
be pretty killer.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on May 09, 2014, 07:00 am


You'll notice that the so-called Ethernet SS-pin nastiness does not really exist.

I am not understanding what you were trying to say.

The Ethernet SS issue relates to using an Ethernet shield with UNO style headers.
It happens anytime the  core & variant combination does not map the SS pin to D10.

--- bill

That's what the rest of the post is about.

w5100.h is written to support the way the "standard" Ethernet shield is designed, and for it to be plugged into UNO-style headers, so the file is perfectly good the way it is, except for adding what I called Fix#1. There is no point in modifying the file unless the shield hardware is changed.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 09, 2014, 05:31 pm

[(Does anyone else think "standard variant" sounds odd? :D)

yes!

One way you could do to include the "non standard" pin mapping variants (such, as, er, "standard")

is to have them define three macros in their variants pins_arduino.h file.

Code: [Select]

#define ENET_INIT_SS DDRB|=_BV(4)
#define ENET_SET_SS PORTB&=~_BV(4)
#define ENET_RESET_SS PORTB|=_BV(4)


or whatever is appropriate for their pin mapping to toggle whatever pin is connected to SS on the Ethernet shield.

And then write:

Code: [Select]

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
#if defined(ENET_INIT_SS) && defined(ENET_SET_SS) && defined(ENET_RESET_SS)
 inline static void initSS()    { ENET_INIT_SS; }
 inline static void setSS()     { ENET_SET_SS; }
 inline static void resetSS()   { ENET_RESET_SS; }
#else
 inline static void initSS()    { DDRB  |=  _BV(4); }
 inline static void setSS()     { PORTB &= ~_BV(4); }
 inline static void resetSS()   { PORTB |=  _BV(4); }
#endif


This gives the guys with pin mappings where SS != D10 a chance to use the etherent shield, at least.

For "standard shield" mappings (Bobuino, Goldilocks, SB (I think ?)) the default could be used, and the macros wouldn't need to be defined. For "standard", and other non-standard mappings, they would have define the three macros.
 
Just a thought.

BTW, I removed the trailing ; after the inline function definitions (shouldn't really be there, since the closing brace closes a function definition, not a statement.)

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 09, 2014, 05:46 pm

This gives the guys with pin mappings where SS != D10 a chance to use the etherent shield, at least.


I'm not seeing why this is necessary.

If SS is not connected to D10 when used on a UNO form factor,
then the shield will not work since
the shield is tied to the header pin where D10 is on the UNO.

If the board is not in an UNO form factor then
it is not an issue for them since the shield can not physically
plug into their board and wires are going to be used for connections
between the board and the shield.
Since they are using wires,  they can wire
whatever pin is SS on their board to the D10 pin on the shield.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 09, 2014, 05:58 pm


This gives the guys with pin mappings where SS != D10 a chance to use the etherent shield, at least.


I'm not seeing why this is necessary.

If SS is not connected to D10 when used on a UNO form factor,
then the shield will not work since
the shield is tied to the header pin where D10 is on the UNO.


The board could physically have the UNO header layout, just not have physical SS connected as their logical D10.

So you could plug the Ethernet (or other) shield in. If they are connected via the ICSP port, they have SPI (that's the standard SPI connection these days, anyway).

It would be a pity to say they couldn't run a shield on SPI just because they didn't have physical SS mapped to that pin. And a bit arbitrary. Particularly since it's not technically difficult to free up that constraint.

Anyway, just a suggestion. I like to see flexibility, even if it isn't always clear in advance how that might be used. Someone may be grateful at some later date the flexibility is there, however. And even if not, it incurs no overhead or does any other harm to provide it, so why not?
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 10, 2014, 02:31 am



This gives the guys with pin mappings where SS != D10 a chance to use the etherent shield, at least.


I'm not seeing why this is necessary.

If SS is not connected to D10 when used on a UNO form factor,
then the shield will not work since
the shield is tied to the header pin where D10 is on the UNO.


The board could physically have the UNO header layout, just not have physical SS connected as their logical D10.

So you could plug the Ethernet (or other) shield in. If they are connected via the ICSP port, they have SPI (that's the standard SPI connection these days, anyway).

It would be a pity to say they couldn't run a shield on SPI just because they didn't have physical SS mapped to that pin. And a bit arbitrary. Particularly since it's not technically difficult to free up that constraint.

Anyway, just a suggestion. I like to see flexibility, even if it isn't always clear in advance how that might be used. Someone may be grateful at some later date the flexibility is there, however. And even if not, it incurs no overhead or does any other harm to provide it, so why not?



I'm all for flexibility but it isn't always without potential overhead or harm.
It can end up using  a "hidden" pin, depending on the variant pin mappings
so users would need to be careful when using this since the real AVR SS pin is still
half being used.
I say "half being used" since the AVR SS pin can still be used as an output, it just can't be used
as an input.

It would work, but it is a bit funky though, to put library & shield specific pin mapping macros
in the variant file.
Typically this kind of stuff is handled by config files in the library or by the library constructor
but since since the Ethernet code is doing raw port i/o on the Ethernet SS,
it is running into that pin mapping issue that is based
on having to know the exact core & variant pin mappings at compile time.

--- bill
Much more details below, for those that are interested.



Ignoring the weirdness of putting library/shield specific macros inside the variant file,
there are some other potential issues that can crop up.

One potential issue that quickly arises is that the real SS pin can affect master mode SPI transfers.
(if SS pin is in input mode and driven low, the SPI interface flips back to slave mode)
The Ethernet shield uses the Arduino D10 pin for the Ethernet SS and if
it is not the AVR SS pin, then two pins are used since the Ethernet library uses SPI in master mode.
The SPI library will be setting the AVR SS pin to be an output and setting it to be HIGH initially and
the Ethernet shield will still need to use Arduino D10 for its SS.

So now look at the real world pin mappings in 6 different mighty 1284 variants
I've seen floating around out there.
(Yes there are actually at least 6 different 1284 variants out there)
Code: [Select]

PIN   bobuino/SB  standard/avr_dev  hiduino/Goldilocks
------------------------------------------------------
SS       PB4          PB4                PB4   
D10      PB4          PD2                PB4   
D4       PB0          PB4                PD4   



So in if these variants were to be used on an UNO form factor:

for bobuino/Sbeauty/hiduino/Goldilocks the macros would be:
(or these variants could chose to not define these since the default is the same as these)
Code: [Select]

#define ENET_INIT_SS DDRB|=_BV(4) // make D10 output
#define ENET_SET_SS PORTB&=~_BV(4)  // set D10 LOW
#define ENET_RESET_SS PORTB|=_BV(4) // set D10 HIGH



For the standard and avr_developers variants they would need to define these:
Code: [Select]

#define ENET_INIT_SS DDRD|=_BV(2) // make D10 output
#define ENET_SET_SS PORTD&=~_BV(2)  // set D10 LOW
#define ENET_RESET_SS PORTD|=_BV(2) // set D10 HIGH


Arduino pin D10 can now be driven using raw port i/o with the macros.

But also remember that the SPI hardware will need the AVR SS pin to be in output mode.
The AVR SS pin is on D10 with the SBeauty/bobuino/hiduino/Goldilocks variants so on those
variants only a single AVR pin is needed to run the Ethernet SPI interface.

On the standard/avr_developers variants SS is on D4 so two pins are needed to run
the Ethernet SPI interface on those variants: D4 and D10.
Technically D4 isn't used, it just can never be an input and be driven low.

So when using standard and avr_developers variants D4 is not free for use as an input
even though the Ethernet library is not really using it.
(It can still be used as an output)

Also, don't forget that the SD interface on the Ethernet shield uses Arduino D4 as its SS pin.
(This is the potential D4 issue that Jack brought up earlier)

In these 6 pin mappings, the SD interface could still be used since it allows the user to select
the SS pin. If D4 is selected to work with the shield, it still should work ok even on the
standard and avr_devleopers variants since the SD library never puts  the SD SS pin in input mode.

So on the standard and avr_developers variants, the AVR SS pin  (Arduino digital pin 4)
would remain in output mode but could also be used as the SD SS pin.

Other variant pin mappings may run into different pin issues.



Title: Re: Updating the mighty-1284p core
Post by: pico on May 10, 2014, 05:47 am
Bill, while everything you say is true, it's also kind of old news. You are describing the situation that actually currently exists with the Mega (both 1280 and 2560).


I'm all for flexibility but it isn't always without potential overhead or harm.
It can end up using  a "hidden" pin, depending on the variant pin mappings
so users would need to be careful when using this since the real AVR SS pin is still
half being used.
I say "half being used" since the AVR SS pin can still be used as an output, it just can't be used
as an input.


Yep, just like with the Megas.


It would work, but it is a bit funky though, to put library & shield specific pin mapping macros
in the variant file.


Well, it *is* called pins_arduino.h. And it's main job is to describe specific pin mappings.


Much more details below, for those that are interested.


Which is all correct, but also note that all these points have long affected those with a Mega,  as a Mega also has 1) a Uno shield factor layout, but 2) hasn't mapped the physical SS pin on the chip to D10.

So what was the result? Mega owners had to learn to ensure that when using SPI the *real* chip SS was explicitly set as an output (there must about 1M forum posts on this subject alone), and if they were thinking of using it as an input, look somewhere else, or your SPI isn't going to work (at least, not as expected)!

The same situation may even be true for other boards (e.g., Leo, I don't know, I'd have to check.)

But in any case, the idea that SPI resides on pins 11-13, with SS on 10, has long been out the door, and the "official" way to get SPI to a shield these days is from the ICSP header.

But that still leaves SS, which isn't on the ICSP header.

So doing it this way, while not ideal (ideal? Hey, this is *Arduino* we are talking about...)  is basically putting the variant 1284p boards with physical SS not mapped to D10 in the same class as the Megas.

Which, on balance, doesn't seems unreasonable. If it isn't "too hard" for the Mega, why should be it too hard for the 1284p?

As it turns out, for the "standard" mighty variant, SS maps to D4 which I think is likely to be set as an output anyway (if used as the for the SS for the SD Card on the ethernet shield), so no practical issue in that case anyway. (Edit: I see Bill has already looked at this in detail above, and comes to the same conclusion. So at least we are in agreement on that.)

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 10, 2014, 07:31 pm
As an important reminder about AVR direct port i/o,
the gcc compiler kludge that turns these
Code: [Select]
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.

On the mega, this will be ports H, J, K, & L
There are several pins on the Mega boards in the UNO header
space, that use these ports.
This is part of the complexity of trying to do AVR direct port i/o correctly.
Essentially there is no atomic direct port i/o for the pins on ports
H, J, K, & L.
So in order to do atomic i/o on those pins you have to mask interrupts
before doing the i/o to the port register.
But then you can't just blindly enable interrupts after doing the i/o.
This means the direct port i/o code has to:
- save the interrupt mask state
- mask interrupts
- do the i/o
- restore the interrupt mask sate.

If you don't do properly mask interrupts on those higher ports,
you can and will end up with subtle port corruption issues
if the same port is being modified at ISR level by some other library updating
a pin on the same port.
There is no way around this.






It would work, but it is a bit funky though, to put library & shield specific pin mapping macros
in the variant file.


Well, it *is* called pins_arduino.h. And it's main job is to describe specific pin mappings.

Yes but so far the pin mappings and macros in the variant file are generic for use with any library.
There are currently no macros specific to a given library or shield.
I think it becomes a very slipery slope and an ongoing maintenance issue when the pin mapping macros are
for the purpose of AVR port i/o and are not related to the actual board but rather a shield or a library.

In the case of the Ethernet shield library, the library could have used a constructor object
to allow the user to to configure the Ethernet SS pin and then used the core digital i/o
routines. This would have been portable across ALL arduino boards with no
potential atomicity issues.

To dramatically increase the pin i/o performance over using the
Arduino digital core i/o routines, the Ethernet library could be tweaked to use
the indirect port i/o I described earlier.
This gives a solution that while not as fast as direct port i/o is still much
faster than the core i/o routines.
The big benefit is that because most of the runtime overhead is shifted in time to setup(),
the library can use a constructor parameter to configure which pin is used.
This would be the solution that I would suggest using if there is a desire to allow
the user to configure the pin used for Ethernet SS and using the core i/o routines
creates a performance issue.
This solution works across all Arduino boards & variants and allows
the user to configure the pin from his sketch.


What we currently have in the Ethernet library is situation just like I have in my openGLCD library.
The use of direct port i/o - probably for performance reasons.
And like I've said many times, once you want to do AVR raw port i/o
things can get complicated pretty quickly since you have to know not only the core but the variant to be
able to get the mapping correctly.

My suggestion would be that if there is a desire to add AVR port i/o macros to the variant files,
then it would be much better to create a macro for each digital pin or a macro that
can be passed the desired pin number (similar to the way digitalWriteFast() works)
rather than creating an i/o macro that is specific to a given library or shield.
That way any library could now do raw port i/o based on knowing which digital pin it needed to wiggle.

For example, the ethernet library could check for the existence of the raw port i/o
macro to wiggle D10. If it existed, it uses it,  otherwise it falls back to using the
Arduino core i/o routines.
That way the code is guaranteed to work on all Arduino boards.

For configuring the Ethernet shield library to pin than D10 for Ethernet SS, I think the user
should go in and modify something down in the ethernet library rather than
something down in the variant.

Again, I think it is a very slippery slope to start adding library and shield specific support into the variant files.
My belief and desire is not to solve things haphazardly one case at a time but rather to solve them for the general case.
i.e. the ethernet shield library is not the only library that may want to have faster AVR pin i/o.
So why not create a solution that can work for all libraries?


-- bill
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 15, 2014, 10:03 pm
So I was looking at trying to do a pull request for SleepingBeauty board support
for Jacks 1284p repo and immediately saw an issue
related to the bootloader and variant files.
The LED....
I'm not sure how things are working correctly on various boards.
My guess is they aren't.

All the 644/1284  variant files map the LED to PB7 regardless of which digital pin that may be.
This is true for  the ManiacBug core, Jacks core, and the SleepingBeauty core.
It is true for all the variants within each of those 3 cores.
So at least according to all the variant files, an LED must be on PB7.

However, things start to look problematic when looking at the bootloader.
The optiboot bootloader controls which pin is used for the LED in pin_defs.h

The optiboot pin_defs.h in the ManiacBug core sets it to PB0

The optiboot pin_defs.h in the SleepingBeauty core sets it to PB7
(It mentions that Sanguino is PB0 but sets the LED to PB7)

The optiboot pin_defs.h in the Jacks 1284p core sets it to PB1
(It mentions that Sanguino is PB0 but sets the LED to PB1)

So what you can see here is that the ManiacBug core optiboot bootloader will use
PB0 for the LED, SleepBeauty core will use PB7 for the LED, and Jacks core will use PB1.
So if you re-burn the bootloader, you can end up with a non working bootloader LED, depending on
how the LED is wired up and which core you used.

I'd also like to point out that the all variant files indicate that the LED is on PB7.
This means in order for sketches to work that use LED or LED_BUILTIN, all the 1284/644 boards
must have an LED wired to PB7 since that is what is in the variant file.
If the board uses a pin other than PB7 for its LED,
those sketches that now use LED_BUILTIN will break.

So there is an inconsistency issue here unless some of the 1284/644 boards have two LEDs.
with one being used for the bootloader and another one being used for sketches.
Is that really the case?

If not, and there is a desire to use a pin other than PB7 for the LED, then there is some work to
ensure that things remain consistent between the bootloader, the variant file, and the actual hardware.
- the makefile must be able to build a version of the bootloader for each LED pin
- there must be variant files for each different LED pin
- 1284/644 boards in boards.txt must point to the proper bootloader hex image since will be more than one.

So jack, that means you will have to create your own variant file for your board, if you  want to use
a different pin for your LED unless you have two LEDs on your board since what I'm seeing right now
is the bootloader and the variant files disagree on what pin is used for the LED.

My suggestion at least for now, would be to see if everyone could use PB7 since that is what
all the variant files are already specifying. That would really simplify things.

If not, then there is some work to do, to make things really work and to be able to
build and update bootloaders and be able to use LED_BUILTIN in sketches as intended.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 15, 2014, 11:33 pm
When designing my board, before we embarked on updating the MB core, I checked the "standard" variant and found the LED was on digital pin 7 (https://github.com/maniacbug/mighty-1284p/blob/master/variants/standard/pins_arduino.h#L52), which is PB7. That seemed reasonable, so I went with it.

Once my board was built, I found through experimentation that optiboot_atmega1284p.hex (https://github.com/maniacbug/mighty-1284p/blob/master/bootloaders/optiboot/optiboot_atmega1284p.hex) in the MB core actually blinked PB0. None of that has changed in the refreshed core.

However, when I recently built the 1M baud Optiboot, I downloaded the latest Optiboot code (https://code.google.com/p/optiboot/) and found that by default, building the mighty1284 bootloader used PB7 for the LED. That fit my purposes so I just added the 1M bootloader in with the existing stuff, and pointed my boards.txt entry at it.

So in general, what Bill has found is that any given board may require its own bootloader in combination with a pins_arduino.h file just to get the onboard LED right, if there is one.

I'd like to see new bootloaders built from the current Optiboot source for all boards supported by the refreshed core. If board owners/designers don't want to do it themselves, I'll volunteer to build additional bootloaders if they will supply me with the following information: Target MCU and clock speed, UART (0 or 1) for upload and baud rate, LED port and pin number (or if there is none), and name desired for the .hex file.

I can't tell for sure whether there ever was an actual "mighty1284" board per se (meaning a PCB that was produced even in some small quantity). MB's blog shows a breadboard, so maybe folks were just doing their own thing whether it was breadboard, perfboard, or their own PCB. Anyone have any insight into that? Just curious.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 15, 2014, 11:46 pm

The optiboot pin_defs.h in the ManiacBug core sets it to PB0
...
The optiboot pin_defs.h in the Jacks 1284p core sets it to PB1


No, the pin_defs.h file has not changed, see:
https://github.com/maniacbug/mighty-1284p/blob/master/bootloaders/optiboot/pin_defs.h#L52
https://github.com/JChristensen/mighty-1284p/blob/v1.0.5/bootloaders/optiboot/pin_defs.h#L52

But, as I did observe somewhat earlier in the thread, the source (i.e. pin_defs.h) in MB's core does not match what the hex file (https://github.com/maniacbug/mighty-1284p/blob/master/bootloaders/optiboot/optiboot_atmega1284p.hex) actually does, it blinks PB0.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 16, 2014, 01:18 am
Jack,
I tracked down the differences I saw in the ManiacBug core.
My ManiacBug core was out of date from 2012. Just before the LED pin was changed from PB0 to PB1.
So while MB and your core are now both using PB1, I'm seeing that the current optiboot repo uses PB0 by default.
Code: [Select]
/*------------------------------------------------------------------------ */
/* Sanguino support (and other 40pin DIP cpus) */
#if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega32__)
/*------------------------------------------------------------------------ */
/* Onboard LED is connected to pin PB0 on Sanguino */
#if !defined(LED)
#define LED         B0
#endif



The bigger issue is the pin used in the optiboot files that comes with the core
differs from the pin used in the variant files included in the very same core.
i.e. the bootloader in the core is using PB1 and the variant files tell the sketches to use PB7.




What I'm really pointing out
is that I believe that any board that comes with a core package in its boards.txt file should
have boot loader support "out of the box" after they install the core
that allows the end user to re-install a working bootloader for that board using the IDE.
If the variant for a board specifies a different LED pin mapping then the bootloader build package
that comes with that core also needs to support building the matching bootloader for that board variant.
Or at least it should come with a pre-built bootloader for that board.
My preference is it should build them all, it's easy and that is what make is for.

What I'm seeing with the 1284/644 cores is that all the variants are setting the Arduino IDE LED define to be pin B7
but the optiboot bootloader build included with the core is not using that pin for the 1284 images.
Note: The SleepingBeauty core did go fix the optiboot bootloader build to correctly build the correct
bootloader.

So in all the cores except the SleepingBeauty core, optiboot build will use PB1 while sketches uses PB7.
This is a big issue.




But it sounds like most if not all boards are now using PB7 for their LED, even though the optiboot build included with the core
may be using PB1 and the official optiboot repo seems to be using PB0 by default.

A "quick & dirty" solution would be to update the pins_defs.h included in the core to use PB7
so it matches all the variant files.

However, I think the better solution is to update the optiboot included with the core
to the newer version as it also supports setting the LED pin from the command line.
This makes it easier to build images should the LED pin need to be changed or
additional bootloader images need to be created.

summary of needed changes:
-  optiboot build files in the core updated to the new optiboot,
- makeall script should be updated to build all the needed 644/1284 images.
Which includes images for the 1M baudrate as  115200.
That way board types can be added to the boards.txt file for both speeds and users
can use the IDE to update the bootloader for whichever one they want.
- bootloaders/optiboot directory should include pre-built bootloaders for all the boards in the boards.txt file


I'll be happy to make the changes if people agree that this is needed.



--- bill

Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 01:40 am

I'll volunteer to build additional bootloaders if they will supply me with the following information: Target MCU and clock speed, UART (0 or 1) for upload and baud rate, LED port and pin number (or if there is none), and name desired for the .hex file.


id be very grateful if you could produce one for uart0, 16mhz,, and no led. specially if it turns out 447bytes or less like the one coding badly put up on page 4 but  57kbaud instead of 1m. this would have best chance of working  on ALL systems instead of needing a new bootloader for every new combination of usb adapter, mcu board, and pc os. it would even run fine at 8mhz  (half speed, 28kbaud). "opti1284.hex " or any other name would be fine.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 02:35 am


I'll volunteer to build additional bootloaders if they will supply me with the following information: Target MCU and clock speed, UART (0 or 1) for upload and baud rate, LED port and pin number (or if there is none), and name desired for the .hex file.


id be very grateful if you could produce one for uart0, 16mhz,, and no led. specially if it turns out 447bytes or less like the one coding badly put up on page 4 but  57kbaud instead of 1m. this would have best chance of working  on ALL systems instead of needing a new bootloader for every new combination of usb adapter, mcu board, and pc os. it would even run fine at 8mhz  (half speed, 28kbaud). "opti1284.hex " or any other name would be fine.


The bootloader I just built is closer to 500 bytes. Is 447 a special number for some reason? What difference does it make, since the hardware has to allocate 512 bytes for the bootloader?
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 02:54 am

summary of needed changes:
-  optiboot build files in the core updated to the new optiboot,
- makeall script should be updated to build all the needed 644/1284 images.
Which includes images for the 1M baudrate as  115200.
That way board types can be added to the boards.txt file for both speeds and users
can use the IDE to update the bootloader for whichever one they want.
- bootloaders/optiboot directory should include pre-built bootloaders for all the boards in the boards.txt file

I'll be happy to make the changes if people agree that this is needed.


Bill, I think we're on the same page. If you want to run with it that's fine with me, thank you very much!

What do you think about bootloaders/standard? MB included them for historical reasons but recommended against them. I wonder if they could just be dropped at this point, along with the boards.txt entries that reference them. Does anything other than Optiboot need to be supported for the 1284/644 at this point?

I'm a big fan of 8MHz but personally, I think I'd be much less likely to use it with a 1284 than with a 328. OTOH, it's not a huge deal to include 8MHz versions in the makefile and makeall script. So either way works for me.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 16, 2014, 03:01 am
So is PB7 still the LED then? That's the activity LED for Bobuino pinouts = SCK/D13.
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 03:03 am

The bootloader I just built is closer to 500 bytes. Is 447 a special number for some reason? What difference does it make, since the hardware has to allocate 512 bytes for the bootloader?


did it have led? as i mentioned just now in my post the 447 number came from the one coding badly put up on page four of this thread. i was surprised at how much the no-led cut down. i have been able to get down to 300 and some bytes by massaging  in asm to make room for >128k feature but had to make some sacrifices. and it wasnt open source. in any case id like to get a more standard version to distribute. specially if it was smaller or had the >128k. not a requirement though so it would be nice to check out anything for m1284. i always saw this chip as wave of the future and finally others seem to be picking up on it. more ram than any other avr, cheap, lotsa flash, and friendly dip.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 03:08 am

So is PB7 still the LED then? That's the activity LED for Bobuino pinouts = SCK/D13.


There's two things here, what the pins_arduino.h file defines as the built-in LED, and what the bootloader flashes when the reset button is pressed. The former is only of concern to a user sketch, and the latter is only of concern to the bootloader. Strictly speaking there is no connection between the two, as they are specified in different ways and in different places.

On a bobuino board, a sketch that uses LED_BUILTIN will correctly address the SCK/D13 LED, but the bootloader flashes won't be seen.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 16, 2014, 03:16 am

On a bobuino board, a sketch that uses LED_BUILTIN will correctly address the SCK/D13 LED, but the bootloader flashes won't be seen.

It will when I get done with some updates...  ;)

Or at least all the boards included in the core's boards.txt file, will point to a pre-built
bootloader that will blink the same pin as its LED_BUILTIN in its variant file.

Actually, is anybody using SB0 or SB1 for their 1284 LED?
If not, curious why the default shouldn't be SB7 at this point
since that seems to be what bobuino, SB, and your board (Jack) is using
for the LED pin and then it would match all the current variant files.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 03:16 am


The bootloader I just built is closer to 500 bytes. Is 447 a special number for some reason? What difference does it make, since the hardware has to allocate 512 bytes for the bootloader?


did it have led? as i mentioned just now in my post the 447 number came from the one coding badly put up on page four of this thread. i was surprised at how much the no-led cut down. i have been able to get down to 300 and some bytes by massaging  in asm to make room for >128k feature but had to make some sacrifices. and it wasnt open source. in any case id like to get a more standard version to distribute. specially if it was smaller or had the >128k. not a requirement though so it would be nice to check out anything for m1284. i always saw this chip as wave of the future and finally others seem to be picking up on it. more ram than any other avr, cheap, lotsa flash, and friendly dip.


Yes it did have an LED, so that could well be the difference. But 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. The bootloader section can be 256, 512, 1024 or 2048 1, 2, 4 or 8k bytes. So no saving in flash memory used, until it gets down to 256 bytes or less any bootloader under 1kB will still require 1kB of flash dedicated for it.

Edit: Corrected bootloader sizes, I read the table as "bytes" not "words".
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 03:22 am

Actually, is anybody using SPB0 or SPB1 for their 1284 LED?
If not, curious why the default shouldn't be SPB7 at this point
since that seems to be what bobuino, SB, and your board (Jack) is using
for the LED pin and then it would match all the current variant files.


Unknown, but I do want to make the point that the Arduino standard "seems" to be (meaning that I haven't found it actually written down) to put the LED on "digital pin 13", whereas the mb/1284 standard seems to be to put it on SCK/PB7, whatever digital pin that might happen to be.

I can see it either way, but I wouldn't necessarily advocate following what seems to be the Arduino convention, in fact the "SCK" standard seems to me to maybe make a little more sense, for reasons that I cannot fully explain :D

Of course, with things set up properly, as Bill has pointed out, it should all be transparent to the user.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 16, 2014, 03:46 am

Unknown, but I do want to make the point that the Arduino standard "seems" to be (meaning that I haven't found it actually written down) to put the LED on "digital pin 13", whereas the mb/1284 standard seems to be to put it on SCK/PB7, whatever digital pin that might happen to be.

I can see it either way, but I wouldn't necessarily advocate following what seems to be the Arduino convention, in fact the "SCK" standard seems to me to maybe make a little more sense, for reasons that I cannot fully explain :D


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

FWIW, I chose to put the LED on D13 (PB7) for my "Big Bob" board (now to be named "Skinny Bob", upon consideration), just for maximum compatibility with Uno "standards". I really don't want to have to take that into consideration when selecting a bootloader.

I would vote for a small set of generic, non-LED flashing bootloaders that simply corresponded to various xtal frequency and baud rate combos.

I don't want no steenkin' bootloader flashing my LEDs!!!

(I actually tried to upload that statement to a Mega once, but it failed.)
Title: Re: Updating the mighty-1284p core
Post by: pico on May 16, 2014, 03:50 am

I can see it either way, but I wouldn't necessarily advocate following what seems to be the Arduino convention, in fact the "SCK" standard seems to me to maybe make a little more sense, for reasons that I cannot fully explain :D


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!
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 04:16 am

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.


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.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 05:35 am

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

Quote

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!
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 16, 2014, 06:16 am
This place is getting like Burger King, bootloader, have it your way!

Title: Re: Updating the mighty-1284p core
Post by: westfw on May 16, 2014, 06:49 am
Quote
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 :-( )
Title: Re: Updating the mighty-1284p core
Post by: Coding Badly on May 16, 2014, 07:28 am
(Also, note that the 1.5.x directory structure breaks the "use the arduino compiler" feature of the optiboot Makefile :-( )


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.

Quote
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!
Title: Re: Updating the mighty-1284p core
Post by: pico on May 16, 2014, 08:21 am

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


I'm completely with you on this.


Thank you for adding support for 1 M baud!


+1. Thanks to westfw for all your outstanding contributions generally!
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 01:52 pm

Quote
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 ?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 16, 2014, 02:30 pm
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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 02:54 pm
Ack I missed "words" again :smiley-red:  I stand corrected thank you!
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 03:03 pm

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


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.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 16, 2014, 05:51 pm

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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 16, 2014, 06:01 pm
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  :smiley-eek-blue:


As an important reminder about AVR direct port i/o,
the gcc compiler kludge that turns these
Code: [Select]
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:

Code: [Select]
        //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>
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on May 16, 2014, 06:05 pm
Quote
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 (http://playground.arduino.cc/Main/CustomizeArduinoIDE)



Ray
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 06:13 pm

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.
Title: Re: Updating the mighty-1284p core
Post by: john1993 on May 16, 2014, 06:20 pm

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.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 16, 2014, 06:23 pm

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  :smiley-eek-blue:


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
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 17, 2014, 03:39 am


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  :smiley-eek-blue:


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.


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

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

Quote
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.
Title: Re: Updating the mighty-1284p core
Post by: westfw on May 17, 2014, 03:44 am
Quote
I wonder which the "most other AVRs" are.

Probably everything whose part number starts with "AT90S"...
Title: Re: Updating the mighty-1284p core
Post by: pico on May 19, 2014, 05:30 pm
So where did we get up to with the discussion on whether the patched libraries should be added to the repository?
Title: Re: Updating the mighty-1284p core
Post by: OldMicroGuy on May 20, 2014, 04:04 pm
Hi pico.

How is testing going on "Big Bob"
Going to offer it for sale soon?

Roger
Title: Re: Updating the mighty-1284p core
Post by: pico on May 20, 2014, 04:23 pm

Hi pico.

How is testing going on "Big Bob"
Going to offer it for sale soon?

Roger



hi Roger,

Tests have checked out well, I'm now just waiting for some parts to arrive from China so I can put some kits together. So "real soon now" (?!)

I got a similar query near the end of this thread in "Hardware"

http://forum.arduino.cc/index.php?topic=236897.0

so you may want to keep an eye on that for general discussion. Also, when it's officially for sale, I'll also put something up in the "Products" forum.

Edit: And by the way, he's officially "Skinny Bob" now! :-)
Title: Re: Updating the mighty-1284p core
Post by: pico on May 21, 2014, 07:59 pm
Anyone think of any reason not to have the JTAG programming fuse bit programmed as enabled?

It involves changing the high fuse setting from 0xDE to 0x9E. I've been playing around a bit with JTAG programming/debugging on a 1284p using an AVR Dragon, and so I've had to adjust this.

I can't see any issues so far with leaving it as the default, since the 1284p supports JTAG. Anyone else know better?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 21, 2014, 09:22 pm
I think if you do that, it disables SPI for programming. Read the datasheet to be sure.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 21, 2014, 09:36 pm
I withdraw the prior comment - they appear to be independent:

Table 27-4. Fuse High byte.
Fuse High byte Bit no. Description Default value
OCDEN (Note 4) 7 Enable OCD 1 (unprogrammed, OCD disabled)

JTAGEN 6 Enable JTAG 0 (programmed, JTAG enabled)

SPIEN (Note 1) 5 Enable Serial Program and Data Downloading 0 (programmed, SPI prog. enabled)

WDTON (Note 3) 4 Watchdog Timer always on 1 (unprogrammed)

EESAVE 3 EEPROM memory is preserved through the Chip Erase 1 (unprogrammed, EEPROM not preserved)

BOOTSZ1 2 Select Boot Size (see Table 27-9 on page 302 for details)
0 (programmed) (Note 2)

BOOTSZ0 1 Select Boot Size (see Table 27-9 on page 302 for details)
0 (programmed) (Note 2)

BOOTRST 0 Select Reset Vector 1 (unprogrammed)

Note:
1. The SPIEN Fuse is not accessible in serial programming mode.
2. The default value of BOOTSZ1..0 results in maximum Boot Size. See Table 26-10 on page
292 for details.
3. See "WDTCSR - Watchdog Timer Control Register" on page 59 for details.
4. Never ship a product with the OCDEN Fuse programmed regardless of the setting of Lock bits
and JTAGEN Fuse. A programmed OCDEN Fuse enables some parts of the clock system to
be running in all sleep modes. This may increase the power consumption.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 27, 2014, 10:31 am

Anyone think of any reason not to have the JTAG programming fuse bit programmed as enabled?

It involves changing the high fuse setting from 0xDE to 0x9E. I've been playing around a bit with JTAG programming/debugging on a 1284p using an AVR Dragon, and so I've had to adjust this.

I can't see any issues so far with leaving it as the default, since the 1284p supports JTAG. Anyone else know better?



I had a play with this a bit more, and for boards like the Goldilocks and SB which have the JTAG pins PC2-PC5 dedicated to a JTAG header, and are not broken out as general IO, it probably makes sense to program JTAGEN.

However, for variants that break out those pins for general IO use, probably best to leave unprogrammed, as it does restrict function on those pins for general IO if JTAGEN is programmed.

So that would be my recommendation: If pins dedicated to JTAG header, program; otherwise leave unprogrammed.

Actually, playing with JTAG using Skinny Bob+AVR Dragon+Atmel Studio 6.1 has been pretty interesting so far, and not difficult to get together. I can see using the 1284p as a debug platform for AVR sketches could potentially be quite useful, e.g for difficult ISR related bugs.

Anyone else got any experience with JTAG debugging using Atmel Studio?

Title: Re: Updating the mighty-1284p core
Post by: pico on May 27, 2014, 10:36 am
And Jack: the "Skinny Bob" is now available, so could you put a link up under the "supported boards" list?

http://embeddedcoolness.com/shop/rfx-1284p-devdep-board-w-prototyping-area-nrf24l01-headers-kit/
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 27, 2014, 03:41 pm

And Jack: the "Skinny Bob" is now available, so could you put a link up under the "supported boards" list?

http://embeddedcoolness.com/shop/rfx-1284p-devdep-board-w-protyping-area-nrf24l01-headers-kit/


Done. Check it out (https://github.com/JChristensen/mighty-1284p) and let me know what you think.

Also check the spelling of "prototype" on the embedded coolness page.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 27, 2014, 04:09 pm

Also check the spelling of "prototype" on the embedded coolness page.


Belgium!

Thanks for spotting that!. I've corrected the spelling on the page (and the spelling of the link, so if you could adjust that for me on the project page as well, I'd appreciate it.)

Also, maybe say "Arduino shield compatible headers" instead of just "headers"?

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 27, 2014, 07:00 pm

Thanks for spotting that!. I've corrected the spelling on the page (and the spelling of the link, so if you could adjust that for me on the project page as well, I'd appreciate it.)

Also, maybe say "Arduino shield compatible headers" instead of just "headers"?


You got it!
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 09:52 am

You got it!


Thanks for that. :-)

Now, what about this proposal of including in the repository the "fixed" 1284p versions of the three or so standard libs that oric_dan has identified?

I think that would make it a one-stop point of call  for anyone wanting to get their new 1284p board up and running (putting the "hub" into "github", as it were.), And the promise

Quote

What is it?

Everything you need to run Arduino on an ATmega1284P microcontroller.


would arguably be more completely delivered upon.

My feeling is that providing a download for the patched standard distribution libs should be a minimum, and perhaps we could discuss whether hosting volunteered third-party libs that have been patched for 1284p core use would be appropriate to host as well.

Thoughts?

Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 28, 2014, 03:13 pm
I'm ready to have my website point to something besides maniacbug's 1284 core files if things are settled down. Have been busy designing lately and not doing hardware testing, so I don't know the compatibility status with Bobuino pinouts.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 03:24 pm

My feeling is that providing a download for the patched standard distribution libs should be a minimum, and perhaps we could discuss whether hosting volunteered third-party libs that have been patched for 1284p core use would be appropriate to host as well.

Thoughts?


How best to structure this?  Is each patched library a repo?  One repo for all patched libs?  Is there a way to combine them with the existing core repo?

Trying to think ahead to how installation would work.  Seems like a user would have to go through at least two installation steps, one for the core (landing it in the sketchbook/hardware folder) and one for the libraries (going into sketchbook/libraries).  This may be fine.

Would a structure like this work?

Code: [Select]
hardware
    mighty-1284p
        ...
libraries
    Ethernet
        ...
    Servo
        ...
    SD
        ...
    Etc.
        ...

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 03:29 pm

I'm ready to have my website point to something besides maniacbug's 1284 core files if things are settled down. Have been busy designing lately and not doing hardware testing, so I don't know the compatibility status with Bobuino pinouts.


I'd say things have settled, there have been no issues raised with my repo.  Of course I don't know whether that may be because it's not being used :D

I believe the Bobuino pinouts are fine, but please check it yourself.  If changes are needed either let me know or submit a pull request.  For that matter, if some of you guys want to be collaborators on the repo, I'd welcome that.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 28, 2014, 03:35 pm
Looks like everything is here then?
https://github.com/JChristensen/mighty-1284p
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 04:05 pm

Trying to think ahead to how installation would work.  Seems like a user would have to go through at least two installation steps, one for the core (landing it in the sketchbook/hardware folder) and one for the libraries (going into sketchbook/libraries).  This may be fine.


I think keeping separate the core, official libs, and unofficial libs (if it decided that hosting those is also a good idea) would be most manageable.

That would mean the downloading of 1-3 zip files, but I don't think that would be too onerous.

Mainly, keeping everything in sync and in one place would be the main thing here, by my thinking anyway.


Would a structure like this work?

Code: [Select]
hardware
   mighty-1284p
       ...
libraries
   Ethernet
       ...
   Servo
       ...
   SD
       ...
   Etc.
       ...




That looks fine, or maybe

Code: [Select]

libraries
   Official
       Ethernet
           ...
       Servo
           ...
       SD
           ...
       Etc.
           ...
   Unofficial
        Patched3rdPartyLib
          ...
        Etc.
           ...


if hosting the 3rd party libs as well.

In that case, a zip file for core, for official libs, and unofficial libs would probably be workable.

Alternatively, each lib could also have its own zip, so the downloader can pick and choose? Is that extra works to maintain?

I'd be willing to help with the maintenance if you'd like.


Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 04:15 pm

Looks like everything is here then?
https://github.com/JChristensen/mighty-1284p


Yes.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 04:18 pm

I believe the Bobuino pinouts are fine, but please check it yourself.  


I believe the Bobuino pin description and macros are working well now. I've been testing them fairly extensively on my "Skinny Bob" derivative board, and so far have found no further issue past those originally identified and fixed.

BTW, the more I play with the Bobuino pinout, the more I am convinced it really is the best of those designed for compatibility with Uno shield layouts. I'm now glad I chose this rather than the "Goldilocks", for example. So thank you to CR! (the original "Bob" ;-)
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 04:25 pm

That would mean the downloading of 1-2 zip files, but I don't think that would be too onerous.


Agree, that would be fine.  Even three.

Quote

Mainly, keeping everything in sync and in once place would be the main thing here, by my thinking anyway.


That's where I got fuzzy.  If "one place" means "GitHub" (but several repos), then I can see that, but if "one place" means "one repo" that seems like it might be difficult to manage, although I am certainly not a Git/GitHub expert.

In the former case, we'd want to have links between the repos, probably in the README files.

Quote

I'd be willing to help with the maintenance if you'd like.


Thanks, I'll add you to my mighty-1284p repo.  Others are welcome as well.  Spreading the workload around is of course worthwhile but also want to avoid what happened to maniacbug's repo.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 04:29 pm

That's where I got fuzzy.  If "one place" means "GitHub" (but several repos), then I can see that, but if "one place" means "one repo" that seems like it might be difficult to manage, although I am certainly not a Git/GitHub expert.

In the former case, we'd want to have links between the repos, probably in the README files.


Can one repo not sustain several separate zip files? Or is downloading a repo an all or nothing thing?

Sorry, not a git expert (actually still kinda wedded to svn, I know, I'm such a dinosaur.) But this will help to fix that, I hope!

Quote

Thanks, I'll add you to my mighty-1284p repo.  Others are welcome as well.  Spreading the workload around is of course worthwhile but also want to avoid what happened to maniacbug's repo.


What happened there?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 28, 2014, 04:37 pm
Thanks pico. Layout-wise, having the analog definition swapped end for end really helps for nice short wiring, gives a good chance to keep those signals clean. Too bad Aref ended up where it did versus being next to A0 on the original Arduino design. Having to go all the way across the board with that doesn't make much sense. That original pinout design would have really benefitted from some outside review. Having the common signals be the same from chip to chip helps keep coding simpler in my mind from the user perspective.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 04:57 pm

Can one repo not sustain several separate zip files? Or is downloading a repo an all or nothing thing?

Sorry, not a git expert (actually still kinda wedded to svn, I know, I'm such a dinosaur.) But this will help to fix that, I hope!


Yeah, that's where I'm fuzzy too.  I think a repo is always treated as a unit.

Quote

What happened there?


The repo just languished, evidently only one person had the permissions to work on it, and he has dropped out of the picture.  If I get hit by the proverbial Mack truck, and if the repo is worth saving, then others can continue to work on it, transfer ownership or whatever.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 05:32 pm

Yeah, that's where I'm fuzzy too.  I think a repo is always treated as a unit.


Having a quick read, it looks like if you use the git utility to download a repo, it's all or nothing. But, if you just want to download a single file directly using, say, wget or http "save as", it appears you can you can do this on githib.

So if the additional zip files were placed and maintained in the repo, that should be doable. The whole repo (including the additional zip files) could still be downloaded as one big zip file, from what I'm reading.

I'd vote to keep things in one repo, if possible, even if it meant a bit of manual rebuilding of the zip files to keep things maintained. Keeping things a bit more tightly coupled helps to keep things consistent and in sync. I like the idea of a one-stop resource.

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 06:46 pm


Yeah, that's where I'm fuzzy too.  I think a repo is always treated as a unit.


Having a quick read, it looks like if you use the git utility to download a repo, it's all or nothing. But, if you just want to download a single file directly using, say, wget or http "save as", it appears you can you can do this on githib.

git really wants to keep the repository as an atomic unit.
(although there is some recent changes that kind of let you get portions of a tree)
But for the most part you can't just grab portions of the repo tree and sync to that portion
the way you can with SVN.
It is one of the capabilities of SVN that I  miss.
However, git has much better collaborative/distributed development capabilities.

I'd vote to keep things in one repo, if possible, even if it meant a bit of manual rebuilding of the zip files to keep things maintained. Keeping things a bit more tightly coupled helps to keep things consistent and in sync. I like the idea of a one-stop resource.


As far as one repo vs multiple, consider this carefully in your decision making process.

This is what I do for Arduino development and it works quite well.
I check/clone out the repo directly into my user sketchbook libraries, or hardware directories.
This allows active development using the repo and it is shared among all the
different vesions of the IDE.

For example, I have 26 different version of the IDE
(18 Arduino , 8 MPIDE)
By using this development structure I can quickly test across
many different IDE versions to make sure things are still buildable.
It also doesn't matter what the SCM tool is.
I have libraries that are in SVN, hg, and git.
When using file-manager extensions  like Tortoise or RabbitVCS
on Windows, or Linux it is very convenient since they all tend to work/look
similar.


For most libraries and 3rd party cores like Jacks 1284p core this works.
However, there are some projects that have their own/different directory
structure that makes this impossible.
even a top level subdirectory at the top of the repo tree can break this when using
git as you can't extract just part of the tree.
i.e. you can't checkout/clone them directly into the your sketchbook area and
have it work with the IDE.
Working with those projects is a real pain because it means you have to maintain
2 directory trees.
- one that goes into the Arduino libraries/core area for building sketches
- a separate repo/clone development tree for repo syncing.

It is so much easier when the repo is directly in the Arduino sketchbook area
as then you can make changes, see them, and test them directly on many different IDE
versions.
You can also sync back to the master repo.


Be careful when setting up the tree in the repo.
My preference is to always ensure that that repo can be directly checked out/cloned
directly into the Arduino sketchbook tree.
However, this may create certain limitations like the inability combine
multiple "things" into a single repository but it makes active development so much easier.


My openGLCD is a bit of a hybrid.
While it has a tool that builds a zip release image,
the git tree can be directly cloned into the users sketchbook libraries directory
and used.
The release images contain additional things like updating version numbers and documentation
but the cloned tree can be used for active development.

This allows me to do active development, but then create a fuller/richer zip image(s) for users
that don't want/need to do development.

--- bill


Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 28, 2014, 06:57 pm
I don't get the whole 'git' thing. Is this some kind of automatic dynamic file downloading or something else? Is there an explanation for software dummies of how the whole process works?

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 07:10 pm

I don't get the whole 'git' thing. Is this some kind of automatic dynamic file downloading or something else? Is there an explanation for software dummies of how the whole process works?



git is a version control system - probably the best at this point in time.
http://git-scm.com/ (http://git-scm.com/)
I view it as an evolution from several before it:

sccs, rcs, cvs,
svn added remote repositories
Then a split between hg or git
as there was some early disagreement over some capabilities/features
when adding better multi user and branch capabilities.

git is nice because you can run local repositories without having to involve server.

--- bill

Title: Re: Updating the mighty-1284p core
Post by: OldMicroGuy on May 28, 2014, 07:13 pm
Whoever maintains the GitHub repository please be diligent in keeping the ZIP file up to date.  At one time I assumed that this was an automatic feature of GitHub but after I downloaded the ZIP from the maniacbug/RF24Network I wasted many hours before I discovered this is not the case.  The ZIP  was full of out-of-date files. 

Roger
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:18 pm

As far as one repo vs multiple, consider this carefully in your decision making process.


Thanks for those thoughts, Bill.

Do you think this would work to satisfy your preference that the git pull can goo straight into production, as well as allowing ad-hoc downloaders to retrieve just the zips to install without the whole git thang?

(The assumed "root" here is the Arduino hardware directory):

Code: [Select]

hardware
   mighty-1284p
       bootloaders
       cores
       variants
       patched-libs
           Official
               mighty-1284p-official-libs.zip
               Ethernet
                   ...
               Servo
                   ...
               SD
                   ...
               Etc.
                   ...
            Unofficial
               mighty-1284p-3rdparty-libs.zip
               Patched3rdPartyLib
                  ...
                Etc.
                   ...


In this way, a "pull" gets a patched-libs directory that will have to be manually copied to the working lib dirs if that is needed, but the core stuff will be in the right place for production.

OTOH, If a user simply wants the zips files, they can link and download them directly.

Not perfect, perhaps, but seems to me like not too bad a compromise.

@lefty: GIt is a distributed source version control system, to empower Internet wide collaborative bug creation.

But it can also be used as means for distributing the results of said collaborative bug creation to users that just need the end results.

If you want to collaborate, you need to use the whole Git client panoply.

OTOH, if you just want access to the download the files, you can just use normal download methods.

Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 28, 2014, 07:19 pm


I don't get the whole 'git' thing. Is this some kind of automatic dynamic file downloading or something else? Is there an explanation for software dummies of how the whole process works?



git is a version control system - probably the best at this point in time.
http://git-scm.com/ (http://git-scm.com/)
I view it as an evolution from several before it:

sccs, rcs, cvs,
svn added remote repositories
Then a split between hg or git
as there was some early disagreement over some capabilities/features
when adding better multi user and branch capabilities.

git is nice because you can run local repositories without having to involve server.

--- bill




That doesn't help me understand how it works in relationship to my computer?
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on May 28, 2014, 07:21 pm
Quote
OTOH, if you just want access to the download the files, you can just use normal download methods.


Thanks, that means it doesn't do or perform anything at my end of the process. I just down load zip file as I do from any other site and manually unzip it into my libraries or hardware folder in my sketch directory?

HEY, 17K posts made!

Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:26 pm

Whoever maintains the GitHub repository please be diligent in keeping the ZIP file up to date.  At one time I assumed that this was an automatic feature of GitHub but after I downloaded the ZIP from the maniacbug/RF24Network I wasted many hours before I discovered this is not the case.  The ZIP  was full of out-of-date files. 

Roger



Yes, overall GitHub is great, but definitely has it's blind spots.

I wonder if the Atlassian "bitbucket" Git server does this more intelligently?

In any case, yes of course, a well maintained repository must have the zip files up to date!

Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:29 pm

Quote
OTOH, if you just want access to the download the files, you can just use normal download methods.


Thanks, that means it doesn't do or perform anything at my end of the process. I just down load zip file as I do from any other site and manually unzip it into my libraries or hardware folder in my sketch directory?


Yes, that's right.

You only get all the necessary source control funny stuff coming down when you "pull" the repo with the Git client software installed on your computer.

A "normal" download of a zip file and you get a straight zip with just the files you would expect in it.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 07:31 pm

Quote
OTOH, if you just want access to the download the files, you can just use normal download methods.


Thanks, that means it doesn't do or perform anything at my end of the process. I just down load zip file as I do from any other site and manually unzip it into my libraries or hardware folder in my sketch directory?



SCM tools do all kinds of things on the local end.
SCM tools have been around for decades and git is just one of the latest tools that works
well for multi-user remote collaboration.
http://en.wikipedia.org/wiki/Software_configuration_management (http://en.wikipedia.org/wiki/Software_configuration_management)

Using an SCM tool is how s/w developers track and manage their s/w development.
There is no way to really do this without using one, particularly for a large
project or one that involves multiple developers.

Simple end users of the s/w, don't really have a need for scm tools.

--- bill

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 07:33 pm
Just to clarify, when clicking the "Download ZIP" button on GitHub, this is not simply downloading a previously uploaded ZIP file.  It's creating the ZIP file on the fly from the current branch.  So it should never be out of date WRT the repo but of course the repo can be out of date with the rest of the world which is the problem with the maniacbug mighty-1284p repo.

OTOH, it is certainly possible to manage ZIP files with Git and upload them to GitHub, but therein lies the danger, especially if they are built via some external process.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:36 pm

HEY, 17K posts made!


I would respectfully suggest you take some time off, go outside and smell the fresh air.  :P
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 07:49 pm


Yeah, that's where I'm fuzzy too.  I think a repo is always treated as a unit.


Having a quick read, it looks like if you use the git utility to download a repo, it's all or nothing. But, if you just want to download a single file directly using, say, wget or http "save as", it appears you can you can do this on githib.

So if the additional zip files were placed and maintained in the repo, that should be doable. The whole repo (including the additional zip files) could still be downloaded as one big zip file, from what I'm reading.

I'd vote to keep things in one repo, if possible, even if it meant a bit of manual rebuilding of the zip files to keep things maintained. Keeping things a bit more tightly coupled helps to keep things consistent and in sync. I like the idea of a one-stop resource.


Right but I think we're looking for something in between "the whole repo" and "one file at a time". The latter would be tedious for libraries. Would require separate downloads of a .cpp file, a .h file, keywords.txt, often a readme file and an examples sub-folder. And that's for the simplest libraries.

I've done several projects that are both hardware (using Eagle CAD) and firmware (either sketches or libraries) and I thought it'd be great to have one repo, but I gave it up. Like Bill pointed out, I develop my libraries directly in sketchbook\libraries for ease of testing. But my Eagle stuff is elsewhere in an unrelated directory. Working at a higher folder level is no good, because there's always a ton of other unrelated stuff by the time you get to the common parent folder.

As one example, my MCP7941x RTC project has separate repos for the library and for the hardware design and there are links in the README files to point to the other repo.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:51 pm

Just to clarify, when clicking the "Download ZIP" button on GitHub, this is not simply downloading a previously uploaded ZIP file.  It's creating the ZIP file on the fly from the current branch.


That's good to know -- one less thing to worry about.

Although the two additional zip files I propose for the patched libs would have to be maintained manually if this structure was adopted. Although I can't see the patched lib files changing very much once they are up there, so shouldn't be an overly onerous undertaking.

If my suggestion is adopted, I will take responsibility for seeing that those manual zips are kept up to date if everyone is happy with that.



Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 07:53 pm

Right but I think we're looking for something in between "the whole repo" and "one file at a time". The latter would be tedious for libraries.


Not if the "one file" is a zip file.

Have a closer look at my proposed directory structure in post #293.
Title: Re: Updating the mighty-1284p core
Post by: OldMicroGuy on May 28, 2014, 08:06 pm


Just to clarify, when clicking the "Download ZIP" button on GitHub, this is not simply downloading a previously uploaded ZIP file.  It's creating the ZIP file on the fly from the current branch.


That's good to know -- one less thing to worry about.

Although the two additional zip files I propose for the patched libs would have to be maintained manually if this structure was adopted. Although I can't see the patched lib files changing very much once they are up there, so shouldn't be an overly onerous undertaking.

If my suggestion is adopted, I will take responsibility for seeing that those manual zips are kept up to date if everyone is happy with that.




Despite what Jack said that was not my experience.  The zip that I downloaded had   .cpp   .h   and  keywords   that were older than the files in the current branch.

Roger
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 08:12 pm

Despite what Jack said that was not my experience.  The zip that I downloaded had   .cpp   .h   and  keywords   that were older than the files in the current branch.


Perhaps the "zip-on-the-fly" feature has been added since then?

The other possibility is that somehow the branch management had got screwed up for that repo. My understanding talking to folks more experience than I in the ways of GitHub is that this can be non-trivial and confusing.

In any case, everything will tested carefully to fully understand the workings with this repo.

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 08:14 pm


As far as one repo vs multiple, consider this carefully in your decision making process.


Thanks for those thoughts, Bill.

Do you think this would work to satisfy your preference that the git pull can goo straight into production, as well as allowing ad-hoc downloaders to retrieve just the zips to install without the whole git thang?

I didn't quite understand it.
Are you suggesting not only a zip image of the libraries but the extracted versions  as well?
I'm never a fan of including the same information more than once.
The zip image of the libraries might be ok since it would be an "atomic" copy of working libraries.
However, while it allows everything to be all bundled together and will allow the core to work,
it won't allow active development on any of the library code.
For example, suppose you want to test a new feature of the Ethernet library.
You can't just go in and make a branch or change and start testing.
You have to copy it over to the user sketchbook area then make changes
(which are now no longer under scm control).
Then when it is working, copy it back.
This makes things very difficult to manage, particularly if trying to work on multiple feature branches





Just to clarify, when clicking the "Download ZIP" button on GitHub, this is not simply downloading a previously uploaded ZIP file.  It's creating the ZIP file on the fly from the current branch.  So it should never be out of date WRT the repo but of course it can be out of date with the rest of the world which is the problem with the maniacbug mighty-1284p repo.

OTOH, it is certainly possible to manage ZIP files with Git and upload them to GitHub, but therein lies the danger, especially if they are built via some external process.

I view creating separately managed zip files as the better process for Arduino,
where users often tend be pretty far down on the technical skill set and often are using Windows
which doesn't have many of the needed tools to do fancier things.

The problem with using master branch zip images built by sites like github, bitbucket, googlecode,
is that it is often not usable by the IDE library installer or the user ends up with a funky
directory name for his library.

It is much better to create controlled releases consisting of zip images
that are easily installed by the user.
Not only does this make things easier for the user since they can use the IDE to
install libraries but it also ensures that they are getting a controlled release which presumably has had some
sort of testing done on it vs just getting the head of the development, which depending
on how careful the developers are, might not even work.



The key to all this is to pick a  strategy and get the tools & scripts in place to do it.
Many developers just want to jump right in and start writing code rather than
spend a little bit of up front time to get the build methodology and tools in place.
I like to have a strategy that encompasses three main goals:
- let the developers have an easy way to develop using a scm tool like git/svn/hg etc...
- let the end users have an easy way to install and use released s/w that doesn't require using an scm
- automate as much as possible

These are sometimes at odds with each other.
I really struggled with this when setting up my openGLCD project.
I ended up using  git, and the tree can be cloned directly into the
user's libraries directory for active development.
However, I have build scripts that build the release zip images
that can be installed by end users using the IDE.

Now that the tools are in place, I can create a set of zip image
release files with a single click at any time, directly from my
openGLCD repo working tree.
The build scripts go in and patch things like version numbers, and create
all the documentation. The files in the development tree are unreleased
and so version numbers are dummy development release numbers.
In the plans are to update the build scripts to push the released zip images
up to a server along with an automatically generated change long from the git history
where the users have access to it.
A 1 button release process.


In the case of the 1284p core and libraries, it is a more complex environment.
But I think the same sort of thing could be done.


--- bill

Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 08:22 pm


Do you think this would work to satisfy your preference that the git pull can goo straight into production, as well as allowing ad-hoc downloaders to retrieve just the zips to install without the whole git thang?

I didn't quite understand it.
Are you suggesting not only a zip image of the libraries but the extracted versions  as well?


Yes, exactly.


I'm never a fan of including the same information more than once.
The zip image of the libraries might be ok since it would be an "atomic" copy of working libraries.
However, while it allows everything to be all bundled together and will allow the core to work,
it won't allow active development on any of the library code.
For example, suppose you want to test a new feature of the Ethernet library.
You can't just go in and make a branch or change and start testing.
You have to copy it over to the user sketchbook area then make changes
(which are now no longer under scm control).
Then when it is working, copy it back.
This makes things very difficult to manage, particularly if trying to work on multiple feature branches


Yep, you've got it. Not perfect, but still workable I think. Particularly since the "pull" and "push" to the patched libs (well, the official ones at least) should be fairly rare to non-existent once they are up there, I'd think.

In any case, you could still make your library changes directly under version control, in the repo directories, and just copy over for testing in the Arduino directories. That's what I'd do, anyway. No "copying back" required that way.

You still get to "pull" and "push" all the core stuff etc. without copying and moving if you want. Which is why I was suggesting it a compromise that might satisfy your concerns.

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 08:40 pm



Do you think this would work to satisfy your preference that the git pull can goo straight into production, as well as allowing ad-hoc downloaders to retrieve just the zips to install without the whole git thang?

I didn't quite understand it.
Are you suggesting not only a zip image of the libraries but the extracted versions  as well?


Yes, exactly.

But why have both?
It requires work to maintain both and allows things to potentially get out sync.
I'd suggest pick one or the other.
If the intent is to simply include an atomic set of libs that are source controlled elsewhere, use the zip.
If the intent is to source control the libs here, then don't include the zip.
The real down side is that you can't do active library development in the local repo tree.
That makes it much more of a pain to do development and track changes.
It makes doing feature branches really tough.
Although, I guess if you have a modern OS you could create a symlink for any library
in the user sketchbook libraries directory
that is being actively developed to point to the repo for that library.
That would be pretty easy and allow active development
since the library could show up in both places.
I could live with that - but then why also have the .zip file of all the libraries as well?


One thing to keep in mind with a monster tree structure like this is release management.
A new full release must be done anytime there is a change to any component.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on May 28, 2014, 08:59 pm

But why have both?
It requires work to maintain both and allows things to potentially get out sync.


Yes, I know. That's why I said I'd take responsibility for the extra work it if it was adopted.


I'd suggest pick one or the other.
If the intent is to simply include an atomic set of libs that are source controlled elsewhere, use the zip.
If the intent is to source control the libs here, then don't include the zip.
The real down side is that you can't do active library development in the local repo tree.
That makes it much more of a pain to do development and track changes.
It makes doing feature branches really tough.
Although, I guess if you have a modern OS you could create a symlink for any library
in the user sketchbook libraries directory
that is being actively developed to point to the repo for that library.
That would be pretty easy and allow active development
since the library could show up in both places.
I could live with that - but then why also have the .zip file of all the libraries as well?


So the end-users can conveniently download just a patched lib zip file without downloading the whole repo zip file.

I'm proposing the source files are kept in repo source form as well so they can be pulled and pushed (i.e., source control managed) like any other source files that are part of the repo.


One thing to keep in mind with a monster tree structure like this is release management.
A new full release must be done anytime there is a change to any component.


Yes, I appreciate that. In practice, I don't think it's going to be a unreasonably onerous job for this particular repo. It mostly just making sure someone is on the ball and paying attention, which is why I said I'd do that.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 28, 2014, 09:44 pm
Absent a nice, clean way to manage multiple libraries/cores in one repo, I very much favor one repo per library and managing them per the regular Git/GitHub process. If the changes are simple, then it makes it all that much more straightforward. Having the public record of the commits and the changes made is invaluable. It sounds like we're talking about a handful of libraries. Downloading a ZIP from each repo is simple enough and is a commonly understood way of operating.

Best in that case then to just document things well in the README files, with plenty of cross-references. Also maybe use GitHub's Wikis to create a repository of 1284P knowledge, resources, links, etc. Maybe the mighty-1284p repo is the place for this.

Regarding third party libraries that do not support the 1284P, a discussion should first be had with the owner regarding adding 1284P support. If the library already exists in some VCS (GitHub or other), then offer to collaborate if the author is amenable. Start a new repo for a 3rd party library only if one does not already exist and/or the author is unwilling to support the changes.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 28, 2014, 11:12 pm
I did a test using symbolic links.
It works great on linux.
You can checkout/clone the repo anywhere you want then simply create
symbolic links in your sketchbook libraries directory to the library directory over in the local repo.
Not sure why I never tried this in the past,
but it is a good way to directly checkout/clone  libraries into local repositories
whose repo directory structure is incompatible with the IDEs local library directory structure.


Absent a nice, clean way to manage multiple libraries/cores in one repo,

1.5x might have and answer for this.
It looks like in the latest 1.5x
each core can have its own libraries directory and libraries.
If so, that starts to look really interesting, in that a full blob of core and matching core patched libraries
could be created and then installed all at once.
It would also mean that it all could be source controlled in a single repo if that was desirable.


Regarding third party libraries that do not support the 1284P, a discussion should first be had with the owner regarding adding 1284P support. If the library already exists in some VCS (GitHub or other), then offer to collaborate if the author is amenable. Start a new repo for a 3rd party library only if one does not already exist and/or the author is unwilling to support the changes.

I share you thoughts on the 3rd party libraries
Title: Re: Updating the mighty-1284p core
Post by: pico on May 29, 2014, 04:09 am

Absent a nice, clean way to manage multiple libraries/cores in one repo, I very much favor one repo per library and managing them per the regular Git/GitHub process. If the changes are simple, then it makes it all that much more straightforward. Having the public record of the commits and the changes made is invaluable. It sounds like we're talking about a handful of libraries. Downloading a ZIP from each repo is simple enough and is a commonly understood way of operating.


Just to be clear, the public records of the commits and changes for the lib sources would still be there -- the source files would be under source control as part of the repo, just like any of the other "core" files.

The only unorthodox things in the proposal are

a) the directory tree for the location of the library files would be "wrong" when the repo was pulled or downloaded as a zip, appearing all under a directory "hardware/mighty-1284p/patched-libs"

b) two separate, additional zip files would be (manually) maintained that corresponded to the contents of the subdirectories

"hardware/mighty-1284p/patched-libs/official"

and

"hardware/mighty-1284p/patched-libs/unofficial"

purely for the convenience of downloaders who were not interested in development, just access to the patched files for their use with the mighty-1284p cores files.


Best in that case then to just document things well in the README files, with plenty of cross-references. Also maybe use GitHub's Wikis to create a repository of 1284P knowledge, resources, links, etc. Maybe the mighty-1284p repo is the place for this.


I was also thinking along these lines, e.g., for a write-up of using the 1284p as a JTAG debugging platform for AVR programs that might be being developed for a smaller target AVR platform, (say) a 328p.

I've only just started exploring this, but so far, it's looking quite promising. Trickiest thing is getting an Arduino sketch "in harness" to work as a straight C++ program in Atmel Studio. A way of simplifying that process could potentially be very useful, I think.


Regarding third party libraries that do not support the 1284P, a discussion should first be had with the owner regarding adding 1284P support. If the library already exists in some VCS (GitHub or other), then offer to collaborate if the author is amenable. Start a new repo for a 3rd party library only if one does not already exist and/or the author is unwilling to support the changes.


I think this is all solid commonsense, and certainly one would hope that a 3rd party lib patched for 1284p should reside in its natural development "home", wherever that might be, ideally as just the latest version of that lib.  But for the exceptional cases where this just isn't possible for whatever reason, the repo could provide a home of last resort. oric_dan seems to be up on several 3d party libs that he has identified previously and worked on -- perhaps he'd like to comment on the specifics of the status of those 3rd party libs he's patched for 1284p.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 29, 2014, 01:48 pm


Despite what Jack said that was not my experience.  The zip that I downloaded had   .cpp   .h   and  keywords   that were older than the files in the current branch.


Perhaps the "zip-on-the-fly" feature has been added since then?


Not to my knowledge. Roger, is that repo still suffering from that problem? I might have a look...
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 29, 2014, 06:48 pm



Despite what Jack said that was not my experience.  The zip that I downloaded had   .cpp   .h   and  keywords   that were older than the files in the current branch.


Perhaps the "zip-on-the-fly" feature has been added since then?


Not to my knowledge. Roger, is that repo still suffering from that problem? I might have a look...

Doesn't the zip file come from the tip of the master branch?
perhaps, the latest/desired code is not on the master branch but on some other branch?

Title: Re: Updating the mighty-1284p core
Post by: pico on May 29, 2014, 06:52 pm

Doesn't the zip file come from the tip of the master branch?
perhaps, the latest/desired code is not on the master branch but on some other branch?


My thought as well. Apparently, unless you really know what you're doing, this is easy to screw up with Git.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 29, 2014, 07:14 pm


Doesn't the zip file come from the tip of the master branch?
perhaps, the latest/desired code is not on the master branch but on some other branch?


My thought as well. Apparently, unless you really know what you're doing, this is easy to screw up with Git.


Hmmm. Why do you say that? It's one of the few things that I haven't managed to screw up!  :D  Not even sure how it would get screwed up. And I certainly wouldn't say that I "really" know what I'm doing!
Title: Re: Updating the mighty-1284p core
Post by: pico on May 29, 2014, 07:22 pm


My thought as well. Apparently, unless you really know what you're doing, this is easy to screw up with Git.


Hmmm. Why do you say that? It's one of the few things that I haven't managed to screw up!  :D  Not even sure how it would get screwed up. And I certainly wouldn't say that I "really" know what I'm doing!


Just repeating what I was told by someone who is more experienced in Git and GitHub than me. Branch management (e.g., trying to maintain multiple stable and development braches) can get counter-intuitive fairly quickly, with sometimes unexpected results. Or so I've been informed. So just hearsay and gossip.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 29, 2014, 07:47 pm



My thought as well. Apparently, unless you really know what you're doing, this is easy to screw up with Git.


Hmmm. Why do you say that? It's one of the few things that I haven't managed to screw up!  :D  Not even sure how it would get screwed up. And I certainly wouldn't say that I "really" know what I'm doing!


Just repeating what I was told by someone who is more experienced in Git and GitHub than me. Branch management (e.g., trying to maintain multiple stable and development braches) can get counter-intuitive fairly quickly, with sometimes unexpected results. Or so I've been informed. So just hearsay and gossip.


Oh oh oh. Branch management in general, yes I suppose that would be true. Best to keep things simple and prune old branches that no longer have a purpose.

As far as this thing where Download ZIP doesn't work properly, I'd really like to see an example of that.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 29, 2014, 07:52 pm


Doesn't the zip file come from the tip of the master branch?
perhaps, the latest/desired code is not on the master branch but on some other branch?


My thought as well. Apparently, unless you really know what you're doing, this is easy to screw up with Git.


I don't think it is any sort of "screw up". git handles branches pretty well.
Much better than several of the other scm tools out there.
The default zip image created from a git repo is usually for the master branch.
When feature branch development is being done, the master branch often
may not yet have some of the new features/updates in it as they are still off in branches.
It has to work this way, in order to scale.
In a large project there can be many feature branches all being worked on concurrently
by different people.
That is why it is best to either clone the full git tree or for those end-users that don't want to do
s/w development, provide them pre-built release images.
grabbing a master branch zip image of a git repo can be unpredictable.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 29, 2014, 09:02 pm

I don't think it is any sort of "screw up". git handles branches pretty well.


Agree. A better way to put it would be that it's easy for a person to become confused if they let things get too complex. As a beginner, I spend a fair amount of time thinking through what I'm doing, making sure which branch I'm on, ensuring I'm taking the proper actions. It may be a new way of working that needs to be adjusted to, but it's very much worth it even if used only on your local computer. I've screwed up a few times, but I can't say that I remember Git screwing up.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 30, 2014, 05:27 am

I've screwed up a few times, but I can't say that I remember Git screwing up.


To be clear in what I was saying (well, repeating), it's not that Git or GitHub isn't doing what it's supposed to do, it's just that driving it can be less than intuitive when things get more complex with multiple branch management, and it's easy for the novice to screw up. So I wasn't suggesting there were problems in Git or GitHub per se. So yes, I think if you keep things simple, there is probably no reason not to expect it all work predictably and reliably.

I've had a further thought reading some of Bill's comment re stable and development versions, and making things easy for the casual downloader as opposed the contributor/developer.

If we provided a prebuilt "stable" zip, which is independent of the auto-build master-branch zip, then the downloader would have the choice of downloading the current state of the master branch (which would be the "development" branch), or the latest "stable" version (which may have been more thoroughly vetted for any glitches that are still to be ironed out.)

I was thinking this approach could kill two birds with one stone: Keep a "stable" and a "development" version available without (potentially) confusing branch management issues, and also make things maximally convenient for the casual downloader.

The cost is the extra manual maintenance of preparing the "stable" zips for download, but that doesn't appear to be a big deal. In fact, lighter work than having to maintain a separate "synced" version of the current state of the master every time that changes.

Thoughts?
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on May 30, 2014, 05:32 am
Kind of like the Beta or Nightly builds vs the Released version:
http://arduino.cc/en/Main/Software

I see the IDE's been updated for Win 8.1.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 30, 2014, 01:59 pm


I've screwed up a few times, but I can't say that I remember Git screwing up.


To be clear in what I was saying (well, repeating), it's not that Git or GitHub isn't doing what it's supposed to do, it's just that driving it can be less than intuitive when things get more complex with multiple branch management, and it's easy for the novice to screw up. So I wasn't suggesting there were problems in Git or GitHub per se. So yes, I think if you keep things simple, there is probably no reason not to expect it all work predictably and reliably.


Yes, exactly, I think we are saying the same thing.

Quote

I've had a further thought reading some of Bill's comment re stable and development versions, and making things easy for the casual downloader as opposed the contributor/developer.

If we provided a prebuilt "stable" zip, which is independent of the auto-build master-branch zip, then the downloader would have the choice of downloading the current state of the master branch (which would be the "development" branch), or the latest "stable" version (which may have been more thoroughly vetted for any glitches that are still to be ironed out.)

I was thinking this approach could kill two birds with one stone: Keep a "stable" and a "development" version available without (potentially) confusing branch management issues, and also make things maximally convenient for the casual downloader.

The cost is the extra manual maintenance of preparing the "stable" zips for download, but that doesn't appear to be a big deal. In fact, lighter work than having to maintain a separate "synced" version of the current state of the master every time that changes.

Thoughts?


GitHub will automatically create ZIPs for downloading from any branch.
Note that in my mighty-1284p repo, there are two branches, "master" and "v1.0.5".
(The "master" branch is identical to maniacbug's repo.)
Use the branch pulldown to switch between them.
The Download ZIP button will zip up whichever branch is selected.
The branch name will be appended to the ZIP filename.
Master is usually the default, but in my repo, I set "v1.0.5" to be the default.
Title: Re: Updating the mighty-1284p core
Post by: pekasus on May 30, 2014, 03:15 pm
I suggest removing the 2 'Original Mighty 1284p' boards from the boards.txt file, because Maniacbug wrote 2 years ago that they were only for reference then and did not recommend using them. I doubt that anyone will be using them in this release, so it could reduce potential for error of choosing the wrong the board, and at minimum reduces clutter.

Also, should comments like this just be made at GitHub now?
Title: Re: Updating the mighty-1284p core
Post by: pico on May 30, 2014, 04:09 pm

GitHub will automatically create ZIPs for downloading from any branch.
Note that in my mighty-1284p repo, there are two branches, "master" and "v1.0.5".
(The "master" branch is identical to maniacbug's repo.)
Use the branch pulldown to switch between them.
The Download ZIP button will zip up whichever branch is selected.
The branch name will be appended to the ZIP filename.


I think even this could potentially cause confusion for the casual non-Git literate downloader.


Master is usually the default, but in my repo, I set "v1.0.5" to be the default.


What do you think about a "development" and a "stable" branch of 1.0.5?

I'm kind of inclined to think keeping the master branch pointing to the Maniacbug repo has more downside than upside.
Title: Re: Updating the mighty-1284p core
Post by: pico on May 30, 2014, 04:12 pm

I suggest removing the 2 'Original Mighty 1284p' boards from the boards.txt file, because Maniacbug wrote 2 years ago that they were only for reference then and did not recommend using them. I doubt that anyone will be using them in this release, so it could reduce potential for error of choosing the wrong the board, and at minimum reduces clutter.


I support this simplification as well. The original Maniacbug repo is still going to be there for the historical reference if need be.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 30, 2014, 07:23 pm


GitHub will automatically create ZIPs for downloading from any branch.
Note that in my mighty-1284p repo, there are two branches, "master" and "v1.0.5".
(The "master" branch is identical to maniacbug's repo.)
Use the branch pulldown to switch between them.
The Download ZIP button will zip up whichever branch is selected.
The branch name will be appended to the ZIP filename.


I think even this could potentially cause confusion for the casual non-Git literate downloader.


I think that the casual non-Git literate downloader is just going to hit the Download ZIP button and get the latest version of the master branch or whichever is the default branch.

Quote


Master is usually the default, but in my repo, I set "v1.0.5" to be the default.

What do you think about a "development" and a "stable" branch of 1.0.5?


This is what I do in most of my repos, I have "dev" and "master". And sometimes others as well.

Quote

I'm kind of inclined to think keeping the master branch pointing to the Maniacbug repo has more downside than upside.


If someone understands enough to switch branches, then they ought to have some small clue what a branch is. Note though, my repo is a fork (copy) of maniacbug's, so my master branch doesn't point to his, it's just the master branch in my repo. I'd prefer to keep it that way for historical reasons, at least for a while.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 30, 2014, 07:25 pm


I suggest removing the 2 'Original Mighty 1284p' boards from the boards.txt file, because Maniacbug wrote 2 years ago that they were only for reference then and did not recommend using them. I doubt that anyone will be using them in this release, so it could reduce potential for error of choosing the wrong the board, and at minimum reduces clutter.


I support this simplification as well. The original Maniacbug repo is still going to be there for the historical reference if need be.


Agree. If no dissent is heard, I'll go ahead with it. I'll open an issue so I don't forget.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on May 30, 2014, 10:58 pm



I suggest removing the 2 'Original Mighty 1284p' boards from the boards.txt file, because Maniacbug wrote 2 years ago that they were only for reference then and did not recommend using them. I doubt that anyone will be using them in this release, so it could reduce potential for error of choosing the wrong the board, and at minimum reduces clutter.


I support this simplification as well. The original Maniacbug repo is still going to be there for the historical reference if need be.


Agree. If no dissent is heard, I'll go ahead with it. I'll open an issue so I don't forget.

Fewer boards is better.
Fewer variants would be even better.
Are people using the "standard" variant?
I'm assuming some are.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on May 31, 2014, 12:23 am

Are people using the "standard" variant?
I'm assuming some are.


My board (https://github.com/JChristensen/mini1284), of which I am aware of four instances  :D  uses the "standard" variant.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 03, 2014, 06:56 pm
Has anyone come across this?
One of my customer's drives up from NYC last night, 5 hr drive for him, because he suddenly can't upload into a Bobuino with standard mighty1284 bootloader.
I open the box, make sure no wires were loose or anything.
Connect up to my older WinVista Sony Viao, and upload the sketch first time with no problem from 1.0.5.
Pulls out his small netbook kind of thing with Win 7, 1.0.5.r2, and it appears to get hung up after compile section and before the upload section.  I'm thinking perhaps the reset pulse went out, then the bootloader timed out before the code download started.
Compiled again, couldn't make it fail. Tried numerous times, making code changes to force some compiling, couldn't make it not work.
Any thoughts?
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 03, 2014, 08:58 pm
It may or may not be a timing issue between autoreset and start of download.
The avrdude "arduino" protocol sits on top of "stk500" the only difference is that "arduino"
tries to toggle both dtr and rts and then falls into stk500. So there isn't any sort of known potential
delay since it is all done in the same executable.

I'd be leaning towards a screwup in the dtr and rts signal line handling.
i.e. the dtr signal is not able to be controlled the way the application wants to control it.


Another possibility is that perhaps the avrdude usleep() function doesn't always work correctly under windows.
The "arduino" protocol does a toggle of dtr and rts for 50,000us
On windows, eventually it calls QueryPerformanceCounter()
If that returns non zero,
a high performance counter is available and is used to measure the delay.
If not, the delay is converted to use Sleep() which uses ms instead.
Perhaps Win7 supports this and there is an issue in the code giving a delay that is sometimes too short.
There are some comments in the avrdude code that there are issues with the high performance
counter and it sometimes does not work correctly.

--- bill

other thoughts


Over the past 30 years I've seen many issues with dtr and rts signals in various
operating systems.
My guess is that the s/w guys writing the drivers tend not to read the rs232 specs and
therefore they screw it up.
Microsoft has been notorious for screwing this up. From early windows,
to XP, to 98, to NT, to Vista, I've see many issues and they have changed their
implementations from time to time.
Some versions have advanced properties that allow some control over its behavior.
And in some cases, you must set them to get proper/reliable behavior of
the DTR signal.

Even linux isn't immune to some of these issues. I've seen cases
where the driver swapped rts and dtr signals, so the application ends up
controlling the wrong pin. In others, they won't let you control dtr.

I've seen many issues with controlling dtr, since it is normally controlled before
the application starts and again after it exits, which is why I use and recommend
using rts rather than dtr for a control line from an application.


The only way to know for sure is to start hooking up an analyzer and take
a look to see what is really going on.
But in testing it may require rebooting the Windows OS as it may
be one time condition that clears it self up after the first program uses
the serial port and then exits, particularly when using DTR since DTR
is usually controlled by the operating system outside of the application.

BTW, the reason that DTR was originally picked over RTS for autoreset
was that the OS does control it outside of the application.
This allowed using avrdude with the stock stk500 protocol and the OS
would set it when the application opened the serial port.
This required using a cap to turn the level signal into a pulse but it
required no s/w changes.
It was a h/w solution to a s/w problem.
Now that avrdude has the "arduino" protocol that toggles the RTS signal,
I'd recommend using RTS over DTR.

--- bill

Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 03, 2014, 09:10 pm
Well, I suppose I could design the board to connect the Reset cap to either signal, or put a cap from both to reset:
http://www.mouser.com/ds/2/272/usb_uart_manual_v100-32094.pdf

I had not seen the long delay before tho.
Scrolling back when it failed (like forcing a fail by not powering the chip) the other odd thing was that I didn't see the "compiled xxx of 128xxx bytes" message like 1.0.5 puts out. And when it passed, I couldn't scroll back to the start of the download, seems there was too much output during the download to save it all.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 03, 2014, 09:30 pm
Bummer on the trace.

Another possibility is that if the OS driver has h/w handshaking enabled, it might have gotten hung up waiting
for DSR or DCD to be set.
That would also keep any data from being sent to the 1284.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 03, 2014, 09:49 pm
I don't think FT232 driver uses those.  Has never come up in a forum discussion that I recall.
I'll see if I can find out which rev of driver is on the PCs they are using.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 03, 2014, 10:34 pm

I don't think FT232 driver uses those.  Has never come up in a forum discussion that I recall.
I'll see if I can find out which rev of driver is on the PCs they are using.

It's been a long time but  I've used them for h/w flow control before on both Vista and linux.
I believe by default, when not connected, the FTDI chip has them pulled appropriately
so as not to halt traffic.
But that depends on how the FTDI chip is initialized, which depends on how
the driver is configured.



--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 04, 2014, 01:47 am

Connect up to my older WinVista Sony Viao, and upload the sketch first time with no problem from 1.0.5.
Pulls out his small netbook kind of thing with Win 7, 1.0.5.r2, and it appears to get hung up after compile section and before the upload section.


Assuming you can verify on the 'scope or analyzer the the pulse from DTR is indeed *not* being propagated to the board reset line via the FTDI (or, at least the FTDI chip isn't responding to the USB signalling as expected), then an interesting test would be to connect the FTDI via a powered USB hub, and see if the problem still occurs.

I'm thinking marginal USB electrical specs coming from the netbook USB port. Bolstering the signalling via a power USB hub might help to support or discount this idea.
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 04, 2014, 03:03 am
I can't test the DTR signal from their computers now tho, customer went back to NY after we showed it was downloading ok.
Title: Re: Updating the mighty-1284p core
Post by: john1993 on Jun 04, 2014, 05:48 am
3 words: emmm.. essss... dosss... lol

ill also say these issues were one of the reasons i switched over to cp2102. far fewer problems with drivers, os compatibility, and handshake signals. not to mention better availability and lower cost.
Title: Re: Updating the mighty-1284p core
Post by: retrolefty on Jun 04, 2014, 06:41 am

3 words: emmm.. essss... dosss... lol

ill also say these issues were one of the reasons i switched over to cp2102. far fewer problems with drivers, os compatibility, and handshake signals. not to mention better availability and lower cost.


I too have a couple of CP2102 converters and have had no problems with them. But I also have about a dozen FTDI devices (between on-boards and standalone) and never have had a problem with them either.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 04, 2014, 06:43 am


I'm thinking marginal USB electrical specs coming from the netbook USB port. Bolstering the signalling via a power USB hub might help to support or discount this idea.


In the absence of other data, that wouldn't be very high on my list if at all
until I verified the h/w flow control modes being used by the OS driver.

I would be focused on an incorrect/incompatible flow control mode in the driver.
Take a look a the code in avrdude down in the "arduino" protocol that does the auto reset:
Code: [Select]
 /* Clear DTR and RTS to unload the RESET capacitor
  * (for example in Arduino) */
 serial_set_dtr_rts(&pgm->fd, 0);
 usleep(50*1000);
 /* Set DTR and RTS back to high */
 serial_set_dtr_rts(&pgm->fd, 1);
 usleep(50*1000);


This code sequence is not guaranteed to work. In fact, if it were up to me, I'd change/fix it.
The problem is that the Arduino autoreset uses a capacitor because it was a hack on top of DTR
when DTR was controlled by the OS prior to the "arduino" protocol.
When DTR was only controlled by the OS, it went from HIGH to LOW when the port was opened
and stayed low until the port was closed.
The cap was used to change the low level to a pulse on the falling edge of DTR.
Because of this, it requires a high to low transition on the signal.
This code does not ensure that DTR starts out in a HIGH state. It assumes it.
Depending on how the driver uses DTR this may or may not be the case when this code
runs.
This code should set the signal to HIGH then LOW than back to HIGH to ensure
that the signal makes the proper transition to trigger AVR reset when the signal goes
through a cap.

There are many scenarios of timing and OS driver configuration that can cause autoreset
to fail when DTR is used along with the capacitor to trigger AVR reset.
The timing is the period of time from when the port is opened until the "arduino" protocol
starts which does the above line controls.
The configuration is how the driver handles DTR with respect to opening/closing  the port
and if it lets the application control DTR.
In some cases the application is not allowed to control DTR, but in that case the OS transitioning
DTR from HIGH to LOW when the port is opened should work with the capacitor autoreset circuit.

I've played with many version of Windows and they are not consistent with how they treat DTR.
However, several of them have advanced properties that allow you to alter the DTR behavior.
That is where I'd start looking.

The only way to know what is happening will be hook up the logic analyzer and catch it when
it doesn't work.

--- bill

   
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 05, 2014, 02:46 am
Thanks Bill.  That is too bad, DTR operation was that one the things that you think of as being a solid operation you can count on.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 05, 2014, 03:28 am

Thanks Bill.  That is too bad, DTR operation was that one the things that you think of as being a solid operation you can count on.

It has never really been solid/consistent on any Microsoft OS platform.
Each version had its own idiosyncrasies.
Roll the clock way back in the old unix days pre dos and pre Windows,
DTR was controlled by the h/w or the OS and the application could never manipulate it.
The ability to allow the application to control DTR has made a real mess of things
as it drags in all sorts of configuration and behavior complications.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 12:05 am
I don't know if this is something you guys want to worry about, since it is present in the Arduino core [I imagine since day-1]. However, there is no real bounds-checking on the argument value passed to analogRead(uint8_t pin). For this reason, I inserted the following line in the code:
Code: [Select]
if( (pin < 0) || (pin > 7) ) return( -1 );
Exactly where you insert it depends upon how many of those conditional-compile statements you have and where they're located, etc.

Also, depends on whether or not you wish to interpret argument 'pin' as a channel number, an analog pin number (0..7), or an analog assignment (A0..A7). There is clearly a non-trivial inconsistency between what the Arduino Reference says and how the analogRead() routine is actually written.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 12:17 am

I don't know if this is something you guys want to worry about, since it is present in the Arduino core [I imagine since day-1]. However, there is no real bounds-checking on the argument value passed to analogRead(uint8_t pin). For this reason, I inserted the following line in the code:


Doesn't that break the current functionality that allows a pin number rather than an ADC channel number? Not saying the current functionality is "right", I think I'd much rather see the argument to analogRead() to be strictly defined as an ADC channel number, but as things stand, inserting that line of code would cause

Code: [Select]
analogRead(A0);

to not work, correct?
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 12:46 am
That's why I said
Quote
Exactly where you insert it depends upon how many of those conditional-compile statements you have and where they're located, etc.

I guess, depending on the actual routine, it may better have read such as follows; difficult to deal with every single option in a short msg,
Code: [Select]
if( (channel < 0) || (channel > 7) ) return( -1 );

However, I think you need to look at what the following lines give you, given the various 1284 pins_arduino.h variants, if argument pin is out-of-bounds ... I believe you can end up assigning -1 to pin or channel in the following:
Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

// allow for channel or pin numbers
#if defined(digitalPinToAnalogPin)
if (digitalPinToAnalogPin(pin) != -1 )
pin = digitalPinToAnalogPin(pin);
#else
if (pin >= A0) pin -= A0;
#endif

#if defined(analogPinToChannel)
uint8_t channel = analogPinToChannel(pin);
#else
uint8_t channel = pin;
#endif

If not, then ... never mind :-).

EDIT: also, the inconsistency I mentioned is that the Reference page says nothing about using analogRead(A0), although the code is written to handle it, so there is obfuscation on several levels.
http://arduino.cc/en/Reference/AnalogRead

[as an aside: you should take pity on my poornoobeeness, as somehow my boards.txt file got corrupted so that it was actually using wiring_analog.c from the IDE, rather than from the 1284 library, to compile the code, and I was getting totally ripped for the past couple of days. Think unmitigated disaster, duh].  
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 01:36 am
BTW, I realize this is never gonna gain any traction, but to me, the way that ardunio code is written just drives me up the d*mn wall. You end up with 10 or 12 or 16 conditional-compiles in many files, layer upon layer. Eg:
Code: [Select]
int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
pin = analogPinToChannel(pin);
#elif defined(analogPinToChannel) && (defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__))
pin = analogPinToChannel(pin);
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif

#if defined(__AVR_ATmega32U4__)
pin = analogPinToChannel(pin);
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
// the MUX5 bit of ADCSRB selects whether we're reading from channels
// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
 
// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits).  this also sets ADLAR (left-adjust result)
// to 0 (the default).
#if defined(ADMUX)
ADMUX = (analog_reference << 6) | (pin & 0x07);
#endif

// without a delay, we seem to read from the wrong channel
//delay(1);

#if defined(ADCSRA) && defined(ADCL)
// start the conversion
sbi(ADCSRA, ADSC);

// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read.  reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low  = ADCL;
high = ADCH;
#else
// we dont have an ADC, return 0
low  = 0;
high = 0;
#endif

// combine the two bytes
return (high << 8) | low;
}


So whenever, I "fix" anything, I go in and shortcut the entire mess to make it actually readable, such as follows, and then I know what I'm actually looking at:
Code: [Select]

#if defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) ||     
      defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)

int analogRead(uint8_t pin)
{
uint8_t low, high;

      pin = analogPinToChannel(pin);

        // set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits).  this also sets ADLAR (left-adjust result)  to 0 (the default).
ADMUX = (analog_reference << 6) | (pin & 0x07);

// without a delay, we seem to read from the wrong channel
//delay(1);

// start the conversion
sbi(ADCSRA, ADSC);
// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read.  reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low  = ADCL;
high = ADCH;
// combine the two bytes
return (high << 8) | low;
}

#else

int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(analogPinToChannel) && (defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__))
pin = analogPinToChannel(pin);
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif

#if defined(__AVR_ATmega32U4__)
pin = analogPinToChannel(pin);
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
// the MUX5 bit of ADCSRB selects whether we're reading from channels
// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
 
// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits).  this also sets ADLAR (left-adjust result)
// to 0 (the default).
#if defined(ADMUX)
ADMUX = (analog_reference << 6) | (pin & 0x07);
#endif

// without a delay, we seem to read from the wrong channel
//delay(1);

#if defined(ADCSRA) && defined(ADCL)
// start the conversion
sbi(ADCSRA, ADSC);

// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read.  reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low  = ADCL;
high = ADCH;
#else
// we dont have an ADC, return 0
low  = 0;
high = 0;
#endif

// combine the two bytes
return (high << 8) | low;
}
#endif


I think you'd find that, most of the time, you would need only 2 or 3 MUCH simplified #elif's and modified analogRead()/etc routines to make it 98% cleaner and more readable. But, that's just me.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 01:39 am
Where is your code snippet from, it does not match v1.0.5.


EDIT: also, the inconsistency I mentioned is that the Reference page says nothing about using analogRead(A0), although the code is written to handle it, so there is obfuscation on several levels.


Obfuscation ... agree.

Quote

[as an aside: you should take pity on my poornoobeeness, as somehow my boards.txt file got corrupted so that it was actually using wiring_analog.c from the IDE, rather than from the 1284 library, to compile the code, and I was getting totally ripped for the past couple of days. Think unmitigated disaster, duh].  


Ugh, I hate it when that happens. Hope you have some hair left :D
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 01:44 am
Doesn't really matter, as whichever one you're working with is the one to re-consider whether to "fix" it, or not.

And don't remember. The snippet could have been from v1.05 [maybe not, as you say], the old maniacbug1284, your 1284, or "my" 1284 library. LOL.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 02:06 am

Doesn't really matter, as whichever one you're working with is the one to re-consider whether to "fix" it, or not.

And don't remember. The snippet could have been from v1.05 [maybe not, as you say], the old maniacbug1284, your 1284, or "my" 1284 library. LOL.


Well yes it does matter. If something is going to be fixed, we need to be clear on exactly what that something is, and exactly what the problem is.

maniacbug's core is based on v1.0. Can't fix it (no access), so don't intend to.
My core is based on v1.0.5.

You may be aware, but we instituted a new requirement (https://github.com/JChristensen/mighty-1284p/commit/b9caa6c406abe6ce31afcaa4193c68f4b7336c07) in the ("my") refreshed core. The pins_arduino.h file for each variant in the mighty-1284p core is required to implement an analogPinToChannel() macro. Thus, pin mappings and issues related to same are squarely in the hands of the board's designer.

However, even if there is some flaw in an analogPinToChannel() macro, the resultant pin number is masked (https://github.com/JChristensen/mighty-1284p/blob/v1.0.5/cores/mighty/wiring_analog.c#L69) so that it will always have a valid value. Note that this does not guarantee the user will get the result they expected (if they code some inappropriate value) , but it does prevents serious errors like memory leaks, out-of-bounds subscripts, and other totally unexpected behavior.

Bottom line for me, I'm not sure this is a problem, or if it is, how big of a problem it is.

Finally, the other thing we accomplished with the refreshed core is that save for a single line of code, wiring_analog.c is identical to that from Arduino v1.0.5. So unless the perceived problem here is with that very line of code (which I doubt, since that line of code is not even in your snippet, hence my question on its origin), I would recommend that if you decide to pursue a fix, that an issue be created at the Arduino repo instead.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 02:41 am
It was only a suggestion of what "I" would do [and actually did do]. Obviously, the Ardunio-IDE people never fixed it in the core, so apparently they don't think it's a problem.

Quote
However, even if there is some flaw in an analogPinToChannel() macro, the resultant pin number is masked so that it will always have a valid value. Note that this does not guarantee the user will get the result they expected (if they code some inappropriate value) , but it does prevents serious errors like memory leaks, out-of-bounds subscripts, and other totally unexpected behavior.


Not sure I agree. You might still check the circumstances in analogRead() for which analogPinToChannel() will pass back -1, and then what the rest of the routine does with it. After all, it's easy enough to preclude getting the wrong results by using the simple check I mentioned initially, via placing it at the "correct" point in the analogRead() routine,
Code: [Select]
if( (pin < 0) || (pin > 7) ) return( -1 );
OR
if( (channel < 0) || (channel > 7) ) return( -1 );
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 03:13 am

Not sure I agree. You might still check the circumstances in analogRead() for which analogPinToChannel() will pass back -1, and then what the rest of the routine does with it. After all, it's easy enough to preclude getting the wrong results by using the simple check I mentioned initially, via placing it at the "correct" point in the analogRead() routine,
Code: [Select]
if( (pin < 0) || (pin > 7) ) return( -1 );
OR
if( (channel < 0) || (channel > 7) ) return( -1 );



Right. Of course that redefines analogRead() just a bit, which currently says "Returns int (0 to 1023)". Not saying that'd be a bad thing either though.

On such small machines with such modest resources, the tradeoff between resources and lots of error detection is not always insignificant IMHO. In my own code I will often make the decision in favor of resources (although the 1284P is spoiling me). Worst case scenario now with analogRead() is that the wrong channel gets read. Personally I'm plenty good with that.

One of my goals with the mighty-1284p core is to keep it as close to the Arduino distribution as practical, lumps and all. Several of us were surprised at how well we were able to accomplish that. Because of that, in addition to the reasons stated previously, I really do think this discussion belongs with the Arduino repo (https://github.com/arduino/Arduino/issues?state=open). The purpose of the mighty-1284p core is not to fix errors in the Arduino distribution, unless doing so is required to meet the goals of the mighty-1284p core. Absent that, I actually prefer for mighty-1284p to contain the same errors as v1.0.5.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 03:48 am
I appreciate your considerations with trying to maintain max compatibility with the IDE. I'm sure those guys are dealing with endless issues.

Quote
Worst case scenario now with analogRead() is that the wrong channel gets read. Personally I'm plenty good with that.

However, to me, this is different, and an unmitigated disaster that can cause me to lose a couple of days pulling my hair out.

Duh, deja vu from the past couple of days, :-). I finally figured out the wiring_analog.c file in the IDE was being used, instead of the 1284 library version, as a complete shot in the dark after trying 50 other things. One little non-obvious internal problem can take forever to fix.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Jun 14, 2014, 04:00 am
Quote
I finally figured out...


I am at the point when working with any non-Arduino board type, that I now pull the verbose compiler log and analyze that output.  Amazing how quickly that leads to corrective action.

Ray
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 04:20 am

Quote
I finally figured out...

I am at the point when working with any non-Arduino board type, that I now pull the verbose compiler log and analyze that output.  Amazing how quickly that leads to corrective action.

Ray


I use that all the time. Now that I know what was happening, I can see how to tell the difference between which core is being used in the compiler window. Normally, use of the wrong one would likely be a low probability issue, plus you have to really begin to understand how the IDE internals work. BTW, one thing I did discover is, if you edit boards.txt, you have to exit and restart the IDE for the changes to take effect. Rule #102.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Jun 14, 2014, 04:25 am
:D
Quote
BTW, one thing I did discover is, if you edit boards.txt, you have to exit and restart the IDE for the changes to take effect. Rule #102.


Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 14, 2014, 05:02 am

The purpose of the mighty-1284p core is not to fix errors in the Arduino distribution, unless doing so is required to meet the goals of the mighty-1284p core.


Succinctly put. I think this is a wise and manageable policy.

The problem with starting to try to fix things in the general Arduino code is that there would simply be no end to it. I don't think it would be too controversial to say that the logical conclusion would be that the whole thing needs chucking out and be redone properly from the beginning. Which is a little outside the scope of the original project!

Now, how about we agree on on some way of getting those patched libraries into the repo? I don't think it's too much of a stretch to suggest that *is* within the project scope. (And I don't really care how, anything half-way reasonable is OK with me, let's just agree to do something.)
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 14, 2014, 05:08 am

BTW, one thing I did discover is, if you edit boards.txt, you have to exit and restart the IDE for the changes to take effect. Rule #102.


This is simply a corollary of the general rule that the Arduino IDE assumes *nothing* on your hard disk has changed since it started, apart from (perhaps) the code in your sketch. Think configuration files in Windows. Change something, even one line, requires a reboot. Duh. Great minds think alike. And the not so great ones too, apparently.

Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 03:08 pm

Now, how about we agree on on some way of getting those patched libraries into the repo? I don't think it's too much of a stretch to suggest that *is* within the project scope. (And I don't really care how, anything half-way reasonable is OK with me, let's just agree to do something.)


I can agree, except I don't understand how to do it in GitHub given that the source code folders are in different places (and one is not a strict subset another). Could be I'm missing something, but I have tried and have not come up with a good way to do this.

If someone has done this, I would greatly appreciate an example and/or a few pointers.

To be clear, the problem is not how to structure things in GitHub, the problem is on the local computer where development is done. The main question is: Where does the .git directory go?  If it's a single repo on GitHub, then so it has to be on the local development machine, and AFAIK that means a single .git directory. Two .git directories means two repos, etc.

Multiple repos can work and will be easy to manage. It's not "one-stop shopping" though, the various repos will need to be "loosely coupled" via ReadMe files, GitHub Wiki pages, etc. Actually an advantage of this approach is that as a user, it's not an all-or-nothing proposition. Just my 2µF.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Jun 14, 2014, 04:53 pm
Quote
Now, how about we agree on on some way of getting those patched libraries into the repo? I don't think it's too much of a stretch to suggest that *is* within the project scope. (And I don't really care how, anything half-way reasonable is OK with me, let's just agree to do something.)


I have a very uneasy feeling about this extrapolation; building a separate library repository specifically for the 1284.  The only way I can imagine this would work without issue is if the original library owner performs any required modifications and submits said library her/himself.  So, restated, my problem is the ownership of the end-product in a one-off copy.

To accelerate library conversion while at the same time ensuring proper documentation, my suggestion would be to have all libraries requiring modification to be renamed, perhaps to include "_1284' as a suffix?  Additionally, the changes should be code managed so that anyone can easily identify the deltas made in hopes of convincing the original author to assume direct ownership.  This means that a policy needs to be adopted on who/how will contact the original library owner/author.

Ray
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 14, 2014, 06:57 pm

I have a very uneasy feeling about this extrapolation; building a separate library repository specifically for the 1284.  The only way I can imagine this would work without issue is if the original library owner performs any required modifications and submits said library her/himself.  So, restated, my problem is the ownership of the end-product in a one-off copy.


I'm not understanding the issue. Seems to me to be pretty much the same as modifying the core for the 1284.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 14, 2014, 07:00 pm
I don't remember all 360 posts here, but in regards libraries in the IDE distribution, there are some clear errors in regards the 1284, and which I identified a year ago and posted on my website page, as mentioned previously in this thread. The IDE guys should be encouraged to fix those errors.

OTOH, since Arduino does not specifically sell any 1284 boards, this means the ownership of the modified maniac1284 libraries will reside  elsewhere than with the main IDE distribution. In this case, this means Jack. Then, if for some reason Jack disappears like m-b has, then someone else will have to fork his github, and carry on.
Title: Re: Updating the mighty-1284p core
Post by: mrburnette on Jun 15, 2014, 12:05 am

<....>
OTOH, since Arduino does not specifically sell any 1284 boards, this means the ownership of the modified maniac1284 libraries will reside  elsewhere than with the main IDE distribution. In this case, this means Jack. Then, if for some reason Jack disappears like m-b has, then someone else will have to fork his github, and carry on.


I understand that maniacbug has been missing since 4Q13 (based on github posts and other web postings) and that forking his work represents a true benefit to us 1284'ers.  I am OK with this.

Forking core libs that Arduino has been notified about issues, I am OK with.  My remarks were (and I fault for not having been specific) to 3rd party libs; those libraries that are not installed via the core installation/ZIP.  Perhaps there are none?

Ray
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 15, 2014, 01:46 am

Forking core libs that Arduino has been notified about issues, I am OK with.  My remarks were (and I fault for not having been specific) to 3rd party libs; those libraries that are not installed via the core installation/ZIP.  Perhaps there are none?


Seems like there would certainly be some.  Previous related discussion:


Regarding third party libraries that do not support the 1284P, a discussion should first be had with the owner regarding adding 1284P support. If the library already exists in some VCS (GitHub or other), then offer to collaborate if the author is amenable. Start a new repo for a 3rd party library only if one does not already exist and/or the author is unwilling to support the changes.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 15, 2014, 05:04 am


<....>
OTOH, since Arduino does not specifically sell any 1284 boards, this means the ownership of the modified maniac1284 libraries will reside  elsewhere than with the main IDE distribution. In this case, this means Jack. Then, if for some reason Jack disappears like m-b has, then someone else will have to fork his github, and carry on.


I understand that maniacbug has been missing since 4Q13 (based on github posts and other web postings) and that forking his work represents a true benefit to us 1284'ers.  I am OK with this.

Forking core libs that Arduino has been notified about issues, I am OK with.  My remarks were (and I fault for not having been specific) to 3rd party libs; those libraries that are not installed via the core installation/ZIP.  Perhaps there are none?

Ray


1. seems to me a good idea that someone has taken up the cause since maniacbug disappeared. [however, the actual truth is I've been using the maniac1284 library for the past year and a half, and it works fine without my having had to make any core changes at all. The only change I found needed was to the Bobuino pins_arduino.h file].

2. there should be NO need to fork the Arduino IDE core libraries. They only started adding support for the 1284/644 a year or so ago, and simply failed to track down all the places that needed fixing - as indicated on my webpage. Certainly, the IDE people will want to fix these themselves for the next IDE release.

3. in regards 3rd party libs, I wouldn't spend my time forking them and making necessary fixes, and including in a distribution. If the owners of the libs weren't interested in adding correct 1284 support, I might add a note in regards what might be needed to fix them - as I did on my webpage - so anyone wishing to use them with 1284 could easily do so. The last thing I wanted to do was fork, fix, and maintain a dozen or more 3rd party libraries on my own. That's a thankless job, and a complete and total waste of time. Especially as many of them are being continually updated by the owners.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 15, 2014, 09:51 am
OK, here's a simplified version of what I proposed as the repo structure back in post #293:

(The assumed "root" here is the Arduino hardware directory):

Code: [Select]

hardware
   mighty-1284p
       bootloaders
       cores
       variants
       patched-libs
           Official
               Ethernet
                   ...
               Servo
                   ...
               SD
                   ...
               Etc.
                   ...
            Unofficial
               Patched3rdPartyLib
                  ...
               Etc.
                  ...


In this way, a download (or fork) gets the whole enchilada, including a patched-libs directory with subdirs that will have to be manually copied to the working lib dirs if that is needed.

The "casual downloader" (i.e., not developing or improving repo code, just using it) will have three choices with regard to the patched official libs:

1) Overwrite 1.0.5. distribution lib files in the arduino/libraries directory
2) Copy to user's sketches/libraries dir to override the official distro files, while still keeping those intact
3) Do nothing with them, only interested in core files for whatever reason

Of these options, I would expect option 2) to be the recommended one in most situations.

OTOH, the developer who wished to push changes back to the repo will have to suffer the (minor) inconvenience of making sure any new versions of the library files are back in the repo directory locations before putting in the pull request. bperrybap (Bill) has already described a way of using file links (post #311) that obviates the need to even copy the files back and forth from the "live" directories to the "repo" directories.

In practice, for the official patched lib files, this is largely theoretical rather than practical anyway, as it is unlikely the patched 1.0.5 libs, once in the repo, are going to be changed at all.

The "unofficial" patched libs we might consider slightly differently. In the first instance, I propose we create the "unoffical" directory as an empty directory, essentially as a place holder. As Jack has made clear, and I thoroughly agree, this should be a home of "last resort" for any 3rd party library, for the rare and unusual case where a library a) has become an orphan, and there is no maintainer to implement the changes to support 1284p, or b) the maintainer(s) have decided against supporting the 1284p changes for whatever reason, and so this is the only way to make the patched version available.

In short, much preferable that any third-party library changes for 1284p find their way into the main supported distribution, and only in rare circumstances will there be a need to host a 3rd-party patched lib in the repo. Before accepting any such submitted libs for inclusion in the repo the expectation would be that a serious attempt has been made to contact the nominal lib owners to get them to incorporate and support the changes into their distribution.

So, what would need to be done? Not much: Just create the repo directories, and deposit patched versions of the 3 or 4 known official libs that require patches under the "official" directories. "unofficial" directory left empty at this stage, and any proposals to add to it will be considered on a case by case basis.

Any strong objections to this course of action?
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 15, 2014, 06:34 pm
Hi pico, I really consider myself an observer and suggester here, rather than an "active" contributor. So, other than my considerations made in the post prior to yours, let me just say that some of the 3rd party libraries are a complete disaster, and trying to "fix" them yourself is an enormous PITA. Specifically, I spent days trying to get jeelib for the RFM12 radios to work with my 1284 boards, but finally gave up. There are just too many problems in there. It works OK for 328 chips, but anything else presents a mess to re-engineer. Likewise, when the low power labs guy forked jeelib, he only ever used it with the 328, and never tried any other chips, so he didn't fix the original problems either. Just a warning. But I guess you're free to do what you want.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 15, 2014, 06:59 pm


Any strong objections to this course of action?


while pretty much anything can be made to work,
I think it might be worth while to look at what it takes to move to 1.5x before making any substantial changes.

Also, 1.5x already has a structure in place for supporting core specific libraries.
The 1.5x library structure still seems to be a bit in flux, and from
from my looking at it, it probably still needs a few tweaks to really work well for 3rd party cores,
but lately the Arduino team has been pretty good about accepting input and even pull requests.
My concern is that if energy is placed on making a new 1284 structure that includes libraries
work on 1.x that it delays/defers moving the core to the 1.5x IDE.

I'm also concerned that spending time on an ambitious new restructuring like this may
cause us to miss out on the opportunity to correct some issues in the 1.5x code base, which I assume
is the long term goal.
My biggest concern is with 3rd party libraries being mixed into the same repo as support for the 3rd
party libraries seems like a project in itself and a project with no bounds.

In other words, would it be more effective to simply update the 1.x core for the 1284 now,
(which seems to be pretty much done), and then put it to bed for a while, to focus on 1.5x?

This new focus could include trying to get the 1284 actually supported into the mainline official code.
My guess is that if we started to focus on 1.5x instead, that we could work with the Arduino
team to either get many if not all the changes we want/need to finally get the 1284 into the mainline release
and/or to fix some of the remaining issues for 3rd party cores.
Either way,  it could help eliminate much of the support pain that is currently happening
for the 1.x release.

I think at this point, we still have the opportunity to make some updates/corrections to the 1.5x code base.
A real tragedy would be if the 1.5x code ends up go to full release with some
issues that ends up requiring doing a bunch of work like what is having to be done in the 1.x code base.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 15, 2014, 07:28 pm

Hi pico, I really consider myself an observer and suggester here, rather than an "active" contributor. So, other than my considerations made in the post prior to yours, let me just say that some of the 3rd party libraries are a complete disaster, and trying to "fix" them yourself is an enormous PITA. Specifically, I spent days trying to get jeelib for the RFM12 radios to work with my 1284 boards, but finally gave up. There are just too many problems in there. It works OK for 328 chips, but anything else presents a mess to re-engineer. Likewise, when the low power labs guy forked jeelib, he only ever used it with the 328, and never tried any other chips, so he didn't fix the original problems either. Just a warning. But I guess you're free to do what you want.


I don't know why you seem to think anything proposed here implies solving the (software) world's problems.

If you read carefully you will see there is no commitment to making things work outside the standard 1.0.5 Arduino distribution. Anything else beyond that would have to have an extraordinary situation to be included in the repo. Having said that, I am suggesting provision for a mechanism for being able to accommodate such a situation, on a case by case basis.

Quote

What is it?

Everything you need to run Arduino on an ATmega1284P microcontroller.


That statement implies the standard libs will work. It does not imply every third party lib in existence has been made to work with this  distribution.

So the state of the jeelib libs is neither here nor there in terms of the basic proposal here.

Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 15, 2014, 07:30 pm

I'm also concerned that spending time on an ambitious new restructuring like this


You have got to be kidding me.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 15, 2014, 08:01 pm
Quote

...........
I don't know why you seem to think anything proposed here implies solving the (software) world's problems.

If you read carefully you will see there is no commitment to making things work outside the standard 1.0.5 Arduino distribution. Anything else beyond that would have to have an extraordinary situation to be included in the repo. Having said that, I am suggesting provision for a mechanism for being able to accommodate such a situation, on a case by case basis.
..........


That statement implies the standard libs will work. It does not imply every third party lib in existence has been made to work with this  distribution.

So the state of the jeelib libs is neither here nor there in terms of the basic proposal here.


I was responding to the following lines in your previous post,
Quote
patched-libs
........
             Unofficial
                Patched3rdPartyLib
                   ...
                Etc.
                   ...

and simply warning you about my own experiences. Some of those 3rd party libraries are a real mess.

Been there, done that, know better now.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 15, 2014, 08:16 pm


I'm also concerned that spending time on an ambitious new restructuring like this


You have got to be kidding me.


No. Dead serious.

It isn't the structure itself that takes any time.
In my opinion, the continual maintenance of the 3rd party libraries will be the real distraction.
It is a boundless task that never ends.
Plus this is effort that is very specific to this 1284 core running on 1.x
It is not effort that is going to make things better/easier for users
or reduce or eliminate any of the maintenance moving forward.

I'd much rather spend time trying to make the need for 1284 core "go away" by getting things fixed in 1.5x
And also work with Arduino team to try to add some tweaks into 1.5x to do things like:
- allow 3rd party cores to have libraries in their core that can override IDE supplied common libraries.
- allow multiple libraries to be installed at once from a single zip image
- some way to add/install new board types from a file

These are the kind of things that benefit all Arduino users & developers
and would help eliminate most of the need for the 1284 core re-structuring and tree structure you are proposing.

The multiple library install is something that has come up in the past on the developers forum.
This would allow 3rd parties to distribute library "packs" of multiple libraries that can all be installed at once.
It is useful for many things not just cores.
In the past it has been pushed back in favor of a full blown library manager.
However, I think there is a the possibility of a much simpler interim solution.
The feature of core specific libraries could allow core creators to create a core
with all the updated/modified libraries already in place that gets installed as part of the core install.
I think that most of what is needed for the core specific libraries  is already in the IDE code
and might already "just work".

In other words, what I'm saying is that I'd much rather see efforts put into moving
1284 core support to 1.5x where things can potentially be solved in a better way
than move further down a path of supporting 1284 libraries on the 1.x platform.


--- bill

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 15, 2014, 08:41 pm

....
In my opinion, the continual maintenance of the 3rd party libraries will be the real distraction.
It is a boundless task that never ends.
Plus this is effort that is very specific to this 1284 core running on 1.x
It is not effort that is going to make things better/easier for users
or reduce or eliminate any of the maintenance moving forward.

I'd much rather spend time trying to make the need for 1284 core "go away" by getting things fixed in 1.5x
......
These are the kind of things that benefit all Arduino users & developers
and would help eliminate most of the need for the 1284 core re-structuring and tree structure you are proposing.
............
In other words, what I'm saying is that I'd much rather see efforts put into moving
1284 core support to 1.5x where things can potentially be solved in a better way
than move further down a path of supporting 1284 libraries on the 1.x platform.

--- bill


I second this, and as stated 2 or 3 times now, it seems much better to get the IDE core libraries straightened out by the IDE guys, and generally leave the 3rd party libraries alone completely. The following does not exist in the manic1284 library, and is just unnecessary replication:
Quote
patched-libs
            Official
                Ethernet
                    ...
                Servo
                    ...
                SD
                    ...
                Etc.
                    ...
             Unofficial
                Patched3rdPartyLib
                   ...
                Etc.
                   ...
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 16, 2014, 04:10 am



I'm also concerned that spending time on an ambitious new restructuring like this


You have got to be kidding me.


No. Dead serious.

It isn't the structure itself that takes any time.
In my opinion, the continual maintenance of the 3rd party libraries will be the real distraction.
It is a boundless task that never ends.


Okey dokey. I suggest both you and Dan read (and re-read, if necessary) post #369. In particular, the 1st, 2nd, 3rd, and 4th paragraphs I wrote. As you will both see, the anticipated La Brea pits nightmare that you are both wringing your hands about isn't actually part of the proposal.

The patched official libs tide things over until the day the support finds its way into the official distributions -- just like the core files, as I think Jack has already pointed out. Do it once, properly, and it's done. This really isn't invading Iraq.

The third party "unofficial" libs directory may or may not ever even be used. At this stage, I'm unaware of any candidates for it. It does provide the provision for some flexibility if it is deemed that hosting a third party patched lib is in the interests of the project's stated goals at some point, however.

The central issue that is being overlooked here is that the job "Everything you need to run Arduino on an ATmega1284P microcontroller" isn't actually done until the standard libs and examples are working. It makes no difference to me at all whether the standard libs were within the scope of ManiacBug's original project. Elevating the 1284p to a "first class" Arduino citizen rather than the fringe-dweller it has been hitherto is what I am personally interested in seeing achieved here.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 16, 2014, 05:01 am
Ok by me.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 17, 2014, 03:24 pm
Just pushed support for first three official libs: Ethernet, Servo, SD.

I could test SD fairly thoroughly, but if you've got some applications that you could use to test the Servo and Ethernet libs more thoroughly, that would be good.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 17, 2014, 03:34 pm
BTW, going through these files, I noticed that support for the arrays digital_pin_to_pcint[] and __pcmsk[] is defined in the "Bobuino" variant pins_arduino.h, but not in the other variants. 

Why is that?
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 17, 2014, 07:22 pm

Just pushed support for first three official libs: Ethernet, Servo, SD.


Just had a quick look, but would you give us a sentence or two describing the changes to the pins files? Was it mostly style stuff?

I might have added the vanilla libraries then done a commit at that point, made the changes, then another commit. As it is, it's impossible to see the changes, the diff just looks like the files were all new adds (which technically they were). I suppose a person could do a diff outside of the repo using their own vanilla copy of the libraries, but that's kind of jumping through hoops.
Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 17, 2014, 08:54 pm

BTW, going through these files, I noticed that support for the arrays digital_pin_to_pcint[] and __pcmsk[] is defined in the "Bobuino" variant pins_arduino.h, but not in the other variants.  

Why is that?


Do you know offhand where digital_pin_to_pcint[] is ever called in any core or library routines?

EDIT: answer to my own question. In the Bobuino pins_Arduino.h file there is this macro, and which has a much simpler definition in the other variants in the maniac-1284 library. m-b apparently added the extra array due to non-trivial remapping for the Bobuino.
Code: [Select]
#define digitalPinToPCICRbit(p) ifpin(p,digital_pin_to_pcint[p] >> 3,(uint8_t *)0)
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 03:17 am

EDIT: answer to my own question. In the Bobuino pins_Arduino.h file there is this macro, and which has a much simpler definition in the other variants in the maniac-1284 library. m-b apparently added the extra array due to non-trivial remapping for the Bobuino.
Code: [Select]
#define digitalPinToPCICRbit(p) ifpin(p,digital_pin_to_pcint[p] >> 3,(uint8_t *)0)


Ah, OK, mystery solved. Thanks for that.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 03:17 am

Just had a quick look, but would you give us a sentence or two describing the changes to the pins files? Was it mostly style stuff?


It does look mostly stylistic, but actually it was required to make things feasible for the SD lib.


I might have added the vanilla libraries then done a commit at that point, made the changes, then another commit. As it is, it's impossible to see the changes, the diff just looks like the files were all new adds (which technically they were). I suppose a person could do a diff outside of the repo using their own vanilla copy of the libraries, but that's kind of jumping through hoops.


Fair enough. I did put a brief description in a README.txt in the directory for each patched lib, but I will also explain the patches made a bit more fully. I'll start with the simplest (Ethernet) and go through to the least simple (SD).
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 03:29 am
Ethernet.lib just what required what Dan described as "Fix #1: on his site.

In w51000.h:

Original
Code: [Select]

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
 inline static void initSS()    { DDRB  |=  _BV(4); };
 inline static void setSS()     { PORTB &= ~_BV(4); };
 inline static void resetSS()   { PORTB |=  _BV(4); };
#elif defined(__AVR_ATmega32U4__)


Patched
Code: [Select]

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
 inline static void initSS()    { DDRB  |=  _BV(4); };
 inline static void setSS()     { PORTB &= ~_BV(4); };
 inline static void resetSS()   { PORTB |=  _BV(4); };
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) \
 || defined(__AVR_ATmega644__)  || defined(__AVR_ATmega644A__) \
 || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644PA__)
 inline static void initSS()    { DDRB  |=  _BV(4); }
 inline static void setSS()     { PORTB &= ~_BV(4); }
 inline static void resetSS()   { PORTB |=  _BV(4); }
#elif defined(__AVR_ATmega32U4__)


This will only work for those variants where the physical SS pin is mapped to D10, as discussed earlier in this thread.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 03:36 am
Servo was a little bit more interesting. The changes are  in Servo.h.

Original
Code: [Select]

// Say which 16 bit timers can be used and in what order
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
#define _useTimer5
#define _useTimer1
#define _useTimer3
#define _useTimer4
typedef enum { _timer5, _timer1, _timer3, _timer4, _Nbr_16timers } timer16_Sequence_t ;

#elif defined(__AVR_ATmega32U4__)  


Patched
Code: [Select]

// Say which 16 bit timers can be used and in what order
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
#define _useTimer5
#define _useTimer1
#define _useTimer3
#define _useTimer4
typedef enum { _timer5, _timer1, _timer3, _timer4, _Nbr_16timers } timer16_Sequence_t ;

#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__)
#define _useTimer3
#define _useTimer1
typedef enum { _timer3, _timer1, _Nbr_16timers } timer16_Sequence_t ;

#elif defined(__AVR_ATmega644__)  || defined(__AVR_ATmega644A__) \
 || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644PA__)
#define _useTimer1
typedef enum { _timer1, _Nbr_16timers } timer16_Sequence_t ;

#elif defined(__AVR_ATmega32U4__)  


The deal here is that you have to set up the enum that reflects the timers available for the chip. Interestingly, the datasheet reveals that the 1284 and 1284p have two 16bit timers, whereas the 644 only has one, hence the need to distinguish them in the above.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 03:47 am
SD as most involved, because of the way fat16lib (Bill G.) set up arrays for fast digital pin access.

This is what required the recasting of the info in pins_arduino.h.

These are the changes in Sd2PinMap.h:

Original
Code: [Select]

//------------------------------------------------------------------------------
#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644__)
// Sanguino

// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = 17;
uint8_t const SCL_PIN = 18;

// SPI port
uint8_t const SS_PIN = 4;
uint8_t const MOSI_PIN = 5;
uint8_t const MISO_PIN = 6;
uint8_t const SCK_PIN = 7;

static const pin_map_t digitalPinMap[] = {
 {&DDRB, &PINB, &PORTB, 0},  // B0  0
 {&DDRB, &PINB, &PORTB, 1},  // B1  1
 {&DDRB, &PINB, &PORTB, 2},  // B2  2
 {&DDRB, &PINB, &PORTB, 3},  // B3  3
 {&DDRB, &PINB, &PORTB, 4},  // B4  4
 {&DDRB, &PINB, &PORTB, 5},  // B5  5
 {&DDRB, &PINB, &PORTB, 6},  // B6  6
 {&DDRB, &PINB, &PORTB, 7},  // B7  7
 {&DDRD, &PIND, &PORTD, 0},  // D0  8
 {&DDRD, &PIND, &PORTD, 1},  // D1  9
 {&DDRD, &PIND, &PORTD, 2},  // D2 10
 {&DDRD, &PIND, &PORTD, 3},  // D3 11
 {&DDRD, &PIND, &PORTD, 4},  // D4 12
 {&DDRD, &PIND, &PORTD, 5},  // D5 13
 {&DDRD, &PIND, &PORTD, 6},  // D6 14
 {&DDRD, &PIND, &PORTD, 7},  // D7 15
 {&DDRC, &PINC, &PORTC, 0},  // C0 16
 {&DDRC, &PINC, &PORTC, 1},  // C1 17
 {&DDRC, &PINC, &PORTC, 2},  // C2 18
 {&DDRC, &PINC, &PORTC, 3},  // C3 19
 {&DDRC, &PINC, &PORTC, 4},  // C4 20
 {&DDRC, &PINC, &PORTC, 5},  // C5 21
 {&DDRC, &PINC, &PORTC, 6},  // C6 22
 {&DDRC, &PINC, &PORTC, 7},  // C7 23
 {&DDRA, &PINA, &PORTA, 7},  // A7 24
 {&DDRA, &PINA, &PORTA, 6},  // A6 25
 {&DDRA, &PINA, &PORTA, 5},  // A5 26
 {&DDRA, &PINA, &PORTA, 4},  // A4 27
 {&DDRA, &PINA, &PORTA, 3},  // A3 28
 {&DDRA, &PINA, &PORTA, 2},  // A2 29
 {&DDRA, &PINA, &PORTA, 1},  // A1 30
 {&DDRA, &PINA, &PORTA, 0}   // A0 31
};
//------------------------------------------------------------------------------
#elif defined(__AVR_ATmega32U4__)
// Leonardo


Patched
Code: [Select]

#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) \
 || defined(__AVR_ATmega644__)  || defined(__AVR_ATmega644A__) \
 || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644PA__)

#if defined(MIGHTY_1284P_VARIANT)
// from pins_arduino.h in mighty-1284p core

// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = SDA;
uint8_t const SCL_PIN = SCL;

// SPI port
uint8_t const SS_PIN = SS;
uint8_t const MOSI_PIN = MOSI;
uint8_t const MISO_PIN = MISO;
uint8_t const SCK_PIN = SCK;

#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }

static const pin_map_t digitalPinMap[NUM_DIGITAL_PINS] = {
 DPM(0),
 DPM(1),
 DPM(2),
 DPM(3),
 DPM(4),
 DPM(5),
 DPM(6),
 DPM(7),
 DPM(8),
 DPM(9),
 DPM(10),
 DPM(11),
 DPM(12),
 DPM(13),
 DPM(14),
 DPM(15),
 DPM(16),
 DPM(17),
 DPM(18),
 DPM(19),
 DPM(20),
 DPM(21),
 DPM(22),
 DPM(23),
 DPM(24),
 DPM(25),
 DPM(26),
 DPM(27),
 DPM(28),
 DPM(29),
 DPM(30),
 DPM(31)
};

#else
// else, assume Sanguino pin assignments
#warning "SANGUINO PIN ASSIGMENT ASSUMED"

// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = 17;
uint8_t const SCL_PIN = 18;

// SPI port
uint8_t const SS_PIN = 4;
uint8_t const MOSI_PIN = 5;
uint8_t const MISO_PIN = 6;
uint8_t const SCK_PIN = 7;

static const pin_map_t digitalPinMap[] = {
 {&DDRB, &PINB, &PORTB, 0},  // B0  0
 {&DDRB, &PINB, &PORTB, 1},  // B1  1
 {&DDRB, &PINB, &PORTB, 2},  // B2  2
 {&DDRB, &PINB, &PORTB, 3},  // B3  3
 {&DDRB, &PINB, &PORTB, 4},  // B4  4
 {&DDRB, &PINB, &PORTB, 5},  // B5  5
 {&DDRB, &PINB, &PORTB, 6},  // B6  6
 {&DDRB, &PINB, &PORTB, 7},  // B7  7
 {&DDRD, &PIND, &PORTD, 0},  // D0  8
 {&DDRD, &PIND, &PORTD, 1},  // D1  9
 {&DDRD, &PIND, &PORTD, 2},  // D2 10
 {&DDRD, &PIND, &PORTD, 3},  // D3 11
 {&DDRD, &PIND, &PORTD, 4},  // D4 12
 {&DDRD, &PIND, &PORTD, 5},  // D5 13
 {&DDRD, &PIND, &PORTD, 6},  // D6 14
 {&DDRD, &PIND, &PORTD, 7},  // D7 15
 {&DDRC, &PINC, &PORTC, 0},  // C0 16
 {&DDRC, &PINC, &PORTC, 1},  // C1 17
 {&DDRC, &PINC, &PORTC, 2},  // C2 18
 {&DDRC, &PINC, &PORTC, 3},  // C3 19
 {&DDRC, &PINC, &PORTC, 4},  // C4 20
 {&DDRC, &PINC, &PORTC, 5},  // C5 21
 {&DDRC, &PINC, &PORTC, 6},  // C6 22
 {&DDRC, &PINC, &PORTC, 7},  // C7 23
 {&DDRA, &PINA, &PORTA, 7},  // A7 24
 {&DDRA, &PINA, &PORTA, 6},  // A6 25
 {&DDRA, &PINA, &PORTA, 5},  // A5 26
 {&DDRA, &PINA, &PORTA, 4},  // A4 27
 {&DDRA, &PINA, &PORTA, 3},  // A3 28
 {&DDRA, &PINA, &PORTA, 2},  // A2 29
 {&DDRA, &PINA, &PORTA, 1},  // A1 30
 {&DDRA, &PINA, &PORTA, 0}   // A0 31
};
#endif
//------------------------------------------------------------------------------


The recasting of the pin port and port bit mask info in pins_arduino.h enabled the DPM macro to be defined to set up the SD digitalPinMap[] array. The way I did it doesn't incur any additional overhead or potentially break anything since it's really just breaking out some hardcoded literal into macros, and then using those macros rather than the literals to set up the arrays both in pins_arduino.h and Sd2PinMap.h.

I also introduced the MIGHTY_1284P_VARIANT macro into pins_arduino.h to alllow backward compatibility with anyone using the lib with a Sanguino core rather than the  mighty-1284p. There were ad-hoc heuristic ways of deciding if the mighty-1284p core was actually being used, e.g.

Code: [Select]

#if defined(PORT_TO_MODE) && defined(PORT_TO_INPUT) && defined(PORT_TO_OUTPUT) && defined(BIT_D0)


instead of

Code: [Select]

#if defined(MIGHTY_1284P_VARIANT)


but this seemed like a neater and clearer solution.

Since I have chosen to simply define the  MIGHTY_1284P_VARIANT macro as a string with the name of each variant (not really required above, just whether it is defined is tested), the specific variant info is also potentially using a construct like

Code: [Select]

#if (MIGHTY_1284P_VARIANT == "AVR_DEVELOPERS")
...
#elif (MIGHTY_1284P_VARIANT ==  "BOBUINO")
...
#elif (MIGHTY_1284P_VARIANT ==  "STANDARD")
...


if so desired.

I also put a #warning in the Sanguino code to explicitly warn if this is somehow being used by mistake.

Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 18, 2014, 04:53 pm
I just pushed an updated version of the Firmata lib to patched-libs/official.

I did as a two-step process as Jack suggested to make it easier to see the diffs from the original 1.0.5 distribution version.

Also added the digitalPintoAnalogPin macro to pins_arduino.h for both the standard and avr_developers variants. The digitalPintoAnalogPin macro is used in the updated Firmata lib.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 18, 2014, 08:12 pm
Thanks, didn't mean to put you through all that work!
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 20, 2014, 07:18 am
I just pushed an updated version of the SoftwareSerial lib to patched-libs/official, two-step process.

Also updated the Bobuino digitalPinToPC* macros in pins_arduino.h. (The digitalPinToPCMSK(p) macro in particular was a complete disaster...)

Redoing it I got rid of the __pcmsk[] array and replaced with the PORT_NDX_TO_PCMSK macro.


Thanks, didn't mean to put you through all that work!


No probs. Actually writing the code is the relatively fun part! ;-)

And so far, porting the libs has been a good exercise for shaking out a few of the latent bugs (such as the above).
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 20, 2014, 08:52 am
I just pushed an updated version of the GSM lib to patched-libs/official, two-step process.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 20, 2014, 10:40 am
And to complete the port of the 1.0.5 official libs, I just pushed partial support for the RobotControl lib (changes to SdCard.h).

From the README.txt:
Quote

Note: This is not a complete port of the RobotControl lib, only a single file (SdCard.h) with changes that would be required for SPI pin assignment if ever a full port to using the mighty-1284p core was undertaken. It is unclear, however, whether the RobotControl lib could be or should be applied to anything except the Arduino RobotControl hardware. The library seems to be a melange of many other libs, and has the potential to interfere with files with the same name in other standard libs (e.g., SPI.h, SPI.cpp). Given these considerations, it is not intended at this stage to support the lib for the mighty-1284p core project beyond providing this single patched file for reference.

How and when it should be deployed it left to the user, but because of the potential problems indicated above, the recommendation is to not install the RobotControl lib unless there is a definite requirement, and you fully understand how the Arduino IDE build process works (and when it doesn't) so you can debug any snarls resulting from the wrong files picked up from the libs containing files of the same name.


I don't know much about the Arduino RobotControl hardware, but the way they've provided support in this lib really looks like a mess. Anyone know the back story on this one?
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 20, 2014, 04:10 pm
In any case, that completes the first cut at porting all the 1.0.5 official libs to mighty-1284p core support. Nothing too difficult, as it turned out. But significantly, this gets us to an important "Everything you need to run Arduino on an ATmega1284P microcontroller" milestone.

So what's next?

I should note that (not by accident) the changes for the SD lib also straightforwardly adapt to Bill Greiman's SdFat lib.

Because of its many improvements over the official SD lib, I suspect SdFat is probably more widely used than the official SD lib.

I've been in contact with Bill G., and he is receptive to SdFat support for the new mighty-1284p core, although he is not sure when the next version of the SdFat lib will be released.

In any case, the patches for SdFat lib are ready to go -- it's just a question of where they get hosted, if at all, until the next release of SdFat. One possibility we could host them here under "patched-libs/unofficial", with the understanding that when the support becomes available in the mainstream release, then the interim patched version could be removed from the repo.

Thoughts? Are there any other third-party libs important enough that we should be thinking about pro-actively approaching the maintainers for mighty-1284p core support?

Title: Re: Updating the mighty-1284p core
Post by: retrolefty on Jun 20, 2014, 04:43 pm
Quote

Thoughts? Are there any other third-party libs important enough that we should be thinking about pro-actively approaching the maintainers for mighty-1284p core support?


I've used the MsTimer2 library in the playground ( http://playground.arduino.cc/Main/MsTimer2 ) in several projects. I found it a simple way to utilize interrupt driven user functions and is a classic does-what-it-says-and-nothing-more kind of useful library to have on hand. I see that the source has lots of specific AVR stuff for many ATMEGA devices but nothing for the 1284P. So that would be my first choice.

Title: Re: Updating the mighty-1284p core
Post by: oric_dan on Jun 20, 2014, 05:42 pm
Pico, it's good you've worked out the changes in the SD libraries. I've never used SD, so didn't investigate them previously, in regards my webpage for the 1284.

Also, a lot of people seem to use the maniac bug nRF2401 library, so you might take a look there. It's currently also an unsupported orphan, I should imagine.  Also, since the 1284 has two h.w. UARTs, it's much more useful for radios that use an RS232 I/F, such as XBee and BT. However, I don't know if there are any libraries for those radios.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 20, 2014, 08:01 pm
Pico, excellent job and fast, too!  :smiley-eek:

I use Andrew Rapp's XBee library (https://code.google.com/p/xbee-arduino/) pretty much exclusively. Have yet to try it with the 1284P (it's in the queue) but it already has the capability to specify which serial port to use (and also SoftwareSerial). If it needs any mods to work with the 1284P, I'd be a bit surprised.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 20, 2014, 09:17 pm
In  moving down a path of maintaining forked libraries,
I'd have a look at the libraries paul is hosting for his teensy products.
https://www.pjrc.com/teensy/td_libs.html (https://www.pjrc.com/teensy/td_libs.html)
It is a good collection of many of the most popular libraries.
His versions are more up to date and often have bug fixes in them
They aren't just forked and modified for teensy but have been updated to also support
Teensy since he doesn't want to make them "teensy only".
He also has been open about adding in updates from others,
and when I've talked to him he's even been open about adding/allowing others to help maintain the libraries.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: larryd on Jun 20, 2014, 11:17 pm
Just wanted to say thank you to everyone who worked on this.
Tried to follow but a bit out of my league.
I can however press download.

Thanks Jack!
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 21, 2014, 02:22 am

Just wanted to say thank you to everyone who worked on this.
Tried to follow but a bit out of my league.
I can however press download.

Thanks Jack!


Thanks very much, it was definitely a group effort.
Bit out of my league too, when I started. Still is, just less so :D
A good example of open source collaboration!
Title: Re: Updating the mighty-1284p core
Post by: larryd on Jun 21, 2014, 03:41 am
For Bobuino is this correct, to make the oscillator full swing change this in boards.txt then burn the bootloader as usual?
From:
bobuino.bootloader.low_fuses=0xff
to this:
bobuino.bootloader.low_fuses=0x7f
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 21, 2014, 03:57 am

For Bobuino is this correct, to make the oscillator full swing change this in boards.txt then burn the bootloader as usual?
From:
bobuino.bootloader.low_fuses=0xff
to this:
bobuino.bootloader.low_fuses=0x7f


I think it should be 0xF7.
Title: Re: Updating the mighty-1284p core
Post by: larryd on Jun 21, 2014, 04:05 am
Fingers too fast brain too slow.

Should have asked also, for the 1M bootloader do I make the following change in boards.txt?
From
bobuino.bootloader.file=optiboot_atmega1284p.hex
to
bobuino.bootloader.file=optiboot_mighty1284p_1M.hex
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 21, 2014, 03:01 pm

Fingers too fast brain too slow.

Should have asked also, for the 1M bootloader do I make the following change in boards.txt?
From
bobuino.bootloader.file=optiboot_atmega1284p.hex
to
bobuino.bootloader.file=optiboot_mighty1284p_1M.hex


Here, that is usually caused by too much caffeine or not enough caffeine.   :D

Yes, that should do it for the bootloader, let us know how it works!
Title: Re: Updating the mighty-1284p core
Post by: pekasus on Jun 21, 2014, 03:10 pm
Jack - I just wanted to follow up with you that I've since started using the new bootloader with old code from the previous version and it all works fine (I had only added the INPUT_PULLUP to the previous loader). From what I can tell, they appear to be compatible.

Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.

Personally, I think we should make a new repo for the altered 1284 stuff since there is a group of people working on it. That way, we can collaborate on the wiki as well instead of keeping track of the different issues on the forum. As official libraries get updated to include compatibility to 1284, we can just include a link to the library to keep the amount of redundant data down.

At any rate, do you have a link where I could download the fixed version of SDfat for 1284?

Cheers!
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 21, 2014, 07:17 pm
@pekasus, thanks for the feedback. The patched libraries are part of the same repo: https://github.com/JChristensen/mighty-1284p
Title: Re: Updating the mighty-1284p core
Post by: larryd on Jun 21, 2014, 09:21 pm
Tried this on the 1284WEENY see picture (Crossroads may be offering them at some point).
- Changing the LOW fuse to 0xF7 worked great! (WEENY has a bit more lead capacitance than a normal PCB and needs full swing)
- Changing to the 1M optiboot would NOT work, reverted back to optiboot_atmega1284p.hex this worked again.
Thanks again to all.

Good Idea when re-burning the bootloader is to first put a blank sketch on it.
Code: [Select]

//This cleans the current program from the controller

void setup()
{               
}

void loop()
{
}

Title: Re: Updating the mighty-1284p core
Post by: bluesmoke328 on Jun 22, 2014, 04:28 am

Pico, excellent job and fast, too!  :smiley-eek:


Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!

Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing mighty-1284p-1.0.5.zip and -- success!

Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later!  :) :) :) Thanks again to everyone who made this possible.

(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 22, 2014, 03:31 pm

Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.


You wouldn't have seen issues unless you were enabling USE_SOFTWARE_SPI in SdFatConfig.h, as all the required changes were in DigitalPin.h.


At any rate, do you have a link where I could download the fixed version of SDfat for 1284?


For want of a better idea of where to park it, I've uploaded it to patched-libs/unofficial so as to make accessible until such time Bill G. incorporates the changes into his next release.

Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 22, 2014, 03:35 pm

Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!

Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing mighty-1284p-1.0.5.zip and -- success!

Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later!  :) :) :) Thanks again to everyone who made this possible.


Excellent to hear. :-)


(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)


Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 22, 2014, 06:53 pm

Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?


Actually you can, it's just part of the repo. It's a Markdown file, README.md. I use Markdown Pad, seems pretty good. But I'd be glad to do it if you wouldn't mind sending me what you want to say. It should go in the Revision History section, but I wonder if we should have a Libraries section in the README as well.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 25, 2014, 03:34 am
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?

If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit,  and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.

To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.

This allows you to access things like bit, bitmask or port: (examples for B7)
CORE_BIT(PIN_B7)
CORE_BITMASK(PIN_B7)
CORE_PORTREG(PIN_B7)

It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.

To see the defines and macros, look down in the teensy core at the file core_pins.h

--- bill

One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.


Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 25, 2014, 06:04 am
Guys,
I'm seeing this:
Code: [Select]
extern const uint8_t digital_pin_to_pcint[]; // this extern needed for mighty-1284p core support
show up in code. Like SoftwareSerial and the GSM libraries.
To me this is wrong. This is an extern to support some macros like
digitalPinToPCICRbit(p)
digitalPinToPCMSK(p)
digitalPinToPCMSKbit(p)

The code that uses those macros should have no knowledge about their internal implementation
and shouldn't have to do special things to make them work.
So in my view the extern declaration should be in  pins_arduino.h where the macro definition is.
i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines
work and that should also include declaring extern references when needed.
Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?

Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.h
then a patched version of SoftwareSerial wouldn't be needed.



Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.
For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.
So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,
you overwrite/replaced the SoftSerial with Teensy support.
I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcint[]
that this specific issue will go away.
But this is hinting at the issue I was concerned about: supporting patched libraries.
It is a very large task with almost no boundaries.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 25, 2014, 06:07 am

In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?


Actually, no, the port/pin info needed to be recast so as to be able to support Bill G.'s fast pin mapping code in Sd2PinMap.h SD lib (also used in his SdFat lib, in DigitalPin.h).


If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit,  and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.

To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.

This allows you to access things like bit, bitmask or port: (examples for B7)
CORE_BIT(PIN_B7)
CORE_BITMASK(PIN_B7)
CORE_PORTREG(PIN_B7)

It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.

To see the defines and macros, look down in the teensy core at the file core_pins.h

--- bill

One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.


I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.

Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 25, 2014, 06:30 am

Guys,
I'm seeing this:
Code: [Select]
extern const uint8_t digital_pin_to_pcint[]; // this extern needed for mighty-1284p core support
show up in code. Like SoftwareSerial and the GSM libraries.
To me this is wrong. This is an extern to support some macros like
digitalPinToPCICRbit(p)
digitalPinToPCMSK(p)
digitalPinToPCMSKbit(p)

The code that uses those macros should have no knowledge about their internal implementation
and shouldn't have to do special things to make them work.
So in my view the extern declaration should be in  pins_arduino.h where the macro definition is.
i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines
work and that should also include declaring extern references when needed.
Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?


The digital_pin_to_pcint[] array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..

Changing this so that

#ifndef ARDUINO_MAIN
extern const uint8_t digital_pin_to_pcint[];
#else
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =
:
#endif

will work just as well, and has the advantage of not needing a patched version of  SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.


Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.h
then a patched version of SoftwareSerial wouldn't be needed.



Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.
For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.
So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,
you overwrite/replaced the SoftSerial with Teensy support.
I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcint[]
that this specific issue will go away.
But this is hinting at the issue I was concerned about: supporting patched libraries.
It is a very large task with almost no boundaries.

--- bill


The boundaries are just where you set them. In this case, I was seeking to make a set of libs that patch support for the mighty-1284p core with the official Arduino 1.0.5 IDE. If anyone wants to mix and match patched libs from other non-official distros of the IDE, fine, but that's beyond the well-defined scope of the undertaking here.

Having said that, if we can easily make things compatible with what Paul has done, why not?

But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has.  :smiley-mr-green:

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 25, 2014, 07:18 am

The digital_pin_to_pcint[] array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..

Changing this so that

#ifndef ARDUINO_MAIN
extern const uint8_t digital_pin_to_pcint[];
#else
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =
:
#endif

will work just as well, and has the advantage of not needing a patched version of  SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.

Very nice. Somehow I missed that conditional.
That will remove that collision with the Teensy SoftSerial patches.

Quote

But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has.  :smiley-mr-green:

I might be wringing my hands but definitely not wagging my fingers...  :)

I think many of the library issues can go away on 1.5x as each core can have its own libraries.
I need to verify that a core library trumps a common library the same way that a user sketchbook library
trumps a common library.
Assuming it does, that will make things really nice as the core can ship with
all the core specific/patched libraries already in place ready to go so it becomes a nice simple install.

And if it doesn't, that is something that we need to work with the Arduino team to
get changed/fixed in the 1.5x IDE before it finalizes.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: westfw on Jun 25, 2014, 08:07 am
Optiboot 6.0 "alpha":  https://drive.google.com/file/d/0B6dMB5dovDUZazNpNWhwc04ydmc/edit?usp=sharing

The important change WRT 1284 is EEPROM support!  Also, I think I fixed "Bobuino", and put the 1284/644 in there own sub-makefike, so that adding platforms can be more easily "logically separate" from actual logic changes.

Code: [Select]
/* 6.0 WestfW: modularize memory read/write functions   */
/*             Remove serial/flash overlap   */
/*              (and all references to NRWWSTART/etc)   */
/*             Correctly handle pagesize > 255bytes       */
/*             Add EEPROM support in BIGBOOT (1284)       */
/*             EEPROM write on small chips now causes err */
/*             Split Makefile into smaller pieces         */
/*             Add Wicked devices Wildfire   */
/*        Remove LUDICOUS_SPEED option   */

Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 25, 2014, 05:02 pm
We had a "ludicrous" speed option before?  Was that like overclocking?
Title: Re: Updating the mighty-1284p core
Post by: westfw on Jun 26, 2014, 01:00 am
"ludicrous speed" was 230400bps at 3.5% error.  I like the idea of having 1Mbps at 0% error better!
(except that I can't convince my Mac Host-side to support 1Mbps...)
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 26, 2014, 01:28 am

"ludicrous speed" was 230400bps at 3.5% error.  I like the idea of having 1Mbps at 0% error better!
(except that I can't convince my Mac Host-side to support 1Mbps...)


Does it like 500kbps?
Title: Re: Updating the mighty-1284p core
Post by: westfw on Jun 26, 2014, 01:55 am
Quote
Does it like 500kbps?

Nope.  Apparently only "standard" bitrates.  I can't tell whether it's a MacOS thing or an FTDI driver thing :-(
(FTDI claims to support non-standard speeds, but when I look for details, all the info is about the windows driver(s))

avrdude -carduino -p atmega1284p -P /dev/tty.usbserial-AM01QQUY -b 500000 -t
avrdude: ser_setspeed(): tcsetattr() failed
avrdude: ser_open(): can't set attributes for device "/dev/tty.usbserial-AM01QQUY": Invalid argument
ioctl("TIOCMGET"): Bad file descriptor
avrdude: ser_close(): can't reset attributes for device: Bad file descriptor

avrdude done.  Thank you.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 26, 2014, 02:21 am

Quote
Does it like 500kbps?

Nope.  Apparently only "standard" bitrates.  I can't tell whether it's a MacOS thing or an FTDI driver thing :-(
(FTDI claims to support non-standard speeds, but when I look for details, all the info is about the windows driver(s))


I'm guessing it is a MacOS thing.
From what I remember from decades ago, and a brief google,
the unix ioctls only support standard bit rates,
but in more recent times there is "kludge" that has been done,
where a different field is overloaded with the desired bitrate if it is non standard.
http://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
Apple may not support this.
UGLY, but maybe this will help:
http://spin.atomicobject.com/2013/06/23/baud-rates-ftdi-driver-mac/

--- bill
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 26, 2014, 02:59 am
So on a different note,
I decided to get the existing 1284 core working on 1.5x

I've got it up and working. Didn't take very long - maybe 30 minutes.
The tree is different, and there are some mods and added files, and libraries
that have to be delt with but not very difficult.
Things like the boards.txt files are slightly different, there is a platform.txt for all the compile/build rules
and then some local core libraries that must now exist in the core directory tree but that's about it.

I also verified that libraries supplied with the 1.5x core override libraries in the distribution.
That is good, since the patched libraries can now be put into the core directory tree so that that
they can automatically override the distribution versions when the 1284 core is being used.

So here is the current precedence of libraries
- User sketchbook libraries
- core libraries
- IDE supplied "common" libraries

Which seems like the order it should be in.

I haven't beat on it to see where the issues are - I'm sure there are issues
as essentially, what I did is get a 1284 1.x core working on 1.5x

What  needs to happen is the core files from 1.5x need to be moved over and then
the tweaks made for the 1284 as there are a few new features in the 1.5x core that
won't exist until that is done.
I did notice that there are some big differences in HardwareSerial and wiring_analog.c
so those need very close scrutiny.

To me the 1.5x solution looks interesting as it can create a package that once installed
"just works" and has all the needed patched libraries already in place and ready to go.

Long term, maintaining a 1284 core that is so close to the Arduino team distribution AVR core is
a maintenance PITA.
I think the ideal solution would be to get the 1284 mods pushed into the Arduino team AVR core
as they are pretty minor.
That way there is only a single AVR core vs having to maintain a parallel AVR core.


--- bill
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jun 26, 2014, 03:51 am

I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.


What I saw wasn't any sort of recasting but rather some use of macros that use concatenation
to derive other macro names similar to what is done in the Teensy core.
Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminating
the old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.
The DPM() macro used in those libraries when using the mighty 1284 would break.
However, the DPM macro could easily be changed to use the CORE macros instead since the
functionality is the same.
By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,
but the DPM() macro is inside the header too, so the headers would have to be modified.
The macro would change from this:
Code: [Select]
#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
to this:
Code: [Select]
#define DPM(x) { CORE_DDRREG(x), CORE_PINREG(x), CORE_PORTREG(x), CORE_BIT(x) }


I'm not sure what other code out there is already using these BIT* and PORT* macros,
but I think Paul's way is a bit more useful with additional capabilities.
All this said it is a pretty large change and a good bit of work.
I'm not sure if folks are on board with the changes.
However, if this change is to be made, it is better to make it sooner rather than later.

BTW,
In looking at the low level code, it looks like there might be a small performance bump and
code size reduction if the tables stored the bitmask rather than the bit number.
i.e. let the compiler do the bit shift vs doing it at runtime in the data path.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: CrossRoads on Jun 26, 2014, 04:17 am
Man, you guys are good! I don't think I'd ever been able to dig in & understand all the layers and subtleties from IDE version to IDE version and then all the library implications.
Title: Re: Updating the mighty-1284p core
Post by: JChristensen on Jun 26, 2014, 04:29 am

Man, you guys are good! I don't think I'd ever been able to dig in & understand all the layers and subtleties from IDE version to IDE version and then all the library implications.


My eyes are fairly glazed over too. I haven't really even looked at 1.5 yet.
Title: Re: Updating the mighty-1284p core
Post by: pico on Jun 26, 2014, 04:54 am


I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.


What I saw wasn't any sort of recasting but rather some use of macros that use concatenation
to derive other macro names similar to what is done in the Teensy core.
Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminating
the old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.
The DPM() macro used in those libraries when using the mighty 1284 would break.
However, the DPM macro could easily be changed to use the CORE macros instead since the
functionality is the same.


As long as the DPM macro can be rewritten to use the CORE macros, there no issue then.


By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,
but the DPM() macro is inside the header too, so the headers would have to be modified.
The macro would change from this:
Code: [Select]
#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
to this:
Code: [Select]
#define DPM(x) { CORE_DDRREG(x), CORE_PINREG(x), CORE_PORTREG(x), CORE_BIT(x) }


Try it out and see if it works as expected. Post what you propose the CORE macros will be that will be included in the pins_aruduino.h files, and I'll test as well.


I'm not sure what other code out there is already using these BIT* and PORT* macros,
but I think Paul's way is a bit more useful with additional capabilities.


Nothing else I can think of off-hand, although I'm sure the compiler will quickly remind me if a macro it was expecting somewhere goes missing.


All this said it is a pretty large change and a good bit of work.
I'm not sure if folks are on board with the changes.
However, if this change is to be made, it is better to make it sooner rather than later.


I have to disagree. This looks a very minor change, and not much work at all.  :smiley-mr-green:

But I will agree that if we are going to do it, let's do it now. Just so we agree on something.


BTW,
In looking at the low level code, it looks like there might be a small performance bump and
code size reduction if the tables stored the bitmask rather than the bit number.
i.e. let the compiler do the bit shift vs doing it at runtime in the data path.

--- bill


As long as the macros give you the access to the bit shift values as integers as well as masks, I'm happy. Writing a macro or function to convert a pin no. to a mask is trivial, but going the other way is annoyingly messy. One thing I didn't like about the original casting of the pin/port info is that it didn't have the pin no. info explicitly accessible, only indirectly in mask format, and that made things relatively awkward and inflexible.

(BTW, by "casting" I don't mean "cast" as in type casting, rather "cast" as in "represent in a particular way",  the more general/non-technical sense. Just to avoid any misunderstanding or confusion.)

Title: Re: Updating the mighty-1284p core
Post by: westfw on Jun 27, 2014, 02:25 am
Quote
[aliasing baud rates to get 1Mbps] http://spin.atomicobject.com/2013/06/23/baud-rates-ftdi-driver-mac/

That seems to have worked.  Icky, though.  Can't ask normal Arduino users to go through that.

Title: Re: Updating the mighty-1284p core
Post by: scargill on Jul 07, 2014, 11:04 pm
Can anyone help. I've been using Manicbug's 1284p Optiboot code on 1.05 and I've now tried twice to get it to work with 1.52 and now 1.57 - I've moved the core files from my sketches hardware folder  - and updated the boards.txt file --- and....  Although I can select the 1284p - I get this error even on an empty sketch.

sketch_jul07a.ino:1:21: fatal error: Arduino.h: No such file or directory
compilation terminated.
Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jul 08, 2014, 12:26 am

Can anyone help. I've been using Manicbug's 1284p Optiboot code on 1.05 and I've now tried twice to get it to work with 1.52 and now 1.57 - I've moved the core files from my sketches hardware folder  - and updated the boards.txt file --- and....  Although I can select the 1284p - I get this error even on an empty sketch.

sketch_jul07a.ino:1:21: fatal error: Arduino.h: No such file or directory
compilation terminated.



I'm not sure what all you have done,
but it isn't as simple as just moving around a few core files and updating a boards.txt file.
You have to create a separate 1.5x compatible 3rd party h/w core directory tree for the
1284 core files under the users sketchbook/hardware directory as 1.5x 3rd party cores work differently.

You will also have to create a platform.txt with all the compile/link rules for the builds
and then you have to copy some libraries (Wire, SPI, EEPROM, & SoftSerial) that used to be in main libraries area that are now
down under each core.
You will also have to copy over any of the patched libaries into the proper location in the new 1.5x h/w core tree.


And then...... after all that.......
I just found out it what I had working on 1.5.6-r2 no longer works under 1.5.7
They changed where avrdude lives in the directory tree which affects how it is used by boards.txt
avrdude has been moved from {installdir}/hardware/tools/
to {installdir}/hardware/tools/avr/bin

The net result is that avrdude will not be found with the existing 1284 boards.txt entries.
With the existing entries, the IDE ends up only looking in {installdir}/hardware/tools
and bombs out because it can't find an avrdude executable there.

To me this new location and execution method has some issues as it doesn't fall back to an avrdude on the users path
(which it will be for linux users that have avr tools installed separately from the Arduino tools)

Second, while moving the avrdude executable down into a core related directory is a good thing,
I don't think it shouldn't be placed down with the gcc tools. It should be somewhere else.
Moving it down with the gcc tools makes it much harder to swap out gcc tools supplied
with the IDE for a different locally installed versions since you can no longer just move/rename
the IDE's gcc tool directory since it now contains avrdude.
The gcc tools and avrdude are now somewhat bound together.

There is a work around for this in boards.txt
If you prefix the upload.tool with the name of the core then it will find it.
so in a 1.5x boards.txt file you must change this:
Code: [Select]
mighty_sleepingbeauty.upload.tool=avrdude
to this
Code: [Select]
mighty_sleepingbeauty.upload.tool=arduino:avrdude

And then it will work on both 1.5.7 and pre 1.5.7

Guys, this is the kind of stuff that I believe shows why this core should be rapidly moved to 1.5x
as 1.5x is still having all kinds of changes and updates and you have to keep your eye on it
to make sure that things are working and that the Arduino teams doesn't accidentally
break the 3rd party libraries/cores.

1.5x IDE also has some nice features that are not in 1.x
The biggest being that dropdown are now scrollable.
This is critical if you have lots of boards or libraries installed.
Without this capability you may not be able to select the desired board or be able
to pick an example sketch because the entry is below what is on the screen and there
is no way to scroll down to it.
Having this scrolling capability is a MUST HAVE for me as I have close to 100 libraries
and nearly the same number of board selections.
There is a work around in 1.x that I'm using for that, and that is if you install Pauls
teensyduino he modifies the IDE to add in the scrolling menus.
So you can get the scrolling menus on 1.x by simply installing Pauls Teensyduino add on.

Another thing that is better with 1.5x is that all the patched libraries could be put into place in
the core directory structure so that once the user installs the core all the patched libraries are there
and ready to go with nothing else to do.


--- bill


Title: Re: Updating the mighty-1284p core
Post by: pico on Jul 08, 2014, 03:41 am

1.5x IDE also has some nice features that are not in 1.x
The biggest being that dropdown are now scrollable.
This is critical if you have lots of boards or libraries installed.
Without this capability you may not be able to select the desired board or be able
to pick an example sketch because the entry is below what is on the screen and there
is no way to scroll down to it.
Having this scrolling capability is a MUST HAVE for me as I have close to 100 libraries
and nearly the same number of board selections.
There is a work around in 1.x that I'm using for that, and that is if you install Pauls
teensyduino he modifies the IDE to add in the scrolling menus.
So you can get the scrolling menus on 1.x by simply installing Pauls Teensyduino add on.


There's also the eried enhanced 1.0.5 IDE that supports scrolling menus (I believe this is the code that Paul based some of his Teensyduino enhancements upon.)

http://forum.arduino.cc/index.php?topic=118440.0

Personally, I'd never recommend someone use 1.5.x just for something like scrolling menus. 1.5.x is, after all, still a beta platform, with an unstable code base and feature set. If you want to program a Due, then I guess you don't have much choice. But for anything else, unless you are particularly yearning for adventure, well -- fuggetaboutit!

If someone asks "how do you program a 1284p using Arduino?", the current correct answer is "we have a 1.0.5 compatible core and set of libs".

Well, at least that's the answer *I* give!

But for the adventurous, I'd suggest a new thread would be appropriate for discussion of any 1.5.x related work on the 1284p core.

Title: Re: Updating the mighty-1284p core
Post by: bperrybap on Jul 08, 2014, 07:36 am

But for the adventurous, I'd suggest a new thread would be appropriate for discussion of any 1.5.x related work on the 1284p core.


Yeah, 1.5x is definitely a moving target.

I guess I fall in to the "adventurous" category.
I got the 1284 core up and working on 1.5x including the 1.5.7 just released.
I think there are some features in 1.5x that are very useful.
The biggest feature for this core being that it makes installing the core
and the updated/patched libraries MUCH easier than installing the core on 1.0.5
since with 1.5x you can include the patched libraries in the core so that they are
installed with the 1284 core and they will automatically get used over the distribution libraries
but will only get used with the 1284 core
so the risk of breaking some other core or processor is eliminated.

That said 1.5x is moving target and updates can break things.

--- bill
Title: Re: Updating the mighty-1284p core
Post by: AlfaOmega on Oct 19, 2014, 12:04 am


I've had exactly the same problem as scargill - fatal error: Arduino.h: No such file or directory

Solved it by changing:

Code: [Select]

#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard


Code: [Select]

mighty_opt.build.core=arduino:arduino
#mighty_opt.build.core=standard


Dear bperrybap/Bill,

It is really encouraging to read on a forum messages like "Hurray! Got it working!"  XD

If it is not too much trouble please explain how you made it)
Title: Re: Updating the mighty-1284p core
Post by: bvernham on Dec 10, 2014, 11:31 pm
Has any work been done for 20 MHz bootloader?  I have previously run the Bobuino boards at 20 MHz with no issue using the 20 MHz bootloader.

Thanks

Bruce Vernham
Title: Re: Updating the mighty-1284p core
Post by: OldMicroGuy on Dec 26, 2014, 05:41 pm
Back in July bperrybap posted about the work he had done with porting the mighty-1284p core to Arduino 1.5.7.  The current version is now 1.5.8 and if you install 1.5.8, it will uninstall your 1.0.5

Is there some other thread about this discussion ?

Any Github site like Jack's where we could download the files for 1.5.x ?


Roger

Title: Re: Updating the mighty-1284p core
Post by: pert on Apr 28, 2015, 02:30 pm
I have updated Mighty 1284P to work with Arduino IDE 1.5+ https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility (https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility). I had to update the patched GSM library because the previous patched version doesn't work with 1.5+ but I don't have the GSM hardware to test it. Does anyone have an ATmega1284/644 and the GSM hardware that can try it out and let me know if it works: https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility/patched-libs/official/IDE1.5.x-Compatible/GSM (https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility/patched-libs/official/IDE-1.5.x-Compatible/GSM)
Thanks, Per