I would like to learn to program a LCD/ LCD controller so that i can create an embedded system in the near furture. I would like to know any reccomandations to startup. with Any links, books, etc........

And also, are there some comipler / simulation IDE freeware?
An example i could think of is MPLab from Microchip.com But i don't think they have LCD simulation.

The first step is to figure out what platform you will be working with. Is the microcontroller that you are programming directly controlling the LCD? Or is there a general purpose microcontroller that writes to an LCD controller device?

If you are lucky, you can use an Atmel AVR microcontroller, because it's the only one supported by http://gcc.gnu.org/. I did a project using the ATmega88 that wrote data to a separate LCD controller. I compiled GCC as cross compiler that ran on GNU/Linux (but you can use Windows if you must), and generated code for the AVR.

If you're not so lucky, you may still be able to use http://sdcc.sf.net/, which is a free (as in freedom) compiler supports several microcontrollers.

GCC supports hundreds of microcontrollers, if not thousands. Let's see:

Renesas H8 (perhaps 400 variants?)
Renesas M16 (perhaps 200 variants?)
Renesas SuperH (perhaps 200 variants?)
Freescale ColdFire (perhaps 40 variants?)
ARM (several different manufacturers and core varieties)
TI BlackFin
MIPS (several different manufacturers and core varieties)

...and, of course, AVR is also supported along with several others that are sometimes used in embedded systems, but are traditionally considered to be microprocessors rather than microcontrollers such as x86, PowerPC, Alpha, etc.

For someone interested in simulation, one need go only as far as GDB, which has a simulator for a number of the micros it supports.

Once you build gdb for the target, you need only to look in the sim directory to see if a simulator exists for it. Then, you can invoke your application using the simulator.


:davis:

Well if you call the CRAY supercomputer a microcontroller, then every processor GCC supports is a microcontroller!

I'm only vaguely familiar with the H8 and I didn't realize it was supported. That will be good news if I ever get to work with it.

But calling the ARM, MIPS and BlackFin microcontrollers stretches the the definition. If they are microcontrollers, then we need a new word for little, low-power processors that contain all their own memory and peripherals and require no (or little) glue logic to implement a tiny system or the tiny logic part of a larger product. I didn't mean to start a semantics and definitions war here, but I suppose one will have to ensue.

Actually, since ahbi82 referenced Microchip, I suspect he meant a microcontroller like the PIC16F914 (a true microcontroller) that directly controls an LCD with onboard hardware. Unfortunately, GCC doesn't support that, and surely never will.

Not a semantics or definitions "war," but perhaps you will realize that even your previously stated Atmel manufacturers ARM microcontrollers.

www.atmel.com

Considering that there are also plenty of MIPS microcontrollers such as:

www.semicon.toshiba.co.jp

Your notion of what stretches the definition is as absurd as your original statement regarding AVR being the only microcontroller supported by GCC.

If you want to consider why the PICs are not likely to be supported by GCC, consider also that C tends to be less favored among PIC programmers due to the relative constraints of most of the varieties of PIC parts. Only a relatively few PICs have enough memory resources to adequately support a full-blown C-based embedded application, compared to the billions of PICs sold in the 256 bytes of code space varieties. With 256 bytes, you don't even have space for a minimalist C runtime. Its not hard to see why GCC might not be eagerly adopted by that crowd.

Of course, the trend in all microcontrollers are smaller, faster, more resources and even lower power.

Considering that every BlackFin (Analog Devices, not Ti as I previously stated) has embedded SRAM on-chip, it is not a huge stretch to place them in a location between microcontroller and general purpose processor, particularly when one considers that they are more specific-purpose even if power requirements far exceed normal expectations for the word microcontroller. Microcontroller is not just about physical size, since there are PIC DIPs that consume well over three of a ColdFire 5211 64p footprint.

However, about the only remaining distinction between microcontroller versus microprocessor is whether or not the part is able to address external memory, but millions of H8s sold are able to address external memory, so even that distinction is blurred. And, the distinction regarding performance is clearly in question when one considers that the 80MHz ColdFire operates at upwards of 75+ MIPS...all with absolutely no addressable memory, unless you consider GPIO to be addressable memory. It even has an on-chip oscillator. Talk about little or no glue logic!

So, when you get your head out of it and stop saying things like if I call the Cray a microcontroller...

...maybe you'll also note that GCC supports Z80, I don't suppose that you'd consider it to be a microcontroller when it was widely used as a general purpose microprocessor in the late 70s through much of the 80s. Considering that Zilog's business includes the Z8 in an 8-pin! package, you'd be hard-pressed to consider it in any category other than microcontroller.

I guess that the summary of all of this is that if someone needs to know what microcontrollers are supported by GCC, ask anyone BUT you.


:davis:

What kind of LCD do you want to use in your embedded system? Are you looking for a simple 4 or 5 digit display, a character display or do you want something more robust, like a graphical display that you can use for complex drawing?

The first book that I recommend for those who are newcomers to embedded systems is:

An Embedded Software Primer
by David E. Simon
ISBN: 978-0201615692

While it doesn't really discuss LCD controllers, it does fully discuss all of the basics of embedded systems that you will first need in order to get started.

If you want to output to a simple character display, there are two basic types that tend to be most common. The first is based on a parallel interface and requires wiring to a system that is able to assert data on typically 4 or 8 data pins and two or three control pins. This can often be handled using GPIO (General Purpose Input/Output) pins on your micro. The second is a serial based display that typically connects to a serial port on your device. These are usually much more expensive, but have the added benefit of being able to be used from any PC with a serial port. They also tend to be a bit slower, but this isn't often an issue since they are plenty fast enough to keep up with the amount of data that they are able to display at one time.

You probably need to realize that LCD devices tend to be very slow. One of the more common mistakes made by those first discovering them is that they try to write data too quickly to the device. Pay close attention to the timing specification of your display choice.

If you are looking for a fun, embedded system to experiment with, I have numerous boards that I've done over the years. If you are in a country where I am able to send one, I don't mind sending you one for free. Reply with the country where you live and if I can send one to you, I'll let you know so that then you can send me a PM with your mailing address.

It will also help to better understand what you're looking for from your embedded system. Like, what features do you need to support? What things do you want it to be able to do for you?

Is this for a school project? If so, for which area of study? Electrical/electronics engineering or more towards the software side?

What are your needs for being able to manufacture the design, if that is an objective of yours? For example, if you're limited to home-made PCBs, then through-hole is probably a better choice for you, along with probably a relatively few number of signals compared to traditional surface mount methods.

What form-factor do you envision for your product? How small must it be physically?

What are its power requirements?

...all of these and plenty more must be taken into consideration. For example, do you want to program the device using mostly C or are you comfortable using or learning assembly language programming for the particular part?

What development environment do you want to use? Are you a Windoze slave, or have you emerged into the light of Linux yet?

Are you just looking for a software-simulation or do you want to get down and dirty with the hardware? It sounds as if you want to build an embedded system.


:davis: