Yes, I was talking about trying to do hard real-time data collection in a user-space program. If you look at the maximum interrupt latencies from other stuff running on the system, then you see just why PRUs are necessary to always meet your deadlines. Most of the time, a user-space program running mmap to access gpios will run up at Mhz speeds but every now and then one of your data samples might be 100 msec late because something else was running. That kind of irregular sampling makes an FFT worthless. (But there certainly are some slower speed control applications where that kind of latency is perfectly okay.)

I have a program that runs the SPI0 port as a slave, and it can be clocked by the master SPI device at 12-16 MHz because my protocol never overflows the SPI FIFOs. I had to use mmap, so I could set SPI control registers in ways no Linux drivers support.

On 6/5/2014 11:53 AM, Brandon I wrote:
> but you can't run the clock much faster than 1 KHz using a user-space program 
under Linux.

Not true at all! You can get over 3MHz just fine with mmap to the gpio registers. If you try to open and close a file each gpio toggle, like the insanely inefficient sysfs interface, then yeah...you'll be severely limited, but still much faster than 1kHz.

Did you google? http://e2e.ti.com/support/arm/sitara_arm/f/791/t/296484.aspx

On Thursday, June 5, 2014 8:31:24 AM UTC-7, William Hermans wrote:

    Sounds like fun. Good luck :)


    On Wed, Jun 4, 2014 at 2:17 PM, <swapn...@gmail.com> wrote:

        Hey William...

        I do know that the Chip Select line can be used to toggle
        between different SPI units... But I need data to be collected
        simultaneously from multiple sensors... As of now I have 32
        sensors - I have clubbed them into groups of 4 and so I have 8
        sets of SPI units that I want to communicate with
        "simultaneously"...


        On Wednesday, June 4, 2014 11:46:21 AM UTC-4, William Hermans
        wrote:

            It sounds as though you need to read more concerning what
            SPI actually *is*.

                /Devices communicate in master/slave mode where the
                master device initiates the data frame. Multiple slave
                devices are allowed with individual slave select
                lines. Sometimes SPI is called a four-wire serial bus,
                contrasting with three-, two-, and one-wire serial
                buses. SPI is often referred to as SSI (Synchronous
                Serial Interface)./


            http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
            <http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus>

            What does this mean ? Multiple devices can share the same
            data bus, and only CS( chip select ) needs be different
            for each device. CS only needs to go high, or low, which
            hey remarkably is exactly what GPIO pins do ! :)


            On Wed, Jun 4, 2014 at 7:37 AM, <swapn...@gmail.com> wrote:

                I am trying to run multiple SPI modules (more than the
                two available on the BBB) to try and read data from a
                bunch of accelerometers (LSM303D).

                I was therefore wondering if it would be possible to
                implement the SPI module using code (preferably C/C++)
                on the abundant GPIO pins. I have been scanning
                through a lot of documentation but I cant seem to find
                anything that fits the bill.

                Please help --- getting desperate...


-- 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
                <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.
        For more options, visit https://groups.google.com/d/optout
        <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+unsubscr...@googlegroups.com <mailto:beagleboard+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to