Pages: [1] 2   Go Down
Author Topic: Does the latest IDE support 644P and 1284P?  (Read 2496 times)
0 Members and 1 Guest are viewing this topic.
Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've seen a few Sanguino sites which indicate the IDE supports those directly now, but I can't seem to find an entry for them in boards.txt, and I don't see them listed in the IDE.  Were they removed in version 1.0?
Logged

Austin, TX
Offline Offline
Faraday Member
**
Karma: 63
Posts: 6055
Baldengineer
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I've seen a few Sanguino sites which indicate the IDE supports those directly now
Don't believe everything on the Internet.  Probably better to go to the source.

From http://sanguino.cc/useit :
"The Arduino host software does not support the Sanguino out of the box, but it is very easy to add support for the Sanguino to the host software."
Logged

Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The IDE doesn't support those chips directly, but it's easy enough to add support.  For example, you can use my mighty-1284p platform to add support in the IDE.

https://github.com/maniacbug/mighty-1284p
Logged


SE USA
Offline Offline
Faraday Member
**
Karma: 40
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

the mighty 1284 core seems to work fine with my 644P, though I have not exactly tested it from head to toe
Logged


Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Maniac:

Well this is an amusing coincidence...

http://www.kickstarter.com/projects/shawnswift/the-mightytm-microcontroller

It appears we chose similar names for our boards.  Mine isn't really an Arduino variant though, it's designed to be programmed in basic via the SD card, with either a custom bootloader doing the work of compiling the code or an interpreter, either being uploaded via ISP.

I'm curious... why did you create your own setup rather than using the Sanguino's?  Does it not work with the 1284P period, or does it just not work when doing a serial upload using a bootloader?  And I think you mentioned changing your analog pin mapping to match the Leonardo... Is theirs backwards?  Is it the opposite of the Sanguino? 

I haven't decided what I'll do with the analog pins yet.  Before I decided to upgrade my design tot he 644P or 1284P, I had the analog pins and digital pins backwards so that the analog pins would start at pin 1, because it's less confusing if the analog pin indexes match up with the digital ones.
Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 437
Posts: 23699
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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.

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Anchorage, AK
Offline Offline
Edison Member
*
Karma: 37
Posts: 1146
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Logged

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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. 

Code:
SERVO(2) = KNOB(1)

or in more typical parlance, we might write

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

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


Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
« Last Edit: May 22, 2012, 02:40:12 am by scswift » Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 37
Posts: 1146
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 1
Posts: 1283
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Pages: [1] 2   Go Up
Jump to: