Linux porting
 

I used linux and done many programs in c and c++. But now i want to do progam for microcontrollers and test it on harware. I also want to write driver for RS232,PWM,USB etc. So how i start. Which board is best for ARM micontroller.

Linraj

Try a Beagleboard.

http://beagleboard.org/

http://code.google.com/p/beagleboard/

They have schematics available because it's a hobbyist board intended to give you ideas on how to design your own board using the ARM. There's a good amount of code written to run on them to get you started too.

To go further, you could look into Microchip PIC micro-controllers if your question was instead not for Linux but general micro-controller programming. There are other manufacturers with other varieties:

Freescale, Atmel, Intel 8051, Texas Instruments MSP430; all varieties of micro-controllers where you can grab a generic development board and play with the board for purposes of programming peripherals.

I'd suggest grabbing a development board which has I2C or SPI (or both) types of peripherals so that you can experiment with those as well as RS232, and some GPIO pins where you can hook up LEDS. Likely there are some LEDS already on that type of a board.

Linux generally requires more CPU than a traditional microcontroller has (unlees we've started calling things like ARMs microcontrollers). Linux definitely requires a Memory Management Unit (MMU), and while I haven't played with microcontrollers for a few years, there was never an MMU on any that I knew of.
It is quite possible to use Linux as a development platform for microcontroller target hardware. I don't know of any particular cross development systems, but I know they're out there. Some might be feeware.
--- rod.

The ARM Cortex-M3 processor is what most people would call a micro controller. But those chips come normally with flash and ram memory in kbyte ranges, which is really not enough to run an operating system like linux.
There are several boards out there. Look for 'arm maple board' or 'arduino due arm' on google.
If the OP really wants to run linux on an ARM then he should look for the beagleboard as rtmistler mentioned or the raspberryPI. Just google for them.

@theNbombr I use my linux machine to develop for avr microcontrollers. :) works perfect with avr-gcc.

Thanks rtmistler,gdejonge,theNbomr. I think now i got good link to start.

@ rtmistler their are three boards which one should buy. I new to this but i wanna buy board which i can use in future also, i mean i want to buy advance board. Please suggest me.

Been away for the holidays, just saw your follow up question.

I guess it really depends on what you wish to accomplish. As others have mentioned, ARM processors are not always considered to be micro-controllers that's why I added information about Microchip, ATMEL, and such.

Sounds like you wish to play with a board that is simple, has peripherals and allows you to add more stuff. I didn't evaluate more than one board and just got the BeagleBoard. However the main reason was to prove that we could run our Linux based applications on an ARM so that our hardware team could then design a board for our product; based on the ARM. The xM board has more stuff on it and in fact has a header to interface for I2C and SPI; it also has Ethernet on the board. You can add Ethernet to the regular BeagleBoard, but if you wish to have it already there and want to experiment with the driver, you're better off with the xM. Not totally sure, but I think the microSD card uses SPI so that at least is one item on the board that uses that type of interface.

You don't have to run Linux on the board, micro-controller programming typically is a main loop coupled with one or more interrupts. As I've said, it really depends on what you were looking to concentrate on.

Playing with Linux on the ARM and experimenting with drivers, I'd recommend the BeagleBoard-xM and starting with their Angstrom distribution.

If you're interested instead with programming for a micro-controller I'd recommend something like the pic24 devkit:

http://<br /> http://www.microchip....en535092<br />

Where you get their tools, a board and debugger capability for about $60. Then you can play with the various things on the board like capacitive touch, flash drive, RTC, PWM, and ADC.

Thanks @ rtmistler, you caught me right i already used GUI development kit and already familiar with PIC, AVR , MSP430, ARM7 and done lots of development But thing is that Linux is free so can i do all things which is had done in GUI like keil , MPLAB, AVRStudio etc.

I mean can i program ARM7(like LPC2194) or 32 bit micro controllers (PIC24 etc.) using Linux environment. I am very new to LINUX. till now just done shell programming in c and c++.

You can for ARM like I've described with something like the BeagleBoard. For a specific ARM processor, it's a matter of searching for a distribution or trying one that doesn't require MMU on the processor you've chosen. I'd recommend first using something that someone has already resolved so that you can understand how the kernel was configured and the HAL was done. Also important is the boot loader where the chip and environment are set up in advance for the kernel to load and utilize that specific processor's resources.

PIC, no. If there is one I suspect it's very limited and not really Linux with most of the capabilities, instead just that someone got it working to a degree so that they could say, "I did it!".

I'd recommend two things.

(1) Program for real in Linux on a current full blown machine, running Linux. You can attach all kinds of stuff via the USB or serial ports, or USB-Serial. You can attach a camera, a game controller, an IR detector; just something which can give you input via USB or serial where you can write a program to attach to that port and grab the data. Here what you want to learn are two things (a) how to interface with Linux resources (b) how to architect under the Linux system services.

I'm not sure there's any specific guide unless someone reading this knows of good references. Probably opinion based too.

My example is that I program a lot in Linux utilizing numerous serial devices. The architectures we use are Linux core computer running a GUI which is driven by one of the various vendors; such as Qt, under which there are various sensors performing real time data collection, but sending either raw or filtered data via serial connections to my Linux core. Linux processes grab that data and communicate via pipe(2). Since there are some cross communications; such as the top GUI needing to send commands down to the other processes, and also those processes always sending data upwards to the GUI, I've developed architectures using fork(2) and execvp(2) so that the pipes are known to each other. Then I use select(2) and recv(2) to determine if there is new data and process it accordingly.

That's a little disorganized, sorry. Summary is: On boot up, I create a daemon, here's a good example.

http://<br /> http://www.netzmafia....wto.html<br />

Of course I extend that because things like exiting or other things are not conducive to an embedded system; i.e. we have speakers, LEDs etc to indicate critical failure, or we retry and retry indicating we are in a phase of booting until we can either succeed or the user has to attach a serial terminal and debug the problem.

Next from that daemon I create common resources, for instance my pipe(2) mechanisms for communications to/from each process I plan to use. I've developed a function to fork() and exec() my child processes. And because the daemon created these processes, it has their pid's and therefore can wait on signals from them and determine if they were killed or exited in error. And then the daemon can then re-spawn a failed process or indicate critical error. But that's all the daemon does, gets it going and then monitors and either attempts recovery or indicates failure. Remember that this is for an embedded system, not really a keyboard or monitor, but instead lights and limited push buttons; like a Coke machine or something, right?

The next step is that each process does something specific; for instance one talks to accelerometers, another talks to an environmental sensor, another one talks to a metal detector maybe. So to extend the Coke machine thought example, acceleration is whether or not some idiot is trying to bang the machine over and maybe that process indicates danger to the idiot that a thousand pound machine may fall on top of them. The environmental sensor detects whether or not refrigeration is working properly, and metal detector detects coins inserted. Each process may inject information to the GUI to tell the user what's happening. I.e. You inserted 5 cents, I got it, but that's not enough yet to make a selection; touch REFUND or insert more coins ... That information was conveyed via one process sending to another, which I use pipes for; however there are a variety of IPC mechanisms in Linux, see:

http://<br /> http://www.tldp.org/L...de7.html<br />

And you can choose how to communicate between two processes in a manner which best suits you.

You may wish to read that whole reference, it talks a lot about Linux in general:

http://<br /> http://www.tldp.org/L...de1.html<br />

Further, because it's embedded there may be a serial port or some way for the administrator/owners to communicate; which isn't available to a normal user. We keep logs on the system so when someone attaches via networking or a terminal, they'll be able to obtain those logs and diagnose.

The second recommendation is to then explore customizing distributions where you cut down the kernel and services that are included in the boot so that you have a minimal version; running what you want, but not running extras that are not needed. For instance, if you're an embedded device with a custom display, you may not need an XServer at all, you may not need CUPS (printer driver), you may not even need any network stacks if you are solely communicating via serial to a device, although most things usually use networking or wireless to interface these days.

So if coming up to speed more on how you can use Linux user programming to accomplish things like talking to peripherals and such, there are some thoughts. I'm not really a kernel person, I do what I need to get things accomplished on that front and the most I've done is customized an existing driver to add more features to it. But reading up on Linux drivers is good too:


http://lwn.net/Kernel/LDD3/