Arduino Mega vs Sanguino (Why not adopt Sanguino?)

On Makezine Blog, I saw that Arduino Mega is out.

Question is: a)Why do they decide not to adapte ATMega644/Sanguino as Arduino Mega? b) Even better, why not ATMega1284, the DIP version of 1280? I want to minimize surface-mounted stuff, you know...

ATmega1280 is much better than the ATmega1284 for the Arduino users: - 12 vs 6 PWM - 4 vs 2 USART - 16 vs 8 ADC (Analog In) - 86 vs 32 I/O lines - Available vs Unavailable

I see.

Well, I do hope they make Saguino official eventually.

EDIT: Reason is that Arduino in the end is still clunky for finalization, and Arduino Mega, being SMB, requires higher than hobby skills to allow DIY-finalization.

Yes, I agree. I've purchased a number of Sanguinos and made a few "standalones" as well and they work really well. The extra I/O pins are very useful.

In general, we've left kits to other people / companies. Not because they're not useful (they are!), but because they're not as conducive to the centralized manufacturing that we use for the official products. It's also nice to have other people creating products and brands of their own.

I would like to see the Sanguino and the Illuminato standardized. It would be really neat to see all various processor/boards in the dropdown. The more the merrier ;D

It is very to get the boards standardized. Just called them Arduino Sanguino, or Arduino illuminato and pay the Arduino foundation the royalty. This is what Sparkfun does.

One requirement is that you cannot just clone a Duemilanove and try to make it a standard. It should show some unique characteristic, like lilypad Arduino. In my opinion the Illuminato deserves to be standardized, as it fits nicely between a Duemilanove and the MEGA. And the design is awesome!

What I mean is that I just wish Arduino would include those (especially Sanguino) in the Arduino IDE, just like they included stuff from Adafruit. Especially support for 644, 324, and 164, and possibly 1284 when it comes out enmass.

Just the software end, make it "official".

I think for the software to support a board officially, it needs to be "certified", which means named Arduino and pay the loyalty. That is the only way I know...

Technically it is possible, bottom line everything are bits and atoms... but it is more complex than that... http://arduino.cc/en/Main/Policy

I am not taking any side... just giving the facts (I may be wrong, I am human after all).

nkcelectronics: I guess you were talking about "royalties" not "loyalties".

Jestersage: You can add new boards easily. Just go to Arduino directory, hardware subdirectory, edit boards.txt add whatever you need.

I also think that Arduino core team should consider user needs and add the most common available boards into the development environment. Sanguino people should send to Arduino team the entries required by boards.txt.

@jcgalvezv, I mean both, royalty and loyalty (you need to bow every morning pointing towards Europe, where the Arduino Team is... and maybe NY and Boston area as well) ;-)

Thanks for pointing my mistake.

You can add new boards easily. Just go to Arduino directory, hardware subdirectory, edit boards.txt add whatever you need.

That only handles the options for the upload command. Supporting a new CPU like Sanguino would also require editing the main wiring library source code.

westfw is right. A lot of people confuse the boards.txt settings with supporting a new microcontroller. As the sanguino, illuminato and other custom boards requiere modifications to the core library, the buyers are either tied to new releases by the same board manufacturer, or maintaining their own versions of Arduino, which makes them live in isolation when trying to get help from the community. I think it is a high price to pay if you are not experienced enough, and my estimate is that 80% of Arduino users are at the basic level (The Long Tail).

Maybe this is the time to jump in and ask if anyone would be willing to offer a brief (if that's possible) explanation of how one can learn the core differences between the various ATmega chips. With the announcement of the Arduino Mega, I compiled a table of ATmega chip specs in an effort to see what ATmega options there all are. Now I'm curious what it takes to put an Arduino supported bootloader on any one of them.

For example, what did the RepRap guys have to do to turn the ATmega644P into the Sanguino.

Or, on Atmel's product card for the ATmega168P, they list the 48PA, 88PA, and 328P so that makes me suspect they have a similar core. Did that make it easier for the Arduino guys to support the 328P? I'm not talking about the IO and memory specs, maybe I mean the necessary bootloader and fuse modifications.

Thanks.

A good place to start is at http://www.avrfreaks.net On their "devices" page they have nice one-page summaries, frequently including "Crossrelation" info (for instance, the Atmega168 page says "pin and feature compatible with mega48, more memory.") There is also a "compare devices" tab that will let you add and subtract features and/or devices and display a table of matching CPUs and features.

AVRFreaks is a little out of date (no ATmega328 yet, for instance), and the information is gathered by volunteers and is somewhat uneven (for instance, ATmega168 crossrelations don't mention ATmega8 or ATmega88, even though the devices are "current" WRT the table.

I'd like to make it easier for users to add support for third-party boards to their copy of the software, but haven't had time to implement this yet. We've discussed it on the developers list, but didn't get too far. Anyone interested in working on this should email the developers list with a proposal.

Creating a complete add-on package for a 3rd party board is quite a challenge, especially if your board uses substantially different approach than a serial port (or dedicated USB-serial converter). I've done this and I'm going to take a little time to write about it...

But first, at the risk of gratuitous self promotion, here's a link to my effort, which is still very much in the beta testing stage. You can install this and look at the code if you like.

http://www.pjrc.com/teensy/teensyduino.html

The first relatively easy step is to make a new entry in the boards.txt file, and make a copy of the core. If your chip is similar to a mega168, you're probably pretty close. In recent Arduino (0014 and maybe 0013, but definitely not 0012), the #ifdefs in the code changed to assume the '168 register names by default (0012 and earlier defaulted to the mega8 names for unknown chips). Most newer chips follow the '168 naming conventions.

The file that probably requires the most editing is pins_arduino.c, which defines which registers and bits within those registers are mapped to which pin numbers. Fortunately, it's all in tables that are pretty easy to edit, and there's even comments in the code to help.

Your next major hackery will be in wiring_analog.c, within the analogWrite() function. If you have anything other than the same 6 PWM, this needs to be changed so analogWrite() works.

If your board uses something other than the normal serial port, as the Teensy does, then you have a LOT of work ahead. You'll need to implement the 5 function serial API (begin, write, available, read, flush) in C, and then add a C++ Serial class that derives from the Print class. If you install Teensyduino, look for usb_serial.c and USBserial.cpp for how I did these.

If you use AVRDUDE to program your board, and your chip is a "mega" part name, you'll probably be spared a lot of pain. If your chip is not a "mega", there is some sloppy code that mangles the name. This bug has been discussed on the developer list before.

If you don't use AVRDUDE (as is the case with Teensy), then you've got some hacking to do. I wanted to minimize disruption to the Arduino code and avoid any chance of breaking existing Arduino boards (so messing with AVRDUDE was out of the question), so I created a tiny patch which lets the boards.txt specify a different program to run instead of AVRDUDE. I submitted this patch, but sadly after much discussion it was rejected, but perhaps someday it may be reconsidered?

If you completely branch/fork the code and remove support for the Arduino, you can just replace AVRDUDE with whatever you want. In hindsight, that probably would have been a LOT easier.

After you've got a working core and you can load your sketches onto your board, then you're probably ready to think about libraries. This is roughly where I am at now, and Teensyduino 0.4 will start adding tweaks to library files.

Fortunately, most of the libraries are very portable and depend only on the core. The Servo library is the notable exception. If you get this far, please do contact me directly, paul@pjrc.com so we can coordinate library changes in compatible ways.

There was talk on the developer list within the last 24 hours are per-board library options, but it's not clear if that will ever happen, or even if the advantages outweigh the long-term problem of maintaining multiple copies of the same code. If that is done, my hope is it could be a patch-style system rather than completely separate copies, since most libraries work as-is.

If your core adds any special features or functions, you'll probably want the syntax highlighting to work nicely, after the initial euphoria of it simply working at all starts to wear off. Unfortunately, there is no per-core mechanism to add keywords (only per-library and one global keywords.txt) Any keywords you add will highlight when other boards/cores are selected, but that's not so terrible.

If your board differs from the Arduino substantially, documentation probably needs to be written. This is an area where my efforts are sorely lacking, and I intend to improve upon soon. It's also amazing how much work it can be.

Long term, the more you do, the more code you'll be maintaining separately from the main Arduino. For example, the micros() function was recently added, and if you've made a core based on 0012 or earlier, you'll have to add it to keep compatibility with newer sketches that might use it.

Some changes are more difficult to track than merely adding a new function. For example, 0012 added the Print base class (rather than including the code inside Serial) and libraries were modified to use it. This is the first example of the core being required to implement a class that's inherited by libraries and possibly other code in the future. Perhaps other libraries will in the future depend on base classes from the cores (such as a flash memory abstraction that's recently been proposed on the developer list).

One other area, where I have not explored yet (but intend to try) is supporting non-serial communication. Everything I've written so far assumes you are still using a serial port or dedicated USB-serial converter. As soon as you step off the tried-and-true path of a serial port, things become very painful (even just a serial device that re-enumerates on the USB). So far I've managed to make my "run something else other than AVRDUDE" tweak work without completely branching the code... but alternate communication is going to be more difficult. I don't have much hope the Arduino project will ever accept such a dramatic patch (a very unintrusive patch to optionally run a different program than AVRDUDE wasn't even accepted).... but if you, dear reader who's endured this far-too-long message, are interested in non-serial communication, do contact me by email.

Teensyduino, as of 0.3 is starting to work pretty well and 0.4 will be out very soon. If you're moving to more substantially different (but still AVR) chip, Teensyduino probably has some code in there you'll want to see. If you're making a core closer to the standard Arduino, the Sanguino core and original Arduino core are probably the code you want read.

being SMB, requires higher than hobby skills to allow DIY-finalization

I used to be intimidated by the idea of working with surface-mount components. Having just finished my very first SMD board, I have to say it really isn't as hard as it seems, if your board is silver-tinned and has a soldermask. (This is the default of most of the PCB printing houses I've seen.) It does make it harder to prototype, but there are a lot of generic SOIC breakout boards that can help you in the prototyping stage.)

If you're working with things with more than 30 pins, I'd say DIP is for the dinosaurs. And besides, they're usually a bit cheaper. I just bought several hundred basic SMD components from Digikey for some pocket-change!

Posted by westfw:

That only handles the options for the upload command. Supporting a new CPU like Sanguino would also require editing the main wiring library source code.

. You are right. But I assumed that the Sanguino team already did the core porting and the only missing feature was the possibility to upload the compiled sketch to the board using Arduino's development environment.

I assumed that the Sanguino team already did the core porting ...

They did it, but it has not become part of the Arduino "standard" distribution. That means that when you upgrade from Arduino12 to 14 (or whatever), you have to re-install the Sanguino patches.

Worse is that this means that changes in the Ardunio core don't "automatically" happen for Sanguino, even if they are not inherently CPU-specific. You'd got to apply the Sanguino patches to the Arduino code, and it wouldn't work, unless the Sanguino folks are very much paying attention. (Still worse would be the case that the patch would apply, but result in code that operated incorrectly on both Arduino and Sanguino.) And then there's the possibility of having XXXuino and YYYunino patches that are mutually incompatible :-(

(This is the sort of thing that makes ARM difficult to use (IMO.) Sure, ARM is supported by gcc. But if you want to support Luminary Cortex M3 cpus, you'll need the version X compiler from CodeSorcery, and if you want the NXP cortex M0 code you'll need their patches which are to a different base version, and this version of windows supports THAT download tool but not the other download tool, and ... AARRRGGHH. want Armuino! Sigh. (It might not be quite as bad as all that in reality. But it LOOKS that bad...))