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.
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.