Using SPI in a kernel module

[Nils]

Hello,

I'm currently working on a kernel module which needs to communicate via SPI to an external microchip.

I used the cape manager to enable SPI. The device is accessible through /dev/spidev1.0.
But since it's a kernel module, I guess it's not recommended to access files via sys_open()?

Another approach I found would be adding a struct to arch/arm/mach-omap2/board-am335xevm.c and then use spi_register_driver() in my kernel module. But in my kernel sources (3.8.13) this file doesn't exist.

What would be the right way to use SPI in my kernel module?

Regards,
Nils

[John Syn]

From: Nils <nwk...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Monday, July 28, 2014 at 7:00 AM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: [beagleboard] Using SPI in a kernel module

Hello,

I'm currently working on a kernel module which needs to communicate via SPI to an external microchip.

I used the cape manager to enable SPI. The device is accessible through /dev/spidev1.0.
But since it's a kernel module, I guess it's not recommended to access files via sys_open()?

Another approach I found would be adding a struct to arch/arm/mach-omap2/board-am335xevm.c and then use spi_register_driver() in my kernel module. But in my kernel sources (3.8.13) this file doesn't exist.

There is no board files since the introduction of device tree.

What would be the right way to use SPI in my kernel module?

Look at examples in /drivers/staging/iio or /drivers/iio

There are plenty of examples of using SPI calls in a kernel module. 

Use the power of GIT to find what you are looking for. In the Kernel source do the following:

git grep spi_sync_transfer

Regards,

John

Regards,
Nils

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nwk...@gmail.com]

Thanks, John.

I Iooked at kernel/drivers/iio/dac/ad/5064.c

There's the following struct which is passed to spi_register_driver():

static struct spi_driver ad5064_spi_driver = {
    .driver = {
           .name = "ad5064",
           .owner = THIS_MODULE,
    },
    .probe = ad5064_spi_probe,
    .remove = ad5064_spi_remove,
    .id_table = ad5064_spi_ids,
};

I compiled the module and loaded it but the probe function never gets called. Why?

[John Syn]

From: <nwk...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Tuesday, July 29, 2014 at 7:33 AM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Using SPI in a kernel module

Thanks, John.

I Iooked at kernel/drivers/iio/dac/ad/5064.c

There's the following struct which is passed to spi_register_driver():

static struct spi_driver ad5064_spi_driver = {
    .driver = {
           .name = "ad5064",
           .owner = THIS_MODULE,
    },
    .probe = ad5064_spi_probe,
    .remove = ad5064_spi_remove,
    .id_table = ad5064_spi_ids,
};

I compiled the module and loaded it but the probe function never gets called. Why?

From this I can see that this driver isn’t DeviceTree enabled so I’m not sure which SPI interface it is using. Either you can add the devicetree support to this driver so that you can specify which SPI interface to use, or e-mail the Linux-IIO mailing list and see how to use this driver. 

Regards,

John

[liyaoshi]

Actually , I have write a driver based on iMX6 and V850 , implement via tty driver .

And suggest you follow kernel driver ifx6x60.c

Regards  

[Artie Lekstutis]

I'm looking for a replacement for my antique Trixbox Asterisk servers
using a BBB solution. One is a home system, the other is a small retail
operation. Both in reliable operation since 2008. Run part time by a
someone with a long term interest in Linux and communications systems (me).

The distribution http://www.beaglebone-asterisk.org/ is currently my
focus. Is there anything I should know about it (good or bad)? Is there
anything better for such use?

My occupation is embedded systems, not IT. I'd prefer to have a
reasonable GUI to manage the configuration where possible. FreePbx seems
to provide that in place of Trixbox. Not that I'm afraid of scripting or
re-building kernels, I just have other things to do too.

Thanks!
Artie Lekstutis

[William Hermans]

Running debian the BBB can run lxde, but it wont be like a current  x86 system experience. But for comparison, the BBB has the rPI trumped in all but graphics.

Artie Lekstutis

--
For more options, visit http://beagleboard.org/discuss
--- You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

[nwk...@gmail.com]

When I insmod ifx6x60.ko, its probe method isn't called either. Is there anything else I have to do?

[liyaoshi]

I mean you should follow the ifx6x60c driver struct . use tty driver as general out and input .

Dont' use sys_open .

[Artie Lekstutis]

In case anyone else is interested in running an Asterisk server on the BBB I've found that http://www.beaglebone-asterisk.org performs fairly well. Even better than on one of my older x86 systems. After doing some testing I'm ready for an initial deployment. Looks like it should be able to handle at least 6 simultaneous calls, which is more than I'll ever need. I'll post updates if I find anything interesting (good or bad).

It's running on a 64G micro-SD card:
    Ubuntu 14.04 LTS
    Asterisk 11.8.0
    FreePBX 2.11.0.35

Later,
Artie

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[bchen...@gmail.com]

Hello,
I saw your publish question about using SPI in a kernel module. I kind of stucking in this problem as well.
So i wonder if you find a solution?

 I know it's too late to ask, but i hope i'm lucky to get some feedback from you.

Regards,
Cheng

[John Syne]

It would be helpful if you explained what it is you are trying to do and then we will provide suggestions on how to proceed. 

Regards,

John

[Chengcong BAO]

Hello,

Thanks for replying firstly.

Actully, i am using beaglebone black with debian to developpe a system, which needs at least 72 I/Os (36 outputs, and 36 inputs for interruptions). So i use SPI and I/O expanders to controls the 36 outputs so that i have enough GPIOs for Inputs. I am writing an kernel module for the 36 interrupt inputs.

Now, my SPI is working in User-Space by using /dev/spidev1.0, but i want to integrate the SPI inside my kernel module as well. I wonder if it is possible? 
Because i want to measure the time between output and input (input signal is from a sensor). Since SPI is in user-space, so the output is not always sent in time, sometimes it has 4 or 5 ms delay, which it's a big deal to me.

Thanks,

Regards,

Cheng

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/k4LIScayF9M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[John Syne]

OK, you have several options on how to implement this. First, look in drivers/iio or drivers/staging/iio for example drivers that use SPI. If you use the RT kernel, you will see latency of less than 1mS, but if this isn’t good enough, then I recommend using the PRU to program the McSPI. For examples of how to program the McSPI natively, look at Starterware for example code. If you look on Github, the Starterware examples have been ported to the PRU. 

Regards,

John

[William Hermans]

OK, you have several options on how to implement this. First, look in drivers/iio or drivers/staging/iio for example drivers that use SPI. If you use the RT kernel, you will see latency of less than 1mS, but if this isn’t good enough, then I recommend using the PRU to program the McSPI. For examples of how to program the McSPI natively, look at Starterware for example code. If you look on Github, the Starterware examples have been ported to the PRU. 

Regards,

John

I'd actually recommend using the PRUs *OR* /dev/mem/ + mmap() if you need anything better than 100-200ms. The RT kernels are pretty good at reducing latency from what I've seen, but they still are not "perfect".

[John Syne]

/dev/mem/ + mmap() is always going to have more latency than kernel module because kernel code is executed at a higher priority that user space app. 

Regards,

John

[true...@web.de]

Hi John,

i try to drive the BBB McSPI with using the Pru.

Maybe you can help me to find your tip:"If you look on Github, the Starterware examples have been ported to the PRU".

Lot of thanks

Regards

Peter

[Gerhard Hoffmann]

Am 16.10.2018 um 10:38 schrieb true...@web.de:

Hi John,

i try to drive the BBB McSPI with using the Pru.

Maybe you can help me to find your tip:"If you look on Github, the Starterware examples have been ported to the PRU".

Lot of thanks

I have the very same problem. If you google around, you find sometimes some factoids, and that is
usually stuff like

/* SPIEN line is forced to low state.*/
McSPICSAssert(SOC_SPI_0_REGS, chNum);

/* Enable the Tx/Rx interrupts of McSPI.*/
McSPIIntEnable(SOC_SPI_0_REGS, MCSPI_INT_TX_EMPTY(chNum) |
                        MCSPI_INT_RX_FULL(chNum));

/* Enable the McSPI channel for communication.*/
McSPIChannelEnable(SOC_SPI_0_REGS, chNum);

Abstraction & insight gained == 0. Just repetition.

This all floats in the middle of nowhere. Guess where the header files are
or where some values hit some registers.
If you search on, you end up at a frozen Wiki or a locked discussion thread.

It seems, TI has given up on the Sitara. Maybe it is time to move on to Zynq.

regards, Gerhard

[John Syne]

I just did a quick search on Github for Starterware and found this:

https://github.com/kiran4399/starterware_PRU

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/dd56b1a5-b007-4e81-b812-389d268f6d85%40googlegroups.com.

[John Syne]

From what I read, TI are no longer maintaining Starterware, but there is a community driven development on Sourceforge:

https://sourceforge.net/projects/starterwarefree/

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/71279324-365b-2455-8a4d-375086008404%40hoffmann-hochfrequenz.de.

[Peter Armbrüster]

Great!

Thank you very much.

 

Best wishes

 

Peter.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2ED56849-19C4-4239-9C70-C9D654D68D5E%40gmail.com.

[John Syne]

BTW, you mentioned moving to Zynq, but that processor is more expensive than the complete BBB. Zynq eval boards or kits are even more expensive, not to mention the cost of tools, etc. One other problem is the learning curve is very steep if you want to take advantage of the FPGA features. Anyway, the applications for Zynq and BBB are completely different. I know, because I have looked at the possibility of using Zynq over the years and each time, I have given it a pass. 

I’m currently using PSOC6 (CortexM4 and CortexM0) for some of my projects (no Linux, using FreeRTOS) and it has a Verilog programmable frontend, which is much easier to learn. 

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/003801d465a2%246ea17790%244be466b0%24%40netcologne.de.

[Gerhard Hoffmann]

First, a lot of thanks for the pointer, that could really help.

What I really want to accomplish is to get at least a medium bandwidth interface

between the LAN and some real-time data aquisition units. The LAN side is

patterned after my Agilent 89441A vector signal analyzer. You simply open

port 5025 on 192.169.178.111 and dump/read there GPIB/IEEE488-like commands &

data streams. That side seems to work, although there is not yet much flesh

to it since the data collection side is still missing.

First I wanted to try the SPI interface, then the 16 bit multiplexed bus

to get an intelligent register interface to some FPGA.

For the SPI, I decided to attach a LT2500-32 ADC; that can do 1 Msample

at 24 bits. Add FFTW in the BBB and you have a respectable Fourier analyzer.

For the hardware, that's all that is needed:

<            https://www.flickr.com/photos/137684711@N07/45331444582/in/album-72157662535945536/        

      >

The Xilinx Coolrunner2 generates the sampling clock from the 100 MHz crystal osc. and collects

some left-over gates. $1.50 or so. The other small board is the ADC, its regulators and reference.

Home-etched and soldered.  :-)    It's completely open, in case someone wants it.

The SPI has soaked up much more time than I had planned. A new Debian image from

Robert and some other insights at least made that I don't get a bus error for each SPI access.

One gets thankful for small advances...  At least I can now create and start PRU programs,

talk to them via the shared RAM and transfer huge data blocks to Linux virtual memory land

through ping-pong buffers. It's just that I can't make the SPI say a word. Verbatim.  :-(

I also can finger the SPI pins when I re-assign them to the PRU and use R30/R31.

I also have a Red Pitaya. I like it architecture-wise, except that I'll need a larger FPGA

to support fast ADCs with JESDI204B ports - and that it is based on that exotic Alpine Linux.

FPGAs are a home game for me, I've used them since there has been Xilinx.

best regards,

Gerhard

[true...@web.de]

Hi Gerhard,

Maybe this 2 points helps for the Problem "bus errors":

1.

I had the same Problems at the standard Starterware mcspi, if I forget  "McSPI0ModuleClkConfig" in my Setup.

2. 

I found this tip "   /* check CM_PER enable status, or it may caue "Bus error" signal message. */"  in https://stackoverflow.com/questions/46677025/add-chip-select-hold-time-to-beaglebone-spi .

To the tip of John "Starterware in Pru": https://github.com/kiran4399/starterware_PRU

All spi code is the same as standard Starterware mcspi.

best wishes

Peter

[John Syne]

You might be interested in the FPGA design solutions from Analog Devices. They have FPGA designs for many of their high speed data acquisition devices. 

BTW, if you selected an ADC with a FIFO, then you could do the SPI comms in Linux using DMA, so there would be no need for PRU. 

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/09d5304e-5642-0db2-7755-596ee4ccb1a4%40hoffmann-hochfrequenz.de.