SparkFun Forums

[yo1dog]

I have completed a couple projects with the Arduino including a simple kegbot (reading from a flow meter, displaying info on a character based LCD, and hitting a server through eathernet)

Where do I go from here? I want to upgrade my project and move it off of the Arduino.

For my new project I want to do the same things, except that I want to replace the single, character based LCD with 3 separate graphical LCDs. The microcontroller's responsibilities will be:

• Reading input from two flow meters
• Displaying an image to LCD 1, 2, and 3
• POST data to a web server

What would be the best microcontroller for me? How do I get started with said microcontroller?

One of the issues I had with Arduino is the lack of multi-threading. When I sent a request to a server and waited for a response, the UI had to wait as well.

I found this LCD that looks like it will work well for my purposes. What do you think? How do I connect its parallel 24bit interface with the microcontroller?

Don't feel link you have to answer yourself; If you know of some good links, throw them at me!

Thanks,
- Mike

[stevech]

Recommend: Keep same hardware, move to Atmel Studio 6 for AVR. Learn C++, taking off the Arduino training-wheels user interface for development.
Then consider an ARM Cortex M0/M3 module. There are zillions of options. SFE doesn't sell much in ARM micros... so google a bit.

mbed.org is unique: the compiler is on-line, web based. Lots of contributed code.

Some boards
olimex.com and their distributors,
microcontroller pros in Nevada resells a wide variety http://microcontrollershop.com/default. ... th=154_170
and dozens more 'round the net.

You may wish to avoid proprietary sole-source CPUs such as PIC, PIC32, since ARM based chips/boards are price competitive with ye ole 8 bitters, and have dozens of competing vendors, the key ones being NXP (Phillips) and ST Micro.

Or leap to a cheap Linux embedded such as Raspberry Pi (unavailable due to newness/demand), but it's a trend. Hard to add I/O things to Linux though.

[pcrom]

Keep same hardware, move to WINAVR

Concerning your remark of multi-threading, learn yourself howto use state-machines so you can run several tasks in quasi-parallel, also using the arduino language.

A good way to move on from Arduino is imho www.avrfreaks.net

Patrick

[thebecwar]

Instead of multi-threading I'd recommend that you look at interrupt based programming instead.

You will quickly run into all kinds of performance bottlenecks trying to multi-thread on such a small device. Since the processor is physically only capable of attacking a single task at a time, each time you change tasks, you have to move around a lot of data. If your threads switch back and forth a lot, you essentially will spend all your time switching threads and have no time left to actually do anything.

Interrupts function similarly, except they are based on external events. For example, you can interrupt your execution when you receive data, so you don't have to sit and wait all day for it to come in. If you can master interrupts it will make you a better embedded programmer IMHO.

Just my two cents. I'm sure there are others here who will disagree with me.

[viskr]

The display you've chosen requires a raster scan input and 400KB of memory. So you're looking for a micro that has an external memory interface supporting either an SDRAM or simple SRAM, and a built in LCD display controller. Add to that Ethernet, to get a web interface.

In NXP's bag of tricks that would include an LPC178x, LPC18xx or LPC43xx, parts in single quantities around $8-12.

I agree that a Rasberry Pi might be interesting, as they are still hard to obtain, and making changes to access hardware is not for the novice. Its much easier to deal with an interrupt driven software on a simpler ARM.

[stevech]

Instead of multi-threading I'd recommend that you look at interrupt based programming instead.

You will quickly run into all kinds of performance bottlenecks trying to multi-thread on such a small device. Since the processor is physically only capable of attacking a single task at a time, each time you change tasks, you have to move around a lot of data. If your threads switch back and forth a lot, you essentially will spend all your time switching threads and have no time left to actually do anything.

Interrupts function similarly, except they are based on external events. For example, you can interrupt your execution when you receive data, so you don't have to sit and wait all day for it to come in. If you can master interrupts it will make you a better embedded programmer IMHO.

Just my two cents. I'm sure there are others here who will disagree with me.

Agree.

[sfaleron]

Depending on the sophistication of the graphics you're making, I don't see that you really need to bump your hardware up, except to add a memory chip and probably get a surface mount package with more I/O lines. You could also drop the low bits of your color lines (tie to ground, I'd imagine) if you don't really need super color resolution. You really should up your software game, though, as has been pointed out, although I never tried the Arduino environment, so I don't really know its limits.

If you choose to upgrade the microcontroller, you can be more incremental than jumping to a 32 bit quasi-processor. Consider one of the 16-bit XMEGA CPUs from AVR. One big advantage is you get to keep the same AVR-GCC toolchain. I looked at the open source 32 bit toolchain (for the ARM/Maple system), and while it looked very adequate, I decided that AVR-GCC and friends were more mature, thoroughly documented, and had more support options.

There are a bunch of choices for demo/evaluation boards. The one I'm using in a project now is:
http://www.bostonandroid.com/EVAL-USB-256.html

[tincanman]

Since you need an ethernet connection, this might be quite a big move. I know that many NXP LPC chips have ethernet controller onboard (the LPC17xx and LPC18xx definitely do).
Considering the type of LCD you want to drive, then I would say keep on looking at LPC chips, because some of the higher end ones have LCD controllers on board. To drive a color TFT, you are somewhat forced to run a 32 bit microcontroller, or else you can't keep up with the LCD's sync rate.

If I were you, I would keep the project in Arduino form first and do a lot of research on the LPC chips and PCB design (you will most likely be making your own PCB to fullfill your requirements and needs). You can also try out some evaluation boards of the LPC chips, but those are a bit expensive.

[stevech]

or take a leap to Raspberry Pi ($35). Easy to get going. Runs Linux.
Has 1080i video out.
USB keyboard, mouse, ethernet. It's a $35 not real fast PC.

You can hack with it's GPIO, serial ports, etc. Use any of the popular languages, C++, etc.
I've been fiddling with Python scripting on it and a PC and an low end embedded processor. (I can't say I like Python for embedded, but I'll stick with it a while. Kind of like a rock in the shoe right now).

Or mbed is a good one. Lots of high end contributed software. Amazingly, costs more, does less, than the Raspberry Pi.

It's what you're interested in.

If this is as a University student, I might avoid the Raspberry Pi (not so good on a resume')..

[Joeisi]

I might as well weigh in. I like PICs. I have no clue why. Some PICs with GFX modules can interface that module directly. I'm sure people will start throwing stuff at me for mentioning a PIC, but for that screen, check out this link.

[SFE-Michelle]

I've seen a lot of "keep the hardware, but try this IDE" replies. I say keep both. Learn C++, but you can still run that in the Arduino IDE. One of the main advantages here is that you can still upload over the USB port, not to mention you can code by hand the stuff you want and not worry about the stuff you don't. If the digitalWrite command is working for you but you need to code interrupts by hand then go for it. This also allows you to learn C++ slowly (at your own pace). Also if you are looking to check out the ARM processors check out the new Arduino Due.