SPI Interface

I'm looking into using the SPI interface to talk to ADCs. Is the rPi SPI a hardware interface? How fast might I expect to sample a single 14 bit ADC like the LTC1408?

--

Rick
Reply to
rickman
Loading thread data ...

Yes, it's hardware and there is a supported kernel driver for it.

You can clock it at speeds up to 32Mb/sec - maybe faster.

However the issue with the kernel driver is latency - it's a bit high. Might not get more than 8-16K samples/sec. although I've not measured it recently - I think it may have improved.

Gordon

Reply to
Gordon Henderson

Wow, that's insanely bad. Someone I'm trying to help is interested in using the rPi to sample an ADC and may need to do it at 48 kSPS. I can't imagine what could be going on in a driver that would be 100 times slower than an Arduino.

--

Rick
Reply to
rickman

A multi-user, multi-tasking kernel getting in the way. You can poke the hardware directly and get it going much faster at the expense of more CPU cycles.

Gordon

Reply to
Gordon Henderson

Getting "in the way" is quite an understatement. I read somewhere that when someone tried bit banging the SPI they didn't get any better results. Can the SPI hardware be accessed from a user program? What is to stop the multi-user, multi-tasking kernel from getting in the way of the user program? I thought that was what drivers were all about, doing I/O efficiently and fast.

--

Rick
Reply to
rickman

You certianly can get it to go much faster - well - not faster, but with less latency per transaction. It's the latency that's the slow-down for the kernel driver which is perfecly capable of clocking out a few MB at 32Mb/sec once it's started. It's the time to get from userland into kernel land that appears to be large, as well as the kernel firing up the SPI hardware. I've not looked into the kernel driver in any details though, but I know work was being done on it. I did a lot of benchmarking way back so might dig them out and re-test with a newer kernel.

You can access it (along with all the GPIO) directly from userland in 2 modes - one is to poke the hardware registers directly, push bytes into the fifo and let the hardware clock it out. The other way is to simply bit-bang any selection of gpio pins to emulate SPI clock, select & data lines.

Have a look at my wiringPi sources to see how to memory map the hardware from a user program if you like -

formatting link
you'll need the Broadcom ARM peripherals manual to get the SPI registers, etc.

Gordon

Reply to
Gordon Henderson

I understand that there is a simple interface that only allows you to send and receive a block of data, and that another protocol layer is required on top of that and it has to be coded in user mode?

In that case the entire protocol has to be moved into the kernel (a kernel module) and it should work OK.

Is the SPI protocol too device-specific to wire it entirely into the kernel?

E.g. in a case like this (sampling an A/D converter) one would want to have an interface to user mode that returns blocks of samples gathered in a buffer by the kernel, so the kernel would do the fast transactions and the user can receive them at a convenient rate.

Reply to
Rob

Whether you want blocks of data or individual data samples depends on the algorithm you are processing. In a control loop you often want individual samples with a minimum of latency. Sounds like this might not be a good app for a rPi running Linux.

But I believe the person doing the work is doing a somewhat different type of control that does not require individual samples. However the interface is to multiple ADC which all will produce a sample simultaneously. I'm not sure of the details.

--

Rick
Reply to
rickman

Can't answer for a PI but can answer for Linux in general.

the worst case is disk IO. Then network IO. a disk operation can tie up the bus for a very long time (in hardware interrupt terms) so when processing e.g. audio samples live, you have to expect some jitter and in the case of real time audio, you MAY get actual data loss as the internal buffers on the sound card are not that great.

That tends to mean you are a few samples behind live, in processing, giving a measurable delay, even if you are clocking data as fast as it comes in, and are processing it fast enough to be within one sample period.

Its not the actual latency of the interrupt process, its the generalised latency of a machine which may already be processing another interrupt that makes heavy use of I/O and the bus.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

It's called 'writing a device driver'

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

If you really want bare hardware, well then no it isn't.

unless you are prepared to do almost everything you need at device driver level. And customise the operating system such that nothing else is going on that can interrupt (sic!) the process of gathering it...

And that is the problem. There are a lot of daemons in Linux that can wake up and decide that now is the time to flush a block to disk, or write something to a log file.

Usually these are not interrupt driven and are interruptible BUT when the kernel itself is busy writing raw data to a disk, well its likely that its going to disable interrupts for at least 512 bytes of data transfer. at 100mbps putative transfer rate on a SATA style flash card interface, that's 40us. WAY too long to not miss a real time audio sample at 44/48 Khz. Which is why audio cards are buffered.

Its a long way from e.g. DOS when you could set up an interrupt service request for custom hardware, and write a scheduler off a timer tick, and thereby get your real time process into the top priority queue.

FAR easier to do that sort of malarkey on an arduino.

In LINUX the operating system has control at all times. Its humming and ticking below the surface doing housekeeping, and that's what makes it especially good at being a GP or server operating system. The price you pay is that interrupt latency can stretch to a few hundred microseconds whilst some other interrupt is doing its thing.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

maybe in your book, not in mine. a similar situation exists in the networking code. the device driver for a network device can return packets of network traffic, but those are normally not handed directly to the user, but a network protocol exists in the kernel as well, stacked on top of the driver, that does lots of processing before the user gets the results.

a protocol implementation is not 'writing a device driver'.

Reply to
Rob

In most systems today many of the above actions can take place simultaneously, for example the disk I/O is not done by the processor but by DMA, and the processor can continue while blocks are transferred. Of course a user process can be blocked because it needs a block that has to be read and the "disk" is busy reading or writing a block for someone else. So when the is lots of disk I/O the system can still appear slower, but that normally does not take the form of losing samples on a sound device while doing disk I/O.

Only when everything becomes overloaded and there is a shortage of memory, you may end up in the situation that a user process reading sound samples cannot be run because it first needs to page-in program or data blocks from disk, and the disk is already overwhelmed by page-out of other blocks that is required because there is shortage of memory. Under such conditions the processing can get into problems because of I/O issues.

But normally this does not happen and interrupts should not be an issue.

What can be a problem is to run a fast protocol (e.g. getting samples one by one) from user mode on a slow system like the Pi. Moving the protocol into the kernel makes it more efficient and could make things work that the Pi normally is not capable of.

Reply to
Rob

is it in kernel, or in libraries?

Whatever, it is in user space at that point.

no, but it is not the issue here.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

In the kernel.

No, in the kernel.

For example: TCP. Is entirely in the kernel. All assembly and transmission of datagrams, checking for replies, setting timeouts, re-transmitting when required is all in the kernel.

In user space you see only the payload data, not the headers and all their handling.

Similarly a protocol for talking to an A/D converter can be implemented in the kernel and the user need only read the resulting samples, not the raw communication with the device.

It has been done for USB. But I don't know if it is feasible for SPI or I2C. It may be that there just is not enough uniformity between devices to make it practical to release generic modules for general use, and it could be that for each job you need to write your own.

Reply to
Rob

some of the kernel is in user space, or you would not be able to communicate with it.

I think we are talking about different things here, and I am feeling like a cold coming on, so I cant be bothered to argue through the definitions.

But there are three main things

- what happens under interrupt

- what happens as a root level daemon

- what happens as a result of and linked top code that is 'user level' context switched non real time code.

Since I can write code that opens socketst for datapackets other than e.g. IP level packets, I think you will find that the kernel socket level interface is a lot rawer than you suppose, and quite a lot of the protocol stuff is in TCP IP user level libraries, not hard linked into the kernel.

The kernel is in a sense two things anyway - the sheduler and task manager, and 'inbuilt libraries'. To that you can add 'interrrupt' handlers or device drivers. Whether you count them as part of the lkerenel otr not is a moot point.

From the point of view of real time programming, it doesn't actually mater whether the library is a call to a hard coded kernel routine or within the 'user' code. The delays are similar.

And from the point of real time programming, the Linux convention is that user space programs don't handle hardware interrupts directly.

If you want snappy repose to hardware interrupts you write a device driver. OK you can use callbacks into user code but its highly deprecated.

How much or how little that device driver does is up to the coder.

If, as I suspect, the OP wants to do real time audio processing from input to output, he may be able to get the best response by writing a device driver, and doing a heck of a lot MORE in that than is the general case. And communicating with that through IOCTL type interfaces.

Bearing in mind that device drivers cannot rely on almost every part of the operating system libraries that are available to normal code.

But that is the simplest way to get close to the hardware and raw interrupts.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

I end the discussion concluding that you don't know how it works and don't want to believe my information.

Reply to
Rob

As a hardware guy, I see a problem in understanding what seems to be happening here.

A Ethernet chip has a block buffer, the SPI interface has a one byte interface.

Every time the driver is called, the Ethernet devide gets 100s of bytes, the SPI interface gets one byte.

A block can be sent to an SPI driver, but it gets hung up feeding one byte at a time to the hardware.

So, is there a DMA controller that can feed the SPI interface ? Is there a DMA controller that can be set up to capture bytes from the SPI interface and save a block of received data ?

This is the same problem with 8-bit to 32-bit chips.

thanks

Reply to
hamilton

SPI is a very simple interface. Literally: Here is a block of data (a number of bytes), clock it out using the data signal synchronised with a clock line and at the same time clock data IN using the same clock.

To call the Linux driver, it's one system call once you've opened the device and set the parameters. The kernel takes care of it and your system call returns after the data has been exchanged.

The SPI protocol is simple and well understood - what's less simple is that each device uses it's own protocol to interpret the data. e.g. common ADCs may require you to clock out 4 bits, then clock in 12 bits of data). another device might want you to clock out 8 bits then clock in

16 bits and so on.

There are Linux kernel drivers for some SPI devices but not all.

Which is great, but every device manufacturer has their own protocol, and even devices from the same maker has different parameters - e.g. precision.

Gordon

Reply to
Gordon Henderson

I don't know what century you're living in but this simply does not happen. The kernel sets up the DMA/transfer engine then lets the hardware get on with it, then it gets on with other stuff until the end of transfer interrupt happens. We've come a very long way from PIO data transfers from early ST506 and IDE interfaces.

I was writing SCSI drivers >20 years ago that did this - and even did bus disconnects and re-connects, so you could post commands to different devices at the same time then do other stuff while the disks did the transaction. (or became ready to do the transaction).

The Pi suffers from SD card latency too - and when you observe this most is when an application does an fsync - then the kernel will wait for all data to be flushed to the SD card and for the SD card to report that the data has been written - things like syslogd do this from time to time and badly written applications that expect to crash and are paranoid about stuff being physically on disk - e.g. databases and firefox )-:

(Not that you'd run firefox on a Pi, but it's an example)

However while the disk (SD) system is locked at that point, other computation carries on - as it should.

Gordon

Reply to
Gordon Henderson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.