> On Feb 13, 2018, at 1:55 PM, pierrick.ra...@gadz.org wrote:
> 
> Thank you for your quick answerJohn! 
> 
> So if I understand well, I can use the PRUs with the on-board SPI and I2C 
> interface ?  I have not found any similar project that can help me on this. 
> Is it done using the L2 and L3 interconnect ? I am highly interested by using 
> those on board interface with the PRUs, but it seems that I still need to 
> learn a lot about this. 
The PRU has access these peripherals in the same way the ARM does. There is a 
github project that took the Starterware code for these peripherals and adapted 
them for the PRU.
> 
> For the ADC, my future application is going to be time critical, by this I 
> mean that I want to sample data at around 5khz to 10khz. Is the IIO driver 
> able to execute real-time data acquisition while the ARM is processing the 
> data? 
The IIO driver can sample at 200KHz and higher (don’t remember the upper 
limit). When you say real-time, you need to explain what you mean. For me, it 
means deterministic and in the case of the IIO driver, it samples the ADC at a 
constant sample rate, even if the CPU is under load, so it is deterministic. 
Now if you are doing close loop control, then you have the Linux Kernel 
interrupt latency to deal with and that is deterministic to about 1mS. 

Regards,
John
> 
> Thanks 
> 
> 
> Pierrick 
> 
> Le mardi 13 février 2018 15:43:09 UTC-5, john3909 a écrit :
> 
> 
>> On Feb 13, 2018, at 9:49 AM, pierric...@gadz.org <> wrote:
>> 
>> Hi all, 
>> 
>> I am trying to use the PRUs for real time data acquisition on the Beaglebone 
>> black (Linux debian 4.9.45-ti-r57). I have set up the PRU with remoteproc 
>> and RPMsg; everything is working fine. 
>> The first time, I successfully captured data with the PRU using the SPI 
>> protocol and bit banging, and I have sent them to the ARM with RPMsg. 
>> 
>> Now I want to do the same thing using the I2C protocol, which left me with 
>> some questions: 
>> - Is it possible to use the on-board I2C bus with the PRUs? 
> Yes, and you can also control the SPI interface with the PRU as well. No need 
> to do bit banging. 
>> - If not, I will enable the pull-up resistor on a GPIO pins using a custom 
>> device tree. But after that, I do not really understand how I can read and 
>> write the SDA line for I2C? (Contrary to the SPI protocol, I won't have Data 
>> In and  Data out lines but only one SDA line).
> If you wish to bit bang the I2C, you need to create a state machine for I2. 
> You start by outputting the “Address” together with “Read/Write” bit and then 
> the “Data”, and then tristate the SDA line and wait for it to go high, which 
> is the “Ack” from the slave device. After that, you simply toggle the clock 
> line and read back the “Data” line. 
>> 
>> My final goal will be to use the on-board ADC. There is already a very 
>> interesting project PRUADC that captures data using an external ADC. I would 
>> like to use the on-board ADC, is there any way to do it ? (I am not afraid 
>> of going into complex stuff). 
> Yes, you can access the ADC with the PRU, but not sure why you would want to 
> do that unless you are doing some closed loop control function. If you are 
> simply reading the ADC and sending that info to the ARM, is is better to use 
> the IIO driver. This driver uses DMA to transfer the samples to memory and 
> the timing between the samples is controlled via the device tree.
> 
> Regards,
> John
>> 
>> Thanks,
>> 
>> 
>> Pierrick 
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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/ed0d2be5-9c7f-4fe1-8e79-1f494bde023b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/ed0d2be5-9c7f-4fe1-8e79-1f494bde023b%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8d0c8de1-659d-4b07-9d0a-4a284619992b%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/8d0c8de1-659d-4b07-9d0a-4a284619992b%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/78D7F39A-669C-467C-9A54-DB17A40F15F6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to