I looked in the Arduino IDE and there is no 'board' called "Due" in there yet. Do they supply the new board files with the Due itself somehow or as a download? I'd like to be able to use the IDE to program the Due if i decide to get one.
Thanks for the link. I checked it out, and it turns out that the IDE can be used for the Due too with that new software download. It includes not only a new 'board' file but a lot of other stuff including a new compiler for the ARM chip on the Due board. So it does not use AVRDude for that board.
I just did the "Hello World" program under Linux. I ran basically did 3 things 1) Get the IDE to respond/compile, 2) downloaded and ran a blinking LED program and 3) Ran a program that printed the ASCII table in a "terminal window" That was a tough problem in itself.
I also got 3 blank shields. It's a 3v3 V part with no 5V compatibility.
The interrupt architecture is strange. The IDE for the Due is different because it uses a different USB to serial internally. It currently requires JAVA Run-time and might require the 32 bit compatibility libraries to make the IDE run.
That's interesting, i knew about the 3.3v issue though and i didnt like that a whole lot because i like to use 5v for everything, but i suppose i could put up with it if i have to. Would probably require some 3.3 to 5v level translators though. I guess that means that EVERY pin can only do 3.3v too though, that could be a problem if working with 5v stuff because we'd need a translator (ic or whatever) for every pin.
The overall computing power and speed of the device would be a big step up though.
There is 5 and 3.3 on the board though. Yep, that's what they are saying is that the 3.3 inputs are NOT 5V compatible. I haven't seen any mention of current limiting resistors and I haven't read the processor datasheet that closely. Reference: https://arduino.cc/en/Main/arduinoBoardDue
Too bad, thiis guy **broken link removed** didn't go ahead with the Due look-a-like the Toucan. They definitely came up with some interesting ideas.
Mr Al:
I'm curious as to what you think about the interrupt structure and programming for the Due? It seems to be port based and probably difficult to manage.
Unless I'm mistaken, the "Due" IS short for Duemilanove... (whatever that is?? A google search brings up nothing but Arduino stuff. Maybe some sort of Italian word for "Two Milan Eggs" - or something...).
Unless I'm mistaken, the "Due" IS short for Duemilanove... (whatever that is?? A google search brings up nothing but Arduino stuff. Maybe some sort of Italian word for "Two Milan Eggs" - or something...).
Too bad, thiis guy **broken link removed** didn't go ahead with the Due look-a-like the Toucan. They definitely came up with some interesting ideas.
Mr Al:
I'm curious as to what you think about the interrupt structure and programming for the Due? It seems to be port based and probably difficult to manage.
Well actually i did not look into that deeply yet because i dont have one yet and not sure when i would get one to play around with. This is interesting though, so you are saying that they dont have built in 'on change' pin interrupts any more?
I assumed it was like other uC's or microprocessors as to the interrupts themselves, but i also figured that it would allow for programmable addresses unlike the low end uC's, but then again i dont know how far they really went with this one.
I'll have to do some more reading i guess.
MisterT:
Yes i think it was a bad choice of names on their part, but then they were never good at choosing names anyway
After reading that passage it sounds like they do not have hardware 'on change' pin interrupts like they do on the 328P chip. So with the 'Due' they only have 'on change' port interrupts, which is harder to handle in code and that means it will take longer to resolve which pin it was that caused the change. I guess one port consists of either 6 or 8 bits, so that means when an int occurs it could be (at least) one of 6 different pins that actually caused it, and so the int routine would have to decide which pin it was.
This seems like a bad idea but then again i have not seen their code yet for resolving the individual pins. It seems to me though that it may be impossible to resolve which pin did it unless this data information is available from the hardware. We cant query the pin itself because it may have changed a second time back to the original state, so hopefully the hardware keeps track of this somehow and we are able to query that information (like some register) rather than the pin itself.
Luckily the' Due' processor is faster, but we'll have to see if this new scheme causes a slow down for the now interpreted on pin change interrupts.