Go Down

Topic: Does the latest IDE support 644P and 1284P? (Read 3338 times) previous topic - next topic

scswift

Maniac, I think you may have a bug in your pin mappings. 

In variants\avr-developers\pins_arduino.h, the comments indicate the analog pins for the Sanguino are mapped like so:
Code: [Select]
// ATMEL ATMEGA644P / SANGUINO (also works for ATmega1284P)
//
//                   +---\/---+
//  INT0 (D 0) PB0  1|        |40  PA0 (AI 0 / D31)
//  INT1 (D 1) PB1  2|        |39  PA1 (AI 1 / D30)
//  INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D29)
//   PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D28)
//   PWM (D 4) PB4  5|        |36  PA4 (AI 4 / D27)
//  MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D26)
//  MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D25)
//   SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D24)
//             RST  9|        |32  AREF
//             VCC 10|        |31  GND
//             GND 11|        |30  AVCC
//           XTAL2 12|        |29  PC7 (D 23)
//           XTAL1 13|        |28  PC6 (D 22)
//  RX0 (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//  TX0 (D 9)  PD1 15|        |26  PC4 (D 20) TDO
//  RX1 (D 10) PD2 16|        |25  PC3 (D 19) TMS
//  TX1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//  PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//  PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//  PWM (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                   +--------+


And as near as I can tell, this is correct.  However, where the pin constants are actually defined below you have:

Code: [Select]
static const uint8_t A0 = 24;
static const uint8_t A1 = 25;
static const uint8_t A2 = 26;
static const uint8_t A3 = 27;
static const uint8_t A4 = 28;
static const uint8_t A5 = 29;
static const uint8_t A6 = 30;
static const uint8_t A7 = 31;


I'm not sure where those constants get used, but they're opposite what the comments seem to indicate they should be.

Oh yeah that looks like a bug alright.  It'd be great if you can open an issue on github.

CrossRoads

Make sure scswift is not comparing the Mighty1284 pin picture and the Bobuino A#s or something too, that could make it look out of sync.
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.

retrolefty

Just an observance that I upgraded to the arduino IDE version 1.0.3 and was getting errors when a 1284p board was selected and trying to verify a sketch, but not when a Uno board selected. One error was INPUT_PULLUP not defined and I think byte not a type, etc. What I did was copy the Arduino.h file from 1.0.3 and replaced the one used in the added hardware files and that seemed to work. I guess my main question would be are there other changes required? Seems that adding new/different boards types to the users hardware files will never be completely independent of the version of IDE being used, so on going maintenance is probably a never ending requirement?

Lefty

CrossRoads

Which 1284p board?  I'm still at 1.0 for 1284s, haven't go around to moving the mighty1284 stuff into 1.01 or 1.02 yet, altho I've been using 1.02 for '328p sketches.
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.

scswift


Just an observance that I upgraded to the arduino IDE version 1.0.3 and was getting errors when a 1284p board was selected and trying to verify a sketch, but not when a Uno board selected. One error was INPUT_PULLUP not defined and I think byte not a type, etc. What I did was copy the Arduino.h file from 1.0.3 and replaced the one used in the added hardware files and that seemed to work. I guess my main question would be are there other changes required? Seems that adding new/different boards types to the users hardware files will never be completely independent of the version of IDE being used, so on going maintenance is probably a never ending requirement?

Lefty



Yes I ran into this problem myself.  Apparently definitions for certain constants like INPUT_PULLUP are in those hardware specific folders.  Seems like a bad design decision to me.  I can't see a reason to make a constant like that hardware specific.

retrolefty


Which 1284p board?  I'm still at 1.0 for 1284s, haven't go around to moving the mighty1284 stuff into 1.01 or 1.02 yet, altho I've been using 1.02 for '328p sketches.


Didn't matter which of the 1284 or 644 boards I tried. The issue is that for instance the INPUT_PULLUP is a new feature/constant not defined in IDE version 1.0, so any user add on boards not using the Arduino.h file from the version 1.0.3 will choke if trying to use the newer pull-up command pinMode(pin#,INPUT_PULLUP) command.

My main questions was what other possible effects will upgrading the IDE have on all the 1284/644P added boards that were constructed using version 1.0 of the IDE?

Lefty

retrolefty

#22
Jan 07, 2013, 07:37 pm Last Edit: Jan 07, 2013, 07:42 pm by retrolefty Reason: 1


Just an observance that I upgraded to the arduino IDE version 1.0.3 and was getting errors when a 1284p board was selected and trying to verify a sketch, but not when a Uno board selected. One error was INPUT_PULLUP not defined and I think byte not a type, etc. What I did was copy the Arduino.h file from 1.0.3 and replaced the one used in the added hardware files and that seemed to work. I guess my main question would be are there other changes required? Seems that adding new/different boards types to the users hardware files will never be completely independent of the version of IDE being used, so on going maintenance is probably a never ending requirement?

Lefty



Yes I ran into this problem myself.  Apparently definitions for certain constants like INPUT_PULLUP are in those hardware specific folders.  Seems like a bad design decision to me.  I can't see a reason to make a constant like that hardware specific.


I agree, at least for the case of the Arduino.h file as it already seems to be processor type aware for the 1284P/644P chips, so I don't understand why a seperate Arduino.h file needs to be in the user's hardware folders?  Extracted from the Arduino.h file from IDE version 1.0.3:

Code: [Select]
#if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__) || defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
#define DEFAULT 0
#define EXTERNAL 1
#define INTERNAL 2
#else  
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644P__)
#define INTERNAL1V1 2
#define INTERNAL2V56 3
#else
#define INTERNAL 3
#endif
#define DEFAULT 1
#define EXTERNAL 0
#endif


Lefty

scswift

While we're on the subject of supporting other processors, you know what would be really awesome would be XMEGA support.  I'm not sure why they chose to go with the arm processor they used in the DUO, but that chip is huge and seems to require a whole lot of support circuity.  I don't think I'd ever want to take that processor and stick a bare bones version in my own project.  The xmega on the other hand comes in a small 44 pin version, looks easy to use, has a built in DAC for audio output...  Aside from running a 3.3v potentially being a problem for controlling servos, for projects that need a little bit extra oomph, and 32mhz xmega seems like an excellent choice for an upgrade if you need twice the speed and/or audio output.

retrolefty


While we're on the subject of supporting other processors, you know what would be really awesome would be XMEGA support.  I'm not sure why they chose to go with the arm processor they used in the DUO, but that chip is huge and seems to require a whole lot of support circuity.  I don't think I'd ever want to take that processor and stick a bare bones version in my own project.  The xmega on the other hand comes in a small 44 pin version, looks easy to use, has a built in DAC for audio output...  Aside from running a 3.3v potentially being a problem for controlling servos, for projects that need a little bit extra oomph, and 32mhz xmega seems like an excellent choice for an upgrade if you need twice the speed and/or audio output.


Well googling there seems to have been some working on such a port, but best I can tell progress seems to have stopped with Arduino version 18, so not likely easy to install for arduino IDE 1.0.x

http://www.akafugu.jp/posts/blog/2011_11_25%20-%20Wire%20in%20Xmegaduino/

There seems to also be a currrent kickstarter project that will have to deal with adding support to run on the currrent arduino IDE. However it doesn't appear he/she will reach their goal amount in the time left?

http://www.kickstarter.com/projects/myownduino/sirduino-a-xmega-powered-arduino


Lefty

Tom Carpenter

#25
Jan 07, 2013, 09:14 pm Last Edit: Jan 07, 2013, 09:20 pm by Tom Carpenter Reason: 1
I seem to recall reading somewhere that xmegas were though about but were ditched due to reliability and supply issues.

Also, there is an Arduino IDE spinoff for XMegas:
https://github.com/akafugu/Xmegaduino
But I believe they forked the whole IDE, so it isn't as simple as just a new core.
~Tom~

CrossRoads

Guess I'll have to look at the pins_arduino.h that goes with

defined(__AVR_ATmega1284P__)

and see if its usable with my Bobuino boards.
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.

retrolefty


Guess I'll have to look at the pins_arduino.h that goes with

defined(__AVR_ATmega1284P__)

and see if its usable with my Bobuino boards.


No, the arduino IDE 1.0.3 does not offer any 1284/644 support in their various pins_arduino.h files, just supporting the boards that arduino sells as usual.

Lefty


Go Up