Sure, the latter is a preprogrammed version of the former.

But which would you choose if you were starting from scratch, and needed ~16 GPIO pins?

Neither, Arduino.

Mmm.. harder to use just a standalone chip with Arduino -- they seem to require off-chip resonators and the like. So most likely I'd want a $19 board for each assembly, rather than a $6 chip.

But the board would save a bit of effort soldering, though so would a $4 solderless breadboard..

The programming language for Arduino looks a LOT like the C language, which is a major plus for me (I live in C).

Mmmm...

Arduino is the standardised board with an AVR programmed with a serial bootloader and GCC + their library so it is C. Its not quite as innovative as everybody believes but I guess there weren't really any popular prepackaged solutions before Arduino.

I never really thought of the Arduino as being innovative, and I've never really gotten that impression from other people, either. The thing that everyone seems to love about the Arduino is that it makes it easy, on a platform that's head and shoulders above the only other pre-packaged "easy" solution out there (Basic STAMP).

Easy, and open. What's not to love?

Err.. Picaxe looks pretty darned simple, too. And the chips need only a couple of external resistors as support circuitry.

Cheers

I started out with the PicAXE, but within about a day I came across a massive showstopper (for me anyway). Their serial port read command didn't have a timeout and there was no way to check for bytes available to read. This made it impossible to work in the background and poll for serial commands. They might've fixed this by now, but it was enough for me to move to the Arduino.

While I've not shifted 100's of devices, having to add a 50p resonator to each of them isn't a big deal for me.

There's nothing innovative about the Arduino, it's just that now it's so popular you can find people who've interfaced just about anything to them, and they're usually happy to tell you how they did it.

The newest "X2" picaxes have a *second* serial port, with proper buffering (which can be polled) and the like. But the do-dos didn't mux it onto the original serial pins, so it costs two extra pins to use the better/faster/buffered port. Ugh.

I've just ordered two Arduino Mini Pro (5V) boards from robotshop.ca, just down the motorway from us. They'll arrive here via one-day post, so I can play with them on the weekend.

One thing I need them for, is to drive some character-based LCD displays. I had a look at the stock Arduino library for such, and it has the (very simple) basics. But it uses fixed delays, rather than polling the LCD's busy bit. Duh.. perhaps I'll also now have to get involved.

Cheers

The impression I've gotten from quite a few sites/articles is borderline fanaticism and your project just isn't cool unless you've bolted an Arduino into it somewhere. Just look at Arduino category at Hack a Day site. Even XKCD made fun of it a while back.

There are plenty of forks of the design as well now which vary by voltage, clock, type of AVR, number of headers, shape/size of board and position of ISP header alone so the "standard" isn't quite standard. Most people still don't quite grasp that AVR + serial bootloader = "Arduino" so they'll use the big board when not necessary and waste money + physical space.

Theres nothing wrong with the design and usage of Arduinos and I think its great that more people have found a cheap easy to program microcontroller.

Short answer, neither.

Long answer, I guess it depends exactly on what you're doing....

Personally, I'd have a look at luminary micros range of cortex M3 processors, they don't have anything in DIP, but they do have some 28 pin SOIC members in the family - and they're cheap. (luminary incidentally got purchased by TI a while back)

They're quick (well, they're 32 bit ARMs, so you'd expect that!), there's no more complexity in designing one of these into a circuit than there is a PIC. They use JTAG (or SWD) so your ICD/ICP can be as simple as a soldering a few components and then hanging it off a parallel port, using an FTDI chip or just purchasing a ready built one for next to nothing. You can use all the GNU tools you're already familier with along with openocd.

Their StellarisWare library is just awesome, they've wrapped up all the chip internals into a logical set of API's (on the bigger parts this library is embedded into the ROM) and they also have an amazing USB device and host stack, you get all this for free.

The support is also excellent, they have a forum with lots of their engineers on, if you have a problem they'll get back to you very quickly.

We have just switched from Atmels SAM range of processors to the luminary range because their roadmap is just brilliant, Atmel have stagnated.

Edit:

You could always use something like this to convert the SOIC to a dip.

http://www.sparkfun.com/commerce/product_info.php?products_id=496

It did take a bit to figure that all out -- there's no obvious clear explanation of it at the main site, though I'm sure they must say it somewhere. After reading pages and pages, and datasheets, etc.. it did eventually become clear.

Also, it seems the 328 chip has an onboard resonator, too.. so it will work totally standalone with a 5V supply and nothing else, just like the pic/picaxe stuff!

SparkFun sells the 328 with and without the Arduino bootloader preflashed, for only about $1 difference.

Cheers

Thanks! I had been hoping to hear from you specifically on this stuff.

For now, I've gone with the Atmel 328 + Arduino, because my needs are rather simple. I just want an easy and low-cost way to string some GPIO lines off the end of a serial port, with maybe a teensy bit of smarts in the device.

I'm thinking LCD interface + keypad interface, in a single device. That means 7 GPIO lines for the (text) LCD, and as many as five more for the keypad. Or fewer, if I can get by with using more resistors and less scanning for the keypad.

Cheers!

I'm quite a novice when it comes to this sort of thing, but if I were you, I'd take a look at the Cypress PSoC line. They seem capable and they're super cheap. I don't know exactly what you're doing, but I bet you could get away with using one of their $1.50 chips.

You only need 1 technically. You can bootstrap after that by programming it to be an AVR ISP programmer.

I've got the dev kits for the various PSoC lines here and have used them for quite a few applications. They're fairly flexible in how they're programmed and configured but you have to follow certain restrictions in layout of the special digital/analog blocks. They could do with more RAM really. The C compiler I use with it was a paid license feature. I've no idea about the other one that comes bundled with the development IDE now.

If you're okay with the internal oscillator then you can run one with no external components at all excluding power.

Heh. That's true. I guess I'm thinking mostly of the people I've talked to in person.

If you want easy with absolutely no setup time then I guess you can't really beat the mbed module.

It has loads of interfaces like multiple serial ports, I2C, CAN, multiple SPI, ethernet and the regular analog/digital GPIOs. You "program" it by plugging it into a computer and it appears as a drive. You just copy your compiled code over as a regular file and thats it.

The odd part is that the compiler, IDE and even your source are actually hosted by the mbed website. From what I can tell, it just uses GCC anyway and people have managed to get their own compiler running locally but I'm unsure what they do about the libraries.

The other downside is that the module is fairly expensive and its not very easy to transfer your project into something smaller or less expensive.

mbed was started by two ARM employees and is now actually run by ARM according to their about page.

$64 (mbed) vs. $19 (Arduino), for the chip on a breakout board.

Yup. Not cheap at all. Its easy and has a lot of features though!

Humn, simple requirements....I'd have gone the PIC route, despite having the worst development environment in the world (MPLAB sucks!) that will lead you to pull your hair out, they do have a functional (if very badly written) USB device stack with working CDC implementation, if nothing more you get the ability to use either real RS232 to control your GPIO or a CDC serial port, they even have a reference design which will do exactly what you want.

They have their own C compiler which runs "fully functional" for X months, after which it turns off a few bits and bobs, but the USB reference design still compiles and works perfectly even in the limited mode.

I can't remember what PIC it was that we used on our design, but if you download the microchip USB kit it's the one that they use on the CDC project, the chip is cheap, like a couple of dollars.

Incidentally, we're just finishing off a medical instrument which uses a luminary part, even considering that the chip had a step up in IO from what we'd previously used, we still ended up breaking out the external interface bus and hooking a CPLD up to it, now we have oodles of super fast interrupt driven IO and I also bundled in the logic to control the graphics LCD, the LCD data and instruction registers are just mapped into different memory addresses (twice as the graphics display actually has 2 controllers on it).

Of course, if you didn't baulk at the extra effort of a luminary part (the more advanced ones are QFP's) then you could have your entire development chain in linux, no need to boot into windows for anything...well I say that, stellarisware is provided as a windows installer...maybe I should comment to TI about that.

Well, with the Arduinos, at least, everything happens in Linux (and java). For serial/USB, I'm happy to just stick with the FTDI 232R. More expensive than having the micro do it all, but simple enough that it works for me.

The postman should be here shortly with the two Arduinos.

Did I mention that you have the best job in the world?

That was going to be my other suggestion, something using a FT2** device, at least you know it's going to have solid communications.

Be sure to let us see your invention, whatever it may be!

And yeah, I love my job!

Yup, finally bit the bullet and discovered how easy Arduino stuff really is.
Then wasted 4+ hours finding a bug in the Arduino system software and working around it.
Still, it's simpler than I expected it all to be. The project is still a work in progress, as described here.

Cheers

Fascinating. Post back when you successfully flash your first modem.

Stick it to the man!

Cool.

I was going to suggest that a cypress FX2 would get you much faster transfers, but then I realised that it doesn't natively support SPI, so no hardware assistance, you'd be back to bit banging. Shame, because you can get ridiculous transfer rates out of those chips.

Adrian

Note that I'm not trying to "hack" my modem or anything, but rather just filling in for lack of support from our ISP. The 02.08 firmware on these modems stops working as the cable system is upgraded. The 02.16 firmware fixes that, but the ISP won't upgrade our modems. So I'm trying to fill that hole and save them from the real-life landfill.

I'm also hoping that this experience will come in useful for future projects that are less demanding on transfer rates.

The all-in-one "Pro Micro" (aka. mini-Leonardo) boards are super tiny, and the built-in USB (including a HID profile) makes connectivity really simple. I have lots of use for something like that!

Faster transfers would be nice though. I'm maxing this one out at about 10-11KBytes/sec from the board to the host over USB. That's about 1/100th the wire speed. Can blame some of that on the SPI delays, but not most of it.

On a related note, anyone know how I might go about updating/editing the USB/serial code to include the bug fix that's currently killing performance in the other direction? I have the fix, just not entirely sure (yet) how to use it.

http://code.google.com/p/arduino/issues/detail?id=998

Thanks.

Okay, apparently I can just create my own "hardware" hierarchy inside ~/sketchbook/ and modify files like CDC.cpp as I please from within there.

So I've done that, and simply hacked CDC.cpp to use 520 byte serial buffers instead of 64 byte buffers. This cuts my firmware download time by half. It now takes 8 minutes 53 seconds to transfer the 2MB image to the Arduino. Much better!

For the SPI work, have you looked at the Bus Pirate? I've been using it to talk to i2c and 1-wire devices. http://dangerousprototypes.com/docs/Bus_Pirate

Not really. The Arduino groks both protocols, and is pretty easy to interface to hardware and a host computer. So I'm happy, for now.

Edit: Wow, just had a look at the feature list for that gizmo. Looks like somthing Adrian probably has on his workbench!

Handy device. I'll keep it in mind, thanks!

All sorted, flashed, and appears to be working.

The erase/program code worked first time around on both sides (Arduino and Host-PC), but lots of time in the middle was spent working out how to get round the receive bug in the Arduino USB code. A simple brute-force "bigger buffer" solved it sufficiently for this project.

Cheers