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 toCode: [Select]#mighty_opt.build.core=arduino:arduinomighty_opt.build.core=standardIt 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.
QuoteQuotebobuino.build.mcu=atmega1284pbobuino.build.f_cpu=16000000L#bobuino.build.core=arduino:arduinobobuino.build.core=standardbobuino.build.variant=bobuinoThis boards.txt is parsed by the GUI and ensures all the right "pieces" are passed to AVRDUDE via the command prompt.
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)
Quote from: mrburnette on May 03, 2014, 06:39 pmQuoteQuotebobuino.build.mcu=atmega1284pbobuino.build.f_cpu=16000000L#bobuino.build.core=arduino:arduinobobuino.build.core=standardbobuino.build.variant=bobuinoThis 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?
Quote from: Jack Christensen on May 03, 2014, 01:06 pmThen 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.
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.
QuoteThis 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.
#define analogInputToDigitalPin(p) ((p < NUM_ANALOG_INPUTS) ? 21 - (p) : -1)
#define analogInputToDigitalPin(p) ((p < NUM_ANALOG_INPUTS) ? 14 + (p) : -1)
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 thethe actual data arrays are still initialized as PROGMEM.
Whatever the reason, it does not appear to me that data itself is moving from AVR progmem to RAM on the 1284 core.
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
Is this file currently in/going to be in to version control somewhere?
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.
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.
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
QuoteBut if you *really* prefer, I'll do the pull request thing for bobuino/pins_arduino.hHold 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!