Embedded linux benchmark

Is there any special requirements _from_ the project that a heavy operating system such as Linux is needed (e.g. complex graphical interface, support for PC style peripherals such keyboards, USB, Ethernet etc. ?

Or is the only reason for choosing some kind of embedded linux that someone in the project group is familiar with Linux ?

If the project does not really need such heavy OS, look for some small RTOS or possibly implement the project without an OS at all. In most cases a much smaller and cheaper hardware can be used. This is especially important if a large number of products is expected to be sold.

However, if the volumes are low, say in dozens, just get a big enough x86 motherboard and load standard Linux on it, the total costs will be less, than trying to shoehorn a big OS into a small hardware.

Some kind of embedded Linux is justifiable in production volumes somewhere in between.

Paul

Paul Keinanen [2006-10-31 07:08]:

Thanks for your comments, Paul. Our requirements:

1) Hi speed communication to/from an FPGA 2) Heavvy use of TCP/IP and Ethernet stack 3) Hi speed processing of messages coming from FPGA 4) Use of SNMP (optional, for now) 5) Remote software upgrade via TCP/IP. 6) Remote control and remote logging via TCP/IP.

I'm not so familiar with Linux. I only use Linux on my notebook :-)

Ok, without thinking about prices, volumes and so on (my boss is the people who thinks about that), I need, as a technician, to make some comparison among performances of various platforms. Of course I need to motivate what I'm saying, either showing some benchmarks or explaining advantages and disadvantages of using an OS.

From my point of view, an OS indeed wastes microcontroller resources because some time ticks are used to run the OS itself, but has many other advantages: multitask, threads, maybe embedded stacks, libraries and so on.

For now, I'm using microcontrollers from ZWorld Rabbit family. They are quite cheap and have some libraries, but lack speed (at least for our needs) and dont' have so much flexibility in the IDE (eg. they require a complete rewrite of the flash memory every time you need to test a new software, slowing down development) and they have a limited debugger. That's why we are thinking to move to a better platform.

Any comment will be appreciated.

Marco

Hello ,

Best Regards, Vivekanandan M

Vivekanandan M [2006-10-31 12:44]:

Of course! We don't want to run linux on a Rabbit, but we are evaluating if a new platform running linux could be adopted.

Marco

Requirement 2), would indicate that an 8 bit processor is not up to the task, but on the other hand, it does not absolutely require a 32 processor and standard Linux.

IMHO _anyone_ working with embedded systems should have some ideas about production volumes and what you can do and what you can not do.

How long does that take ? 1-2 hours, a day or a week ?

Most of the application level debugging can be done on any PC, so make sure that you test the application program with the PC tools as well as possible.

For testing on the actual hardware, you need some low level debugging tools to test device drivers etc., but apart from that, the requirements are not that bad.

Use the limited performance HW debugging features for low level testing, do any high level testing on PC and when you are satisfied with both environments, put them together for a final roundup.

Paul

We've used rabbit processors for a project here. The dynamic C environment with it's libraries is incredible crap. Because of some decisions in this project we were forced to continue with these processors. The solution we have chosen was to use the softools compiler with micro C os II as mini RTOS. I wrote a complete very small udp/ip stack. the processors boot by ethernet (bootp, tftp) and run their applications from ram. So what you are doing is quite eh... I have only one program in the flash which is a etherboot application. I just write the motorola file to a linux tftpboot directory and press the reset button. 2 seconds later it runs the application. Debugging also by ethernet. All programming is done under linux with the softools compiler (commandline version) running with wine.

Our system also maps and programs a fpga. you don't mention the speed to/from the fpga. A lot can be done with this processor. If you need help, you can contact me: t.r. walstra at uva.nl

If you have any possibility to switch to some other platform I would certainly use a lowbudget processor board with linux. For example the arm boards by embeddedarm.com with complete rtai linux kernel and development environment. Taco

Paul Keinanen [2006-11-01 08:02]:

Yes, I should have. Many projects, however, start with minimal requirements, then begin to grow more and more up to explosion :-) So, the developer has a very hard job in choosing a microcontroller and maybe the best way is not to choose the cheaper one :-)

On my laptop, the Rabbit Dynamic C IDE takes a couple of minutes to compile, link and load the flash. It's not so much. But it is definitely too much when you need to test several patches a day. Moreover, you have a _very limited_ debugger (you can watch only a few variables) and you need to reload the whole flash every time you want to attach the debugger. More, the IDE doesn't support versioning system (very useful to trace and correct bugs).

Now consider a cheaper hardware like Microchip PIC. You have a very powerful ide/emulator/debugger: you only have to wait a few seconds to load the firmware, you can use the debugger to watch as many variables as you need. And the IDE does support CVS.

I used both platforms (for different tasks) and I greatly appreciated PIC.

Thanks for the helpful suggestion :-)

Marco

Taco [2006-11-01 14:32]:

Same here. But probably I have a chance to migrate to another platform :-)

First, congratulation for your good work. You found a way to overcome some Rabbit Dynamic C limit. Did you also write the etherboot by yourself? And is it possible to use the same motorola file to program the flash in the 'traditional' way using, for example, the Dynamic C RFU?

We designed a proprietary bus for FPGA communication using Rabbit generic I/O pins.

The bus is capable of transferring blocks of data using Rabbit external interrupts. We currently achieve speed of about 300 blocks per second from FPGA to Rabbit (each block is 32 byte, so the total throughput is about 9600 KBps). Each block is processed by Rabbit (the processing involves some floating point math) and an UDP datagram is generated from the resulting data.

In the next version of our system, we plan to overcome those performances, incresing throughput as much as possible, and that's why I was searching another processor. I'd like to know if I can achieve better perfomances (and how better) using an embedded linux.

I was thinking the same: TS-7400 could be an ideal replacement for Rabbit in our design.

Thanks for your help,

Marco

It would eliminate many 16 bit designs as well. Ten years ago, we abandoned one project that was supposed to use a NEC V53 (80188 equivalent) and an NE1000 NIC. The time to read a 100 byte packet from the NIC took so long the UART over ran its FIFO, at 9600 bps.

Then we did some benchmarks with slow 32 bit processors in a PC/104 based product. We found that a 386/25MHz with an NE2000 compatible NIC would start missing packets when sharing a subnet with two or more MS-Windows systems with 500 MHz CPUs. How many packets depended on the number of shares open or connected on the two machines. We actually came up with hard limits of around 250 broadcast packets per second. We offered a 486/133MHz option where needed. The 486 CPU card cost three times as much as the 386.

The 386/486 package used the Novell Lan Workplace socket library.

We no longer sell that particular product, so we have not revisited those limits in light of the faster processors available today.

Bob McConnell N2SPP

IMHO, from this list only "Ethernet" (or rather TCP/IP) might _somehow_ be connected with a decision Pro/contra Linux. All pothers don't force Linux nor vote for not using Linux if absent.

-Michael

Yes, It's a quite small program. It sends a bootp broadcast to get a ip address and filename to download. downloading occurs with tftp. I use a motorola S90 hexfile. each line has a checksum and after receiving the tftp packet I copy it into ram. At the end of the bootloader I execute a few assembler instructions in ram to remap the memory, and jump to address 0 which is the first instruction in ram because of the remappings instead of flash. Of course the application has a different startup assembler file according to the remapping. This kind of stuff is I think very difficult to achieve with the dynamic C "compiler" (is it really a compiler??).

That's quite a high data rate for this processor. I load data from a data acquisition board but the interrupt rate is reduced to about 256 hz and the fpga stores all data in memory banks. Data is sent by udp to a host in raw format, because the host system is a powerful linux processor board.

you can think on TS7300 which has also a fpga. I'm just using one of these arm boards for some initial work here at the moment. Good quality/price, it's a pity that it's still delivered with a 2.4 kernel. I compiled a 2.6 kernel with rtai for a x86 counterpart a year ago. Don't know if I do the same for the arm counterparts. Lot of work. But working with these boards is incredible relaxed. Start the nfs server, export your working directory for the board and compile the application there. On the armboard you mount the nfs directory and just run the application, while you work on your desktop machine or with a ssh shell on the board. Compare this with rabbit environment....

Taco

Hi, You can refer the follwing information: EzHomeTech is a leading embedded middleware (SSP) provider to provide various software development kits to let you quickly and easily build your own embedded products. . Let you OWN an embedded middleware (SSP) and application modules . Let you BUILD your own embedded products

. Let you REDUCE time on learning hardware platform . Let you quickly OWN more turnkey solutions Software development kits for uClinux and video decoding.

1. SSP SDK for IVS-800
2. SSP SDK for Zyxel-iTV-1000 more information:
   formatting link

Robert