I’m having a serious problem with Beaglebone + SPI.
I am able to send data to and read data for SPI, but my application requires that I put the pin 1 and maximum 5us after I send SPI data. This pin is not the chip-select. After that such pin need be in level one indefinitely.
First used GPIO writing directly into memory (which greatly increase performance), but the time between the writing and the writing on the pin SPI is still 50 us.
setfast_pin (MCLR) / / Pin at high level
write (fd, & tx , 1); / / Write SPI
I’m looking at the times on the oscilloscope. Writing in SPI is perfect. But between the time the instruction write (fd, & tx , 1), and transmission is in 50us.
Can anyone help me?
I am sure you are aware that Linux kernel is not a real time kernel so if timing has to be kept in an absolute condition you must first look at either Xenomia, RTAI et al. to ensure proper kernel response
If you are not interested in doing that would like to “wing” it, here is the deal.
Your code has two individual entities as viewed by the kernel, 1. Change the status of GPIO and 2. Call the function to write to SPI device. Since they are two individual functions the kernel can insert any number of tasks in between them.
The simplest way in my opinion is to change the SPI driver and map the chip select pin inside the driver to the GPIO pin you are using.
You can also change the chip_select pin inside of the platform config header file as well.
You can also consider adding this chip select as an addition to the pre-existing chip select inside of the driver. Idea remains the same don’t let the kernel think that this pin function is septate from the spi write function
I am not giving you any file names or paths because, I deal with beagleboard, some of the file names and paths are completely different.
you can start with “linux-x.x.x/arch/arm” in you kernel director.
Hope this helps.
I am also using this methodology and have found that GPIO toggling has it limits. My implementation is in a kernel module and the time between toggling the GPIO and starting the SPI is quite large. I can't remember from the top of my head but I will see if I can have a look today.
This is the fastest I can currently get. I have heard I may be able to improve it by upping the frequency of a clock in the kernel somewhere but I haven't fully investigated this yet.
Yellow: Write Latch (Chip Select)
As you can see it is roughly 50-60us. This is using the gpiolib and spi functions from within the kernel.
It’s exactly what I was thinking, to develop a driver for my specific application. I’ll investigate further.
Thank you for your attention!
Their waveforms are exactly the same that I got here. I can not imagine that I can not perform this operation through my Beaglebone …
Does desevolvendo I’ll get the appropriate driver perform this operation?
You might get much better bandwidth/timing using the GPMC bus.
Using spi_read() and gpio_set_value() I can get about 20 us between
chip select high and a GPIO toggle . Chip select high being my
marker for the SPI operation completing.
This is done in a kernel module. I'm not using the GPIO as a chip
select, like Jack. The GPIO is an out of band signal to the SPI slave.
I don't expect much better than this is easily doable but may be