Linux device drivers for Rapberry Pi on-board I/O

[larsth]

I and Paolo Palmieri had decided to begin developing 2 Linux device drivers for Pi's on-board I/O.

Both I and Paolo are engineers (BEng) in embedded systems. I had made 2 (kernel space) drivers before (not in the kernel tree), and Paolo had done "ARM7TDMI and DSP speech codecs programming before, ... and RasPi has a DSP" <-- I'm quoting a tweet from Paolo.

The device drivers are the missing ones from http://elinux.org/RPi_Low-leve.....er_support


The Foundation will not include a GPIO driver in the initial release, standard Linux GPIO drivers should work with minimal modification.
The Foundation will not include an SPI driver in the initial release, we hope the community might write one.
The Foundation will not include an I²C driver in the initial release, we hope the community might provide one, standard Linux I²C drivers should work with minimal modification.

We will make the kernel space device drivers mentioned in the above list, except the first. If GPIO is done via polling everything from the above list will be made.

We can, of course, not release anything before we have a Pi to test the drivers on.

I'm writing on a more detailed Readme file, which is to be released on this projects GitHub page.

I will post a link to the repository at GitHub as soon as i have just a little bit to show: Readme file, userland documentation (how to use device drivers from programs/software libraries), and of course the kernel source code and example userland (C) source code, including kernel source code for the alpha (=unstable, for daredevils only) device drivers.

Note that SPI and (high-speed) I²C makes it possible to have audio/mic input for the Pi via a 16-bit stereo ADC chip and some custom electronics.

The device driver could, if instructed to do so, redirect raw audio capture from a specific SPI port (SPI1 or SPI2) or I²C device to Linux's sound subsystem. Any desktop should then discover the new sound device via the X11 server (or in the near future: Wayland). Programs are also capable of discovering the audio device.

If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.




And now 3 question to the reader. Thanks to anyone in advance for any useful answer.


1st Question:

I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).

2nd question:

How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.

3rd question:

Does there exists a UART/low-level serial port device driver for the BCM2835. I had seen some bcm2708 stuff in the RasPi kernel tree via https://github.com/simoncadman/Raspberr ... ch-bcm2708

Does the BCM2835 and the BCM2708 shares some of the same on-chip peripherals? If yes, which?


What is you opinion about these device drivers?

Would you use SPI, and I²C in you own DIY hardware project together with a Pi?

[secretagent]

Based on what has been said in the past on this forum, I believe 2708 and 2835 are either the same or at least have the same peripherals. But somebody please correct me if this is not the case.

Lars T. Hansen said:


I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).


The GPIO driver appears to already exist here: https://github.com/raspberrypi/linux/bl ... 708_gpio.c and it does seem to have optional support for interrupts. I don't know if it is complete or if it needs any modifications for the Raspberry PI. The GPIO subsystem of the kernel already has a userspace interface, which allows both polling and waiting for events.


How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.


If you mean, how do you interface the bus drivers with the SPI and I²C subsystems – you can check Documentation/spi and Documentation/i2c in the kernel tree. You can also look at the the existing drivers in drivers/spi and drivers/i2c/busses. The bitbang/gpio examples (spi_bitbang and i2c-gpio) are more generic and may be easier to follow and there is also i2c-stub.

[Enlightenment]

I'm very interested in a I2C driver because a variety of chip types will be able to operate at the same time on this bus.

[bjs]

I don't know yet what drivers I'm going to need but this is fantastic stuff; keep it up!

[csoutreach]

Lars T. Hansen said:


If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.


Yes, we're working on SPI drivers


http://piface.openlx.org.uk/ke.....-pi-io-int

[larsth]

csoutreach said:


Lars T. Hansen said:


If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.


Yes, we're working on SPI drivers


http://piface.openlx.org.uk/ke.....-pi-io-int


Thanks for the reply from you, and forum users Enlightenment, and bjs. Nice to know that another is writes on a SPI device driver.

I will make an I²C host device driver for the Pi.

From Paolo's tweets i guess that he is interested in doing something with stereo sound input. Maybe a SPI client driver for the Linux sound subsystem?, and the hardware to make it possible <— 16-bit ADC chips is difficult to use, because of analog noise.

[selsinork]

Lars T. Hansen said:


I will make an I²C host device driver for the Pi.


Lars, did you ever get anywhere with your I2C driver ?

There's at least myself and one other person looking at doing the same here http://www.raspberrypi.org/for.....-2/#p63572

I guess nobody wants to duplicate effort if it's already being done...

[larsth]

selsinork said:


Lars T. Hansen said:


I will make an I²C host device driver for the Pi.


Lars, did you ever get anywhere with your I2C driver ?

There's at least myself and one other person looking at doing the same here http://www.raspberrypi.org/for.....-2/#p63572

I guess nobody wants to duplicate effort if it's already being done...



I also don't like to do duplicate work.

I was beginning to prepare to make a skeleton I²C host adapter driver, where only would need to add the lowest software layer, which speaks with the real hardware.

I does, however, not have a pi, yet, so i am currently waiting for an you-can-order-a-Pi-now-email, buy it in the RS Comonents RPi on-line shop , and wait for it to be delivered on my doorstep.

I don't care whether or not I am the one that creates that adapter driver, so I will happily let you and that other person do that work.

While you and that other person is working on the host adapter i can do some hardware design, and do a prototype board which contains:

*a RTC chip

*a Dual USART with 8 GPIO pins[1].

*yet another Dual USART with 8 GPIO pins[1].

including any missing I²C client device driver, which will "talk" with your host adapter driver.

I had seen a pyhton GPIO module, but it might not support async I/O, so i will create a C library with support for that, and maybe also a python module.

[1]: GPIO is not available if the chips's advanced serial communication capabillity is used

[rew]

I spent today trying to get an SPI framework driver up and running. So far I've been doing some code, but I haven't gotten to the stage of trying to compile it yet.

If you're going to work on SPI, this is my userspace "driver" that seems to work:


poke 4008 180
poke 4000 0080
poke 4004 $1
usleep 10
poke 4004 $2
usleep 10
poke 4004 $3
usleep 10
poke 4004 $4
usleep 10
poke 4004 $5
usleep 10
poke 4004 $6
usleep 10
poke 4004 $7
usleep 10
poke 4004 $8
usleep 10
poke 4004 $9
usleep 10
poke 4000 0000
flushrfifo


All values are HEX. So programmed IO SPI is relatively simple.

180 into 4008 is the clock divisor, I should put about 250 into that register for exactly 1MHz.

80 into 4000 enables the SPI module "transfer active".

then data goes in 4004, the FIFO.

I'm assuming the fifo will hold my 9 databytes. A real driver will check for fifo space.

I then flush the read fifo, again I'm assuming the read fifo will hold all the data until I get at that point in the script.

[larsth]

rew said:


I spent today trying to get an SPI framework driver up and running. So far I've been doing some code, but I haven't gotten to the stage of trying to compile it yet.

If you're going to work on SPI, this is my userspace "driver" that seems to work:


poke 4008 180
poke 4000 0080
poke 4004 $1
usleep 10
poke 4004 $2
usleep 10
poke 4004 $3
usleep 10
poke 4004 $4
usleep 10
poke 4004 $5
usleep 10
poke 4004 $6
usleep 10
poke 4004 $7
usleep 10
poke 4004 $8
usleep 10
poke 4004 $9
usleep 10
poke 4000 0000
flushrfifo


All values are HEX. So programmed IO SPI is relatively simple.

180 into 4008 is the clock divisor, I should put about 250 into that register for exactly 1MHz.

80 into 4000 enables the SPI module "transfer active".

then data goes in 4004, the FIFO.

I'm assuming the fifo will hold my 9 databytes. A real driver will check for fifo space.

I then flush the read fifo, again I'm assuming the read fifo will hold all the data until I get at that point in the script.



@rew

I am not doing a SPI host adapter driver, because of @csoutreach's post @5:29 pm
March 12, 2012 in this thread:

"Yes, we're working on SPI drivers http://piface.openlx.org.uk/ke.....-pi-io-int  "

[rew]

You still doing I2C then?

in C sending I2C from userspace looks like:


bsc[BSC_DLEN]  = argc-2; //  num bytes to send.

sscanf (argv[1], "%x", &v);
bsc[BSC_A]  = v >> 1;  // slave address.

bsc[BSC_C] = 0x8080; // Enable controller and start the transfer.

// XXX This assumes all bytes fit in the FIFO.
for (i=2;i<argc;i++) {
sscanf (argv, "%x", &v);
bsc[BSC_FIFO] = v;
}
// XXX need timeout.
// XXX Busy waiting is ugly.
t = 0;
while (! (bsc[BSC_S] & 0x2))
if (t++ > 100000) break; // Wait for TX FIFO to drain.
//printf ("t=%d\n", t);


How is that?

[larsth]

rew said:


You still doing I2C then?

in C sending I2C from userspace looks like:


bsc[BSC_DLEN]  = argc-2; //  num bytes to send.

sscanf (argv[1], "%x", &v);
bsc[BSC_A]  = v >> 1;  // slave address.

bsc[BSC_C] = 0x8080; // Enable controller and start the transfer.

// XXX This assumes all bytes fit in the FIFO.
for (i=2;i<argc;i++) {
sscanf (argv, "%x", &v);
bsc[BSC_FIFO] = v;
}
// XXX need timeout.
// XXX Busy waiting is ugly.
t = 0;
while (! (bsc[BSC_S] & 0x2))
if (t++ > 100000) break; // Wait for TX FIFO to drain.
//printf ("t=%d\n", t);


How is that?


Yes I am, but I am waiting for an answer from forum user selsinork. He has a Pi and can start working on a host adapter driver. I can only start working when I have a Pi.

... so you are doing memory mapped i/o?

That does only works if you are doing I²C I/O from only 1 program, because you will get concurrency troubles if more than 1 program try to do memory mapped I²C I/O on 1 I²C bus.

You program is also very inefficient (context switches).

You should use i2c-dev and do a Linux UIO device driver, and let the I²C host adapter driver speak with the I²C hardware. The i2c-dev client device driver will then talk with an I²C host adapter driver.

This is the Linux driver model.

Apropos busy waiting. That can be avoided, because an I²C host adapter driver can  make use of the I²C hardware interrupts. You code cannot do that because you software are not in kernel space. You does of course need to have a time-out soft intterupt running (the full capacity of the write FIFO and/or the read FIFO can be not used completely). FIFOs are 16-byte in length and are read from and written to on the same address.

For now you can use 2 GPIO pins, the i2c-gpio host adapter driver, and the i2c-dev client device driver to create Linux UIO drivers in userspace.

If you are lucky there are already a client device driver in kernel space for you I²C hardware.

lm-sensors has quite a lot of client device drivers: http://www.lm-sensors.org/wiki/Devices (look for bus type: I2C).

[selsinork]

Lars T. Hansen said:


Yes I am, but I am waiting for an answer from forum user selsinork. He has a Pi and can start working on a host adapter driver. I can only start working when I have a Pi.


I'll be starting to look at it over the next few days, however I'm currently limited to compiling the kernel on the Pi and that's a bit slower than I'm used to on a 64 core x86, so I may be a while..

I'm in the process of ordering some parts for an I2C RTC, so I may not make lots of progress until I get that built.

Maybe we should create a repo on github so that several of us can contribute ?  Even if only a few can actually test stuff, others can pitch in and help fix my crappy coding

[larsth]

selsinork said:


Lars T. Hansen said:


Yes I am, but I am waiting for an answer from forum user selsinork. He has a Pi and can start working on a host adapter driver. I can only start working when I have a Pi.


I'll be starting to look at it over the next few days, however I'm currently limited to compiling the kernel on the Pi and that's a bit slower than I'm used to on a 64 core x86, so I may be a while..

I'm in the process of ordering some parts for an I2C RTC, so I may not make lots of progress until I get that built.

Maybe we should create a repo on github so that several of us can contribute ?  Even if only a few can actually test stuff, others can pitch in and help fix my crappy coding



You can cross-compile for the Pi on x86 - also you only have to create a kernel with debugging, and the I²C subsystem enabled only once.

I expect the kernel module to be tiny (a <15 KB bcm2835-i2c.ko file), so it doesn't take that long to compile on the Pi, and cross-compileing on x86 should be very fast.

I had been in the process of creating a GitHub repo but I got stuck, because I couldn't remember the password to my key, so I has to recreate the key again.

I think it is a very good idea to do code peer-reviews. I had good experience with working 2 (or more) on a project, also my Linux kernel hacking knowledge is a little bit rusty - it is about 3 years ago since i last did 2 kernel space device drivers.

BTW i'm  larsth on GitHub, and @LarsTHansen on Twitter, and larsth on IRC (freenode), if my computer is running i am online at the #raspberrypi channel.

[selsinork]

Lars T. Hansen said:


You can cross-compile for the Pi on x86


sure, I just haven't got enough round tuits to set that up yet

I think it is a very good idea to do code peer-reviews.
agreed, but you'll be sorry after reading my spagetti code


BTW i'm  larsth on GitHub, and @LarsTHansen on Twitter, and larsth on IRC (freenode), if my computer is running i am online at the #raspberrypi channel.


I'm lurking in the freenode irc channel although it seems a bit noisy

[larsth]

selsinork said:


Lars T. Hansen said:


You can cross-compile for the Pi on x86


sure, I just haven't got enough round tuits to set that up yet


I think it is a very good idea to do code peer-reviews.


agreed, but you'll be sorry after reading my spagetti code


BTW i'm  larsth on GitHub, and @LarsTHansen on Twitter, and larsth on IRC (freenode), if my computer is running i am online at the #raspberrypi channel.


I'm lurking in the freenode irc channel although it seems a bit noisy


agreed, but you'll be sorry after reading my spagetti code

hehe

apropos IRC, my username is lars_t_h on freenode, not larsth

[cbaurtx]

Lars T. Hansen said:


I and Paolo Palmieri had decided to begin developing 2 Linux device drivers for Pi's on-board I/O.

Both I and Paolo are engineers (BEng) in embedded systems. I had made 2 (kernel space) drivers before (not in the kernel tree), and Paolo had done "ARM7TDMI and DSP speech codecs programming before, ... and RasPi has a DSP" <-- I'm quoting a tweet from Paolo.

The device drivers are the missing ones from http://elinux.org/RPi_Low-leve.....er_support


The Foundation will not include a GPIO driver in the initial release, standard Linux GPIO drivers should work with minimal modification.
The Foundation will not include an SPI driver in the initial release, we hope the community might write one.
The Foundation will not include an I²C driver in the initial release, we hope the community might provide one, standard Linux I²C drivers should work with minimal modification.

We will make the kernel space device drivers mentioned in the above list, except the first. If GPIO is done via polling everything from the above list will be made.

We can, of course, not release anything before we have a Pi to test the drivers on.

I'm writing on a more detailed Readme file, which is to be released on this projects GitHub page.

I will post a link to the repository at GitHub as soon as i have just a little bit to show: Readme file, userland documentation (how to use device drivers from programs/software libraries), and of course the kernel source code and example userland (C) source code, including kernel source code for the alpha (=unstable, for daredevils only) device drivers.

Note that SPI and (high-speed) I²C makes it possible to have audio/mic input for the Pi via a 16-bit stereo ADC chip and some custom electronics.

The device driver could, if instructed to do so, redirect raw audio capture from a specific SPI port (SPI1 or SPI2) or I²C device to Linux's sound subsystem. Any desktop should then discover the new sound device via the X11 server (or in the near future: Wayland). Programs are also capable of discovering the audio device.

If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.




And now 3 question to the reader. Thanks to anyone in advance for any useful answer.


1st Question:

I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).

2nd question:

How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.

3rd question:

Does there exists a UART/low-level serial port device driver for the BCM2835. I had seen some bcm2708 stuff in the RasPi kernel tree via https://github.com/simoncadman/Raspberr ... ch-bcm2708

Does the BCM2835 and the BCM2708 shares some of the same on-chip peripherals? If yes, which?

What is you opinion about these device drivers?

Would you use SPI, and I²C in you own DIY hardware project together with a Pi?


Thank you for offering to develop these drivers. I have a PIC controlled system, which uses I2C to communicate with two devices:

1. Supercap backuped RTC and Thermometer (DS1629)

2. Seven segment LED driver (SAA1064)

I can make available the schematics right the way, but the PCB has a connector with a different pinout than the Raspberrz Pi requires (an adapting cable is needed). I am also not sure, whether the RaPi can deliver enough power for the Seven segment LED display (4 digits).

[larsth]

cbaurtx said:


Thank you for offering to develop these drivers. I have a PIC controlled system, which uses I2C to communicate with two devices:
1. Supercap backuped RTC and Thermometer (DS1629)

2. Seven segment LED driver (SAA1064)

I can make available the schematics right the way, but the PCB has a connector with a different pinout than the Raspberrz Pi requires (an adapting cable is needed). I am also not sure, whether the RaPi can deliver enough power for the Seven segment LED display (4 digits).


You only need 3 pins: SDA, SCL, and the return-signal wire GND. I guess that if you use a stupid USB hub (one which doesn't try to control the +5 volt power) you can power the Pi and anything connected to it, but be careful not to burn the +5 volt wires on the RPi PCB: Because of that it might be better idea to use a separate USB cable from that stupid USB hub to power you expansion board.

Note that SDA and SCL I²C signals are 3,3 volt and are not 5 volt tolerant.

You board must:

* run on 3,3 volt

or

* use a bi-directional level shifter circuit (only 1 transistor per signal) between the 3,3 volt signals, and the 5 volt signals on you board: http://ics.nxp.com/support/doc.....n97055.pdf

You drivers are so called I²C client device drivers, they talk with an I²C host adapter driver <– the one i and selsinork will make.

Currently you can use another host adapter driver which uses GPIO pins, its name is i2c-gpio.

With the i2c-dev client device driver in kernel space you can build you client device drivers in user space as a software library (a *.so file). Note that there are existing client  device drivers in the kernel, and lm-sensors also have a lot of client device drivers (link to website in an previous post in this thread).

With the i2c-gpio and the i2c-dev drivers you can get something to work before I and selsinork have the host adapter driver ready for real use. That can be important if you are doing an embedded system product in a business.

AFAIK the I²C subsystem is not compiled into the current RPi kernel, so you has to cross-compile one with the I²C subsystems enabled. Then you are at configuring a new kernel, do yourself the favour of adding kernel debugging, so you can get a lot more debugging messages form the kernel than usual.

[rew]

You don't need the level shifter.

The Philips design note also starts with "it is not always necessary, but if you have to... ".

I have the http://www.bitwizard.nl/catalo.....ts_id=69  raspberry pi serial breakout board. It provides the I2C on a convenient 4pin connector (GND, SDA, SCL, power).

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

I've tested this with a real RPI and a 5V I2C device, and it works.

[larsth]

rew said:


You don't need the level shifter.

The Philips design note also starts with "it is not always necessary, but if you have to... ".

I have the http://www.bitwizard.nl/catalo.....ts_id=69  raspberry pi serial breakout board. It provides the I2C on a convenient 4pin connector (GND, SDA, SCL, power).

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

I've tested this with a real RPI and a 5V I2C device, and it works.


i wrote:

You board must:

* run on 3,3 volt

or

* use a bi-directional level shifter circuit ...

What i tried to tell you:

So i wrote that if you are using 3,3 volt logic everything is ok=you don't need a level shifter.

However, if it outputs a signal with >3,3 volt logic you should use a level shifter.

The "or" should imply that in the above text, but because English is my 2nd language I might not always be good at explaining advanced stuff in that foreign language.

It is a neat little trick, if it works w/o making harm to the bcm2835.

Thanks for telling me that trick.

[rew]

What (apparently) you should know about I2C is that NO I2C device will output a high level. The high level is always arranged by a pullup resistor.

[texy]

rew said:


You don't need the level shifter.

The Philips design note also starts with "it is not always necessary, but if you have to... ".

I have the http://www.bitwizard.nl/catalo.....ts_id=69  raspberry pi serial breakout board. It provides the I2C on a convenient 4pin connector (GND, SDA, SCL, power).

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

I've tested this with a real RPI and a 5V I2C device, and it works.


Am I missing something, or do they want to charge 24 Euro's to shipo it to the UK?

Texy

[selsinork]

rew said:


Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.


There's no actual guarantee that a 5v device detects anything over 2.5v as high, you would need to check the datasheet for the part in question to be sure.

Anyway, here's a quote from the I2C specification (http://www.nxp.com/documents/u.....M10204.pdf) section 3.1.2

"Due to the variety of different technology devices (CMOS, NMOS, bipolar) that can be
connected to the I2C-bus, the levels of the logical ‘0’ (LOW) and ‘1’ (HIGH) are not fixed
and depend on the associated level of VDD. Input reference levels are set as 30 % and
70 % of VDD; VIL is 0.3VDD and VIH is 0.7VDD."

So at 5v, 0.7VDD is 3.5v.


I've tested this with a real RPI and a 5V I2C device, and it works.


The trouble with things like i2c is that it depends a lot on what other devices are on the bus, what speed you're driving it at, are the pullups strong enough to overcome the capacitance of the bus and get the voltage above the threshold in the necessary time etc.
i.e. what works at 100kHz may not at 400kHz, 1MHz, or 3.4MHz

So while it's nice to know that you have something that happens to work for you, I don't think it's something we can assume will always work for everyone. In practise, with a very short bus, it just might, but ymmv.

With all of the SD card problems being posted, I'm always left thinking that things are not always what they seem... something that works for me, but the exact same doesn't for you, just isn't nice and it's damn hard to debug

[selsinork]

I should also say that the majority of the i2c devices I've been looking at lately are 3.3v ones anyway.

Indeed, the one I'm looking at for my Pi/rtc project will operate down to 1.8v, so it's quite likely that anything current will happily work at the 3.3v used by the Pi without any problems and no need to worry about 5v at all.

[RAThomas]

I'm a driver guy from the I2C thread mentioned earlier and must admit I haven't looked at my driver code for at least a week.  I'm in the same boat as others here in that I don't have a Pi ... my order might go through by the end of June, but who knows.  The driver task looks fairly straight-forward to me and I'm maybe half done (the *easy* half, of course .  I'll dig back into it and hopefully have something others can look at this weekend.

selsinork, do you have some I2C device to test talking with the Pi?  I'm thinking either a really simple device where it's own data "protocol" won't obscure the driver's behavior or one with existing higher level support would be best.  Even without a test device, one might still be able to test that the BSC master can talk using an o-scope.

Is the I2C bus already pulled up on the Pi or does one need to terminate it to do testing?

Other trivia:  The 2835 has 3 BSCs (0-2) where BSC2 is dedicated to the HDMI port and out of our hands.  I'm focused on making BSC0 work, but since they appear to be identical but for the register mapping, it should work for BSC1 too (assuming it works at all!).