Go Down

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

john1993


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.

Coding Badly


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

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

john1993

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.

JChristensen


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.

JChristensen


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

retrolefty



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

JChristensen


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

retrolefty

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

pico

#53
May 03, 2014, 06:44 am Last Edit: May 03, 2014, 07:10 am by pico Reason: 1

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

CrossRoads

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

pico

#55
May 03, 2014, 09:37 am Last Edit: May 03, 2014, 11:01 am by pico Reason: 1

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

#56
May 03, 2014, 10:12 am Last Edit: May 03, 2014, 10:19 am by pico Reason: 1
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.
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


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.

JChristensen

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.

pico

#59
May 03, 2014, 03:16 pm Last Edit: May 03, 2014, 03:32 pm by pico Reason: 1

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

Go Up