views:

75

answers:

5

Hey guys

Im planning to use Intel atom on a board for an embedded system. The embedded system will be running programs written in C for image processing. Since its an embedded system footprint is obviously a concern. I was thinking about using a modified version of the linux kernel. Any other options??

A: 

I don't know how much memory you have, but Windows CE might be another choice. Going this route lets you stay with Windows tools (if you like those) There is also a Micro edition of the .NET framework available for use on Windows CE

samoz
windows CE has a GUI etc.. I dont need all that. That stuff will just waste space. All i need is a kernel that will run a program. There will be now software based interface to the user
Ram Bhat
@Ram: with the same argument you can't use Linux either, because there is a GUI for it. As far as I know you can use many different configurations of Windows CE (or whatever their embedded system is called at the moment), with or without a GUI.
Joachim Sauer
I wasnt going for a linux distro.. Just the kernel should be sufficient for me.. Probably a shell initially to test..
Ram Bhat
+2  A: 

Hey,

I've written my own O/S for embedded systems so I'm not too sure. But one project I've been wanting to try is uCLinux. Though that might not be enough for what you want to do. If you have more ressources you might want PuppyLinux or Damn Small Linux. They all should have a C compiler which will suit your need.

Hope this helps!

p.s. since I'm a new user, I can only post one hyperlink, you'll have to google the other two, sorry!

w3b_wizzard
Cool.. About the O/S you wrote yourself.. What platform was this for? How much development effort did this take?
Ram Bhat
It's more for firmware than anything else. I've written everything from scratch in x86 assembly (for the Intel 8088 uP). And built myself a set of libraries. I've just recently built myself a network library where I wrote my own TCP/IP Stack for which I used for a networked controlled coffee machine (Computer Eng. final project ;) ). So you won't find much use of my stuff as it's all 8-bit instructions.
w3b_wizzard
A: 

It depends what services you need form your OS. The smallest footprint will be achieved by using a simple RTOS kernel such as uC/OS-II or FreeRTOS; however support for devices and filesystems etc will be entirely down to you or third-party libraries with associated integration issues. Also the simpler kernels do not utilise the MMU to provide protection between tasks and the kernel - typically everything runs as a single multithreaded application.

Broader and more comprehensive hardware support can be provided by 'heavyweights' such as Linux or Windows Embedded.

A middle ground can probably be achieved with a more fully featured RTOS such eCOS, VxWorks, Neucleus, or QNX Neutrino. QNX is especially strong on MMU support.

Clifford
A: 

"Image processing" in an embedded box almost always means real-time image processing. Your number one concerns are going to be maximizing data throughput and minimizing latency processing overhead.

My personal prejudice, from having done real-time image processing (staring focal plane array FLIR nonuniformity compensation and target tracking) for a living, is that using an Intel x86-ANYTHING for real-time embedded image processing is a horrible mistake.

However, assuming that your employer has crammed that board down your throat, and you aren't willing to quit over their insistence on screwing up, my first recommendation would be QNX, and my second choice would be VxWorks. I might consider uCOS.

Because of the low-overhead, low-latency requirements inherent in moving massive numbers of pixels through a system, I would not consider ANYTHING from Microsoft, and I would put any Linux at a distant third or fourth place, behind QNX, VxWorks, and uCOS.

John R. Strohm
Why is Intel x86 so bad for this task and what is the alternative chip? You weren't clear on alternatives or reasons, only that it's a poor choice.
Karl
First, real-time image processing involves moving LARGE amounts of data. Consider a 640x480 sensor running at 60 frames per second. The raw input stream is 18.43 million pixels per second. Given that you are almost certainly going to need a real-time image output, double that to almost 37 million pixels per second. You are going to have to do something to every single pixel. The x86 architecture runs a large number of clocks per instruction, and takes a lot of instructions to do anything, because of the register shortage, so you very quickly run out of horsepower.
John R. Strohm
Basically, you want a fast integer DSP. Ideally, you want a fast integer DSP with multiple cores, a REALLY flexible DMA engine, and multiple data paths off the chip. The Texas Instruments 320C80 met two of the three, but only had one data bus (and it was a bottleneck). The IBM Cell looked good, but I haven't programmed it in a real application and I can't really say. Analog Devices and Freescale make lots of DSP chips.
John R. Strohm
A: 

If you are needing to do real-time image processing, then you will likely want to use a Real-Time Operating System. If that is the route you want to take, I would recommend trying out QNX. I (personally) find that QNX has a nice balance of available features and low overhead. I have not used VxWorks personally, but I have heard some good things about it as well.

If you do not need Real-Time capabilities, then I would suggest starting with a Linux platform. You will have much better luck stripping it down to meet your hardware limitations than you would a Windows OS.

The biggest factor you should consider is not your CPU, but the rest of the hardware on your board. You will want to make sure that whatever OS you choose has drivers available for all of your hardware (unless you are planning on writing your own drivers), and embedded boards can often have uncommon or specialized chipsets that don't yet have open-source drivers available. Driver availability alone might make your decision for you.

bta