Go Down

Topic: Updating the mighty-1284p core (Read 124079 times) previous topic - next topic

pico


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.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

pico


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?
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

JChristensen


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.

bperrybap

#408
Jun 25, 2014, 03:34 am Last Edit: Jun 25, 2014, 03:37 am by bperrybap Reason: 1
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.



bperrybap

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

pico


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.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

pico

#411
Jun 25, 2014, 06:30 am Last Edit: Jun 25, 2014, 06:32 am by pico Reason: 1

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:

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

bperrybap


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

westfw

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   */


CrossRoads

We had a "ludicrous" speed option before?  Was that like overclocking?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

westfw

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

JChristensen


"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?

westfw

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.

bperrybap


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

bperrybap

#419
Jun 26, 2014, 02:59 am Last Edit: Jun 26, 2014, 03:01 am by bperrybap Reason: 1
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

Go Up