Go Down

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

retrolefty


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

mrburnette

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.


retrolefty


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?

CrossRoads

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

bperrybap



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.

bperrybap



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

pico


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)


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


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

retrolefty

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

JChristensen

#69
May 03, 2014, 11:11 pm Last Edit: May 03, 2014, 11:18 pm by Jack Christensen Reason: 1
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. 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

JChristensen

#70
May 03, 2014, 11:56 pm Last Edit: May 04, 2014, 02:02 am by Jack Christensen Reason: 1

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

pico

#71
May 04, 2014, 04:32 am Last Edit: May 04, 2014, 04:41 am by pico Reason: 1

PS: Or I can just grab Crossroads' file 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
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


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

pico

#73
May 04, 2014, 05:06 am Last Edit: May 04, 2014, 05:17 am by pico Reason: 1

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

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


Go Up