Microcontrollers, USB and Linux

Hi all,

Simple question, I hope :-)

What's a good architecture for embedded/microcontroller software development (in C) _under Linux_, with respect to the toolchain (C cross-compiler, assembler, linker, etc.); nativly without using things like Wine) ?

Background info:

I would like to develop a _simple_ and low-cost microcontroller hard- and software platform for study/training purposes, for my colleagues (and myself :-) ). The focus is software and the hardware should be as simple/breadboardable as possible, i.e. DIP packages instead of QFP or BGA. Just basic I/O, perhaps add simple SPI/I2C peripherals, etc. at some point. I would also like to include USB in it, which is available on plenty 8-bit controller (and an interesting challenge I've seen).

I would like to use/program USB directly so no FTDI converter IC's to simulate RS232 ports (what's the point of USB when you simulate RS-232 anyway? Just the option of using a USB hub?).

I've looked at _many_ websites (see below) but I haven't been able to find what I'm looking for. Does anybody already have any experience in this area? How active is SDDC for example?

ARM or AVR(32) look nice but they all have QFP or similar packages so that's not really an option. The Freescale Blackfin controllers start at BGA packages. Even the Atmel 8051's with USB are QFP packages. The starter-kits or experiment boards all start at 40+ euros on pre-built rather large boards with extra peripherals which make them unsuitable for real simple experiments or applications (e.g. a simple switch controlled via USB; which is

Hi all,

Simple question, I hope :-)

What's a good architecture for embedded/microcontroller software development (in C) _under Linux_, with respect to the toolchain (C cross-compiler, assembler, linker, etc.); nativly without using things like Wine) ?

Background info:

I would like to develop a _simple_ and low-cost microcontroller hard- and software platform for study/training purposes, for my colleagues (and myself :-) ). The focus is software and the hardware should be as simple/breadboardable as possible, i.e. DIP packages instead of QFP or BGA. Just basic I/O, perhaps add simple SPI/I2C peripherals, etc. at some point. I would also like to include USB in it, which is available on plenty 8-bit controller (and an interesting challenge I've seen).

I would like to use/program USB directly so no FTDI converter IC's to simulate RS232 ports (what's the point of USB when you simulate RS-232 anyway? Just the option of using a USB hub?).

I've looked at _many_ websites (see below) but I haven't been able to find what I'm looking for. Does anybody already have any experience in this area? How active is SDDC for example?

ARM or AVR(32) look nice but they all have QFP or similar packages so that's not really an option. The Freescale Blackfin controllers start at BGA packages. Even the Atmel 8051's with USB are QFP packages. The starter-kits or experiment boards all start at 40+ euros on pre-built rather large boards with extra peripherals which make them unsuitable for real simple experiments or applications (e.g. a simple switch controlled via USB; which is

I'm using these ones and I'm happy with them. Complete toolchain and programming tools available under Linux.

Very nice project. I tried it here and it works with my Atmega8 and Atmega16.

JB

(If there are no additional prerequisites) you should first investigate what functionality you expect from the target device. Then you should decide what OS you want to use _on_the_target_. After that you should decide what processor you want to use on the target and at last what toolchain you use for development

If you don't want to use Linux on the target processor you picked the wrong forum here.

I suppose you can't do Linux on a PIC or other processors aiming for extreme low cost.

-Michael

It might be a good tart to use just the development PC as a target for developing a Linux based device. You can port it to any other Linux based architecture once you decided which one to use.

-Michael

Thanks for the AVR and "dead bug" info! I'll do a re-post in comp.arch.embedded.