Does the latest IDE support 644P and 1284P?

maniacbug:
Backwards compat is critical for people who want to re-use shields of course, but personally I have no use for it.

The Arduino (maybe Wiring?) guys didn't seem to plan much for moving beyond the 8/168/328. That may not have ever been their intention, which is fine. This whole thing probably grew way beyond their expectations anyway, and you could say the blame lies more on Atmel for not sticking to a regular and defined arrangement. Whatever, it is what it is, and given the difference between the various families, it's pretty understandable that you can't always just swap out hardware.

IMO, shield and pin mapping compatibility involves possibly more compromises than it's worth. I feel that if you're moving your project from one chip to another, a little work to change some DEFINEs or some IFDEFs in the library are perfectly acceptable. Abstraction comes at a cost, and sometimes it's just easier to cut ties.

That said, the variants out there do a great job of allowing the user to choose the layout that makes the most sense given their application. Between the various community 1284 designs, you get some very reasonable options for whatever degree of backward compatibility matters to you. That might actually be better than a single official 1284 design that chooses one layout or another as the bona-fide standard.

CrossRoads:
"it's less confusing if the analog pin indexes match up with the digital ones"

I wouldn't think so - A0-A5 as D14-D19 has been the "standard" for quite a while now.

If the board were designed to be an Arduino variant and to be programmed with the Arduino IDE, I might agree with you, but since it's designed to be programmed in basic by people with no experience with the Arduino, there is no standard that they've been exposed to, and I can remap the pins however I like. And it just made more sense to have the analog and digital pins start at the same index.

Or at least I did when I started. The original intent was to set things up so the user would access a switch with SWITCH[1] or a pot on the same pin with KNOB[1]. It wouldn't have made sense to have KNOB[] start at pin 7. And it would have meant that if I read the values and stored them in an array at the start of the loop that the array would either have a bunch of wasted space or I'd have to mess with the index the user provided to index it to 1 internally.

The design is still evolving though, and it seems likely users will need to define what each port is being used for in the initialization file. That way I can set up the servos at the start, and the user won't be able to try to give a servo command to a switch by specifying the wrong index, and I won't have to change a port from input to output in the middle of the script, which wouldn't even make sense anyway because why would a port go from an input to an output while someone is using the device?

Even with months of planning I'm still working out a few MINOR last minute details. :slight_smile:

I would find it more confusing, and hurt with backwards compatibilty, if D0/D1 were not the main serial port, if D11-12-13 were not the SPI port, if D18/D19 were not the I2C port, etc.

Yeah, but folks using this aren't likely to want to access those, and they'll be in use by the DAC, SD card, and LED drivers. The power user who decides they want to just toss my code and write everything in C is going to be few and far between, and I'm sure they can figure out the pin mappings if they want to go that far.

"Before I decided to upgrade my design tot he 644P or 1284P"
Your kickstarter page does not mention that (yet?). You appear to have planned this project out pretty well.
The room for larger sketches & SRAM offered is nice. I have used the extra IO offered vs adding another chip or two to a project as well.

That's because I only discovered that SD cards don't play nice on the SPI bus a week before the Kickstarter ended, and I didn't know at that point whether I was going to solve the problem by taking away the SPI expansion port and two IO pins, or by upgrading to a better microprocessor.

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.

And before I can do that I need to decide what I'm going to do with my scripts. The original plan was to interpret the code in realtime, from the SD card. That requires transferring and processing a lot of data though, and even though it doesn't need to run as fast as the code to update the LEDs, servos, and sound, I would still like the whole script to be parsed at least 30 times a second.

So there's a few other options I've been looking at.

Option 1 is to tokenize the code and write it back to the SD card. That would allow the user to comment their code all they like without slowing down the script being interpreted, and in general it would greatly reduce the data that needs to be read as well.

Option 2 is to do the same thing but store the tokenized code in ram. With 16K of ram I could do this. It would limit the size of the scripts a bit, but I don't think many would hit the limit.

Option 3 is to do the same thing but store the tokenized code in flash. I'd have to work out how to alter flash without overwriting my main program but I don't think that would be too difficult. Worst case is I have to write the main program to the SD card and read that back and then the tokenized code as well.

And Option 4 is to actually compile the code. User sticks the code on the SD card, the bootloader senses it's been changed, compiles it into actual assembly commands, and writes that to flash. This is the option I'm looking at most seriously at this point. I know it's possible to have a bootloader burn code from an SD card because others have done it. I just need to work out how to compile it, and how to include the code I'll have written in C to support it. (Ie, do all the led and sound updating, read the sounds off the sd card, etc.)

I figure I'm going to be very busy these next three months. :slight_smile:

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.