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
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.
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.
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
scswift:
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
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:
#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
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.
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.
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
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:
But I believe they forked the whole IDE, so it isn't as simple as just a new core.
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.
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.
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