Go Down

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

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.

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.

"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.
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

maniacbug

When I started bringing up the 1284p, Sanguino seemed dead.  The last update was to arduino-0017 or some such.  Didn't seem like a useful point of reference.

As to the analog pins, I wanted them to follow Uno convention, so that analog channel = digitial pin - A0.

Backwards compat is critical for people who want to re-use shields of course, but personally I have no use for it.  I've long since stopped using shields (and 5V for that matter).  Whenever I put a 1284 into something, it's a custom piece of hardware. 

Plus back-compat pin mappings are horrible confusing on a breadboard.  Anyway, Arduino encapsulates pin differences in 'variants', so it's easy to switch from one to the other.

SirNickity

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.

scswift


"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. :-) 


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

Quote

"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. :-)

maniacbug


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


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.

Go Up