Does the latest IDE support 644P and 1284P?

scswift:
Since then I've settled on either the 644 or 1284, but I won't know which I want to go with until I write the code and see if I really need the extra ram.

Why not just decide on the 1284 and be done with it? Surely the extra $0.23 isn't going to kill your BOM. (In fact the 1284 is CHEAPER at higher quantities.)

scswift:
Option 2 is to do the same thing but store the tokenized code in ram.

Alternately, you could page the script into RAM if it was at all linear.

I don't remember why. I've got so many pages of notes it's hard to keep track of everything... I think it was cause it was a little more expensive, not as many were being kept in stock at Digikey and Mouser, and the Sanguino I knew had good support.

Looking at it again though, on Digikey it's more like 35 cents more. Which for 250 units only comes to $84. The parts on these boards is already pretty high though. And it will get even higher just going to the 644. And I may add more pins headers, and a buck regulator to manage heat better. I also still have to produce prototypes and I'm gonna be working on it the next three months. So if the extra ram will never be used... it seems like a waste to include it, and if I ever do find a use for it, I can always just swap the chips.

But I dunno. Maybe I'll go for it. 4K of ram still isn't much to work with. Especially if I end up needing a stack for recursion and gosubs and stuff.

As for paging in the script, I could do that, but I don't know how much that would speed things up.

Thinking about it some more this evening, I really don't want to write a compiler that generates assembly code. Interfacing that with my Arduino program would be a nightmare. I could do it, but... it wouldn't be fun and would take way too long to implement. I've got a schedule I need to adhere to.

It seems like the best option is to tokenize the code and store it in flash the first time the user boots with a new script. I could either try to figure out where the code for my interpreter ends and write it after that, or I could have the interpreter as a file on the SD card along with the script, and the bootloader would automatically load both that and then the compiled basic script in.

I need to do some more reading up on how the bootloader stuff works. I need to know if I can put my interpreter outside the bootloader space, have it interpret my script, and then have it tell the bootloader to load the tokenized verson of the the code from the sd card or ram into the space after the interpreter.

So one more question... Why write your own scripting language? Why not just use standard Arduino coding style? Then you can write a library to add the semantics you want. Thousands of people with no programming experience have picked it up. My son is 6 and he has no problem with it.

With a bit of C++ tomfoolery you could actually write this and have it do what you want.

SERVO(2) = KNOB(1)

or in more typical parlance, we might write

Servo myServo(2);
Knob myKnob(1);
myServo.isControlledBy(myKnob);

Then you won't have to worry about custom bootloaders and custom interpreters, etc etc.

You mean why not use the Arduino IDE?

Too steep a learning curve for beginners. I see people come here all the time and ask "How can I do two things at once in my program?" because they want to blink an LED and read an input but the LED example uses a delay statement.

My scripting language will do away with the delay statement. It will have timers. You reset a timer, and then it starts counting up. When the time equals how long you wanted to wait, you then perform your task and reset it again.

Presenting a user with my whole code base for reading the SD card and updating the sounds, and the servos, and checking for input, and updating the LEDs would also be incredibly confusing, even if I tell them that the only thing they need ever do is touch the code in one function. Hell, I'd be confused if someone handed me their huge program and told me to just start adding code in some function.

Doing things this way hides all that from them. They won't fret over it because they won't see it. They won't need to worry about installing the compiler. Configuring it. Installing any necessary drivers. Getting it to upload to their board properly. And I won't need to include a USB port and all the support circuitry for that, which I don't have the room for, and which would add additional expense and complexity anyway.

Is a C code generator possible? It would require a toolchain, but if you have an installable package, you could hide all of that from the user the same as the IDE. I don't know if that fits your vision or not..

That's an interesting idea, but it would require a ton of additional work and I've really gotta have these ready by August. It would also have to work with macs. I could code it in Blitz Basic which is cross platform, but writing a basic interpreter in basic would be horribly ironic, and again, it would be a ton of work.

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:

// 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:

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.

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.

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

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.

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