This is what I'm running.
Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l
It's a long story but this system has been growing in both hardware and
software for some time and we haven't wanted to rock the boat by upgrading.
Maybe now's the time.
I was wondering what won't work on the rt kernel?
Even if the SPI and code is SUPER fast it won't solve the problem if
something else takes over for more than 1/3 of a millisecond.
I'm not using the FIFO on the ADXL312 because it creates extra noise on the
signals. (it's a design problem in the chip).
The code is written in Python and it uses the PyBBIO library to handle the
SPI communication and GPIO.
Here's the snippet of code that is doing the tight loop grabbing the
accelerometer data:
*********************** begin snippet **************************************
try:
while sample_count < sensor_channel.samples_per_burst +
extra_samps_for_smoothing:
# wait for interrupt bit to go hi before grabbing the sample
while bbio.digitalRead(sensor_channel.accel_interrupt_gpio) ==
0:
loop_count += 1
if loop_count > max_loop_count:
break
# read the SPI data
spi_read_data = bbio.SPI0.transfer(0,
[((ADXL312_REG_INT_SOURCE_R | 0xC0)
<< 8), 0, 0, 0, 0])
enc_unpack = struct.unpack("<L", mem[EQEP2_POSITION:EQEP2_POSITION + 4])[0]
# INT_SOURCE spi_read_data[0] hi byte store in int_source
# nothing spi_read_data[0] lo byte
# DATA_FORMAT spi_read_data[1] hi byte
# DATAX0 spi_read_data[1] lo byte store in xlo
# DATAX1 spi_read_data[2] hi byte store in xhi
# DATAY0 spi_read_data[2] lo byte store in ylo
# DATAY1 spi_read_data[3] hi byte store in yhi
# DATAZ0 spi_read_data[3] lo byte store in zlo
# DATAZ1 spi_read_data[4] hi byte store in zhi
# FIFO_CTL spi_read_data[4] lo byte ignore
# it timed out, break out of the outer loop
if loop_count > max_loop_count:
break
# grab the bytes and put them in the right place
x_accel = (spi_read_data[2] & 0xFF00) | (spi_read_data[1] &
0x00FF)
y_accel = (spi_read_data[3] & 0xFF00) | (spi_read_data[2] &
0x00FF)
z_accel = (spi_read_data[4] & 0xFF00) | (spi_read_data[3] &
0x00FF)
# convert to +- 32767
if x_accel >= 32768:
x_accel -= 65536
if y_accel >= 32768:
y_accel -= 65536
if z_accel >= 32768:
z_accel -= 65536
BUFFA.append(x_accel)
BUFFA.append(y_accel)
BUFFA.append(z_accel)
BUFFP.append(enc_unpack)
# count the number of times data is missed
if spi_read_data[0] & 0x0001:
overrun_count += 1
sample_count += 1
except KeyboardInterrupt:
pass
*********************** end snippet **************************************
On Wednesday, August 3, 2016 at 6:22:03 PM UTC-7, William Hermans wrote:
>
>
>
> On Wed, Aug 3, 2016 at 3:50 PM, Kirk <[email protected] <javascript:>>
> wrote:
>
>> I have a scope on the SPI signals there is nothing I can see that is a
>> problem. The SPI hardware module is doing its job and clocking all the
>> bits.
>> It's recognizing the data ready, doing the SPI transfer, saving the data
>> with time to spare. (99% of the time anyway)
>>
>
> I can tell you that the SPI modules, as I recall are only set to run at
> 16Mhz ? Something much lower than these modules max out at. I seem to
> recall someone saying that these modules can easily run 50Mhz, but I can
> not think of the source from which I read that.
>
>>
>> To clarify, it's not overrunning a bit in the SPI word.
>> The problem is that the data ready bit comes at a steady 3200Hz and
>> sometimes it just doesn't get back in time for the next data transfer.
>> As far as I can tell no fault of the code I'm running.
>>
>
> Show us the code. You can't have anything we( who are programmers ) have
> not seen already. But this way we( I ) can examine the code and tell if you
> "we" see anything that can be a potential problem.
>
>
>> The code is focused only on the tight loop that monitors the data ready
>> bit and then uses the SPI to transfer the data.
>> I assume there must be things going on in Linux like WiFi communications
>> and Ethernet communications that interrupt my code.
>>
>> I'm using a somewhat older image.
>> What image should I use to get started working with the PRU?
>>
>> Kirk
>>
>
> It sounds like you might be running a 3.8.x kernel ? But you can start
> with any image. However, I might suggest you start off with the newest
> images. As changes have been made to make it simpler to use either
> remoteproc, or uio_pruss.
>
> So what the PRU will net you is a tighter loop, that runs outside of
> linux. So this means that your code can not be preempted by anything Linux.
> Pretty much, and put very basically. It'll be like running your code on a
> bare metal Cortex M3. NBut this Cortex M3 is special in that these do not
> have a instruction pipeline. Which means that instructions typically take
> only one cycle( 5ns ) There are multi cycle instructions, but you can do
> your best to stay away from those as much as possible. *If* you need to.
> Initially though, it seems like you'll have plenty of room, while still
> being able to maintain your needed timing.
>
> What I would recommend that you try first is upgrading your kernel, and
> upgrade to an rt kernel to see if that helps any. 4.x kernels by themselves
> already seem more responsive to me, but it is entirely possible all you'll
> need is an rt kernel. I've yet to test SPI on an rt kernel myself, but what
> I have done is parse 1Mbit worth of CANBUS data, in realtime, parse out,
> and send out via websockets around 1,000 seperate fields per second. So . .
> .
>
> $ sudo apt-get update
> $ apt-cache search linux-image |grep 4.4.*rt*
>
> And then just pick one of the newer bone, or TI kernels. Then give your
> code a whirl on that.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/ae767729-e733-434f-8533-86c31a9e657e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
