On Sat, Jul 5, 2008 at 4:03 AM, Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx> wrote: > Hi, > > for my project I would like to design an ARM9 based single board computer (SBC) > using the cirrus logic EP9302 CPU: > The AT91SAM9 family is a better choice[1], the ATMEL and community support is great [2][3]. [1] http://www.atmel.com/dyn/products/devices.asp?family_id=605 [2] http://www.linux4sam.org [3] http://maxim.org.za/at91_26.html The AT91SAM9260 and the older AT91RM9200 is available in TQFP208 package. Both support SD Cards, Ethernet, USB, SPI,I2C, a lot of GPIOs... ADCs only in the AT91SAM9260. The at91 lacks of FPU, but the cirrus maverick crunch support is very poor. > http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf > http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf > > > My goal is to use existing linux drivers together with attached peripheral > hardware without having to patch the driver code. > For this reason I'm looking for the best way to hook up peripheral hardware to > the CPU so that the linux kernel can handle it. > > > Among other features the CPU has a SPI bus and a total of 27 GPIO pins. > Using bit-banging on some of the available GPIO pins the CPU can also do I2C > communication. > (AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.) > > Peripheral hardware (e.g. some linux-supported bluetooth chipset) can be hooked > up to the CPU in the following ways: > > 1) directly connect it to the CPU's GPIO pins > 2) connect it to the CPU's GPIO pins in a multiplexed way using a bus > switch > 3) hook it up to some existing serial bus (SPI or I2C) > 4) hook it up to some existing _external_ serial bus (USB, UART) > 5) connect it to GPIO pins of a linux-supported GPIO expander that can > be accessed over I2C > > > Now I would like to review the mentioned approaches: > > > 1) directly connect it to the CPU's GPIO pins: > > The CPU has 18 standard GPIO pins (usable for I/O) and 19 enhanched GPIO pins > which also have interrupt support. > Obviously, I do not wan't to use all of the available GPIO pins for peripheral > hardware. > Also, if we consider chipset configuration pins, the number of available CPU > GPIO pins would not suffice. > For this reason, IMHO a direct connection of peripheral hardware to the CPU's > GPIO pins is not a reasonable design decision. > > > 2) connect it to the CPU's GPIO pins in a multiplexed way using a bus switch > > This approach is similar to 1) except for the difference that the CPUs GPIO pins > are multiplexed using a bus switch. > Thus different peripheral chipsets could be accessed in the following way: > > 1. address the according bus switch so that the CPU's required GPIO are > routed through to the chip we want to talk to > 2. communicate with the chip > > Again to save GPIO pins, the various bus switches could be addressed over a > serial bus like I2C. > While this communication is certainly suitable for high-speed devices, it also > has the drawback that the CPU's GPIO lines need to be routed all over the PCB > (printed circuit board) to the different bus switches and from there to the > chips we want to talk to. > Since I plan to use low-speed devices only, I do not want to make the hardware > design too complex. > For this reason I'd rather not take this design decision. > > > 3) hook it up to some existing serial bus (SPI or I2C) > > If the peripheral hardware chipset has support for serial communication, this > would be the easiest way to go. > Since there's already linux support for SPI as well as for I2C I would like to > use this way of talking to low-speed hardware whenever possible. > > > 4) hook it up to some existing _external_ serial bus (USB, UART) > > The single board computer should have external connections to the "outside world". > One serial port should be used as serial console while the other one will be > used for something else. > The USB connectors should be usable to connect arbitrary devices which are > supported by the linux kernel (e.g. external harddisk, webcam, whatever ...). > Also, usually peripheral hardware chips do not support USB. > For this reason this approach will not be taken for peripheral hardware access. > > > 5) connect it to GPIO pins of a linux-supported GPIO expander that can be > accessed over I2C > > This is IMHO a very promising approach which also has been taken in various > other (linux-compatible) designs I found on the internet > (e.g. the "DaVinci prototyping board", > http://www.linuxdevices.com/news/NS2209350555.html). > > The idea is to connect a GPIO expander to the CPU's I2C bus which provides a > number (i.e. 8, 16, ..) of freely usable GPIO pins. > These GPIO pins are then connected to the peripheral hardware. > The linux kernel already has support for various GPIO expanders like the PCA9539 > (16 port) or the PCF8574 (8 port) chips. > As far as I read in the kernel documentation, the drivers transparently map > those GPIO pins to the GPIO interface of the linux kernel. > Thus, from a device driver perspective, it makes no difference whether a device > is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can > be accessed over thr I2C bus. > > Another advantage is the simple circuit design: Instead of having to route a > complete parallel bus over the PCB, only the serial I2C bus has to be routed > from the CPU to the port expander. > >From the port expander a rather short bus then goes to the low-speed chip we > want to talk to. > > In my oppinion, from a hardware as well as from a software perspective, this is > the right way to go. > > > > > > As we saw, from a software perspective, it doesn't seem to make a big difference > whether peripheral hardware is directly hooked up to the CPU's GPIO pins or > it is hooked up to GPIO expanders. > > > * However, if we look at existing device drivers, will it be possible to use > them with this setup without modification ? > > * How will the kernel find devices attached to GPIO pins ? > (There's no way to scan the bus since the kernel doesn't know what and where > devices are attached to the GPIO pins, right ?) > > * What would be the best way to attach peripheral hardware from a linux-kernel > perspective ? > > * Can you suggest any embedded hardware design documentation that considers > linux compatibility ? > > > sincerly, > stefan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-embedded" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Andrés Calderón Cel: +57 (300) 275 3666 Email: andres.calderon@xxxxxxxxxx Web: www.emqbit.com "El hombre que produce mientras otros disponen de su producto, es un esclavo." -- Ayn Rand -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
