Re: [beagleboard] Using PTP with Beaglebone black

[John Syne]

Here is some additional info that might be helpful.

http://processors.wiki.ti.com/index.php/ICSS_PTP_1588_Developer_Guide


Regards,
John





> On Dec 5, 2018, at 4:14 PM, BBB _user  wrote:
> 
> I am a student trying to implement PTP using BBB. I have studied that there 
> are BBB images that already have HW timestamps enabled.
> Is there any easy way that I can follow to implement PTP without having to 
> compile a Linux kernel by myself?
> Any help in this regard is much appreciated.
> 
> -- 
> 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/af3e19bb-94ed-410d-b259-2185b23075ab%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F21D8033-13FE-43CA-986A-CFD5A81F31B3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using PTP with Beaglebone black

[John Syne]

This discussion on E2E might be helpful.

https://e2e.ti.com/support/processors/f/791/t/539697


Regards,
John





> On Dec 7, 2018, at 5:33 AM, Tarmo Kuuse  wrote:
> 
> On Friday, 7 December 2018 02:06:46 UTC+2, BBB _user wrote:
> I am a student trying to implement PTP using BBB. I have studied that there 
> are BBB images that already have HW timestamps enabled.
> Is there any easy way that I can follow to implement PTP without having to 
> compile a Linux kernel by myself?
> Any help in this regard is much appreciated.
> 
> Without knowing anything about PTP, Debian has a package ptpd - perhaps that 
> is what you're looking for.
> 
> --
> Kind regards,
> Tarmo
> 
> -- 
> 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/10b6b5f7-b051-4a5c-90ae-a9a27548ac89%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/315735B6-1774-4839-8031-D01BC3CD5B9D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using SPI in a kernel module

[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





> On Oct 17, 2018, at 4:20 AM, Gerhard Hoffmann  
> wrote:
> 
> 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/
>  
> <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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Am 17.10.2018 um 04:43 schrieb 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
>> 
>> 
>> 
> 
> 
> -- 
> 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/09d5304e-5642-0db2-7755-596ee4ccb1a4%40hoffmann-hochfrequenz.de
>  
> <https://groups.google.com/d/msgid/beagleboard/09d5304e-5642-0db2-7755-596ee4ccb1a4%40hoffmann-hochfrequenz.de?utm_medium=email_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/FF6A7857-5B9A-49D5-AF05-D770D7A41F85%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using SPI in a kernel module

[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





> On Oct 16, 2018, at 3:49 PM, 'Peter Armbrüster' via BeagleBoard 
>  wrote:
> 
> Great!
> Thank you very much.
>  
> Best wishes
>  
> Peter.
>  
>  
>  
> Von: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] Im 
> Auftrag von John Syne
> Gesendet: Mittwoch, 17. Oktober 2018 00:41
> An: beagleboard@googlegroups.com
> Betreff: Re: [beagleboard] Using SPI in a kernel module
>  
> From what I read, TI are no longer maintaining Starterware, but there is a 
> community driven development on Sourceforge:
>  
> https://sourceforge.net/projects/starterwarefree/ 
> <https://sourceforge.net/projects/starterwarefree/>
>  
> 
> Regards,
> John
>  
>  
>  
> 
> 
> 
>> On Oct 16, 2018, at 4:47 AM, Gerhard Hoffmann > <mailto:g...@hoffmann-hochfrequenz.de>> wrote:
>>  
>>  
>>  
>> Am 16.10.2018 um 10:38 schrieb true-t...@web.de <mailto:true-t...@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
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>> -- 
>> 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/71279324-365b-2455-8a4d-375086008404%40hoffmann-hochfrequenz.de
>>  
>> <https://groups.google.com/d/msgid/beagleboard/71279324-365b-2455-8a4d-375086008404%40hoffmann-hochfrequenz.de?utm_medium=email_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/2ED56849-19C4-4239-9C70-C9D654D68D5E%40gmail.com
>  
> <https://groups.google.com/d/msgid/beagleboard/2ED56849-19C4-4239-9C70-C9D654D68D5E%40gmail.com?utm_medium=email_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/discu

Re: [beagleboard] Using SPI in a kernel module

[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





> On Oct 16, 2018, at 4:47 AM, Gerhard Hoffmann  
> wrote:
> 
> 
> 
> 
> Am 16.10.2018 um 10:38 schrieb true-t...@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
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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/71279324-365b-2455-8a4d-375086008404%40hoffmann-hochfrequenz.de
>  
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2ED56849-19C4-4239-9C70-C9D654D68D5E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using SPI in a kernel module

[John Syne]

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

https://github.com/kiran4399/starterware_PRU 
<https://github.com/kiran4399/starterware_PRU>


Regards,
John





> On Oct 16, 2018, at 1:38 AM, true-t...@web.de wrote:
> 
> 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
> 
> 
> 
> Am Dienstag, 5. Januar 2016 21:32:51 UTC+1 schrieb john3909:
> 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
> 
> 
> 
> 
>> On Jan 5, 2016, at 4:57 AM, Chengcong BAO > wrote:
>> 
>> 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 
>> 
>> 2016-01-04 19:20 GMT+01:00 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
>> 
>> 
>> 
>> 
>>> On Jan 4, 2016, at 1:34 AM, bchen...@gmail.com <> wrote:
>>> 
>>> 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
>>> 
>>> Le lundi 28 juillet 2014 16:00:59 UTC+2, Nils a écrit :
>>> 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
>>> 
>>> -- 
>>> 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 <>.
>>> 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 a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/k4LIScayF9M/unsubscribe 
>> <https://groups.google.com/d/topic/beagleboard/k4LIScayF9M/unsubscribe>.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleb

Re: [beagleboard] Problem to configurate the GPIO as inputs in the Beaglebone black

[John Syne]

There needs to be a space between sudo and /opt/scripts/tools/version.sh like 
this:
sudo /opt/scripts/tools/version.sh

Regards,
John





> On Oct 8, 2018, at 6:31 PM, Krish Nachimuthu  wrote:
> 
> Hi all,
> I tried sudo python and sudo python3 and it did not work.
> 
> Hi Robert,
> I tried sudo/opt/scripts/tools/version.sh but it displayed "command not 
> found". Attached is the snapshot for your reference.
> 
> I have LCD, motorbridge capes and MAX3223E eval board (communicating through 
> UART4) connected to my BBB. I tried updating bootloader and kernel, and it 
> disabled SPI 2 and GPIO input is not working as well. Please comment on this 
> issue. Your help is much appreciated.
> 
> Thanks and regards,
> Krish.
> 
> On Tue, 9 Oct 2018 at 09:10, Hugo Casal  > wrote:
> Hello 
> 
> I used sudo python command and the issue was solved.
> 
> Now, I can run the code line, GPIO.input ("P9_15", GPIO.IN )
> 
> I am going to continue writing my script to my telemetry project.
> 
> I thank you very much for the help.
> 
> 
> 
> 
> El sáb., 6 oct. 2018 a las 16:43, Robert Nelson ( >) escribió:
> 
> 
> On Sat, Oct 6, 2018 at 1:10 PM Hugo Casal  > wrote:
> 
> Hello
> 
> Thank for your response 
> 
> Bellow can you find a print screen with the information you ask me. I just 
> write a short  code to show the error . I tried to write the line  print 
> ("test") , but the program always generate an error message and is not 
> possible write the line .   
> 
> 
> Please run and the share the output of:
> 
> sudo /opt/scripts/tools/version.sh
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/ 
> 
> -- 
> 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/CAGvkCdW608oTLajLDFm%3DrL-h74HiU3jH5OaYi9V61X%3D70Ah%3Dpg%40mail.gmail.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOBTkVqnSM%3DKEKq1SV3iv3EbwJWrV6Qk9muiMX0U%3DcmRSFHTmA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C98EBD5D-CDD1-4787-B073-F83F93CD0952%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On May 21, 2018, at 6:20 AM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks for the answer, I did use u-boot overlays and setup the uEnv.txt to 
> load the right overlay. BTW, I am rebooting the BeagleBone every-time I want 
> to load a new overlay, can you confirm that it's the only way to do it ? 
Yes, you have to reboot every time you modify the overlay, but you should only 
modify the overlay once.
> 
> I'll try to use the IIO Oscilloscope, however as I have access to a "real" 
> oscilloscope so I am not sure to understand how it can help me... 
> Finally, I think I've found my mistake this weekend. The input voltage was to 
> low (i've built a tension divider bridge between the generator and the input 
> of the ADC...)so basically I was measuring noises. However, do you know if 
> there is an auto-scale on the iio driver, indeed the "noises" where scaled to 
> the entire range of the ADC.
The IIO Oscilloscope (OSC) is just an easy way to see that the IIO driver is 
working correctly. As you modify this input, you can see the waveform update on 
the OSC dynamically. So the way this works, the ADC driver reads the analog 
inputs and forwards them to the IIO buffer. The IIOD (iio deamon provided by 
the libiio repo [1]) makes the IIO sysfs and buffer available over TCP/IP. The 
OSC running on your host PC connects to the IIOD running on your BBB so that it 
can display all the info from the ADC driver. You can enable channels, display 
waveforms of one or more channels and also display FFT of these waveforms. 

1 https://github.com/analogdevicesinc/libiio 



Regards,
John
> 
> TJF, 
> Thanks for the help,I tried to use libiio but i was not successful when it 
> came to read the data, i was read (nil) instead of my data (I am adding the 
> code I was using at the end of this message). That is why I change and used 
> the iio_generic_buffer.c example. BTW, is libpruio working with the latest 
> kernels, remoteproc and rpmsg? 
> 
> #define _GNU_SOURCE
> #define _DEFAULT_SOURCE
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #ifdef __APPLE__
> #include 
> #else
> #include 
> #endif
> 
> struct iio_context *ctx;
> struct iio_device *dev;
> struct iio_channel *ch;
> 
> int main()
> {
>   ctx = iio_create_default_context();
>   dev = iio_context_get_device(ctx, 0);
>   ch = iio_device_get_channel(dev, 3);
> 
> 
>   iio_device_attr_write_
> longlong(dev, "sample_rate", 100);
>   iio_channel_attr_write_double(ch, "scale", 1);
> 
>   iio_channel_enable(ch);
> 
>   char *a = iio_device_get_data(dev);
>   printf("%p\n", a);
> 
>   iio_channel_disable(ch);
> 
>   return 0;
> }
> 
> 
> 
> Le samedi 19 mai 2018 23:52:13 UTC-4, TJF a écrit :
> Hi Pierrick!
> 
> Have you tried libpruio  yet? It makes one 
> PRU fetching samples from the internal ADC. Parameters are controled from the 
> ARM side. Everything can get configured in user space (sampling rate, active 
> channels, avaraging, and more). Device tree action is only necessary once in 
> the install process. This make programming and testing much more easy.
> 
> 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?
> 
> In such a case I'll start with ADC input by libpruio and a controller loop on 
> the ARM. When real-time requirements cannot get fulfilled, the controller 
> loop can get shifted to the second PRU later in the development process.
> 
> Regards
> 
> -- 
> 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/9f646186-6e07-4e64-a9cc-65b1704ae9a2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/588E6C1B-EA2F-48F6-9FA0-96954A6CDC9F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

BTW, you can run iiod on your BBB and then use IIO Oscilloscope on you desktop 
which can connect to your BBB and display the waveforms. 


https://wiki.analog.com/resources/tools-software/linux-software/iio_oscilloscope
 



Regards,
John





> On May 18, 2018, at 4:57 PM, pierrick.ra...@gadz.org wrote:
> 
> 
> John, 
> I am still working on this project. I have studied the iio_generic_buffer.c 
> and adapted it to save the result of the sampling in a csv file. I was 
> testing it today with a waveform generator in the following configuration:
> - signal frequency : 1Hz (sin function)
> - signal amplitude: 1V
> - averaging 8 times
> 
> I took 1000 samples (buffer length 1000), I then displayed the result and 
> instead of a constant horizontal line, i had a sinus-like curve (attached as 
> 8 average sin 1Hz 1000 samples). 
> 
> I tried with higher frequencies such as 20khz and i have a similar result but 
> with a "pulse" which, as far as understand corresponds to the signal I want 
> to sample ( attached as 8 average sin20kHz).
> 
> In both cases, I have some "waves" that does not seems to be linked to the 
> frequency of the signal... 
> 
> I guess something is wrong in my iio_generic_buffer.c like i am not reading 
> the data at the right place... but i do not really know what kind of error I 
> should look for, I am also attaching it to this post (maybe it can help). 
> The changes I made are from the patch on this page : 
> https://www.teachmemicro.com/beaglebone-black-adc/ and I also modified the 
> process_scan(), print2byte() function and the main (~line 650) to save the 
> value in a csv file instead of just printing them. 
> 
> If you can give me an hint of where my error could be it would be very 
> helpful. 
> 
> Thanks a lot,
> 
> Pierrick 
> 
> 
> Le mardi 17 avril 2018 00:19:16 UTC-4, john3909 a écrit :
> 
> 
> 
>> On Apr 16, 2018, at 3:40 PM, pierric...@gadz.org <> wrote:
>> 
>> Hi John, 
>> Thanks a lot for this very complete answer ! I think I understand it now, 
>> the last point I am not sure about is:
>> 
>> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */ 
>> 
>> I went through  12.3.3 of the AM3358 Technical Reference Manual and it seems 
>> that the setting the averaging value to 1 disable the averaging (instead of 
>> setting it to 2) am I right? 
>> Thanks again for your help 
> If you look in the AM3358 TRM, it says 0 will disable averaging and 1 will 
> average over two samples.
> 
> From the TRM
> 
> Number of samplings to average:
> 000 = No average.
> 001 = 2 samples average.
> 010 = 4 samples average.
> 011 = 8 samples average.
> 100 = 16 samples average.
> 
> Regards,
> John
>> 
>> Le mercredi 11 avril 2018 17:00:54 UTC-4, john3909 a écrit :
>> 
>> 
>>> On Apr 11, 2018, at 6:04 AM, pierric...@gadz.org <> wrote:
>>> 
>>> Hi John, 
>>> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
>>> patched it to disable the hardware triggers thanks to the patch presented 
>>> on this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>>>  I am now able to 
>>> reader a buffer from the different channel. 
>>> However I have 2 majors questions that remains:
>>> 
>>> 1) I only want to use on channel, then I do not want the ADC to sample the 
>>> other one so that i'll have the maximum sampling rate. What is the best way 
>>> to disable the channel? If I do not enable them in iio_generic_buffer.c I 
>>> am not sure that the ADC is not going to sample this channel or not (well, 
>>> I think it wont sample but I prefer to be sure). Is it preferable to not 
>>> mention them on the devicetree so that Linux wont know that there are 
>>> multiple channels on the ADC? This part is not very clear for me. 
>>> 
>>> 2) To change the sample frequency of the ADC you mentioned that it is done 
>>> using the device tree however I did not find any argument on the ADC 
>>> devicetree to change the sampling frequency. I read the discussion you had 
>>> on this post (https://patchwork.kernel.org/patch/9391487/ 
>>>  ) but it is not clear if the 
>>> frequency setting is done using the kernel module or devicetrees. Could you 
>>> explain me this please? 
>> Looking at this a little more, there is a mistake in the ADC DT file 
>> BB-ADC-0A00.dts. The maximum averaging is 16, not 0x16.
>> 
>> The line
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16 0x16>
>> 
>> should be changed to
>> ti,chan-step-avg = <16 16 16 16 16 16 16 16>
>> Fortunately, the driver does a range check and sets the value to 16. 
>> 
>> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
>> ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
>> ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>
>> 
>> To achieve a conversion rate of 800 KS/s
>> 
>> From ti_am335x_tscad.c, 1 + (1 + 13) * 2 = 30 cycles
>> 
>> The ADC 

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

If you are using the latest kernel, you must use u-boot overlays as the kernel 
capemanager as discussed in that article is no longer available.

Regards,
John





> On May 18, 2018, at 4:57 PM, pierrick.ra...@gadz.org wrote:
> 
> 
> John, 
> I am still working on this project. I have studied the iio_generic_buffer.c 
> and adapted it to save the result of the sampling in a csv file. I was 
> testing it today with a waveform generator in the following configuration:
> - signal frequency : 1Hz (sin function)
> - signal amplitude: 1V
> - averaging 8 times
> 
> I took 1000 samples (buffer length 1000), I then displayed the result and 
> instead of a constant horizontal line, i had a sinus-like curve (attached as 
> 8 average sin 1Hz 1000 samples). 
> 
> I tried with higher frequencies such as 20khz and i have a similar result but 
> with a "pulse" which, as far as understand corresponds to the signal I want 
> to sample ( attached as 8 average sin20kHz).
> 
> In both cases, I have some "waves" that does not seems to be linked to the 
> frequency of the signal... 
> 
> I guess something is wrong in my iio_generic_buffer.c like i am not reading 
> the data at the right place... but i do not really know what kind of error I 
> should look for, I am also attaching it to this post (maybe it can help). 
> The changes I made are from the patch on this page : 
> https://www.teachmemicro.com/beaglebone-black-adc/ and I also modified the 
> process_scan(), print2byte() function and the main (~line 650) to save the 
> value in a csv file instead of just printing them. 
> 
> If you can give me an hint of where my error could be it would be very 
> helpful. 
> 
> Thanks a lot,
> 
> Pierrick 
> 
> 
> Le mardi 17 avril 2018 00:19:16 UTC-4, john3909 a écrit :
> 
> 
> 
>> On Apr 16, 2018, at 3:40 PM, pierric...@gadz.org <> wrote:
>> 
>> Hi John, 
>> Thanks a lot for this very complete answer ! I think I understand it now, 
>> the last point I am not sure about is:
>> 
>> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */ 
>> 
>> I went through  12.3.3 of the AM3358 Technical Reference Manual and it seems 
>> that the setting the averaging value to 1 disable the averaging (instead of 
>> setting it to 2) am I right? 
>> Thanks again for your help 
> If you look in the AM3358 TRM, it says 0 will disable averaging and 1 will 
> average over two samples.
> 
> From the TRM
> 
> Number of samplings to average:
> 000 = No average.
> 001 = 2 samples average.
> 010 = 4 samples average.
> 011 = 8 samples average.
> 100 = 16 samples average.
> 
> Regards,
> John
>> 
>> Le mercredi 11 avril 2018 17:00:54 UTC-4, john3909 a écrit :
>> 
>> 
>>> On Apr 11, 2018, at 6:04 AM, pierric...@gadz.org <> wrote:
>>> 
>>> Hi John, 
>>> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
>>> patched it to disable the hardware triggers thanks to the patch presented 
>>> on this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>>>  I am now able to 
>>> reader a buffer from the different channel. 
>>> However I have 2 majors questions that remains:
>>> 
>>> 1) I only want to use on channel, then I do not want the ADC to sample the 
>>> other one so that i'll have the maximum sampling rate. What is the best way 
>>> to disable the channel? If I do not enable them in iio_generic_buffer.c I 
>>> am not sure that the ADC is not going to sample this channel or not (well, 
>>> I think it wont sample but I prefer to be sure). Is it preferable to not 
>>> mention them on the devicetree so that Linux wont know that there are 
>>> multiple channels on the ADC? This part is not very clear for me. 
>>> 
>>> 2) To change the sample frequency of the ADC you mentioned that it is done 
>>> using the device tree however I did not find any argument on the ADC 
>>> devicetree to change the sampling frequency. I read the discussion you had 
>>> on this post (https://patchwork.kernel.org/patch/9391487/ 
>>>  ) but it is not clear if the 
>>> frequency setting is done using the kernel module or devicetrees. Could you 
>>> explain me this please? 
>> Looking at this a little more, there is a mistake in the ADC DT file 
>> BB-ADC-0A00.dts. The maximum averaging is 16, not 0x16.
>> 
>> The line
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16 0x16>
>> 
>> should be changed to
>> ti,chan-step-avg = <16 16 16 16 16 16 16 16>
>> Fortunately, the driver does a range check and sets the value to 16. 
>> 
>> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
>> ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
>> ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>
>> 
>> To achieve a conversion rate of 800 KS/s
>> 
>> From ti_am335x_tscad.c, 1 + (1 + 13) * 2 = 30 cycles
>> 
>> The ADC uses a 24 MHz clock, so 1/24,000,000 * 15 = 800 KS/s
>> 
>> You could increase the sampling rate to 1.6MS/s by changing the average to 
>> 0, which means there 

Re: [beagleboard] PRU examples are half there

[John Syne]

BTW, I seem to remember that I had to modify the code to work because RPMSG use 
to use mailbox to exchange messages, but that was changed to use Interrupts.  I 
believe Jason Reeder from TI helped me get this working. 

Regards,
John





> On May 7, 2018, at 12:47 PM, Mark A. Yoder  wrote:
> 
> John:
>   That's a great help.  Is the documentation for the example?
> 
> --Mark
> 
> On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote:
> https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
>  
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On May 7, 2018, at 8:19 AM, Mark A. Yoder > wrote:
>> 
>> Yup, all I see is the PRU code, no ARM code.
>> 
>> --Mark
>> 
>> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>> Did you look at http://git.ti.com/pru-software-support-package 
>>  ?
>> 
>> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
>> 
>>> I'm starting to build up some remoteproc-based examples for the PRU and 
>>> found a bunch of examples here:  
>>> /usr/lib/ti/pru-software-support-package/examples.
>>> 
>>> But the examples are only half there.  That is, the code is present for the 
>>> PRU side but not the ARM side.
>>> 
>>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
>>> interrupt to the ARM, but there is no example code for the ARM side.
>>> 
>>> Anyone know where the ARM code is?
>>> 
>>> Thanks...
>>> 
>>> --Mark
>>> 
>>> -- 
>>> 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/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.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 <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/807cdbb4-3cf2-4086-ae1a-319ff4f5d4e1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/07260740-530F-4A49-BEA4-27D83FFDA9FF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[John Syne]

Yeah, I haven’t worked on this for a while, but from what I remember, the ARM 
side sends out 200 ping messages to the PRU and the PRU responds to each 
interrupt with a reply, which the ARM side prints out. Look for the PING 
example for the PRU, load the firmware and then load this Kernel Module. 

Regards,
John

Regards,
John





> On May 7, 2018, at 12:47 PM, Mark A. Yoder  wrote:
> 
> John:
>   That's a great help.  Is the documentation for the example?
> 
> --Mark
> 
> On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote:
> https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
>  
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On May 7, 2018, at 8:19 AM, Mark A. Yoder > wrote:
>> 
>> Yup, all I see is the PRU code, no ARM code.
>> 
>> --Mark
>> 
>> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>> Did you look at http://git.ti.com/pru-software-support-package 
>>  ?
>> 
>> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
>> 
>>> I'm starting to build up some remoteproc-based examples for the PRU and 
>>> found a bunch of examples here:  
>>> /usr/lib/ti/pru-software-support-package/examples.
>>> 
>>> But the examples are only half there.  That is, the code is present for the 
>>> PRU side but not the ARM side.
>>> 
>>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
>>> interrupt to the ARM, but there is no example code for the ARM side.
>>> 
>>> Anyone know where the ARM code is?
>>> 
>>> Thanks...
>>> 
>>> --Mark
>>> 
>>> -- 
>>> 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/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.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 <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/807cdbb4-3cf2-4086-ae1a-319ff4f5d4e1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5759B607-1D37-455A-9691-48323953FA8D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[John Syne]

https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
 



Regards,
John





> On May 7, 2018, at 8:19 AM, Mark A. Yoder  wrote:
> 
> Yup, all I see is the PRU code, no ARM code.
> 
> --Mark
> 
> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
> Did you look at http://git.ti.com/pru-software-support-package 
>  ?
> 
> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
> 
>> I'm starting to build up some remoteproc-based examples for the PRU and 
>> found a bunch of examples here:  
>> /usr/lib/ti/pru-software-support-package/examples.
>> 
>> But the examples are only half there.  That is, the code is present for the 
>> PRU side but not the ARM side.
>> 
>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an interrupt 
>> to the ARM, but there is no example code for the ARM side.
>> 
>> Anyone know where the ARM code is?
>> 
>> Thanks...
>> 
>> --Mark
>> 
>> -- 
>> 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/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C3E4538C-4265-479F-99E9-ECB61F6C9515%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] ADC frequency sample calculus using PRU and C code on BBB

[John Syne]

Why don’t you use the IIO ADC driver which can sample as 800Ksps? The sampling 
frequency is calculated as follows:

In the file BB-ADC-0A00.dts, you must configure the following settings:

ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>

To achieve a conversion rate of 800 KS/s

>From include/linux/mfd/ti_am335x_tscad.c

/*
 * time in us for processing a single channel, calculated as follows:
 *
 * max num cycles = open delay + (sample delay + conv time) * averaging
 *
 * max num cycles: 262143 + (255 + 13) * 16 = 266431
 *
 * clock frequency: 26MHz / 8 = 3.25MHz
 * clock period: 1 / 3.25MHz = 308ns
 *
 * max processing time: 266431 * 308ns = 83ms(approx)
 */

So, with the settings in the dts file, we have 1 + (1 + 13) * 2 = 30 cycles

The ADC uses a 24 MHz clock, so 1/24,000,000 * 15 = 800 KS/s

You could increase the sampling rate to 1.6MS/s by changing the average to 0, 
which means there is no averaging. To achieve this, the minimum number of 
cycles for a conversion is 15 (12.3.7 of the AM3358 Technical Reference Manual)

1 + (1 + 13) * 1 = 15 cycles

which will give you 1.6 MS/s

To use the IIO driver, do the following:

1) Make sure you have enabled BB-ADC-0A00.dtbo in the Env.txt file
2) echo 1 >  /sys/bus/iio/devices/iio:device0/scan_elements/in_voltage0_en
echo 1 >  /sys/bus/iio/devices/iio:device0/scan_elements/in_voltage1_en
Enable as many channels as you need
3) echo 1 >  /sys/bus/iio/devices/iio:device0/buffer/enable // Starts sample 
capture
4) Read samples from char driver /dev/iio:device0 (in the kernel, under 
tools/iio, you will find examples on how to do this, like iio_generic_buffer.c)
5) echo 0 >  /sys/bus/iio/devices/iio:device0/buffer/enable // Stops sample 
capture


Regards,
John





> On Apr 26, 2018, at 3:27 PM, maique.gar...@gmail.com wrote:
> 
> Hi friends. Im trying to use the BBB built-in ADC to read values with regular 
> sampling frequency. I am using almost all defined by Rafael Vega's github 
> project page  (https://github.com/rvega/bbb-pru/blob/master/apps/adc/pru.c). 
> I already made changes to read the ADC sampled values on the ARM program and 
> everithing are working fine. BUT i have 2 questions about this program:
> 
> 1) I want to know how he knows the necessaries BBB registers to configurate 
> the ADC and the communication pipe between ADC and PRUs on this setup? I 
> already looked the PRUSS and SITARA doccumentation but with no match the 
> registers names used by him.
> 
> 2) how i can calculate the sampling frequency? I found on his page that it 
> was configured to 50 ksps but, trying to calculate this sampling frequency on 
> the gived formula:
> 
>// fs = 24MHz / (CLK_DIV*2*Channels*(OpenDly+Average*(14+SampleDly))) (on 
> line 108 from the link above)
> I didn't get an integer fs value, for example, using their specified values 
> (clock_divider = 4;  open_delay = 4;  average = 1; sample_delay = 4; and 
> channel = 6) i get 22727.2727273 Hz.. Am i missing something? 
> 
> Thanks for all..
> 
> 
> 
> -- 
> 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/432ef525-8267-4b80-bdc4-664bec06fb11%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0B32CC51-B5D8-4269-9F46-07AB111C1CB2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[John Syne]

The adapter I use came with this package:

https://www.amazon.com/Lexar-High-Performance-MicroSDXC-version-LSDMI64GBBNL633R/dp/B00IF4OATU/ref=sr_1_22?s=electronics=UTF8=1524092120=1-22=lexar+sd+card
 


Someone gave this to me and it is fast and reliable. I haven’t used the Lenar 
SDCard, so I cannot say if it is reliable. 

Regards,
John





> On Apr 18, 2018, at 2:12 PM, Jeff Andich  wrote:
> 
> Thanks John!!
> 
> Will pass along this suggestion to my management and that its potentially 
> worth tracking SD card reliability by make, model, size, etc in the event 
> that we're not able to stick to SanDisk..
> 
> Rgds,
> 
> jeff
> 
> 
> 
> On Wednesday, April 18, 2018 at 3:22:55 PM UTC-5, john3909 wrote:
> I’ve gone through my fair share of bad SDCards (Pariot, Kingston, etc), so I 
> know what you are going through. I decided a few years ago to stay with one 
> make that always seems to work and that is SanDisk Ultra and SanDisk Extreme. 
> Since then, I haven’t had any more SDCard issues. 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Apr 18, 2018, at 6:56 AM, Jeff Andich > wrote:
>> 
>> Ok John,
>> 
>> In the case of the 32 GB Kingston #10 card I tried yesterday, I think it's 
>> the card, as I get the same result today ([3.896022] mmc0: error -110 
>> whilst initialising SD card ).  However, when I tried a different 32 GB 
>> Kingston uSD of the same type, it boots (see boot log below).  I'm not sure 
>> why subsequently trying it on the 16 GB Kingston uSD card yesterday yielded 
>> the same mmc error..
>> 
>> Anyhow, I'm sorry.  I  should have tried flashing multiple cards and 
>> configurations before posting this error... As indicated before, Robert gave 
>> me a Beagleboard-X15 image to try on the TI 5718 IDK a while back, and we 
>> kept getting MMC errors on SD cards larger than 4GB.  But Robert mentioned 
>> at the 2018 ELC what the issue was there, but I don't recall what it was..
>> 
>> If I see any other issues, I'll first try to perform more sanity checks and 
>> then post up..
>> 
>> Thanks!
>> 
>> jeff
>> 
>> 
>> Following is the successful boot log of this image.
>> 
>> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
>> jenkins-github_Bootl2
>> 
>> CPU  : DRA752-GP ES2.0
>> Model: TI AM5728 BeagleBoard-X15
>> Board: AM572x EVM REV A.3A
>> DRAM:  2 GiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> 
>> ** Unable to use mmc 0:1 for loading the env **
>> Using default environment
>> 
>> setup_board_eeprom_env: am57xx_evm_reva3
>> SCSI:  SATA link 0 timeout.
>> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
>> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
>> scanning bus for devices...
>> Found 0 device(s).
>> Net:not set. Validating first E-fuse MAC
>> cpsw
>> Press SPACE to abort autoboot in 2 seconds
>> usb_boot is currently disabled
>> scsi_boot is currently disabled
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc device 0
>> Checking for: /uEnv.txt ...
>> Checking for: /boot/uEnv.txt ...
>> 445 bytes read in 24 ms (17.6 KiB/s)
>> Loaded environment from /boot/uEnv.txt
>> Checking if uname_r is set in /boot/uEnv.txt ...
>> debug: [uname_r=4.9.78-ti-r94] ...
>> loading /boot/vmlinuz-4.9.78-ti-r94 ...
>> 9960536 bytes read in 454 ms (20.9 MiB/s)
>> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
>> 155403 bytes read in 100 ms (1.5 MiB/s)
>> loading /boot/initrd.img-4.9.78-ti-r94 ...
>> 6300596 bytes read in 291 ms (20.6 MiB/s)
>> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
>> rootwait coherent_pool.
>> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>> 
>> Starting kernel ...
>> 
>> [0.072556] /cpus/cpu@0 missing clock-frequency property
>> [0.072580] /cpus/cpu@1 missing clock-frequency property
>> [2.430461] dra7-pcie 5100.pcie: phy link never came up
>> [2.705777] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
>> [2.721471] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
>> [2.835224] omap_voltage_late_init: Voltage driver support not added
>> [FAILED] Failed to start TI MultiCore Tools Daemon.
>> See 'systemctl status ti-mct-daemon.service' for details.
>> [  OK  ] Started Connection service.
>> [  OK  ] Reached target Network.
>>  Starting Permit User Sessions...
>> [  OK  ] Reached target Network is Online.
>>  Starting LSB: Advanced IEEE 802.11 management daemon...
>>  Starting The Apache HTTP Server...
>>  Starting OpenBSD Secure Shell server...
>> [  OK  ] Started LSB: Start 

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[John Syne]

One more thing you should consider is the SDCard/USB adapter. The one I find 
the most reliable is a Lenar adapter similar to this one:

https://www.amazon.com/Lexar-Professional-microSDHC-UHS-II-LSDMI32GCBNL1000R/dp/B00U77V8AM/ref=sr_1_fkmr0_3?s=electronics=UTF8=1524091902=1-3-fkmr0=sd+card+lexar+usb+adapter
 


I have a bunch of SDCard readers and this is the only one that seems to work 
consistently. 

Regards,
John





> On Apr 18, 2018, at 2:12 PM, Jeff Andich  wrote:
> 
> Thanks John!!
> 
> Will pass along this suggestion to my management and that its potentially 
> worth tracking SD card reliability by make, model, size, etc in the event 
> that we're not able to stick to SanDisk..
> 
> Rgds,
> 
> jeff
> 
> 
> 
> On Wednesday, April 18, 2018 at 3:22:55 PM UTC-5, john3909 wrote:
> I’ve gone through my fair share of bad SDCards (Pariot, Kingston, etc), so I 
> know what you are going through. I decided a few years ago to stay with one 
> make that always seems to work and that is SanDisk Ultra and SanDisk Extreme. 
> Since then, I haven’t had any more SDCard issues. 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Apr 18, 2018, at 6:56 AM, Jeff Andich > wrote:
>> 
>> Ok John,
>> 
>> In the case of the 32 GB Kingston #10 card I tried yesterday, I think it's 
>> the card, as I get the same result today ([3.896022] mmc0: error -110 
>> whilst initialising SD card ).  However, when I tried a different 32 GB 
>> Kingston uSD of the same type, it boots (see boot log below).  I'm not sure 
>> why subsequently trying it on the 16 GB Kingston uSD card yesterday yielded 
>> the same mmc error..
>> 
>> Anyhow, I'm sorry.  I  should have tried flashing multiple cards and 
>> configurations before posting this error... As indicated before, Robert gave 
>> me a Beagleboard-X15 image to try on the TI 5718 IDK a while back, and we 
>> kept getting MMC errors on SD cards larger than 4GB.  But Robert mentioned 
>> at the 2018 ELC what the issue was there, but I don't recall what it was..
>> 
>> If I see any other issues, I'll first try to perform more sanity checks and 
>> then post up..
>> 
>> Thanks!
>> 
>> jeff
>> 
>> 
>> Following is the successful boot log of this image.
>> 
>> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
>> jenkins-github_Bootl2
>> 
>> CPU  : DRA752-GP ES2.0
>> Model: TI AM5728 BeagleBoard-X15
>> Board: AM572x EVM REV A.3A
>> DRAM:  2 GiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> 
>> ** Unable to use mmc 0:1 for loading the env **
>> Using default environment
>> 
>> setup_board_eeprom_env: am57xx_evm_reva3
>> SCSI:  SATA link 0 timeout.
>> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
>> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
>> scanning bus for devices...
>> Found 0 device(s).
>> Net:not set. Validating first E-fuse MAC
>> cpsw
>> Press SPACE to abort autoboot in 2 seconds
>> usb_boot is currently disabled
>> scsi_boot is currently disabled
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc device 0
>> Checking for: /uEnv.txt ...
>> Checking for: /boot/uEnv.txt ...
>> 445 bytes read in 24 ms (17.6 KiB/s)
>> Loaded environment from /boot/uEnv.txt
>> Checking if uname_r is set in /boot/uEnv.txt ...
>> debug: [uname_r=4.9.78-ti-r94] ...
>> loading /boot/vmlinuz-4.9.78-ti-r94 ...
>> 9960536 bytes read in 454 ms (20.9 MiB/s)
>> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
>> 155403 bytes read in 100 ms (1.5 MiB/s)
>> loading /boot/initrd.img-4.9.78-ti-r94 ...
>> 6300596 bytes read in 291 ms (20.6 MiB/s)
>> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
>> rootwait coherent_pool.
>> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
>> 
>> Starting kernel ...
>> 
>> [0.072556] /cpus/cpu@0 missing clock-frequency property
>> [0.072580] /cpus/cpu@1 missing clock-frequency property
>> [2.430461] dra7-pcie 5100.pcie: phy link never came up
>> [2.705777] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
>> [2.721471] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
>> [2.835224] omap_voltage_late_init: Voltage driver support not added
>> [FAILED] Failed to start TI MultiCore Tools Daemon.
>> See 'systemctl status ti-mct-daemon.service' for details.
>> [  OK  ] Started Connection service.
>> [  OK  ] Reached target Network.
>>  Starting Permit User Sessions...
>> [  OK  ] Reached target Network is Online.
>>  Starting LSB: Advanced IEEE 802.11 management daemon...
>>  Starting The 

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[John Syne]

I’ve gone through my fair share of bad SDCards (Pariot, Kingston, etc), so I 
know what you are going through. I decided a few years ago to stay with one 
make that always seems to work and that is SanDisk Ultra and SanDisk Extreme. 
Since then, I haven’t had any more SDCard issues. 

Regards,
John





> On Apr 18, 2018, at 6:56 AM, Jeff Andich  wrote:
> 
> Ok John,
> 
> In the case of the 32 GB Kingston #10 card I tried yesterday, I think it's 
> the card, as I get the same result today ([3.896022] mmc0: error -110 
> whilst initialising SD card ).  However, when I tried a different 32 GB 
> Kingston uSD of the same type, it boots (see boot log below).  I'm not sure 
> why subsequently trying it on the 16 GB Kingston uSD card yesterday yielded 
> the same mmc error..
> 
> Anyhow, I'm sorry.  I  should have tried flashing multiple cards and 
> configurations before posting this error... As indicated before, Robert gave 
> me a Beagleboard-X15 image to try on the TI 5718 IDK a while back, and we 
> kept getting MMC errors on SD cards larger than 4GB.  But Robert mentioned at 
> the 2018 ELC what the issue was there, but I don't recall what it was..
> 
> If I see any other issues, I'll first try to perform more sanity checks and 
> then post up..
> 
> Thanks!
> 
> jeff
> 
> 
> Following is the successful boot log of this image.
> 
> U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: 
> jenkins-github_Bootl2
> 
> CPU  : DRA752-GP ES2.0
> Model: TI AM5728 BeagleBoard-X15
> Board: AM572x EVM REV A.3A
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> 
> ** Unable to use mmc 0:1 for loading the env **
> Using default environment
> 
> setup_board_eeprom_env: am57xx_evm_reva3
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> usb_boot is currently disabled
> scsi_boot is currently disabled
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 445 bytes read in 24 ms (17.6 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt ...
> debug: [uname_r=4.9.78-ti-r94] ...
> loading /boot/vmlinuz-4.9.78-ti-r94 ...
> 9960536 bytes read in 454 ms (20.9 MiB/s)
> loading /boot/dtbs/4.9.78-ti-r94/am57xx-evm-reva3.dtb ...
> 155403 bytes read in 100 ms (1.5 MiB/s)
> loading /boot/initrd.img-4.9.78-ti-r94 ...
> 6300596 bytes read in 291 ms (20.6 MiB/s)
> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool.
> debug: [bootz 0x8200 0x8808:6023b4 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9fd000, end 83b4 ... OK
>Loading Device Tree to 8f9d4000, end 8f9fcf0a ... OK
> 
> Starting kernel ...
> 
> [0.072556] /cpus/cpu@0 missing clock-frequency property
> [0.072580] /cpus/cpu@1 missing clock-frequency property
> [2.430461] dra7-pcie 5100.pcie: phy link never came up
> [2.705777] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [2.721471] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
> [2.835224] omap_voltage_late_init: Voltage driver support not added
> [FAILED] Failed to start TI MultiCore Tools Daemon.
> See 'systemctl status ti-mct-daemon.service' for details.
> [  OK  ] Started Connection service.
> [  OK  ] Reached target Network.
>  Starting Permit User Sessions...
> [  OK  ] Reached target Network is Online.
>  Starting LSB: Advanced IEEE 802.11 management daemon...
>  Starting The Apache HTTP Server...
>  Starting OpenBSD Secure Shell server...
> [  OK  ] Started LSB: Start daemon at boot time.
> [  OK  ] Started Permit User Sessions.
> [  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
>  Starting Light Display Manager...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
>  Starting LSB: set CPUFreq kernel parameters...
> [  OK  ] Started Generic Board Startup.
>  Starting Hostname Service...
>  Starting WPA supplicant...
> [  OK  ] Started LSB: set CPUFreq kernel parameters.
> [7.212091] remoteproc remoteproc0: request_firmware failed: -2
> [  OK  ] Started OpenBSD Secure Shell server.
> [  OK  ] Found device /dev/ttyS2.
> [  OK  ] Started Serial Getty on ttyS2.
> [  OK  ] Reached target Login Prompts.
>  Starting BB WL18xx Bluetooth Service...
> [  OK  ] Started WPA supplicant.
> [  OK  ] Started BB WL18xx Bluetooth Service.
> [  OK  ] Started Hostname Service.
> [  OK  ] Started Light Display Manager.
> [  OK  ] Started The Apache HTTP Server.
> 

Re: [beagleboard] Re: Stretch Image, debian-9.3-lxqt, for BeagleBoard-X15 Doesn't Boot Normally - Boots into initramfs

[John Syne]

I use San Disk Ultra 32GB in my X15 and it works fine.

Regards,
John





> On Apr 17, 2018, at 5:59 PM, Jeff Andich  wrote:
> 
> Hi,
> 
> First run:  32GB
> Second:   16GB
> Third: 4GB
> 
> Will redo the first run but with a different 32 GB SD as Etcher hung during 
> verifying that card (but subsequently Win32DiskImager didn’t complain)..  
> That card maybe bad.  However, the same result occurred on the 16 GB card...
> 
> Thanks!
> 
> -- 
> 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/37465c0f-a787-4490-b3c3-8531d3b7ee7d%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1044DF9B-D918-4C03-9436-CA6E387AD637%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Apr 16, 2018, at 3:40 PM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks a lot for this very complete answer ! I think I understand it now, the 
> last point I am not sure about is:
> 
> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */ 
> 
> I went through  12.3.3 of the AM3358 Technical Reference Manual and it seems 
> that the setting the averaging value to 1 disable the averaging (instead of 
> setting it to 2) am I right? 
> Thanks again for your help 
If you look in the AM3358 TRM, it says 0 will disable averaging and 1 will 
average over two samples.

>From the TRM

Number of samplings to average:
000 = No average.
001 = 2 samples average.
010 = 4 samples average.
011 = 8 samples average.
100 = 16 samples average.

Regards,
John
> 
> Le mercredi 11 avril 2018 17:00:54 UTC-4, john3909 a écrit :
> 
> 
>> On Apr 11, 2018, at 6:04 AM, pierric...@gadz.org <> wrote:
>> 
>> Hi John, 
>> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
>> patched it to disable the hardware triggers thanks to the patch presented on 
>> this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>>  I am now able to reader 
>> a buffer from the different channel. 
>> However I have 2 majors questions that remains:
>> 
>> 1) I only want to use on channel, then I do not want the ADC to sample the 
>> other one so that i'll have the maximum sampling rate. What is the best way 
>> to disable the channel? If I do not enable them in iio_generic_buffer.c I am 
>> not sure that the ADC is not going to sample this channel or not (well, I 
>> think it wont sample but I prefer to be sure). Is it preferable to not 
>> mention them on the devicetree so that Linux wont know that there are 
>> multiple channels on the ADC? This part is not very clear for me. 
>> 
>> 2) To change the sample frequency of the ADC you mentioned that it is done 
>> using the device tree however I did not find any argument on the ADC 
>> devicetree to change the sampling frequency. I read the discussion you had 
>> on this post (https://patchwork.kernel.org/patch/9391487/ 
>>  ) but it is not clear if the 
>> frequency setting is done using the kernel module or devicetrees. Could you 
>> explain me this please? 
> Looking at this a little more, there is a mistake in the ADC DT file 
> BB-ADC-0A00.dts. The maximum averaging is 16, not 0x16.
> 
> The line
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16 0x16>
> 
> should be changed to
> ti,chan-step-avg = <16 16 16 16 16 16 16 16>
> Fortunately, the driver does a range check and sets the value to 16. 
> 
> ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
> ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
> ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>
> 
> To achieve a conversion rate of 800 KS/s
> 
> From ti_am335x_tscad.c, 1 + (1 + 13) * 2 = 30 cycles
> 
> The ADC uses a 24 MHz clock, so 1/24,000,000 * 15 = 800 KS/s
> 
> You could increase the sampling rate to 1.6MS/s by changing the average to 0, 
> which means there is no averaging. To achieve this, the minimum number of 
> cycles for a conversion is 15 (12.3.7 of the AM3358 Technical Reference 
> Manual)
> 
> 1 + (1 + 13) * 1 = 15 cycles
> 
> which will give you 1.6 MS/s
> 
> Regards,
> John
> 
>> 
>> Thanks a lot 
>> 
>> Pierrick 
>> 
>> Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
>> Look at the kernel source under tools/iio for examples on how to use IIO.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>> 
>>> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Hi John, 
>>> 
>>> Sorry for the late answer, I had hard time using the PRUs and I am now 
>>> going to use the IIO ADC driver, I am able to read the sample with the cat 
>>> command in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
>>> However I am not able to use Libiio in order to read data from a user space 
>>> application, I am reading (nil) instead of my data. Do you have any idea of 
>>> where does the problem comes from ? 
>>> 
>>> Here is the code I am using in the user space :
>>> 
>>> 
>>> #define _BSD_SOURCE
>>> #define _GNU_SOURCE
>>> #define _DEFAULT_SOURCE
>>> 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> 
>>> #ifdef __APPLE__
>>> #include 
>>> #else
>>> #include 
>>> #endif
>>> 
>>> struct iio_context *ctx;
>>> struct iio_device *dev;
>>> struct iio_channel *ch;
>>> 
>>> int main()
>>> {
>>>   ctx = iio_create_default_context();
>>>   dev = iio_context_get_device(ctx, 0);
>>>   ch = iio_device_get_channel(dev, 3);
>>> 
>>> 
>>>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>>>   iio_channel_attr_write_double(ch, "scale", 1);
>>> 
>>>   iio_channel_enable(ch);
>>> 
>>>   char *a = iio_device_get_data(dev);
>>>   printf("%p\n", a);
>>> 
>>>   iio_channel_disable(ch);
>>> 
>>>   return 0;
>>> }
>>> 
>>> Thanks 
>>> 

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Apr 11, 2018, at 6:04 AM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
> patched it to disable the hardware triggers thanks to the patch presented on 
> this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>  I am now able to reader 
> a buffer from the different channel. 
> However I have 2 majors questions that remains:
> 
> 1) I only want to use on channel, then I do not want the ADC to sample the 
> other one so that i'll have the maximum sampling rate. What is the best way 
> to disable the channel? If I do not enable them in iio_generic_buffer.c I am 
> not sure that the ADC is not going to sample this channel or not (well, I 
> think it wont sample but I prefer to be sure). Is it preferable to not 
> mention them on the devicetree so that Linux wont know that there are 
> multiple channels on the ADC? This part is not very clear for me. 
> 
> 2) To change the sample frequency of the ADC you mentioned that it is done 
> using the device tree however I did not find any argument on the ADC 
> devicetree to change the sampling frequency. I read the discussion you had on 
> this post (https://patchwork.kernel.org/patch/9391487/ 
>  ) but it is not clear if the 
> frequency setting is done using the kernel module or devicetrees. Could you 
> explain me this please? 
Looking at this a little more, there is a mistake in the ADC DT file 
BB-ADC-0A00.dts. The maximum averaging is 16, not 0x16.

The line
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16 0x16>

should be changed to
ti,chan-step-avg = <16 16 16 16 16 16 16 16>
Fortunately, the driver does a range check and sets the value to 16. 

ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>

To achieve a conversion rate of 800 KS/s

>From ti_am335x_tscad.c, 1 + (1 + 13) * 2 = 30 cycles

The ADC uses a 24 MHz clock, so 1/24,000,000 * 15 = 800 KS/s

You could increase the sampling rate to 1.6MS/s by changing the average to 0, 
which means there is no averaging. To achieve this, the minimum number of 
cycles for a conversion is 15 (12.3.7 of the AM3358 Technical Reference Manual)

1 + (1 + 13) * 1 = 15 cycles

which will give you 1.6 MS/s

Regards,
John

> 
> Thanks a lot 
> 
> Pierrick 
> 
> Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
> Look at the kernel source under tools/iio for examples on how to use IIO.
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org <> wrote:
>> 
>> Hi John, 
>> 
>> Sorry for the late answer, I had hard time using the PRUs and I am now going 
>> to use the IIO ADC driver, I am able to read the sample with the cat command 
>> in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
>> However I am not able to use Libiio in order to read data from a user space 
>> application, I am reading (nil) instead of my data. Do you have any idea of 
>> where does the problem comes from ? 
>> 
>> Here is the code I am using in the user space :
>> 
>> 
>> #define _BSD_SOURCE
>> #define _GNU_SOURCE
>> #define _DEFAULT_SOURCE
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> #ifdef __APPLE__
>> #include 
>> #else
>> #include 
>> #endif
>> 
>> struct iio_context *ctx;
>> struct iio_device *dev;
>> struct iio_channel *ch;
>> 
>> int main()
>> {
>>   ctx = iio_create_default_context();
>>   dev = iio_context_get_device(ctx, 0);
>>   ch = iio_device_get_channel(dev, 3);
>> 
>> 
>>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>>   iio_channel_attr_write_double(ch, "scale", 1);
>> 
>>   iio_channel_enable(ch);
>> 
>>   char *a = iio_device_get_data(dev);
>>   printf("%p\n", a);
>> 
>>   iio_channel_disable(ch);
>> 
>>   return 0;
>> }
>> 
>> Thanks 
>> 
>> Pierrick 
>> 
>> 
>> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
>> The IIO ADC driver can run at 800K samples per second. Here is the patch 
>> that made that possible. 
>> 
>> https://patchwork.kernel.org/patch/9391487/ 
>> 
>> 
>> I can confirm that I have tested the driver at 800Ksps and it works fine as 
>> long as you have a proper low impedance source for each ADC channel. CPU 
>> utilization was about 5% if I recall and that was probably used by the iiod 
>> daemon, which I used to display the waveform on a remote Linux app. 
>> 
>> There is example code in the original Starterware for McSPI, which should 
>> work fine if you are using the PRU low level drivers. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Thanks John, 
>>> 
>>> I am now working with the starterware_PRU but i did not find examples for 
>>> using the McSPI with the PRU, do you think 

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Apr 11, 2018, at 6:04 AM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
> patched it to disable the hardware triggers thanks to the patch presented on 
> this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>  I am now able to reader 
> a buffer from the different channel. 
> However I have 2 majors questions that remains:
> 
> 1) I only want to use on channel, then I do not want the ADC to sample the 
> other one so that i'll have the maximum sampling rate. What is the best way 
> to disable the channel? If I do not enable them in iio_generic_buffer.c I am 
> not sure that the ADC is not going to sample this channel or not (well, I 
> think it wont sample but I prefer to be sure). Is it preferable to not 
> mention them on the devicetree so that Linux wont know that there are 
> multiple channels on the ADC? This part is not very clear for me. 
First, you have to enable each channel for it to be placed in the buffer. 
Second, you have to setup the size of the buffer and then enable the buffer to 
start filling the buffer with samples. When you enable the buffer, 
tiadc_buffer_postenable() is run which only scans those channels you enabled.
> 
> 2) To change the sample frequency of the ADC you mentioned that it is done 
> using the device tree however I did not find any argument on the ADC 
> devicetree to change the sampling frequency. I read the discussion you had on 
> this post (https://patchwork.kernel.org/patch/9391487/ 
>  ) but it is not clear if the 
> frequency setting is done using the kernel module or devicetrees. Could you 
> explain me this please? 
The sampling frequency is dependent on the Open Delay, Sample Delay and 
Conversion Time. If you look at the file linux/mfd/ti_am335x_tscadc.h line 145, 
there is an explanation of this.

Regards,
John
> 
> Thanks a lot 
> 
> Pierrick 
> 
> Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
> Look at the kernel source under tools/iio for examples on how to use IIO.
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org  wrote:
>> 
>> Hi John, 
>> 
>> Sorry for the late answer, I had hard time using the PRUs and I am now going 
>> to use the IIO ADC driver, I am able to read the sample with the cat command 
>> in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
>> However I am not able to use Libiio in order to read data from a user space 
>> application, I am reading (nil) instead of my data. Do you have any idea of 
>> where does the problem comes from ? 
>> 
>> Here is the code I am using in the user space :
>> 
>> 
>> #define _BSD_SOURCE
>> #define _GNU_SOURCE
>> #define _DEFAULT_SOURCE
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> #ifdef __APPLE__
>> #include 
>> #else
>> #include 
>> #endif
>> 
>> struct iio_context *ctx;
>> struct iio_device *dev;
>> struct iio_channel *ch;
>> 
>> int main()
>> {
>>   ctx = iio_create_default_context();
>>   dev = iio_context_get_device(ctx, 0);
>>   ch = iio_device_get_channel(dev, 3);
>> 
>> 
>>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>>   iio_channel_attr_write_double(ch, "scale", 1);
>> 
>>   iio_channel_enable(ch);
>> 
>>   char *a = iio_device_get_data(dev);
>>   printf("%p\n", a);
>> 
>>   iio_channel_disable(ch);
>> 
>>   return 0;
>> }
>> 
>> Thanks 
>> 
>> Pierrick 
>> 
>> 
>> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
>> The IIO ADC driver can run at 800K samples per second. Here is the patch 
>> that made that possible. 
>> 
>> https://patchwork.kernel.org/patch/9391487/ 
>> 
>> 
>> I can confirm that I have tested the driver at 800Ksps and it works fine as 
>> long as you have a proper low impedance source for each ADC channel. CPU 
>> utilization was about 5% if I recall and that was probably used by the iiod 
>> daemon, which I used to display the waveform on a remote Linux app. 
>> 
>> There is example code in the original Starterware for McSPI, which should 
>> work fine if you are using the PRU low level drivers. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Thanks John, 
>>> 
>>> I am now working with the starterware_PRU but i did not find examples for 
>>> using the McSPI with the PRU, do you think it will be hard to adapt the 
>>> initial code to the PRU ? 
>>> By the way, looking to the IIO driver documentation, it seems that for the 
>>> AM335x chip the max sampling rate is only 200k samples per second which may 
>>> not be enough :
>>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide 
>>>  ; am I 
>>> right ? 
>>> 
>>> 
>>> Thanks 
>>> 
>>> Pierrick 
>>> 

Re: [beagleboard] BBB eewiki down

[John Syne]

No matter, I found the selection in 
0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch line 1668. 

Regards,
John





> On Apr 10, 2018, at 11:42 AM, John Syne <john3...@gmail.com> wrote:
> 
> Thanks Robert. BTW, when using u-boot overlays, what base DTS is used for 
> BBB? I seem to remember you saying we don’t have to define the base DTS and 
> u-boot will select the base DTS. 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Apr 10, 2018, at 6:54 AM, Robert Nelson <robertcnel...@gmail.com 
>> <mailto:robertcnel...@gmail.com>> wrote:
>> 
>> On Tue, Apr 10, 2018 at 2:42 AM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>>> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
>>>  
>>> <https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot>
>>> 
>>> is down.
>> 
>> should be back up, we should have a new server at some point. ;)
>> 
>> Regards,
>> 
>> -- 
>> Robert Nelson
>> https://rcn-ee.com/ <https://rcn-ee.com/>
>> 
>> -- 
>> 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/CAOCHtYiLw4pbdhpgwuf%2BRR2CRMYc_P7mu5R1J7_ZY7WdL5P7ug%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/687E1611-91D3-44CF-9F8C-572FC724193C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB eewiki down

[John Syne]

Thanks Robert. BTW, when using u-boot overlays, what base DTS is used for BBB? 
I seem to remember you saying we don’t have to define the base DTS and u-boot 
will select the base DTS. 

Regards,
John





> On Apr 10, 2018, at 6:54 AM, Robert Nelson <robertcnel...@gmail.com> wrote:
> 
> On Tue, Apr 10, 2018 at 2:42 AM, John Syne <john3...@gmail.com> wrote:
>> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
>> 
>> is down.
> 
> should be back up, we should have a new server at some point. ;)
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/
> 
> -- 
> 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/CAOCHtYiLw4pbdhpgwuf%2BRR2CRMYc_P7mu5R1J7_ZY7WdL5P7ug%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/D9594803-20D8-4DB2-A97B-B45E8A732F34%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB eewiki down

[John Syne]

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot

is down.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B0729119-72A0-4DE6-8908-D4EC45868C23%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I2C SCL Voltage level too low?

[John Syne]

Yeah, that is much better. Not sure you have to use a 1K pullup. See if a 3K3 
or a 4K7 does gives you clean signals. BTW, your earth pin on your scope is too 
long and that is why you are seeing noisy signals. Search google for "scope 
probe short ground” and look at the images on how to do this. 

Regards,
John





> On Apr 9, 2018, at 7:15 PM, yassyass  wrote:
> 
> Thank you John,
> 
> It seems like my scope was loading it quite a bit and is now giving much 
> better readings using x10 probes. The signals bellow are set to 400 kHz using 
> 1kOhm pull-ups
> 
>  
> 
>  
> 
> 
> 
> 
> 
> On Friday, April 6, 2018 at 9:49:48 AM UTC+12, john3909 wrote:
> Yeah, I agree there is something else going on here. with a 1K resistor, the 
> signals should not have a slow rising time. The rise time doesn’t look like a 
> capacitor, but I agree, that is about the only explanation that would cause 
> the rise time to slow like this. Maybe the I2C part is faulty. Try plugging 
> in another I2C part to see if the problem persists. 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Apr 5, 2018, at 8:02 AM, Graham  
>> wrote:
>> 
>> 
>>  It looks like you have some extra capacitance on the bus.  There should not 
>> be any capacitors bridging the I2C data and clock lines. Some of the 
>> third-party universal interface cards have extra capacitance, so take those 
>> off.
>> 
>> I have never heard of an I2C part with built in pull-up resistors.
>> 
>> Do to the multi-drop nature of the I2C bus, pull up resistors are almost 
>> always external. There are some "weak pull up" resistors you could turn on 
>> in the BBB, but are too high in value for most applications.
>> 
>> I suggest you read up on how to select pull up resistors for an I2C bus.  
>> Phillips (now NXP) initially developed the bus and has good documentation.
>> Google: NXP I2C bus documentation
>> 
>> But the short answer is that for a 3.3V bus, resistors in the range of 1.2K 
>> to 3.3K should work fine. The value is not critical. You want to pull 1 to 3 
>> mA through the resistor when the bus is low.
>> 
>> --- Graham
>> 
>> ==
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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/a8ed3ca6-d286-4d29-8dc1-8851aa384db3%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/00a745ff-a990-4f42-9fb5-5b6e92861043%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/EA31EAE8-1075-446E-B075-3843CB5861D9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I2C SCL Voltage level too low?

[John Syne]

Yeah, I agree there is something else going on here. with a 1K resistor, the 
signals should not have a slow rising time. The rise time doesn’t look like a 
capacitor, but I agree, that is about the only explanation that would cause the 
rise time to slow like this. Maybe the I2C part is faulty. Try plugging in 
another I2C part to see if the problem persists. 

Regards,
John





> On Apr 5, 2018, at 8:02 AM, Graham  wrote:
> 
> 
>  It looks like you have some extra capacitance on the bus.  There should not 
> be any capacitors bridging the I2C data and clock lines. Some of the 
> third-party universal interface cards have extra capacitance, so take those 
> off.
> 
> I have never heard of an I2C part with built in pull-up resistors.
> 
> Do to the multi-drop nature of the I2C bus, pull up resistors are almost 
> always external. There are some "weak pull up" resistors you could turn on in 
> the BBB, but are too high in value for most applications.
> 
> I suggest you read up on how to select pull up resistors for an I2C bus.  
> Phillips (now NXP) initially developed the bus and has good documentation.
> Google: NXP I2C bus documentation
> 
> But the short answer is that for a 3.3V bus, resistors in the range of 1.2K 
> to 3.3K should work fine. The value is not critical. You want to pull 1 to 3 
> mA through the resistor when the bus is low.
> 
> --- Graham
> 
> ==
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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/a8ed3ca6-d286-4d29-8dc1-8851aa384db3%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA2B23DC-7B39-4E85-AB6E-2D196A6DE203%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C SCL Voltage level too low?

[John Syne]

You mean decrease the resistor values. Don’t rely on the internal pull up 
resistors. 4K7 should be OK, but try 3K3 to see if the signals look better. 

Regards,
John





> On Apr 4, 2018, at 10:06 PM, yassyass  wrote:
> 
> Thanks Wulf, I will attempt to increase the resistor values and get back with 
> results.
> 
> 
> -- 
> 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/893c8ea1-b87c-4331-94fe-0be41e89e962%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/E178BD24-10B7-4FD9-918D-BE5F873C5FA2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

Look at the kernel source under tools/iio for examples on how to use IIO.

Regards,
John





> On Mar 27, 2018, at 12:10 PM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> 
> Sorry for the late answer, I had hard time using the PRUs and I am now going 
> to use the IIO ADC driver, I am able to read the sample with the cat command 
> in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
> However I am not able to use Libiio in order to read data from a user space 
> application, I am reading (nil) instead of my data. Do you have any idea of 
> where does the problem comes from ? 
> 
> Here is the code I am using in the user space :
> 
> 
> #define _BSD_SOURCE
> #define _GNU_SOURCE
> #define _DEFAULT_SOURCE
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #ifdef __APPLE__
> #include 
> #else
> #include 
> #endif
> 
> struct iio_context *ctx;
> struct iio_device *dev;
> struct iio_channel *ch;
> 
> int main()
> {
>   ctx = iio_create_default_context();
>   dev = iio_context_get_device(ctx, 0);
>   ch = iio_device_get_channel(dev, 3);
> 
> 
>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>   iio_channel_attr_write_double(ch, "scale", 1);
> 
>   iio_channel_enable(ch);
> 
>   char *a = iio_device_get_data(dev);
>   printf("%p\n", a);
> 
>   iio_channel_disable(ch);
> 
>   return 0;
> }
> 
> Thanks 
> 
> Pierrick 
> 
> 
> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
> The IIO ADC driver can run at 800K samples per second. Here is the patch that 
> made that possible. 
> 
> https://patchwork.kernel.org/patch/9391487/ 
> 
> 
> I can confirm that I have tested the driver at 800Ksps and it works fine as 
> long as you have a proper low impedance source for each ADC channel. CPU 
> utilization was about 5% if I recall and that was probably used by the iiod 
> daemon, which I used to display the waveform on a remote Linux app. 
> 
> There is example code in the original Starterware for McSPI, which should 
> work fine if you are using the PRU low level drivers. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org <> wrote:
>> 
>> Thanks John, 
>> 
>> I am now working with the starterware_PRU but i did not find examples for 
>> using the McSPI with the PRU, do you think it will be hard to adapt the 
>> initial code to the PRU ? 
>> By the way, looking to the IIO driver documentation, it seems that for the 
>> AM335x chip the max sampling rate is only 200k samples per second which may 
>> not be enough :
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide 
>>  ; am I 
>> right ? 
>> 
>> 
>> Thanks 
>> 
>> Pierrick 
>> 
>> Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
>> Like I said, it was based on Starterware, so search Github for starterware 
>> and you will see a project starterware_PRU. It does use the mcspi, so it is 
>> not a bitbang implementation. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Thanks John for you answer, I was quit busy last week so I worked on this 
>>> during the Weekend. 
>>> 
>>> Unfortunately, I was not able to find a project that is using the SPI and 
>>> I2C interface with the PRU, I only found this one : 
>>> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller
>>>  
>>> 
>>>  
>>> But it is using bit banging for the SPI part and not using the on-board 
>>> pull-up resistors for the I2C part.
>>> 
>>> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming 
>>> days it seems that it meets my need in term of real-time acquisition. 
>>> 
>>> Regards,
>>> 
>>> Pierrick 
>>> 
>>> -- 
>>> 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/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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 <>.

Re: [beagleboard] Wrong SPI configurations when using config-spi??!

[John Syne]

When configured for a function like SPI or I2C, the mux pins are configured as 
inputs.

Regards,
John





> On Mar 19, 2018, at 2:04 AM, salahuddin...@gmail.com wrote:
> 
> Hi all, 
> 
> I'm trying to configure SPI using config-pin tool.
> The tool only changes the mode and set it to SPI. However, all the SPI pins 
> configured by config-pin are configured to be INPUT.
> This should not be like this. 
> How can I fix it?
> 
> uname -a
> Linux beaglebone 4.9.82-ti-r102 #1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018 
> armv7l GNU/Linux
> 
> 
> Thanks
> 
> -- 
> 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/0b29126c-2b2c-42b3-ab6d-df977e3450a9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/899CB20B-492B-4907-A3FF-1003BDB2795A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to configure BBB as an SPI slave?

[John Syne]

Linux does not currently support SPI slave mode.

Regards,
John





> On Mar 13, 2018, at 7:07 AM, salahuddin...@gmail.com wrote:
> 
> Hi everyone, 
> 
> I've been looking the whole day for a clear way to configure BBB as an SPI 
> slave but I couldn't find any. 
> I read all the threads in this group but I'm still can't get it to work .
> Currently, I can use BBB as an SPI master and another board is a slave but I 
> need to make them change the roles. 
> 
> Following is the output of `uname -a` command:
> Linux beaglebone 4.4.80-ti-r116 #1 SMP Wed Aug 9 13:18:17 UTC 2017 armv7l 
> GNU/Linux
> 
> 
> 
> Any help or link is appreciated. 
> Thank you
> Salahuddin
> 
> -- 
> 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/ebd9c8cd-b6e0-4941-bf90-d52dd1d3a3df%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7E3299DF-81F5-4A7D-8130-194D473EABFD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Best way to build a large array for access by PRU0?

[John Syne]

Hi TJF,

I love the work you do and the advise you give. My only purpose was to remove 
any confusion ;-)

Regards,
John




> On Mar 1, 2018, at 9:06 AM, TJF  wrote:
> 
> 
> 
> Am Mittwoch, 28. Februar 2018 16:28:18 UTC+1 schrieb john3909:
> 
>> On Feb 28, 2018, at 6:47 AM, TJF > wrote:
>> 
>> When you allocate the array from user space the memory may be not 
>> continuous. To get a single block, you have to allocate from kernel space.
> This is not a true statement. The kernel uses virtual memory just like user 
> space does. The memory is only contiguous in physical memory if you use 
> kmalloc. If you use vmalloc, the memory can be fragmented in physical memory. 
>  
> 
> Oh, yes. John is right (as always). Here's my corrected statement: 
> 
> When you allocate the array from user space the memory may be not continuous. 
> To get a single block, you have to allocate from kernel space by kmalloc.
> 
> 
> Note @John:
> 
> A user dealing with real world problems doesn't want to learn about kernel 
> driver details. When he can solve a problem by a simple command line like
> 
> sudo modprobe uio_pruss extram_pool_sz=0x12500
> 
> he'll prefer that solution.
> 
> -- 
> 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/ff1e0d76-008f-42bd-a516-adc1a7feff99%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CBC67D3C-C087-4128-9FF1-592C96254660%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Best way to build a large array for access by PRU0?

[John Syne]

> On Feb 28, 2018, at 6:47 AM, TJF  wrote:
> 
> When you allocate the array from user space the memory may be not continuous. 
> To get a single block, you have to allocate from kernel space.
This is not a true statement. The kernel uses virtual memory just like user 
space does. The memory is only contiguous in physical memory if you use 
kmalloc. If you use vmalloc, the memory can be fragmented in physical memory. 

Anyway, this has nothing to do with rproc vs uio. You can do this with both.

Regards,
John
> 
> The most easy way: drop rproc, instead use libprussdrv. The uio_pruss kernel 
> driver allocates external memory, which you can fill by the C code and read 
> from the PRU code. (Note: PRU access to ARM memory isn't as fast as DRam or 
> SRam, needs at least 3 cycles - AFAIR.)
> 
> -- 
> 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/f1a1ca96-a613-4b16-9788-427a21bf8ceb%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/77F703BC-D527-41E1-B102-8E8EE40EA6F2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

The IIO ADC driver can run at 800K samples per second. Here is the patch that 
made that possible. 

https://patchwork.kernel.org/patch/9391487/

I can confirm that I have tested the driver at 800Ksps and it works fine as 
long as you have a proper low impedance source for each ADC channel. CPU 
utilization was about 5% if I recall and that was probably used by the iiod 
daemon, which I used to display the waveform on a remote Linux app. 

There is example code in the original Starterware for McSPI, which should work 
fine if you are using the PRU low level drivers. 

Regards,
John




> On Feb 26, 2018, at 12:56 PM, pierrick.ra...@gadz.org wrote:
> 
> Thanks John, 
> 
> I am now working with the starterware_PRU but i did not find examples for 
> using the McSPI with the PRU, do you think it will be hard to adapt the 
> initial code to the PRU ? 
> By the way, looking to the IIO driver documentation, it seems that for the 
> AM335x chip the max sampling rate is only 200k samples per second which may 
> not be enough :
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide ; am I 
> right ? 
> 
> 
> Thanks 
> 
> Pierrick 
> 
> Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
> Like I said, it was based on Starterware, so search Github for starterware 
> and you will see a project starterware_PRU. It does use the mcspi, so it is 
> not a bitbang implementation. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org <> wrote:
>> 
>> Thanks John for you answer, I was quit busy last week so I worked on this 
>> during the Weekend. 
>> 
>> Unfortunately, I was not able to find a project that is using the SPI and 
>> I2C interface with the PRU, I only found this one : 
>> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller 
>> 
>>  
>> But it is using bit banging for the SPI part and not using the on-board 
>> pull-up resistors for the I2C part.
>> 
>> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming days 
>> it seems that it meets my need in term of real-time acquisition. 
>> 
>> Regards,
>> 
>> Pierrick 
>> 
>> -- 
>> 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/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/14F65A4F-6A27-48D2-83CA-A61E2EEB833B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using Real Time clock overlay

[John Syne]

There is a very good book that explains everything you will need in embedded 
systems using Linux. I has a complete chapter on RTC.

Linux Device Drivers Development by John Madieu, published by Packt Publishing 
2017.
This book doesn’t cover BBB directly, but it covers all Linux subsystems, such 
as SPI, I2C, RTC, DMA, etc

If you are looking for a book that covers BBB and the build cycle and root file 
system, then this book is very helpful:

Mastering Embedded Linux Programming - Second Edition by Chris Simmons, 
published by Packt Publishing 2017.

These two books will get you up and running so you are able to help yourself. I 
wish I had these books 10 years ago. These are the only two books that deal 
with the latest kernels and Device Tree. 


Regards,
John




> On Feb 23, 2018, at 2:35 PM, zacharyp...@gmail.com wrote:
> 
> I am trying to use a RTC click overlay. I installed the file in uEnv.txt, 
> however I don't know how to utilize the RTC. Is there some way to set the 
> time and use it as the hardware time so that every time the pocketbeagle 
> boots it uses the RTC time?
> 
> -- 
> 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/57c6fac3-8c18-4728-aac5-86b2a1930845%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3D41FA47-D82F-47C4-9C00-8A1F59159812%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is BeagleBoard X15 a good choice for industrial project?

[John Syne]

The BeagleBoard X15 has two powerful DSPs and 4 PRUs which are all suitable for 
real-time control. With suitable interface circuitry, the BeagleBoard X15 can 
easily do everything the OP outlined.

Regards,
John




> On Feb 23, 2018, at 7:03 AM, tom.al...@resourcekraft.com wrote:
> 
> How real-time does its control need to be, what sampling rates will you be 
> using in the analog domain, What else will you be doing besides a data base 
> write?
> If its not real-time response you need, then a BBB would seem to be capable.
> If you want real-time performance then you will have to address the 
> capability of Linux to do real-time control which may be your limiting 
> factor. 
>  
> Regards,
> Tom
> 
> On Tuesday, February 6, 2018 at 2:21:47 PM UTC, pascal1984 wrote:
> Hi,
> 
> i want to know if BeagleBoard X15 is a good choice for my industrial project:
> My project is:
> -control a an AC motor (10KW) with a speed regulator with input+= 0-24V
> -measure temperatures with input: 0-1V
> -input =0-10V
> -input = 0-4mA and 0-20mA
> -control heaters.
> I will digit-analog converter to get values.
> -store data in db.
> 
> 
> Is BeagleBoard X15 a godd choice.
> 
> Thank you
> 
> -- 
> 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/28f99610-d938-4c03-99d4-971dfa051c96%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/FB5A1FE5-73B8-48DD-A042-DBEAD859898D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

Like I said, it was based on Starterware, so search Github for starterware and 
you will see a project starterware_PRU. It does use the mcspi, so it is not a 
bitbang implementation. 

Regards,
John




> On Feb 19, 2018, at 7:33 PM, pierrick.ra...@gadz.org wrote:
> 
> Thanks John for you answer, I was quit busy last week so I worked on this 
> during the Weekend. 
> 
> Unfortunately, I was not able to find a project that is using the SPI and I2C 
> interface with the PRU, I only found this one : 
> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller 
> But it is using bit banging for the SPI part and not using the on-board 
> pull-up resistors for the I2C part.
> 
> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming days 
> it seems that it meets my need in term of real-time acquisition. 
> 
> Regards,
> 
> Pierrick 
> 
> -- 
> 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/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5CFD8EBC-4C2F-486E-AF6F-BDCA40FFF2DE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> 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 
>> 
>> --- 
>> 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
>>  
>> .
>> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8d0c8de1-659d-4b07-9d0a-4a284619992b%40googlegroups.com
>  
> .
> For more options, visit 

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Feb 13, 2018, at 9:49 AM, pierrick.ra...@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 
> 
> --- 
> 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/ed0d2be5-9c7f-4fe1-8e79-1f494bde023b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/FBA6A23C-68C9-4AF2-875E-DB835E4F7802%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] x15 STEP file?

[John Syne]

Yeah, I just checked and V8 does import gerber files
https://knowledge.autodesk.com/support/eagle/troubleshooting/caas/discussion/t5/EAGLE-Forum/How-to-import-gerber-files/td-p/7058370.html

Seems like Eagle uses ecad.io for 3D parts. This might work for you as it seems 
to import Allegro files.
https://www.ecad.io/

Regards,
John




> On Feb 9, 2018, at 6:12 PM, Graham <gra...@flex-radio.com> wrote:
> 
> Eagle does not support import of Gerbers.
> It will output Gerbers of boards you have designed.
> Only the latest (Autodesk) Eagle 8 version will support 3-D parts.
> --- Graham
> 
> ==
> 
> On Friday, February 9, 2018 at 7:59:47 PM UTC-6, john3909 wrote:
> I’m wondering if this can be done with Eagle. It might be possible to import 
> the gerber file, create the PCB from that and then add the connectors 3D 
> parts. Perhaps someone who knows Eagle might comment. 
> 
> Regards, 
> John 
> 
> 
>  
> 
> > On Feb 9, 2018, at 5:54 PM, Rick Mann <rm...@latencyzero.com <>> wrote: 
> > 
> > I don't have Altium. 
> > 
> >> On Feb 9, 2018, at 17:49 , John Syne <john...@gmail.com <>> wrote: 
> >> 
> >> If you could Import the board into Altium it is pretty easy to create the 
> >> step file. Here is how that works. For each connector, add the 3D step 
> >> file from the connector manufacturer, align connectors to board and pads 
> >> and then export the complete board in step. I estimate that is would take 
> >> a few hours to get this done. 
> >> 
> >> I think someone asked for the Alegro ascii file which is necessary to 
> >> import the board into Altium, but so far I think Gerald hasn’t got this 
> >> done. 
> >> 
> >> Regards, 
> >> John 
> >> 
> >> 
> >> 
> >> 
> >>> On Feb 9, 2018, at 4:59 PM, Rick Mann <rm...@latencyzero.com <>> wrote: 
> >>> 
> >>> Oh, that's a pity. Makes it hard to know exactly where to place cutouts 
> >>> along the edges. I mean, I can measure it with calipers, but it's hard to 
> >>> get it accurate. In particular, I wanted to have the reset button insert 
> >>> into a boss on the enclosure to protect it from accidental presses. 
> >>> 
> >>> 
> >>>> On Feb 9, 2018, at 16:39 , Gerald Coley <gco...@emprodesign.com <>> 
> >>>> wrote: 
> >>>> 
> >>>> No, we never did one. We did not do the profiles for all of the parts on 
> >>>> the board. 
> >>>> 
> >>>> Gerald 
> >>>> 
> >>>> 
> >>>> -Original Message- 
> >>>> From: beagl...@googlegroups.com <> [mailto:beagl...@googlegroups.com <>] 
> >>>> On Behalf Of Rick Mann 
> >>>> Sent: Friday, February 9, 2018 6:34 PM 
> >>>> To: beagl...@googlegroups.com <> 
> >>>> Subject: Re: [beagleboard] x15 STEP file? 
> >>>> 
> >>>> Any chance of getting one? I'd like to design an enclosure for the x15. 
> >>>> 
> >>>> 
> >>>>> On Feb 9, 2018, at 16:11 , Gerald Coley <gco...@emprodesign.com <>> 
> >>>>> wrote: 
> >>>>> 
> >>>>> No 
> >>>>> 
> >>>>> Gerald 
> >>>>> 
> >>>>> -Original Message- 
> >>>>> From: beagl...@googlegroups.com <> [mailto:beagl...@googlegroups.com 
> >>>>> <>] On Behalf Of Rick Mann 
> >>>>> Sent: Friday, February 9, 2018 6:07 PM 
> >>>>> To: Beagle Board <beagl...@googlegroups.com <>> 
> >>>>> Subject: [beagleboard] x15 STEP file? 
> >>>>> 
> >>>>> Is there an x15 STEP CAD file available anywhere? 
> >>>>> 
> >>>>> -- 
> >>>>> Rick Mann 
> >>>>> rm...@latencyzero.com <> 
> >>>>> 
> >>>>> 
> >>>>> -- 
> >>>>> 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...@googleg

Re: [beagleboard] x15 STEP file?

[John Syne]

I’m wondering if this can be done with Eagle. It might be possible to import 
the gerber file, create the PCB from that and then add the connectors 3D parts. 
Perhaps someone who knows Eagle might comment. 

Regards,
John




> On Feb 9, 2018, at 5:54 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> I don't have Altium.
> 
>> On Feb 9, 2018, at 17:49 , John Syne <john3...@gmail.com> wrote:
>> 
>> If you could Import the board into Altium it is pretty easy to create the 
>> step file. Here is how that works. For each connector, add the 3D step file 
>> from the connector manufacturer, align connectors to board and pads and then 
>> export the complete board in step. I estimate that is would take a few hours 
>> to get this done. 
>> 
>> I think someone asked for the Alegro ascii file which is necessary to import 
>> the board into Altium, but so far I think Gerald hasn’t got this done. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 9, 2018, at 4:59 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>> 
>>> Oh, that's a pity. Makes it hard to know exactly where to place cutouts 
>>> along the edges. I mean, I can measure it with calipers, but it's hard to 
>>> get it accurate. In particular, I wanted to have the reset button insert 
>>> into a boss on the enclosure to protect it from accidental presses.
>>> 
>>> 
>>>> On Feb 9, 2018, at 16:39 , Gerald Coley <gcol...@emprodesign.com> wrote:
>>>> 
>>>> No, we never did one. We did not do the profiles for all of the parts on 
>>>> the board.
>>>> 
>>>> Gerald
>>>> 
>>>> 
>>>> -Original Message-
>>>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] 
>>>> On Behalf Of Rick Mann
>>>> Sent: Friday, February 9, 2018 6:34 PM
>>>> To: beagleboard@googlegroups.com
>>>> Subject: Re: [beagleboard] x15 STEP file?
>>>> 
>>>> Any chance of getting one? I'd like to design an enclosure for the x15.
>>>> 
>>>> 
>>>>> On Feb 9, 2018, at 16:11 , Gerald Coley <gcol...@emprodesign.com> wrote:
>>>>> 
>>>>> No
>>>>> 
>>>>> Gerald
>>>>> 
>>>>> -Original Message-
>>>>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] 
>>>>> On Behalf Of Rick Mann
>>>>> Sent: Friday, February 9, 2018 6:07 PM
>>>>> To: Beagle Board <beagleboard@googlegroups.com>
>>>>> Subject: [beagleboard] x15 STEP file?
>>>>> 
>>>>> Is there an x15 STEP CAD file available anywhere?
>>>>> 
>>>>> -- 
>>>>> Rick Mann
>>>>> rm...@latencyzero.com
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 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/8309A472-F439-4208-98C2-29BCC20BD3F6%40latencyzero.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.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/beagleboard/0debba3a25e74564a53e069445740289%40winhexbeus11.winus.mail.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>> 
>>>> 
>>>> -- 
>>>> Rick Mann
>>>> rm...@latencyzero.com
>>>> 
>>>> 
>>>> -- 
>>>> For more options, visit http://beagleboard.org/discuss
>>>> --- 
>>>> You received this message because you are subscribed to the Google Group

Re: [beagleboard] x15 STEP file?

[John Syne]

You don’t know of anyone with Altium? Try and find your local Altium user group 
and see if someone will help you. 

Regards,
John




> On Feb 9, 2018, at 5:54 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> I don't have Altium.
> 
>> On Feb 9, 2018, at 17:49 , John Syne <john3...@gmail.com> wrote:
>> 
>> If you could Import the board into Altium it is pretty easy to create the 
>> step file. Here is how that works. For each connector, add the 3D step file 
>> from the connector manufacturer, align connectors to board and pads and then 
>> export the complete board in step. I estimate that is would take a few hours 
>> to get this done. 
>> 
>> I think someone asked for the Alegro ascii file which is necessary to import 
>> the board into Altium, but so far I think Gerald hasn’t got this done. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 9, 2018, at 4:59 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>> 
>>> Oh, that's a pity. Makes it hard to know exactly where to place cutouts 
>>> along the edges. I mean, I can measure it with calipers, but it's hard to 
>>> get it accurate. In particular, I wanted to have the reset button insert 
>>> into a boss on the enclosure to protect it from accidental presses.
>>> 
>>> 
>>>> On Feb 9, 2018, at 16:39 , Gerald Coley <gcol...@emprodesign.com> wrote:
>>>> 
>>>> No, we never did one. We did not do the profiles for all of the parts on 
>>>> the board.
>>>> 
>>>> Gerald
>>>> 
>>>> 
>>>> -Original Message-
>>>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] 
>>>> On Behalf Of Rick Mann
>>>> Sent: Friday, February 9, 2018 6:34 PM
>>>> To: beagleboard@googlegroups.com
>>>> Subject: Re: [beagleboard] x15 STEP file?
>>>> 
>>>> Any chance of getting one? I'd like to design an enclosure for the x15.
>>>> 
>>>> 
>>>>> On Feb 9, 2018, at 16:11 , Gerald Coley <gcol...@emprodesign.com> wrote:
>>>>> 
>>>>> No
>>>>> 
>>>>> Gerald
>>>>> 
>>>>> -Original Message-
>>>>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] 
>>>>> On Behalf Of Rick Mann
>>>>> Sent: Friday, February 9, 2018 6:07 PM
>>>>> To: Beagle Board <beagleboard@googlegroups.com>
>>>>> Subject: [beagleboard] x15 STEP file?
>>>>> 
>>>>> Is there an x15 STEP CAD file available anywhere?
>>>>> 
>>>>> -- 
>>>>> Rick Mann
>>>>> rm...@latencyzero.com
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 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/8309A472-F439-4208-98C2-29BCC20BD3F6%40latencyzero.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.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/beagleboard/0debba3a25e74564a53e069445740289%40winhexbeus11.winus.mail.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>> 
>>>> 
>>>> -- 
>>>> Rick Mann
>>>> rm...@latencyzero.com
>>>> 
>>>> 
>>>> -- 
>>>> 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 t

Re: [beagleboard] x15 STEP file?

[John Syne]

If you could Import the board into Altium it is pretty easy to create the step 
file. Here is how that works. For each connector, add the 3D step file from the 
connector manufacturer, align connectors to board and pads and then export the 
complete board in step. I estimate that is would take a few hours to get this 
done. 

I think someone asked for the Alegro ascii file which is necessary to import 
the board into Altium, but so far I think Gerald hasn’t got this done. 

Regards,
John




> On Feb 9, 2018, at 4:59 PM, Rick Mann  wrote:
> 
> Oh, that's a pity. Makes it hard to know exactly where to place cutouts along 
> the edges. I mean, I can measure it with calipers, but it's hard to get it 
> accurate. In particular, I wanted to have the reset button insert into a boss 
> on the enclosure to protect it from accidental presses.
> 
> 
>> On Feb 9, 2018, at 16:39 , Gerald Coley  wrote:
>> 
>> No, we never did one. We did not do the profiles for all of the parts on the 
>> board.
>> 
>> Gerald
>> 
>> 
>> -Original Message-
>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
>> Behalf Of Rick Mann
>> Sent: Friday, February 9, 2018 6:34 PM
>> To: beagleboard@googlegroups.com
>> Subject: Re: [beagleboard] x15 STEP file?
>> 
>> Any chance of getting one? I'd like to design an enclosure for the x15.
>> 
>> 
>>> On Feb 9, 2018, at 16:11 , Gerald Coley  wrote:
>>> 
>>> No
>>> 
>>> Gerald
>>> 
>>> -Original Message-
>>> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
>>> Behalf Of Rick Mann
>>> Sent: Friday, February 9, 2018 6:07 PM
>>> To: Beagle Board 
>>> Subject: [beagleboard] x15 STEP file?
>>> 
>>> Is there an x15 STEP CAD file available anywhere?
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> -- 
>>> 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/8309A472-F439-4208-98C2-29BCC20BD3F6%40latencyzero.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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/0debba3a25e74564a53e069445740289%40winhexbeus11.winus.mail.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> -- 
>> 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/456546DB-E29B-4693-94AF-207091147C4D%40latencyzero.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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/18e15d0e850043f3bdc79688a4db3017%40winhexbeus11.winus.mail.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> -- 
> 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/BEFD3E61-AE5E-491D-987A-32CE904320E2%40latencyzero.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.
To view this discussion on the web visit 

Re: [beagleboard] Using two analog inputs and occurs distortion on the measure

[John Syne]

Yes, the problem is a combination of the multiplexor and the S Let’s say 
ADC0 is 3.5V and ADC1 is 0.2V and ADC2 is 2V. The S must first charge the 
capacitor to 3.5V for ADC0 and then the multiplexor changes to ADC1 and 
discharges the cap to 0.2V and then the mux changes to ADC2 and charges the cap 
to 2V. Now, if the source impedance of the circuits that feed ADC0, ADC1 and 
ADC2 are not low impedance, then the S cap will not charge/discharge fully 
before the ADC does the conversion. The time constant T=RC where T is the S 
window, R is the source impedance and C is the S cap. So if R is not low 
enough, you will see the accuracy of your conversion affected by the voltage of 
the previous channel. Alternatively, you can slow the sample rate and 
conversion time in the device tree and that will improve your accuracy. 

Regards,
John




> On Jan 21, 2018, at 7:37 AM, Mateus Lucas  wrote:
> 
> Thanks, John.
> 
> But I didn't understand yet how the high impedance on the input may cause 
> this error. The ADC input usually have a high impedance and the S have a 
> capacitor, the problem is related with the time to charge the capacitor? 
> 
> Em domingo, 21 de janeiro de 2018 04:31:36 UTC-3, john3909 escreveu:
> Yes, you use the opamp as a low impedance buffer and you can also use it to 
> scale the input to a range suitable for the ADC. Have a look at Analog 
> Devices, (www.analog.com ), they have many 
> application notes on how to use an opamp as a signal conditioner suitable for 
> an ADC.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Jan 20, 2018, at 3:13 PM, Mateus Lucas > wrote:
>> 
>> Oh, thank you for the explanation.
>> Are you talking about opamp as buffer or other circuit?
>> 
>> Em sábado, 20 de janeiro de 2018 19:43:31 UTC-3, john3909 escreveu:
>> The problem you are experiencing is due to the sample and hold of of the ADC 
>> input which is multiplexed to all analog inputs. If you don’t use a low 
>> impedance source, you will see bleed through from one ADC channel to the 
>> next. What you need is a opamp connected between the circuits you are 
>> measuring and the ADC input. The opamp will provide a low impedance source 
>> for the sample and hole (S) and prevent the bleed through from one channel 
>> to the next.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Jan 18, 2018, at 7:34 PM, mateuslu...@gmail.com <> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I'm using two analog inputs, the first with a LDR and a resistor of 10k 
>>> Ohm, connected at P9_39 (AIN0), and the second connected at P9_38 (AIN3).
>>> When the lights are down, the measure of LM35 works very well, with a low 
>>> distorction, +/- 0.2 ºC.
>>> But when the lights are on, the measure of LM35 starts to float, about +/- 
>>> 1 ºC.
>>> I have tried to put a 4.7nF between GNDA_ADC and AIN3, but the distorction 
>>> continues.
>>> 
>>> I asking for help to diminish this distorction when the lights are on.
>>> 
>>> 
>>> -- 
>>> 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/d5353977-2025-4aa3-b6a0-361742ae9c96%40googlegroups.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 <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/5024589e-3e59-43be-b293-98cd5e6c6f6e%40googlegroups.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 
> .
> To view this discussion on the web visit 
> 

Re: [beagleboard] Using two analog inputs and occurs distortion on the measure

[John Syne]

Yes, you use the opamp as a low impedance buffer and you can also use it to 
scale the input to a range suitable for the ADC. Have a look at Analog Devices, 
(www.analog.com), they have many application notes on how to use an opamp as a 
signal conditioner suitable for an ADC.

Regards,
John




> On Jan 20, 2018, at 3:13 PM, Mateus Lucas  wrote:
> 
> Oh, thank you for the explanation.
> Are you talking about opamp as buffer or other circuit?
> 
> Em sábado, 20 de janeiro de 2018 19:43:31 UTC-3, john3909 escreveu:
> The problem you are experiencing is due to the sample and hold of of the ADC 
> input which is multiplexed to all analog inputs. If you don’t use a low 
> impedance source, you will see bleed through from one ADC channel to the 
> next. What you need is a opamp connected between the circuits you are 
> measuring and the ADC input. The opamp will provide a low impedance source 
> for the sample and hole (S) and prevent the bleed through from one channel 
> to the next.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Jan 18, 2018, at 7:34 PM, mateuslu...@gmail.com <> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> I'm using two analog inputs, the first with a LDR and a resistor of 10k Ohm, 
>> connected at P9_39 (AIN0), and the second connected at P9_38 (AIN3).
>> When the lights are down, the measure of LM35 works very well, with a low 
>> distorction, +/- 0.2 ºC.
>> But when the lights are on, the measure of LM35 starts to float, about +/- 1 
>> ºC.
>> I have tried to put a 4.7nF between GNDA_ADC and AIN3, but the distorction 
>> continues.
>> 
>> I asking for help to diminish this distorction when the lights are on.
>> 
>> 
>> -- 
>> 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/d5353977-2025-4aa3-b6a0-361742ae9c96%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5024589e-3e59-43be-b293-98cd5e6c6f6e%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6950F4F2-53FF-4C54-B31D-12795D7BF85B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using two analog inputs and occurs distortion on the measure

[John Syne]

The problem you are experiencing is due to the sample and hold of of the ADC 
input which is multiplexed to all analog inputs. If you don’t use a low 
impedance source, you will see bleed through from one ADC channel to the next. 
What you need is a opamp connected between the circuits you are measuring and 
the ADC input. The opamp will provide a low impedance source for the sample and 
hole (S) and prevent the bleed through from one channel to the next.

Regards,
John




> On Jan 18, 2018, at 7:34 PM, mateuslucas.l7...@gmail.com wrote:
> 
> 
> 
> 
> 
> 
> I'm using two analog inputs, the first with a LDR and a resistor of 10k Ohm, 
> connected at P9_39 (AIN0), and the second connected at P9_38 (AIN3).
> When the lights are down, the measure of LM35 works very well, with a low 
> distorction, +/- 0.2 ºC.
> But when the lights are on, the measure of LM35 starts to float, about +/- 1 
> ºC.
> I have tried to put a 4.7nF between GNDA_ADC and AIN3, but the distorction 
> continues.
> 
> I asking for help to diminish this distorction when the lights are on.
> 
> 
> -- 
> 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/d5353977-2025-4aa3-b6a0-361742ae9c96%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F6484468-7890-40D1-94C4-F7850E711059%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: X15 Boot via USB

[John Syne]

https://groups.google.com/forum/#!searchin/beagleboard-x15/BeagleBoard-X15$20esata%7Csort:date/beagleboard-x15/2psyUbULTwc/81KWBokQBgAJhttps://groups.google.com/forum/#!searchin/beagleboard-x15/BeagleBoard-X15$20esata%7Csort:date/beagleboard-x15/2psyUbULTwc/81KWBokQBgAJ

Regards,
John




> On Jan 16, 2018, at 4:30 AM, marc bellazzini  wrote:
> 
> Hello Angel, 
> Mine is still collecting dust after my failed attempt at booting off the 
> eSATA and making the modifications you have also done. Very disappointing 
> since it was an expensive purchase. I am also awaiting a solution. The 
> directions on booting from eSATA were not very clear. 
> 
> Good luck!
> 
> On Mon, Jan 15, 2018 at 2:07 PM, Angel Sosa  > wrote:
> Hi Everyone,
> 
>  I am new to the X15. I have an XM since it came out and have done many 
> projects with it. I have recently purchased and X15. My desire is to boot 
> from a SATA drive connected to the ESATA port. I have verified when booted 
> from the MMC card the SATA drive is bootable, can mount and it works well. I 
> imaged the SATA drive with the X15 image, In my case SDA1  is the first 
> partition created. I have removed R444 and placed a jumper I believe what is 
> J3 pins 1-2 and have left the R444 resister solder points/mounts empty. When 
> I try to boot off of the SATA drive the board times out and powers down. The 
> instructions are  a little vague on the on instructions with in the user 
> manual. I had a similar problem when the partition was enlarged on the MMC 
> card to 32 gigs, the boot process would timeout. I used the grow_partition.sh 
> script which fixed the time out issue with the MMC card. If I hold the X15 
> board orienting J3, J4,J6 at the upper right corner hand corner, And join 
> pins 1-2 -- most left hole moving right towards the center  pin, there 
> orientation is horizontal I believe. The board as I mention powers up and 
> then times out and shuts down. I have tried with the MMC in and out no avail. 
> I have also purchased two boards at a pretty steep price and would like to 
> pass them out to family members with the hopes of purchasing additional 
> boards. But the ESATA/SATA issue is stopping me and I don't want to return 
> the second board to DIGIKEY. I cant return the first board well because I 
> modified it by removing the resistor. 
> 
> Is the image I used on the SATA drive incorrect or need an adjustment? Are 
> the PIN orientation as I understand it incorrect.
> 
> Held the X15 so that the ON switch is the upper left and jumpers are upper 
> right hand corner. 
> 
> The drive spins up when I power up the board. So I know the ESATA port is 
> powering up with the board.
>   1 2 3
> | Ethernet   |   | XX0 | J3 Short 1 and 2
> | Connector|   | 000 | J4
> | |   | 000 | J6
> 
> Drive Manufacturer is the SEAGATE IRON WOLF. 
> 
> Image:
> bbx15-debian-9.0-lxqt-armhf-2017-07-02-4gb.img.xz,
> I have also run ( apt-get -y update && and apt-get -y upgrade )
> 
> 
> Can you please help? Is there an alternate way of booting off of the ESATA 
> port
> 
> Thanks in advance 
> 
> Angel
> 
> 
> 
> On Thursday, September 28, 2017 at 10:54:51 AM UTC-4, mab.mo...@gmail.com 
>  wrote:
> Hello,
> 
> I just purchased an X15 and the EMMC memory is rapidly filling up. 
> 
> 1. Is there a way to boot from an external USB hard drive?
> or 
> 2. Can someone provide more detail directions on switching boot sequence to 
> boot directly from eSATA?
> The reference manual is very vague on this. You need to unsolder and resolder 
> resistors to act as jumpers? There are perforated holes in the circuit board 
> where the resistors and jumpers are supposed to be. Are the resistors 
> supplied? Are they on the board? If so where are they? What are their values 
> in Ohms? How are the perforations on the board numbered 1-3 from left to 
> right or right to left? This needs to be much more detailed. Why would you 
> design a board that make switching the boot sequence so difficult? How about 
> just putting in some removable jumpers!
> 
> Any detailed help and direction would be appreciated. 
> 
> Thanks
> 
> MAB
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> 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/xPYp2vR6TDk/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/6e58bd35-d1d8-4027-a5f8-23bd76edf60e%40googlegroups.com
>  

Re: [beagleboard] Re: X15 Boot via USB

[John Syne]

Here is the discussion I read about this issue.

https://groups.google.com/forum/#!topic/beagleboard-x15/FarRcmkeAI8 


Regards,
John




> On Jan 16, 2018, at 4:30 AM, marc bellazzini  wrote:
> 
> Hello Angel, 
> Mine is still collecting dust after my failed attempt at booting off the 
> eSATA and making the modifications you have also done. Very disappointing 
> since it was an expensive purchase. I am also awaiting a solution. The 
> directions on booting from eSATA were not very clear. 
> 
> Good luck!
> 
> On Mon, Jan 15, 2018 at 2:07 PM, Angel Sosa  > wrote:
> Hi Everyone,
> 
>  I am new to the X15. I have an XM since it came out and have done many 
> projects with it. I have recently purchased and X15. My desire is to boot 
> from a SATA drive connected to the ESATA port. I have verified when booted 
> from the MMC card the SATA drive is bootable, can mount and it works well. I 
> imaged the SATA drive with the X15 image, In my case SDA1  is the first 
> partition created. I have removed R444 and placed a jumper I believe what is 
> J3 pins 1-2 and have left the R444 resister solder points/mounts empty. When 
> I try to boot off of the SATA drive the board times out and powers down. The 
> instructions are  a little vague on the on instructions with in the user 
> manual. I had a similar problem when the partition was enlarged on the MMC 
> card to 32 gigs, the boot process would timeout. I used the grow_partition.sh 
> script which fixed the time out issue with the MMC card. If I hold the X15 
> board orienting J3, J4,J6 at the upper right corner hand corner, And join 
> pins 1-2 -- most left hole moving right towards the center  pin, there 
> orientation is horizontal I believe. The board as I mention powers up and 
> then times out and shuts down. I have tried with the MMC in and out no avail. 
> I have also purchased two boards at a pretty steep price and would like to 
> pass them out to family members with the hopes of purchasing additional 
> boards. But the ESATA/SATA issue is stopping me and I don't want to return 
> the second board to DIGIKEY. I cant return the first board well because I 
> modified it by removing the resistor. 
> 
> Is the image I used on the SATA drive incorrect or need an adjustment? Are 
> the PIN orientation as I understand it incorrect.
> 
> Held the X15 so that the ON switch is the upper left and jumpers are upper 
> right hand corner. 
> 
> The drive spins up when I power up the board. So I know the ESATA port is 
> powering up with the board.
>   1 2 3
> | Ethernet   |   | XX0 | J3 Short 1 and 2
> | Connector|   | 000 | J4
> | |   | 000 | J6
> 
> Drive Manufacturer is the SEAGATE IRON WOLF. 
> 
> Image:
> bbx15-debian-9.0-lxqt-armhf-2017-07-02-4gb.img.xz,
> I have also run ( apt-get -y update && and apt-get -y upgrade )
> 
> 
> Can you please help? Is there an alternate way of booting off of the ESATA 
> port
> 
> Thanks in advance 
> 
> Angel
> 
> 
> 
> On Thursday, September 28, 2017 at 10:54:51 AM UTC-4, mab.mo...@gmail.com 
>  wrote:
> Hello,
> 
> I just purchased an X15 and the EMMC memory is rapidly filling up. 
> 
> 1. Is there a way to boot from an external USB hard drive?
> or 
> 2. Can someone provide more detail directions on switching boot sequence to 
> boot directly from eSATA?
> The reference manual is very vague on this. You need to unsolder and resolder 
> resistors to act as jumpers? There are perforated holes in the circuit board 
> where the resistors and jumpers are supposed to be. Are the resistors 
> supplied? Are they on the board? If so where are they? What are their values 
> in Ohms? How are the perforations on the board numbered 1-3 from left to 
> right or right to left? This needs to be much more detailed. Why would you 
> design a board that make switching the boot sequence so difficult? How about 
> just putting in some removable jumpers!
> 
> Any detailed help and direction would be appreciated. 
> 
> Thanks
> 
> MAB
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> 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/xPYp2vR6TDk/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/6e58bd35-d1d8-4027-a5f8-23bd76edf60e%40googlegroups.com
>  
> 

Re: [beagleboard] Re: X15 Boot via USB

[John Syne]

I read that someone did manage to get the X15 to boot from esata when using a 
powered esata interface. Apparently the power to the esata connector isn’t 
available during uboot and hence the need for a powered esata interface. I 
haven’t tried this myself, but I do recall someone on the ARM Linux forum 
working on this. 

Regards,
John




> On Jan 16, 2018, at 4:30 AM, marc bellazzini  wrote:
> 
> Hello Angel, 
> Mine is still collecting dust after my failed attempt at booting off the 
> eSATA and making the modifications you have also done. Very disappointing 
> since it was an expensive purchase. I am also awaiting a solution. The 
> directions on booting from eSATA were not very clear. 
> 
> Good luck!
> 
> On Mon, Jan 15, 2018 at 2:07 PM, Angel Sosa  > wrote:
> Hi Everyone,
> 
>  I am new to the X15. I have an XM since it came out and have done many 
> projects with it. I have recently purchased and X15. My desire is to boot 
> from a SATA drive connected to the ESATA port. I have verified when booted 
> from the MMC card the SATA drive is bootable, can mount and it works well. I 
> imaged the SATA drive with the X15 image, In my case SDA1  is the first 
> partition created. I have removed R444 and placed a jumper I believe what is 
> J3 pins 1-2 and have left the R444 resister solder points/mounts empty. When 
> I try to boot off of the SATA drive the board times out and powers down. The 
> instructions are  a little vague on the on instructions with in the user 
> manual. I had a similar problem when the partition was enlarged on the MMC 
> card to 32 gigs, the boot process would timeout. I used the grow_partition.sh 
> script which fixed the time out issue with the MMC card. If I hold the X15 
> board orienting J3, J4,J6 at the upper right corner hand corner, And join 
> pins 1-2 -- most left hole moving right towards the center  pin, there 
> orientation is horizontal I believe. The board as I mention powers up and 
> then times out and shuts down. I have tried with the MMC in and out no avail. 
> I have also purchased two boards at a pretty steep price and would like to 
> pass them out to family members with the hopes of purchasing additional 
> boards. But the ESATA/SATA issue is stopping me and I don't want to return 
> the second board to DIGIKEY. I cant return the first board well because I 
> modified it by removing the resistor. 
> 
> Is the image I used on the SATA drive incorrect or need an adjustment? Are 
> the PIN orientation as I understand it incorrect.
> 
> Held the X15 so that the ON switch is the upper left and jumpers are upper 
> right hand corner. 
> 
> The drive spins up when I power up the board. So I know the ESATA port is 
> powering up with the board.
>   1 2 3
> | Ethernet   |   | XX0 | J3 Short 1 and 2
> | Connector|   | 000 | J4
> | |   | 000 | J6
> 
> Drive Manufacturer is the SEAGATE IRON WOLF. 
> 
> Image:
> bbx15-debian-9.0-lxqt-armhf-2017-07-02-4gb.img.xz,
> I have also run ( apt-get -y update && and apt-get -y upgrade )
> 
> 
> Can you please help? Is there an alternate way of booting off of the ESATA 
> port
> 
> Thanks in advance 
> 
> Angel
> 
> 
> 
> On Thursday, September 28, 2017 at 10:54:51 AM UTC-4, mab.mo...@gmail.com 
>  wrote:
> Hello,
> 
> I just purchased an X15 and the EMMC memory is rapidly filling up. 
> 
> 1. Is there a way to boot from an external USB hard drive?
> or 
> 2. Can someone provide more detail directions on switching boot sequence to 
> boot directly from eSATA?
> The reference manual is very vague on this. You need to unsolder and resolder 
> resistors to act as jumpers? There are perforated holes in the circuit board 
> where the resistors and jumpers are supposed to be. Are the resistors 
> supplied? Are they on the board? If so where are they? What are their values 
> in Ohms? How are the perforations on the board numbered 1-3 from left to 
> right or right to left? This needs to be much more detailed. Why would you 
> design a board that make switching the boot sequence so difficult? How about 
> just putting in some removable jumpers!
> 
> Any detailed help and direction would be appreciated. 
> 
> Thanks
> 
> MAB
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> 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/xPYp2vR6TDk/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> 

Re: [beagleboard] Threading for Beagle Bone

[John Syne]

Get this book:

Linux Device Drivers Development by John Madieu


Doesn’t use BBB, but it does cover the area you are interested in. Most 
important, it was written for Linux Kernel 4.1 and updated to 4.14

Regards,
John




> On Dec 25, 2017, at 4:34 AM, Rohit Karkala  wrote:
> 
> Hello everyone, 
> 
> I want to implement the threading function for GPIO Interrupt in C Program. 
> 
> Can anyone help with the code or reference . 
> 
> 
> 
> 
> -- 
> 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/e7b781c7-b700-46c5-a443-3afd57189852%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8A6D4884-093E-4FA5-BD39-F3F41FCB9445%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Unable to locate package linux-headers-4.4.91-ti-r133

[John Syne]

I recommend that you get this book as it will cover all the things you need:

Mastering Embedded Linux Programming - Second Edition by Chris Simmonds
Published by Packt Publishing
Released June 2017

Covers Linux Kernel 4.9 and uses the BBB hardware.


Regards,
John




> On Dec 24, 2017, at 9:58 PM, pawan sharma  wrote:
> 
> hi man,
> i m very new with beaglebone black,
> my version is BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.
> when i did 'uname -r' i got vi3.8.13-bone50 .
> i have tried sudo apt-get update and all the things.
> and i m hoping u ll help me from starting.
> and also ll send me the link of latest version too.
> 
> 
> On Monday, 25 December 2017 02:57:50 UTC+5:30, Stuart Longland wrote:
> On 24/12/17 20:35, pawan sharma wrote: 
> > sir i have same problem i did it what have u suggested but i cant get of 
> > my version.plz help my whatsapp number is +918563078782 
> 
> On 24/12/17 20:39, pawan sharma wrote: 
> > hi i have same problem please mail me or whatsApp me as soon as possible 
> > please help me my number is +918563078782.please please please please 
> 
> On 24/12/17 20:50, pawan sharma wrote: 
> > my version is vi3.8.13-bone50 
> > hi please help me i have same problem my whatsapp number is +918563078782. 
> 
> On 24/12/17 21:23, pawan sharma wrote: 
> > RoSchmi 
> > *HELP ME PLEASE 
> > * 
> 
> Jeepers!  There's asking for help… and then there's practically 
> screaming the place down as if you're being murdered! 
> 
> A few points: 
> 1. We're not all running the same timezone and schedule as you. 
> 2. We're volunteers… we're going to respond on *our* schedule, not 
> yours, *IF* we are able to help.  This is *especially* true at this time 
> of year, where many of us will be busy *away* from computers (spending 
> time with friends and family for example). 
> 3. Repeatedly asking "help me" and providing no further information on 
> what you've done to solve the problem does not inspire any of us to 
> assist, as it shows a lack of initiative in researching the problem. 
> 
> Replying to a thread can be okay if you reply with additional 
> information you have found or with different experiments you have 
> attempted… this shows you're at least trying to work the problem, and 
> may help someone else that winds up in your situation in the future. 
> 
> Now… with that underway… 
> 
> It sounds a lot like APT is picking up on the standard `linux-headers` 
> package that Debian ship; and kernel version 3.18 is rather dated now. 
> So likely you're running an out-dated image. 
> 
> That's a guess on my part though, as I am new to the Beagle Bone 
> ecosystem myself.  (I have a few years experience with Linux on RISC, 
> and about 20 with Linux itself, but bought my first BeagleBone a few 
> weeks back.) 
> 
> 1. What BeagleBone image are you running? 
> 2. Have you tried doing an `apt-get update; apt-get dist-upgrade` to get 
> everything up to date? 
> 3. What does `apt-cache policy linux-headers` display? 
> -- 
> Stuart Longland (aka Redhatter, VK4MSL) 
> 
> I haven't lost my mind... 
>   ...it's backed up on a tape somewhere. 
> 
> -- 
> 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/d23c075e-9223-4fd6-864f-1906915da597%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3332DF22-204C-43C5-9C70-8E4F7B204013%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is it possible to make work the BBB C program code without installing any operating systems?

[John Syne]

I think you meant StarterWareFree

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


Regards,
John




> On Nov 22, 2017, at 1:50 AM, mike.maikae...@gmail.com wrote:
> 
> Check out StarterWare from TI (there is also a FreeStarterWare project 
> available on sf.net  which contains a lot of bugfixes and 
> feature enhancements TI never managed to publish). It contains TCP/IP stack, 
> USB stack, functions to read/write FatFS on SD-card and many things more - 
> all as bare metal without the need to use an operating system and with a lot 
> of useful examples.
> 
> On Friday, November 17, 2017 at 4:12:38 AM UTC+1, AVR wrote:
> Thank you Graham, I completely forgot that I also need and exchange data on 
> TCP/IP... in that case is it possible to realize programmatically TCP/IP 
> without OS ?
> 
> четверг, 16 ноября 2017 г., 20:20:30 UTC+5 пользователь Graham написал:
> Yes, it is possible.
> Also, probably extremely painful learning experience.
> There are ARM processors that are designed to run with OS.  They start with 
> the letter A.
> The processor in the Beaglebone is an A-8.
> There are ARM processors that are designed to run without OS. They start with 
> the letter M.
> 
> I would suggest that you look at one of the faster M series, like a 200 MHz 
> M4F and see it that will do your job.
> 
> --- Graham
> 
> ==
> 
> On Wednesday, November 15, 2017 at 9:40:05 PM UTC-6, AVR wrote:
> In other words I'd like to make work the BeagleBone Black on the base C 
> program code without any operating systems. 
> My task is simple enough - frequency meter 0...100 KHz, DI/DO simple logic 
> and data exchange accross TCP/IP.
> 
> -- 
> 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/53d98194-df5e-4bb3-a8fc-5ad4d649f4be%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/79CB769B-7375-4937-9313-B987D6FD184E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Reading TPS65217 INT register with interrupt

[John Syne]

This is where you need to learn some GIT skills. Clone the kernel source and 
then in the kernel directory, issue this command:

git grep tps65217

This will tell you all the files that contain references to TPS65217. 

Regards,
John




> On Sep 23, 2017, at 1:28 AM, Ahmad Fatehi  wrote:
> 
> 
> Hi, I want to use 5V adaptor and battery for powering my beaglebone black, I 
> want to detect when 5V adaptor is missed and the board is supplying from 
> battery, for this I should read the INT and STATUS register of TPS65217 
>  if an interrupt is issued on PMIC_INT 
> pin. So probably I must access the linux kernel for TPS65217 driver and 
> modify it?! From where I can access to this kernel? or how can I detect 
> interrupt and read STATUS register?
> 
> -- 
> 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/059aebf0-c643-4f37-9ffe-9c6c13927881%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/95598A85-00BC-4893-8840-1FCEF6477AE1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Announcing $25 PocketBeagle

[John Syne]

I ordered mine from Digikey on Sept 21st and it arrived Sept 23rd. Product is 
amazingly small and looks beautiful. I also like the plastic packaging. This is 
really a low cost BeagleBone Module. With this module, Developers can now make 
their own hardware without the need for fine pitch PCB layout skills. 

Regards,
John




> On Sep 24, 2017, at 9:43 AM, acheesehead  wrote:
> 
> I had no issue ordering from Digikey as Robert suggested. USPS says it will 
> be here Mon.
> 
> On Saturday, September 23, 2017 at 7:52:26 PM UTC-6, Eric Keller wrote:
> This happens at Mouser every time there is a new 'bone.  It gets sorted 
> eventually.
> 
> 
> On Sat, Sep 23, 2017 at 1:01 PM, Graham  
> wrote:
> And this is just to get it shipped from Ft. Worth, Texas,  to a US Citizen in 
> Austin, Texas.
> 
> Just think what it will be like to get one outside of the U.S.
> 
> --- Graham
> 
> ==
> 
> 
> 
> 
> 
> 
> -- 
> 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/b36629ae-3c7a-4207-b3fe-2b481335ddab%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/0c713225-be9c-402e-8487-7aca85093088%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8DBCD4E9-A117-4B1B-9B61-45B4E9975348%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running the ADC with two channels at 800 kS/s per channel (1.6 MS/s total)

[John Syne]

The IIO driver uses DMA to transfer samples from the ADC to the buffer, so the 
CPU utilization is very low. Using the PRU, the ARM processor has to copy the 
Buffer from the PRU memory to ARM memory, and this causes the ARM CPU 
utilization to be higher than using the IIO driver. The IIO driver freeze up 
the PRU to do something more important.  

Regards,
John




> On Sep 22, 2017, at 3:56 PM, Jeff Andich  wrote:
> 
> Not delving into each implementation, and not knowing anything about the IIO 
> driver, I would think the PRU implementation would offload the utilization of 
> the Linux CPU (Arm9?) vs the IIO driver.   Is this true?
> 
> Also I thin the posted examples are worthwhile to those interfacing with an 
> external ADC and to those who are wanting more PRU coding examples..
> 
> regards and thanks for posting your project!
> 
> jeff
> 
> 
> 
> 
> 
> On Friday, September 22, 2017 at 11:05:55 AM UTC-5, john3909 wrote:
> You do realize that you can achieve the same sample rate with the IIO driver 
> in Linux?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Sep 22, 2017, at 12:07 AM, Arend Lammertink > > wrote:
>> 
>> Hi all,
>> 
>> I just wanted to share that I managed to run the ADC unit in a BBG at 
>> (almost?) 800 kS/sec sampling two channels, which means a total sampling 
>> rate of 1.6 mS/sec. I forked a small project from rvega and played with the 
>> code. You can find my code at:
>> 
>> https://github.com/l4m4re/bbb-pru 
>> 
>> The adc code is in the apps/adc directory.
>> 
>> Perhaps this code is helpful for others, too. The PRU code configures the 
>> ADC and the current setup samples AIN-1 and AIN-2 at 800 kS/sec.
>> 
>> Regards,
>> 
>> Arend Lammertink.
>> 
>> -- 
>> 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/e343b354-1e28-4b32-bd94-ad20fdd91f1b%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/6f5827cf-85ec-45c9-978a-f4e0d1f1957b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/BBEC839B-D260-4ED5-96EC-EDF2A0014D9B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running the ADC with two channels at 800 kS/s per channel (1.6 MS/s total)

[John Syne]

You do realize that you can achieve the same sample rate with the IIO driver in 
Linux?

Regards,
John




> On Sep 22, 2017, at 12:07 AM, Arend Lammertink  wrote:
> 
> Hi all,
> 
> I just wanted to share that I managed to run the ADC unit in a BBG at 
> (almost?) 800 kS/sec sampling two channels, which means a total sampling rate 
> of 1.6 mS/sec. I forked a small project from rvega and played with the code. 
> You can find my code at:
> 
> https://github.com/l4m4re/bbb-pru
> 
> The adc code is in the apps/adc directory.
> 
> Perhaps this code is helpful for others, too. The PRU code configures the ADC 
> and the current setup samples AIN-1 and AIN-2 at 800 kS/sec.
> 
> Regards,
> 
> Arend Lammertink.
> 
> -- 
> 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/e343b354-1e28-4b32-bd94-ad20fdd91f1b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F0692079-E18E-4E9F-9FBF-6E14B4EC7E1C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] After connecting CCS and JTAG to BBB and then disconnecting, the BBB hangs and doesn't show CCCC

[John Syne]

What are you trying to do? To use CCS in bare board mode, you need an SDCard 
that sets up the board to work with CCS. From what I recall, you need more than 
just the DDR3 GEL file to get BBB working. 

Regards,
John




> On Sep 19, 2017, at 1:45 PM, tlsmith3...@gmail.com wrote:
> 
> Running into an issue where we were able to see console output on the serial 
> console when no JTAG or CCS was connected.  After connecting CCS to JTAG and 
> updating the DDR3 gel file we were able to see the output over the CCS serial 
> console.  After disconnecting the JTAG and CCS and doing a board reset, we 
> can no longer see anything over the original serial console.  Disconnected 
> the serial console, did hardware reset, unplugged the BBB from the power 
> supply and still the BBB simply appears hung or redirecting output or simply 
> not responding CPU hung after power is applied.
> 
> What is causing this condition.  It is fine when JTAG is connected and using 
> CCS. But board appears hung with no CCCs or otherwise on reboot when JTAG and 
> CCS is not connected. What is taking place?
> 
> -- 
> 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/455153ef-0552-4de3-9ed8-f6f237cc4c7e%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/FC90A529-7387-4C3E-9DFF-75500C698D74%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Input range digital analog converter. Is the 1.8V adjustable?

[John Syne]

Geralds answer wasn’t complete. It is true that you cannot exceed the 1v8 input 
range of the ADC, but you can add a circuit before the ADC input that will 
convert the range from 0 to 5 volts -> 0 to 1v8. I would recommend that you ask 
a hardware engineer to assist you with this task as it is difficult to get this 
right if you have no experience in this area. Search Google for “ADC range 
opamp” for circuit examples. 

Regards,
John




> On Sep 13, 2017, at 8:53 AM, Ricardo Andres Gomez 
>  wrote:
> 
> I want to connect an analog output sensor from 0 to 5 volts. The adc by 
> specifications has a range of 0 1.8V. Is it possible to change this range?
> 
> -- 
> 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/c7232706-31b1-42f9-b5d0-888f78498010%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C6EA293D-E520-4E55-9933-32ECEA413C8B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] UART PWM Interference

[John Syne]

Shorten the GND wire between the BBB and the GND common point. The BBB GND 
plane must be the reference point and in your picture, you now have a second 
GND reference point with a long wire connecting the two. This creates a GND 
bounce on your second GND reference point and is probably responsible the the 
noise you are seeing. 

Regards,
John




> On Sep 4, 2017, at 4:30 AM, ojc...@gmail.com wrote:
> 
> See the two pictures below - I have tried to simplify things a few times - 
> but nothing seems to change the high error rate, although it might have 
> decreased a bit - a few times it has been ~50% (That was when I was trying to 
> run my Power HD MG1235 servo on a 7.2V UBEC)
> 
> 
> 
> The Xbee and PWM are on different sides of the BBB the only thing in common 
> as per the picture below is the GND.
> 
> 
> The code below shows the computer side of things to get you an idea of what 
> is going on there - I've posted the contents of xbee_tools.py below - not 
> that I think there's an issue there - just as FYI.
> 
> 
> 
>  
> 
> 
>  
> 
> 
> from xbee import XBee
> import serial
> import cPickle
> 
> class xbee_connection:
> def __init__(self, port, baudrate):
> # Start the serial connection
> try:
> self.ser = serial.Serial(port, baudrate)
> except serial.serialutil.SerialException:
> self.ser.close()
> print("Could not start serial connection, ensure that Xbee is 
> connected to COM4 port")
> 
> self.xbee = XBee(self.ser)  # Starting XBee connection
> self.msg = ""   # Initializing message as blank
> self.encoded_msg = ""
> 
> 
> def poll_data(self):
> 
> try:
> raw_data = self.xbee.wait_read_frame()
> #print raw_data['rf_data']
> #self.msg = cPickle.loads(raw_data['rf_data'])
> self.msg = raw_data['rf_data']
> #print(self.msg)
> # Ensuring that these values can be converted into floats
> except KeyboardInterrupt:
> self.ser.close()
> except Exception as e: print(e)
> 
> except:
> pass
> 
> return self.msg
> 
> def disconnect(self):
> self.ser.close()
> 
> 
> 
> 
> On Monday, September 4, 2017 at 12:35:25 AM UTC+12, Przemek Klosowski wrote:
> Could you post a picture or drawing of your physical layout? I think the 
> evidence points to interference from the PWM circuit into the XBee. HOw close 
> physically are they?
> 
> On Fri, Sep 1, 2017 at 9:18 PM,  wrote:
> Just tried adding the 1uF decoupling capacitor in parallel with the existing 
> 0.1uF capacitor - it didn't decrease the high error rate.
> 
> On Saturday, September 2, 2017 at 12:08:00 PM UTC+12, ojc...@gmail.com <> 
> wrote:
> So tested all of that - see table below
> The servo power supply is a QM12V5A 
> 
>  but as seen below - even when this is not active, there is still a high 
> error rate.
> Also, I am not opening and closing the serial port now - it stays open 
> throughout each test. I sent 100 messages for each test. Error rates are an 
> approximate guess.
> 
> PWM running  Servo & Servo Power Supply Active Message Mode   
>Error Rate
> Yes  Yes  
>   RX-TX on loopback   0% - all good
> Yes  No   
>   RX-TX on loopback   0% - all good
> No   No   
>   RX-TX on loopback   0% - all good
> Yes  Yes  
>   BBB to PC via xbee  10 - 50% - no good
> Yes  No   
>   BBB to PC via xbee  10 - 50% - no good
> No   No   
>   BBB to PC via xbee   0% - all good
> 
> I don't really know what to make of it except that the problem seems to be 
> somewhere either in the xbee?
> The xbee is connected with a 0.1uF decoupling capacitor between +3.3V and GND 
> close to the xbee (~25mm length from xbee GND pin thru 0.1uF Cap to xbee 
> +3.3V pin)
> 
> I see some people recommend a 1uF decoupling capacitor on the xbee - maybe 
> I'll try adding one of those in parallel with the 0.1uF cap.
> 
> 
> On Friday, September 1, 2017 at 9:22:31 AM UTC+12, Przemek Klosowski wrote:
> 
> 
> On Thu, Aug 31, 2017 at 3:13 PM, > wrote:
> Errors : yes 

Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

I haven’t used CCS for several years as I use Lauterbach for all my linux 
kernel/driver debugging. However, I’ll try to remember how to everything you 
need. See inline comments:
 
Regards,
John




> On Aug 5, 2017, at 9:44 AM, clarkbriggs...@gmail.com wrote:
> 
> John,
> Thanks. It does sound like you know the TI CCS stuff. While the TI market 
> place exposed several high level products, I can't figure out how to drill 
> down to the compiler. In particular, I think I installed for the AM33xx BBB 
> processor when I first put CCS in, but can't find any trace of the processor 
> family in the configuration.  Further, I don't find any settings for the 
> target OS.  I am using CCS on Windows and targeting Debian on the BBB.
Use CCS to create a new C/C++ Makefile project. On the project in the explorer 
panel, right click on the project name and select properties. I don’t recall 
the section, but you should see a section with environment variables, where you 
add:
CROSS_COMPILE=/arm-linux-gnueabihf-
ARCH=arm
Now in the explorer panel, add files/folders and then run “Build Project” (I 
think that is the name). You should see the result/errors of your build in the 
console window.

This might help:

https://training.ti.com/linux-board-porting-series-module-10-debugging-linux-kernel-jtag-ccs
 

https://training.ti.com/search-catalog/field_language/EN/categories/products?keyword_op=AND=CCS%20linux==
 

http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5 



> Like I said, this is a complex and maybe unusual configuration (source 
> debugging remotely but compiling natively on the target), so I wanted to try 
> a cross compile for helloworld.c but can't find the TI compiler in the 
> development environment. I figured if that worked, the right gdb would be 
> there and I could try living with a (nicely set up by TI) cross development 
> environment.
> So...how to put just the right cross compiler in this existing CCS install?
> Thanks,
> Hugh/Clark
> 
> On Tuesday, August 1, 2017 at 2:24:49 PM UTC-7, john3909 wrote:
> You need arm-linux-gnueabihf-gdb and it needs to be the same as your compiler 
> version used to build your executable. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Aug 1, 2017, at 1:44 PM, clarkbr...@gmail.com  wrote:
>> 
>> William etal,
>> Pointing to Molloy was a good hint. I watched him do it and around minute 31 
>> he starts into remote debugging. He uses Eclipse and some cross tool chain, 
>> but I didn't watch that. I am using the TI CCS v7.2 on Windows 7x64 which is 
>> Eclipse based, but not cross compiling with their included tools.
>> My configuration is somewhat different from Molloy's. He is cross compiling 
>> so the sources AND the binary are present on the dev machine with Eclipse. I 
>> have only the sources on my dev machine since I compile on the BBB.
>> Issue 1. When creating a remote debug configuration in CCS/Eclipse the Main 
>> tab field "C/C++ Application:" apparently wants the local binary on the dev 
>> machine. It isn't happy without it and won't move forward at all. If I drag 
>> the binary from the BBB back to the dev workspace and point at it, it will 
>> go on.
>> What is the correct way to configure this environment (source and dbg on Win 
>> dev host; source, binaries and gdbserver on BBB)?
>> Issue 2. So with a copy of the application binary on the dev host, launching 
>> a remote debugging session leads to a gripe from the gdbserver about not 
>> understanding the MI command list-features.  The console shows the 
>> connection on the BBB target successfully launches gdbserver with the 
>> configured port, the absolute path to the executable and the arguments. 
>> After the "listening on port 2345" echo it terminates with the gripe about 
>> the MI command.
>> Groping der google suggests this is often due to not having the correct 
>> architecture gdb on the dev host selected. When installing CCSv7 I picked 
>> only the arm tools for the AM33xx family processor. In the debug 
>> configuration debugger tab main tab GDB debugger is the default setting 
>> "gdb".  There is a Browse button to go looking through the installed 
>> ti/ccsv7/tools/compiler, but the only gdb in the TI tools I can find is 
>> C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-6-2017-q1-update\bin\arm-none-eabi-gdb.exe.
>>  that gdb echoes as it starts "This GDB was configured as 
>> "--host=i686-w64-mingw32 --target=arm-none-eabi"." then warns "warning: A 
>> handler for the OS ABI "GNU/Linux" is not built into this configuration of 
>> GDB. Attempting to continue with the default arm settings." It then quits 
>> with a complaint that no source was available.
>> Maybe this is really a TI CCS specific setting. Earlier John pointed 

Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

You need arm-linux-gnueabihf-gdb and it needs to be the same as your compiler 
version used to build your executable. 

Regards,
John




> On Aug 1, 2017, at 1:44 PM, clarkbriggs...@gmail.com wrote:
> 
> William etal,
> Pointing to Molloy was a good hint. I watched him do it and around minute 31 
> he starts into remote debugging. He uses Eclipse and some cross tool chain, 
> but I didn't watch that. I am using the TI CCS v7.2 on Windows 7x64 which is 
> Eclipse based, but not cross compiling with their included tools.
> My configuration is somewhat different from Molloy's. He is cross compiling 
> so the sources AND the binary are present on the dev machine with Eclipse. I 
> have only the sources on my dev machine since I compile on the BBB.
> Issue 1. When creating a remote debug configuration in CCS/Eclipse the Main 
> tab field "C/C++ Application:" apparently wants the local binary on the dev 
> machine. It isn't happy without it and won't move forward at all. If I drag 
> the binary from the BBB back to the dev workspace and point at it, it will go 
> on.
> What is the correct way to configure this environment (source and dbg on Win 
> dev host; source, binaries and gdbserver on BBB)?
> Issue 2. So with a copy of the application binary on the dev host, launching 
> a remote debugging session leads to a gripe from the gdbserver about not 
> understanding the MI command list-features.  The console shows the connection 
> on the BBB target successfully launches gdbserver with the configured port, 
> the absolute path to the executable and the arguments. After the "listening 
> on port 2345" echo it terminates with the gripe about the MI command.
> Groping der google suggests this is often due to not having the correct 
> architecture gdb on the dev host selected. When installing CCSv7 I picked 
> only the arm tools for the AM33xx family processor. In the debug 
> configuration debugger tab main tab GDB debugger is the default setting 
> "gdb".  There is a Browse button to go looking through the installed 
> ti/ccsv7/tools/compiler, but the only gdb in the TI tools I can find is 
> C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-6-2017-q1-update\bin\arm-none-eabi-gdb.exe.
>  that gdb echoes as it starts "This GDB was configured as 
> "--host=i686-w64-mingw32 --target=arm-none-eabi"." then warns "warning: A 
> handler for the OS ABI "GNU/Linux" is not built into this configuration of 
> GDB. Attempting to continue with the default arm settings." It then quits 
> with a complaint that no source was available.
> Maybe this is really a TI CCS specific setting. Earlier John pointed to CCS 
> so maybe he can provide some direction.
> Thanks,
> Hugh
> 
> On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:
> 
> 
> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  > wrote:
> This is probably the best guide you're going to find on the subject.
> 
> https://www.youtube.com/watch?v=T9yFyWsyyGk 
> 
> 
> Never used it myself( I do not cross compile ), but I'm confident DR Molly's 
> instructions work.
> 
> Just in case it's not clear, R Molly shows how to setup remote debugging 
> towards the end I think. Been a while since I've watched this. 
> 
> 
> -- 
> 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/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/587433A3-9E03-428E-A642-A003BB9EF79D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] JTAG beagle bone black with buspirate and openocd

[John Syne]

I haven’t heard of anyone successfully using Openocd on BBB even though I have 
seen many users try it. I would recommend using Blackhawk USB200 with Code 
Composer Studio (CCSV7) as it has everything you need to get started. 

Regards,
John




> On Jul 31, 2017, at 5:20 AM, devarya...@gmail.com wrote:
> 
> Hello
> 
> I am very new to JTAG and i am trying to do the setup for jtag in beaglebone 
> black(BBB) rev c board using buspirate(BP) and openocd.
> I have installed the P2 header in BBB manually. I have connected the BBB and 
> BP as follows
> 
> JTAG  BP  BBB
> TMS   CS  P2(1) P2 header pin 1
> TDI   MOSIP2(3)
> VTREF VPU P2(5)
> TDO   MISOP2(7)
> TCK   CLK P2(11)
> TRST  AUX P2(2)
> GRND  GND P2(10)
> 
> 
> I am using my user configuration file(BP_userconfig.cfg) for openocd which 
> has following content.
> 
> source [find interface/buspirate.cfg]
> 
> buspirate_vreg 0
> buspirate_mode open-drain
> buspirate_pullup 1
> reset_config srst_only
> buspirate_port /dev/ttyUSB0
> 
> source [find board/ti_beaglebone_black.cfg]
> 
> Now while running the command sudo openocd -f  BP_userconfig.cfg I am getting 
> following error.
> 
> lenova@lenova-ThinkPad-T410:~/jiten/JTAG$ sudo openocd -f BP_userconfig.cfg 
> Open On-Chip Debugger 0.10.0+dev-00167-g29cfe9c (2017-07-20-14:08)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Warn : Adapter driver 'buspirate' did not declare which transports it allows; 
> assuming legacy JTAG-only
> Info : only one transport option; autoselect 'jtag'
> srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
> trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
> connect_deassert_srst
> adapter speed: 1000 kHz
> trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
> connect_deassert_srst
> Info : Buspirate Interface ready!
> Info : This adapter doesn't support configurable speed
> Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas 
> Instruments), part: 0xb944, ver: 0x2)
> Info : JTAG tap: am335x.dap enabled
> Error: JTAG-DP STICKY ERROR
> Error: Could not initialize the APB-AP
> 
> Does anyone have any idea about this error? and do i need to do anything else 
> in BBB apart from installing P2 header?
> Please let me know if i am doing anything wrong.
> 
> Thanks in advance.
> 
> Regards
> jitendriya
> 
> 
> -- 
> 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/94f1fafb-03d7-43cc-80d1-8249e2735bcd%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7D285B3A-2B28-4859-A25A-347A6F1F54B9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

Are you debugging user space app or kernel code like drivers, kernel modules, 
etc?

If you are debugging user space app, you have two solutions:
1) use gdbserver on your BBB and Code Composer Studio (CCSV7) or Eclipse on 
your host, which uses gdb for debugging. You will need your BBB source code on 
your host. I recommend that you use NFS to host your BBB rootfs on your host 
machine. 
2) use USB200 JTAG debugger and use CCSV7 for debugging.

For kernel code debugging, you can use 2) above, but the debugging is limited 
because CCSV7 isn’t kernel aware. 

Regards,
John




> On Jul 26, 2017, at 4:34 PM, clarkbriggs...@gmail.com wrote:
> 
> I really need to have a symbolic interface to gdb running on my BBBs.  Here 
> is my situation.
> I keep build copies of the software on the BBB and compile them on the BBB.
> I edit them on my PC, keeping the masters in a local repo. I manually move 
> them over after editing to compile them on the BBB.
> I have tried debugging on the BBB with gdb and its command line interface but 
> the code has gotten too complicated nowadays.
> I am running the 2017-03-19 image with updates. I am concerned about the file 
> space remaining on the BBB so I don't want a big app on the BBB.
> I can do X to my desktop, so an X frontend to dbg seems like the best answer.
> In other situations, I have used Eclipse CDT on my dev station (that was a 
> Ubuntu box) but cross compiling and remote debugging were a problem. I ended 
> up pushing the sources over and compiling over on the BBB and never remote 
> debugged.
> Now I have a Windows dev station and I could put Eclipse on it, but things 
> like cross compiling would be a disaster.
> I push the BBB pretty hard with my app. The BBB is only a single processor.  
> Whatever the front end it shouldn't take a lot of cpu. I guess during 
> debugging sessions, the cpu load is excusable tho.
> I don't think the file space for putting Eclipse CDT on the BBB is 
> affordable, otherwise I like running Eclipse on the BBB. I can teach Eclipse 
> where my repo is. I could run it via X from my PC.
> I could rebuild the bots but use a big SD card so file space isn't a problem. 
> I guess I haven't accreted s much stuff that rebuilding would be a set 
> back.
> So what to do?
> Thanks,
> Clark
> 
> -- 
> 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/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C678A9E7-E9E4-4D09-9DAB-CA459FDE0265%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RTC's SDA and SCL Resistors

[John Syne]

OK, if you read the datasheet, you will see VIH = 2v2 and VIL = 0v8, which 
means the I2C signals are compatible with a 3v3 pullups. The module you 
referenced has pullup resistors to 5v0, which means they must be removed. There 
are voltage convertors from TI for I2C devices, but in this case they are not 
required. However, if you want to leave the 5v0 pullup resistors on the module, 
then you must use one of these voltage translators. Here is an example:

https://www.sparkfun.com/products/11955 




Regards,
John




> On Jul 26, 2017, at 3:14 PM, William B  wrote:
> 
> John, I get it. But I do not know how it would be possible to do this in my 
> DS1307 module which is of this type:
> http://www.ebay.com/itm/5-PCS-I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Module-For-AVR-ARM-PIC-/172308340060?epid=846722400=item281e609d5c:g:VxcAAOSwawpXsn0J
>  
> 
> 
> 
> How would It connect to 3.3V hardware instead of 5V?
> 
> Thank you again!
> 
> 
> 
> 
> 
> 
> -- 
> 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/2b99797f-afbb-4408-a47d-3efcbf10b0d4%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/172B3109-D6D8-4358-8133-6F8635C520CC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RTC's SDA and SCL Resistors

[John Syne]

Just to be clear, the Adafruit module has 2k2 resistors to 5V. These must be 
removed. However, the BBB still needs pullup resistors to 3v3.

Regards,
John




> On Jul 26, 2017, at 1:42 PM, William B  wrote:
> 
> Hi! 
> I'm installing a real-time clock (RTC) on Beaglbone Black and I'm seeing 
> divergent information abount hardware of the DS1307 integrated circuit, that 
> operates at 5V voltage, while the I2C IO buses of the BeagleBone operate at 
> 3.3V.
> 
> In the Adafruit RTC, they indicate removing the SCL and SDA resistors from 
> the DS1305 kit as shown here: 
> https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/wiring-the
>  -rtc 
> 
> 
> In linux.org, nothing is reported about the resistors and there are other 
> places that also do not say anything about the resistors: 
> http://elinux.org/Adafruit:_RTC_DS1307 
> 
> 
> Question:
> Should I keep the SCL and SDA resistors? Or should I remove the resistors?
> 
> -- 
> 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/3e5c2f95-d7d4-47e6-9fd9-6c027792386f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/BACFA297-6930-4F0A-B1FA-84864485210D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RTC's SDA and SCL Resistors

[John Syne]

Connect the pullup resistors to 3v3.

Regards,
John




> On Jul 26, 2017, at 1:42 PM, William B  wrote:
> 
> Hi! 
> I'm installing a real-time clock (RTC) on Beaglbone Black and I'm seeing 
> divergent information abount hardware of the DS1307 integrated circuit, that 
> operates at 5V voltage, while the I2C IO buses of the BeagleBone operate at 
> 3.3V.
> 
> In the Adafruit RTC, they indicate removing the SCL and SDA resistors from 
> the DS1305 kit as shown here: 
> https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/wiring-the
>  -rtc 
> 
> 
> In linux.org, nothing is reported about the resistors and there are other 
> places that also do not say anything about the resistors: 
> http://elinux.org/Adafruit:_RTC_DS1307 
> 
> 
> Question:
> Should I keep the SCL and SDA resistors? Or should I remove the resistors?
> 
> -- 
> 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/3e5c2f95-d7d4-47e6-9fd9-6c027792386f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B2CC2BB1-BA46-41D6-95BA-E29CA0785FFC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Self-executing interrupt problem

[John Syne]

Do you have a resistor pull up or pull down on this pin? If your button pulls 
the GPIO pin low, then you need a resistor pull up of at least 10K. It seems 
like you don’t have this resistor connected and hence noise is triggering the 
interrupt.

Regards,
John




> On Jul 21, 2017, at 3:01 PM, William B  wrote:
> 
> Hello again John. I was able to observe the error occurring and the 
> interruption being executed without reason. But the response from 
> "console.log (JSON.stringify (x));" was still the same when the interrupt was 
> executed correctly, ie when I pressed the button.
> 
> So, if you have any suggestions, I appreciate any help.
> 
> -- 
> 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/0113bec9-4291-42c7-8d13-68c138957164%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8E02E9F9-BB84-41F2-976F-8954F7822A99%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Self-executing interrupt problem

[John Syne]

In toggleState, use console.log(JSON.stringify(x)); to see why the interrupt 
triggered.

Regards,
John




> On Jul 21, 2017, at 1:52 PM, William B  wrote:
> 
> Hello! I'm using an interrupt with Beaglebone Black as indicated below, 
> however I'm having problem. 
> PROBLEM: The interrupt that goes through the callback function "toggleState" 
> is triggering itself, without any external reason or action.
> 
> Has anyone seen this happen and knows how to solve it?
> 
> 
> EXAMPLE:
> 
> myInput = 'P9_11';
> 
> b.pinMode(myInput, b.INPUT); 
> b.attachInterrupt(myInput, true, b.CHANGE, toggleState);
> 
> function toggleState(x) {  << Running for no reason
> console.log('Interruption triggered');  
> }
> 
> -- 
> 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/51f710e8-8055-4f1f-aa80-c6eb22289d13%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B9E3BA3F-0E04-4F52-BD4C-55C3D56CB172%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What can I do to eliminate the Display functions in the Debian Jessie Kernal Linux?

[John Syne]

Hi Edgar,

I would recommend that you buy this book as it will answer most of the question 
you have asked:

Mastering Embedded Linux Programming - Second Edition by Chris Simmonds

If you buy the Kindle edition, you can start reading immediately on you Tablet, 
Mac, PC or Kindle device. If you search on Amazon, you will see the table of 
contents and you will see that it covers most of the areas you are interested 
in. 

Regards,
John




> On Jul 20, 2017, at 11:16 PM, edgargrimme via BeagleBoard 
>  wrote:
> 
> Hello Gays,
> 
> what is the easiest way to eliminate all Software parts for the Display 
> Driver if I have a backup SD Card?
> 
> Do I Need a Kernal Projekt to rebuild the Linux Kernal?
> Exist the Option to disable functions in the start configuration  files and 
> to delete Files at the SD Card? Which files?
> 
> Can anyone help me?
> 
> Best regards
> Edgar 
> 
> -- 
> 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/c9e84d1e-f712-41d2-b849-d830952d4772%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/09C37A33-5937-4B4F-87EB-DE77CFF44BF2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can the BBB Board damaged by switch off without shut down?

[John Syne]

> On Jul 18, 2017, at 9:47 PM, edgargrimme via BeagleBoard 
>  wrote:
> 
> Hallo Gays,
> 
> I had two boards damaged. I don't know the reason. I swiched them off without 
> correct shut down. Both boards doesn't starts after this Switch off. The 
> first board can't flashed again. The ROM (eMMC) is damaged and the second 
> board doesn't enables the Power (LED off) but power at Input is OK.
With no power LED, then the power management chip if probably faulty. There is 
an errata for the AM335x which requires that the voltage difference between the 
1v8 and 3v3 rail should not exceed 2v. When you shutdown the BBB, this can 
occur and damage the processor. Many developers power off their BBB all the 
time and they don’t see this happen, but the more you do this, the processor 
will eventually fail. Some of the later boards have a circuit to ensure the 
difference between the 3v3 and 1v8 rails does not exceed 2v. The BBB does not 
have this circuit. 
> Has the BBB Board a Problem with direct Switch off without shut down?
> Writes the Linux (Debian) sporadic or periodically into the ROM e.g. logging 
> System status?
> Use the Linux Driver for the ROM Memory a RAM to reduce writing to ROM?
You can use a temporary ram disk to limit writes to EMMC and SDCard. 
> Can I lost data or damage the System if my BBB Board Switches off without 
> shut down?
This is true of any computer system. All operating systems cache file writes to 
maximize throughput which get flushed to disk when going through a shutdown. if 
you pull the power, the directory may be in the middle of an update and files 
may be partially written, so this will cause file/directory corruption. You 
either need a power supply monitor with batteries or supercaps that will 
trigger a shutdown when a power failure occurs. 

Regards,
John
> 
> Please help me.
> 
> Best regards
> Edgar
> 
> -- 
> 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/ea2bd712-c4ed-41cb-80d2-0963e0c984c1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2D944C3B-2246-4CA8-B038-6A15ECA83112%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[John Syne]

Well, that depends on how complex your algorithm is, but in most cases, 10ms 
latency should not be a problem. 

Regards,
John




> On Jun 28, 2017, at 7:36 AM, MDX  wrote:
> 
> Output must be a constant stream upon any input and 10ms is considered as a 
> critical issue
> 
> -- 
> 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/ffb698e6-8b37-4add-86aa-d091bc33d4c2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/08FDFF60-4119-437D-856C-77B5C1850A8D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

Well the purpose of my advise what to show you how to cross compile kernel 
modules without having to worry about kernel version, kernel headers and 
compiler versions. By using Robert’s build tool, he does all that for you. 
Better still, if you use source indexing with Eclipse, you get function code 
completion and can jump to those function using "ctrl left mouse click” and 
“alt left arrow” to return to your code. There are also lots of example in the 
Kernel/samples folder. 

Regards,
John




> On Jun 28, 2017, at 5:58 AM, mzimmers  wrote:
> 
> Hi, John -
> 
> I was indeed able to successfully execute Robert's instructions, so I know 
> how to make the kernel. Useful information for when the time comes for it. I 
> will also note your advice above. Very much appreciated.
> 
> This thread has drifted a bit, and so I think I'll close it out. I'll pursue 
> my original question (how to cross build and debug an LKM) in another forum, 
> since I think I've bugged everyone here enough for now.
> 
> Thanks to all who participated in this thread...
> 
> On Tuesday, June 27, 2017 at 6:44:08 PM UTC-6, john3909 wrote:
> I see Robert has answered all your question. Here are some suggestions that 
> might help once you complete the first build. 
> 
> After you build, you will find the kernel on the yakbuild/KERNEL folder. This 
> is where you edit your code. Do not “build_kernel.sh” again as this will 
> overwrite any code you edited. Use yakbuild/tools/rebuild.sh to rebuild the 
> kernel with your changes. The output of the build is placed in the 
> yakbuild/deploy folder. You will find an yakbuild/deploy/update.sh which you 
> can customize to copy the files to your NFS share or use 
> yakbuild/deploy/updateSD.sh to update your BBB SDcard.
> 
> I recommend that you place your kernel module/driver under the 
> yakbuild/KERNEL/drivers folder. If you create a custom folder, then you need 
> to edit the Makefile and Kconfig files in the drivers folder. Your custom 
> folder must also have a Makefile and Kconfig file. Look at other folders in 
> the drivers folders for examples. 
> 
> Alternatively, you could also use the yakbuild/KERNEL/samples folder for your 
> source code. 
> 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/4646b453-2069-4d7a-a0f8-30f487caaf98%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8C05D0CD-8A87-41D4-AEEB-A62650416060%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

I see Robert has answered all your question. Here are some suggestions that 
might help once you complete the first build. 

After you build, you will find the kernel on the yakbuild/KERNEL folder. This 
is where you edit your code. Do not “build_kernel.sh” again as this will 
overwrite any code you edited. Use yakbuild/tools/rebuild.sh to rebuild the 
kernel with your changes. The output of the build is placed in the 
yakbuild/deploy folder. You will find an yakbuild/deploy/update.sh which you 
can customize to copy the files to your NFS share or use 
yakbuild/deploy/updateSD.sh to update your BBB SDcard.

I recommend that you place your kernel module/driver under the 
yakbuild/KERNEL/drivers folder. If you create a custom folder, then you need to 
edit the Makefile and Kconfig files in the drivers folder. Your custom folder 
must also have a Makefile and Kconfig file. Look at other folders in the 
drivers folders for examples. 

Alternatively, you could also use the yakbuild/KERNEL/samples folder for your 
source code. 

Regards,
John




> On Jun 27, 2017, at 10:40 AM, mzimmers  wrote:
> 
> Ah, OK...I missed the "branches" button on the web page. A few follow-up 
> questions, please:
> 
> - I neglected to mention that I'm looking for the source code; am I in the 
> correct location?
> - it seems that branches are maintained for each version and patch level. Do 
> I need to concern myself with finding the right stuff for the sublevel as 
> well?
> -  my BBB is currently running 4.4.48. In my brief browsing, I didn't find 
> mention of this particular version. Would it be advisable to move up to a new 
> version as long as I'm going through this exercise?
> 
> Thanks.
> 
> -- 
> 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/14051cf1-b93d-4e3c-90ae-2ee63b30599c%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8AF08D52-C91D-4D06-9D31-315E8A37DC3C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[John Syne]

So what is the maximum latency to can tolerate?

Remember, each DSP has 8 functional units (two multiply units and 6 ALUs) which 
means you can execute up to 8 instructions per cycle.

Here are some core benchmarks:

http://www.ti.com/lsds/ti/processors/technology/benchmarks/core-benchmarks.page 




Regards,
John




> On Jun 26, 2017, at 9:34 PM, MDX  wrote:
> 
> Well, samples are part of stream that must "return" to output in-order and 
> with a minimal latency, and i never planned to use asm
> 
> -- 
> 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/3f0604ab-35b5-4e32-a89d-74fff9ffeb79%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/04F3C7F8-8958-4DF4-A0E3-32E19CB6918E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[John Syne]

First you have to define what you mean by “real-time”. To most it means 
completing a task in a well defined amount of time. As long as you don’t turn 
off interrupts for extended periods, there is no reason why the responsiveness 
isn’t deterministic. 

Coordinating between the DSPs is something you have to setup in your software. 
You can do this via shared memory, interrupts, etc. 

BTW, the TI C-compiler used for the DSPs is extremely good and in many cases is 
more efficient than programming in assembly. Only the most highly skill DSP 
programmer will be able to achieve better assembly performance vs C-code. 

Regards,
John




> On Jun 26, 2017, at 10:36 AM, MDX  wrote:
> 
> Well, you guessed (almost) correctly and your answer pretty much fills my 
> list of requirement. Now i wonder if that "high-level communication" is 
> enough to control resource sharing between C66x software processing samples 
> in programmed order, so that it stays in real-time
> 
> -- 
> 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/e8744846-2529-4fde-b0d7-384bf2d979e3%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/82BDE4BF-F818-4A71-AEF3-7C0515EF33FE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[John Syne]

You can operate them independently. You use Linux to load the DSP firmware for 
each core and then take them out of reset. The same goes for the CortexM4 and 
PRUs. 

Regards,
John




> On Jun 25, 2017, at 7:02 PM, MDX  wrote:
> 
> And if not? Can i partition DSP cores using Linux?
> 
> -- 
> 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/b6397920-5775-499f-868a-d14690fa6202%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F1682267-E357-4827-96A8-71706083E617%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[John Syne]

If you use TI’s RTOS, then yes.

Regards,
John




> On Jun 25, 2017, at 7:33 AM, MDX  wrote:
> 
> I wonder how much sophisticated resource scheduling regarding C66x DSP cores 
> can be. For example, i estimated that code of my project's software would 
> need at least 2 cores' entire processing capacity (according to TI 
> documentation) to be able to work in hard real-time. But then i have so much 
> untapped processing power that can be used by third party plugins. Can i 
> partition workload on DSP's like in generic-purpose CPU? 
> 
> -- 
> 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/8e94a34b-f4b4-422a-920a-20cc6fa7a5a5%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F17C1FC4-97A6-456C-AB07-FE72BFFE3B87%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

One thing I forgot, you would use 

dpkg —add-architecture armhf

as Robert builds with Hardware Floating point. 

Regards,
John




> On Jun 23, 2017, at 1:47 PM, mzimmers  wrote:
> 
> Thanks for all the details, John. I'll look into that approach when I get 
> around to more serious kernel programming. Right now, I just want to figure 
> out why this example isn't working for me.
> 
> I need to download Robert's header files for the BBB to my host. If I just 
> add a file to sources.list.d, and run apt, will this work, or am I at risk of 
> overwriting my host's files?
> 
> -- 
> 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/83496bd4-9803-45cb-ba72-f9c011adbbaa%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/762AF873-DE00-46A2-A384-CCDFE081F933%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

I don’t do this, but I believe you can do this using Multiarch:

https://wiki.debian.org/Multiarch/HOWTO 


Now you can install the headers using dpkg -i 

I have copied Robert as he is the best person to answer your question. 

Regards,
John




> On Jun 23, 2017, at 1:47 PM, mzimmers  wrote:
> 
> Thanks for all the details, John. I'll look into that approach when I get 
> around to more serious kernel programming. Right now, I just want to figure 
> out why this example isn't working for me.
> 
> I need to download Robert's header files for the BBB to my host. If I just 
> add a file to sources.list.d, and run apt, will this work, or am I at risk of 
> overwriting my host's files?
> 
> -- 
> 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/83496bd4-9803-45cb-ba72-f9c011adbbaa%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/D816FA2C-6F07-43C3-A688-630C2BA7CAC0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

The way I work is to have the BBB mount rootfs over NFS which resides on my 
desktop. When I create a Kernel Module, I do the following:

1) I clone Robert’s kernel repo
2) I build the kernel
3) I add my kernel module code
4) I rebuild the kernel
5) I modify Robert’s deploy script to copy the kernel/kernel modules to my NFS 
share directory
6) I run modprobe 
7) If there is a problem; modprobe -r 
8) Modify my code an goto step 4
9) Once everything is working, I create a patch and add it to the patches 
folder and modify Robert’s build script.

By using Robert’s build scripts, you don’t have to worry about kernel headers, 
compiler versions, etc. It all just works. 

No need for any special tools, just use your favorite editor. I tend to use 
Eclipse as I can index the entire kernel source code so I can just  click 
on any function and it will switch to that function.  left arrow returns 
to your previous location. This link will show you how to make Eclipse work. 

https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source 


I hope this helps.

Regards,
John




> On Jun 23, 2017, at 12:23 PM, mzimmers  wrote:
> 
> Hi, John - thanks for the reply. I don't believe, however, that I'll need to 
> use JTAG, at least not for this specific example. 
> 
> Here's my current thinking: I already have a cross-development platform (Qt 
> Creator) set up for the BBB, so I'm going to try to use it to build kernel 
> modules. I know that at a minimum, I'll need the kernel header files, which I 
> can get from RCN's repository. I just have to figure out where to put them on 
> my host so I don't overwrite anything (my host isn't the same Debian version 
> as my BBB).
> 
> I welcome any feedback on this idea.
> 
> On Friday, June 23, 2017 at 1:02:33 PM UTC-6, john3909 wrote:
> You need a kernel aware JTAG debugger like Lauterbach. This will allow you to 
> debug u-boot, kernel code, including all the drivers as they are loaded, etc. 
> It is expensive, but it is the gold standard for kernel/driver debugging. 
> 
> TI have Code Composer Studio that will do some debugging of the kernel using 
> a blackhawk JTAG adapter, but CCSV7 has several limitations as they no longer 
> support kernel aware debugging (dropped after CCSV4). It is somewhat helpful 
> and a lot less expensive ($99) than Lauterbach.
> 
> I hope this helps. 
> 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/b08c6a13-5bd6-4693-a466-9b5596a8e117%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/FC8127CE-8BE9-419A-B126-6679043EAB72%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which "arch" subdirectory to use?

[John Syne]

You need a kernel aware JTAG debugger like Lauterbach. This will allow you to 
debug u-boot, kernel code, including all the drivers as they are loaded, etc. 
It is expensive, but it is the gold standard for kernel/driver debugging. 

TI have Code Composer Studio that will do some debugging of the kernel using a 
blackhawk JTAG adapter, but CCSV7 has several limitations as they no longer 
support kernel aware debugging (dropped after CCSV4). It is somewhat helpful 
and a lot less expensive ($99) than Lauterbach.

I hope this helps. 

Regards,
John




> On Jun 22, 2017, at 12:54 PM, mzimmers  wrote:
> 
> Hey, I'm open to any and all ideas. It seems so strange that I'm getting a 
> seg fault in the client code, though...that does make me suspicious of the 
> compiler version vs. the headers, etc.
> 
> How do people go about debugging kernel code, anyway? I gather that gdb isn't 
> much of an option. Do we just litter the code with printk statements like we 
> did when we were freshmen in college?
> 
> mz
> 
> On Thursday, June 22, 2017 at 1:01:20 PM UTC-6, William Hermans wrote:
> Yeah, ok, seemed like the obvious question to ask, but maybe too obvious ;)
> 
> -- 
> 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/f34faaa9-9be9-47a1-b5a7-9c502f47acb6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/603D3236-AC1E-4C73-9F49-C3608EE16541%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] am i doing this right?

[John Syne]

You need to pay attention to data acquisition circuits that use a input mux and 
a sample and hold circuit like that used by the BBB analog circuits. When the 
ADC samples the analog input, it charges a small capacitor (sample and hold) 
and then the ADC converts the voltage stored in the capacitor. When the 
capacitor is connected to the input circuit, it represents a short circuit and 
then the capacitor charges based on the time constand t = rc, where r is the 
source impedance. This is apparent if the channel before is fully 0 or full 
scale as the capacitor in the sample an hold could be 0 or 1v8 or somewhere in 
between and that can affect the accuracy of your measurements.

A better approach is to use an opamp circuit as a voltage divider as it will 
present as a low impedance to the sample and hold circuit and eliminate bleed 
through from adjacent circuits. 

Regards,
John




> On May 30, 2017, at 4:32 PM, Dennis Lee Bieber  wrote:
> 
> On Tue, 30 May 2017 10:50:55 -0700 (PDT), philip k
>  declaimed the following:
> 
>> i'm attempting a build.  
>> 
>> I will be using 5 pressure sensors.  here are the specs:
>> 
>> Pressure Range: 0-200 psi
>> Output: 0.5V – 4.5V linear voltage output. 0 psi outputs 0.5V, 100 psi 
>> outputs 2.5V, 200 psi outputs 4.5V
> 
>   I'm presuming this is the critical specification...
> 
>> Working Temperature: -40—+125ºC;.
>> Accuracy: ±1%FS;
>> Thread: 1/8"-27 NPT.
>> Overload Capacity: 2 times;
>> Pressure Medium: The gas and liquid which is compatible with 316L stainless 
>> steel;
> 
>   Don't think knowing what size pipe thread it uses means much here...
> 
>> Load Resistance: ?(supply power-6.5V/0.02A)?;
> 
>   This might be important...
> 
>> Wiring: Red for IN+.  Black for GND.  Green for OUT.
>> 
>> would i be correct by running a 600? resistor parallel to each sensor to 
>> bring the voltage down to ?1.8v and go from pin 7 or 8 to the five sensors, 
>> then run sensor1 signal and a 600ohm resistor in parallel to pins P9 35, 
>> sensor2 signal and a 600ohm resistor in parallel to P9 36, and so on?
>> 
> 
>   I doubt it.
> 
>   What you most likely need is a voltage divider system (use fixed width
> font):
> 
> 4.5V  --+
> |
> ~ ?1
> |
> + 1.8V ->
> |
> ~ ?2
> |
> GND   --+--->
> 
> where ~ is resistor, values to be determined (do a Google on how to
> determine a voltage divider -- I'm not going to do all the work )
> 
> {Unstudied: 4.5 / 1.8 = 2.5; say a 240Ohm for ?2, total needs to be 240*2.5
> => 600, so ?1 would be 600 - 240, or 360Ohm...}
> 
> -- 
>   Wulfraed Dennis Lee Bieber AF6VN
>wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
> 
> -- 
> 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/1cvric9sgrbie713a2ghckmep0unioeiq8%404ax.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6F98C44D-22F1-4E08-BC44-087F3DF48647%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Explanation of PRU Programming in C

[John Syne]

I have a Mac and the videos work just fine for me on the Chrome browser.

Regards,
John




> On Apr 20, 2017, at 4:44 AM, Joseph Heller  wrote:
> 
> Thanks for the positive feedback. The TI video does not work on Mac though. 
> 
> I've now also included the hello world blink LED in C. 
> 
> On 19 Apr 2017, at 19:38, Greg  > wrote:
> 
>> Excellent!  I did a couple of projects with PRU and C code, and this type of 
>> tutorial is sorely needed.
>> 
>> I would add a link to this:
>> 
>> https://training.ti.com/pru-compiler-tips-tricks 
>> 
>> 
>> So I wonder how common it is to use a C union and bit selector?
>> When I first encountered this in the PRU header files, I didn't even think 
>> it was C code!
>> In fact, in the information provided by TI in the video and slides, they say 
>> it is really warped C code.
>> 
>> Regards,
>> Greg
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> 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/3KjD7ULjD6M/unsubscribe 
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/830480A5-BD30-4277-882F-230B7BB8D387%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/DEDA0C09-BCE7-44EB-8CF0-9A8260BBF0FD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 16, 2017, at 1:55 PM, Rathin Dholakia <rathindhola...@gmail.com> wrote:
> 
> Yes, I can setup a oscillator circuit, in fact my GPS board provides me 10 
> MHz oscillator output which is extremely stable,  I can use that along with 
> PRU (thanks for the tip).
Just be aware that this 10MHz oscillator probably stops when you loose GPS 
lock. The purpose of a disciplined oscillator is that it acts like a flywheel 
and continues to run accurately even when the GPS signal is lost. When the GPS 
signal returns, the disciplined oscillator makes minor adjustments to sync up 
with the 1pps. GPS signal lost typically occurs during a bad storm. 
> 
> And yes, completely agree, I am reconsidering my ADC choice, that would ease 
> up my design many folds. 
> 
> And I am also trying out  TI's 4.4-rt- kernel for reducing my overall latency.
If the PRU is doing the time tagging, there is no need for rt kernel. 
> 
> I will document things here once I proceed a little, So others can also use 
> it in future :)
That will be great. 
> 
> I cant thank you enough, John! 
You are most welcome

Regards,
John
> 
> 
> On Mon, Apr 17, 2017 at 1:53 AM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> 
>> On Apr 16, 2017, at 6:20 AM, Rathin Dholakia <rathindhola...@gmail.com 
>> <mailto:rathindhola...@gmail.com>> wrote:
>> 
>> Dear John,
>> 
>> Ok, now I understood. So basically,  I have to create a dedicated crystal 
>> based oscillator for time reference. I though you were telling to use PRU 
>> for that, sorry my bad.
> Well, you can use the PRU as part of the PLL. Use the PRU to read the counter 
> when the 1pps signal occurs. If the count is less than 1,000, increase the 
> voltage from the DAC or decrease the DAC voltage if the count is higher than 
> 1,000. The DAC voltage is controlling the VXCO (Voltage Controlled Crystal 
> Oscillator). Typically the VXCO run at several MHz, you you need to divide 
> that down to generate a 1MHz clock. The counter is reset to zero after 
> reading the count. 
>> 
>> Though I'll have to figure out some way to convert my parallel digital 
>> outputs in to SPI compatible serial signals and also how to control ADC, 
>> FIFO and SPI all to gather. but that I will search! and will post here 
>> 
>> Once again thanks and will tell you if there is some query.
>> 
>> 
>> Apart from that Can you suggest some soultion to convert my parallel ADC 
>> output 
> Why not use a ADC with a SPI interface? If you really want to use a parallel 
> ADC, then GreenPAK has a nice solution. 
> 
> http://www.silego.com/products/402/312/AN-1083.html 
> <http://www.silego.com/products/402/312/AN-1083.html>
> 
> 
> Regards,
> John
>> 
>> On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
>> 
>>> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia <rathind...@gmail.com <>> 
>>> wrote:
>>> 
>>> Dear John,
>>> 
>>> Thanks a lot for such a detailed insight!
>>> 
>>> Yes I will need a precise time,and I was misinformed about the timer so I 
>>> was under impression that they are the clock source and hence driving 
>>> force. 
>>> 
>>> I will need some time to think and digest all but before I proceed let me 
>>> rephrase what I have understood, so that you can correct me:  
>>> 
>>> - Use  PRU0 as an timer (oscillator) for deriving SOC
>>> - Use PRU1 for DMA using SPI via FIFO, and also to time tag!?
>> Use ARM SPI driver for reading ADC samples via EDMA, but use PRU1 to monitor 
>> the EDMA completion and then using the value from the 1MHz counter, time tag 
>> the ADC buffer. You don’t have to tag each sample because you know the 
>> sampling rate. 
>>> - Remaining ARM processor for DFT and other thing
>>> 
>>> Did I get it correctly?
>>> 
>>> But then my question are:
>>> 1. I still need to detect EOC and assert READ signals then how will my FIFO 
>>> or DMA free my processor? 
>> Not necessary as the FIFO half full will cause an interrupt and initiate the 
>> DMA transfer. 
>>> 2. My PRU 1MHz, How can it be disciplined, it will still need an interrupt 
>>> to detect 1PPS right?
>> The 1pps is used with a PLL (phase lock loop) to tune the 1MHz crystal 
>> frequency so that the 1MHz is exactly 1MHz. In the case that the GPS is 
>> lost, the Oscillator continues to be accurate for several hours or more.  
>>> 3. And How can it replace Time data from GPS? 
>> Same answer as above.
>>> 
>>> Pard

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 16, 2017, at 6:20 AM, Rathin Dholakia <rathindhola...@gmail.com> wrote:
> 
> Dear John,
> 
> Ok, now I understood. So basically,  I have to create a dedicated crystal 
> based oscillator for time reference. I though you were telling to use PRU for 
> that, sorry my bad.
Well, you can use the PRU as part of the PLL. Use the PRU to read the counter 
when the 1pps signal occurs. If the count is less than 1,000, increase the 
voltage from the DAC or decrease the DAC voltage if the count is higher than 
1,000. The DAC voltage is controlling the VXCO (Voltage Controlled Crystal 
Oscillator). Typically the VXCO run at several MHz, you you need to divide that 
down to generate a 1MHz clock. The counter is reset to zero after reading the 
count. 
> 
> Though I'll have to figure out some way to convert my parallel digital 
> outputs in to SPI compatible serial signals and also how to control ADC, FIFO 
> and SPI all to gather. but that I will search! and will post here 
> 
> Once again thanks and will tell you if there is some query.
> 
> 
> Apart from that Can you suggest some soultion to convert my parallel ADC 
> output 
Why not use a ADC with a SPI interface? If you really want to use a parallel 
ADC, then GreenPAK has a nice solution. 

http://www.silego.com/products/402/312/AN-1083.html 
<http://www.silego.com/products/402/312/AN-1083.html>


Regards,
John
> 
> On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
> 
>> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia <rathind...@gmail.com 
>> > wrote:
>> 
>> Dear John,
>> 
>> Thanks a lot for such a detailed insight!
>> 
>> Yes I will need a precise time,and I was misinformed about the timer so I 
>> was under impression that they are the clock source and hence driving force. 
>> 
>> I will need some time to think and digest all but before I proceed let me 
>> rephrase what I have understood, so that you can correct me:  
>> 
>> - Use  PRU0 as an timer (oscillator) for deriving SOC
>> - Use PRU1 for DMA using SPI via FIFO, and also to time tag!?
> Use ARM SPI driver for reading ADC samples via EDMA, but use PRU1 to monitor 
> the EDMA completion and then using the value from the 1MHz counter, time tag 
> the ADC buffer. You don’t have to tag each sample because you know the 
> sampling rate. 
>> - Remaining ARM processor for DFT and other thing
>> 
>> Did I get it correctly?
>> 
>> But then my question are:
>> 1. I still need to detect EOC and assert READ signals then how will my FIFO 
>> or DMA free my processor? 
> Not necessary as the FIFO half full will cause an interrupt and initiate the 
> DMA transfer. 
>> 2. My PRU 1MHz, How can it be disciplined, it will still need an interrupt 
>> to detect 1PPS right?
> The 1pps is used with a PLL (phase lock loop) to tune the 1MHz crystal 
> frequency so that the 1MHz is exactly 1MHz. In the case that the GPS is lost, 
> the Oscillator continues to be accurate for several hours or more.  
>> 3. And How can it replace Time data from GPS? 
> Same answer as above.
>> 
>> Pardon me if above question sound novice! I have not worked on it before.
>> 
>> Maybe you are suggesting something like this:
>> 1. 
>> http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig
>>  
>> <http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig>
> This example is a good one to show you how to monitor the EDMA transfer 
> completion with the PRU. 
>> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
>> <https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI> 
>> 
>> 
> Regards,
> John
>> 
>> On Sat, Apr 15, 2017 at 8:13 PM, John Syne <john...@gmail.com > 
>> wrote:
>> 
>>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia <rathind...@gmail.com 
>>> > wrote:
>>> 
>>> Dear John,
>>> 
>>> Thanks for your suggestion. Yes I was thinking in same line but bit 
>>> differently. I am still a rookie in all this so have few queries in your 
>>> approach if you can clarify.
>>> 
>>> 1. Instead of PRU as oscillator, I was planning to use one of the 4 onboard 
>>> timers. Wont it be better? why didyou suggested PRU instead of Timer? some 
>>> benefit?
>> It depends on your absolute time accuracy requirements. If you are looking 
>> at 100mS accuracy, then by all means use the Timer with interrupts given the 
>> interrupt latency of Linux. If you want 1uS accuracy, then you need a 
>> disciplined oscillator which drives a 1MHz counter which ca

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia <rathindhola...@gmail.com> wrote:
> 
> Dear John,
> 
> Thanks a lot for such a detailed insight!
> 
> Yes I will need a precise time,and I was misinformed about the timer so I was 
> under impression that they are the clock source and hence driving force. 
> 
> I will need some time to think and digest all but before I proceed let me 
> rephrase what I have understood, so that you can correct me:  
> 
> - Use  PRU0 as an timer (oscillator) for deriving SOC
> - Use PRU1 for DMA using SPI via FIFO, and also to time tag!?
Use ARM SPI driver for reading ADC samples via EDMA, but use PRU1 to monitor 
the EDMA completion and then using the value from the 1MHz counter, time tag 
the ADC buffer. You don’t have to tag each sample because you know the sampling 
rate. 
> - Remaining ARM processor for DFT and other thing
> 
> Did I get it correctly?
> 
> But then my question are:
> 1. I still need to detect EOC and assert READ signals then how will my FIFO 
> or DMA free my processor? 
Not necessary as the FIFO half full will cause an interrupt and initiate the 
DMA transfer. 
> 2. My PRU 1MHz, How can it be disciplined, it will still need an interrupt to 
> detect 1PPS right?
The 1pps is used with a PLL (phase lock loop) to tune the 1MHz crystal 
frequency so that the 1MHz is exactly 1MHz. In the case that the GPS is lost, 
the Oscillator continues to be accurate for several hours or more.  
> 3. And How can it replace Time data from GPS? 
Same answer as above.
> 
> Pardon me if above question sound novice! I have not worked on it before.
> 
> Maybe you are suggesting something like this:
> 1. 
> http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig
>  
> <http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig>
This example is a good one to show you how to monitor the EDMA transfer 
completion with the PRU. 
> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
> <https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI> 
> 
> 
Regards,
John
> 
> On Sat, Apr 15, 2017 at 8:13 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> 
>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia <rathindhola...@gmail.com 
>> <mailto:rathindhola...@gmail.com>> wrote:
>> 
>> Dear John,
>> 
>> Thanks for your suggestion. Yes I was thinking in same line but bit 
>> differently. I am still a rookie in all this so have few queries in your 
>> approach if you can clarify.
>> 
>> 1. Instead of PRU as oscillator, I was planning to use one of the 4 onboard 
>> timers. Wont it be better? why didyou suggested PRU instead of Timer? some 
>> benefit?
> It depends on your absolute time accuracy requirements. If you are looking at 
> 100mS accuracy, then by all means use the Timer with interrupts given the 
> interrupt latency of Linux. If you want 1uS accuracy, then you need a 
> disciplined oscillator which drives a 1MHz counter which can be read by the 
> PRU so that you can time tag the ADC samples.  
>> 
>> 2. My ADC chip (AD7864) has an inbuilt ring output ring register with 
>> circles among the outputs of 4 channels every time I pull down "READ" pin. 
>> So, do I still need a FIFO?
> DMA has to arbitrate for bus access and isn’t efficient if you are only 
> reading one or just a few samples at a time. You want to read at least 32 
> samples at a time to make DMA viable; hence you want a FIFO of at least 64 
> samples with an interrupt that occurs when the FIFO is almost full. 
>> 
>> 3. Why SPI? wont 12 Digital parallel pin faster? and  BBB uses pin addresses 
>> then how is DMA different from normal GPIO access? 
> Because the SPI driver already supports DMA transfers. 
>> 
>> 4. For utilizing PRU, are you recommending ASM coding or normal C coding 
>> using some library? I ham bit reluctant because of the assembly coding 
>> involved because I am not that good at it, yet! 
> It doesn’t matter, both will work just fine.
> 
> 
>> 
>> Thanks a ton,
>> Rathin 
>> 
>> My approach in brief for people's feedback:
>> 1. Use Timer Interrupt using on-board timer periodically for generating SOC
>> 2. Detect EOC using interrupt from ADC, initiate read cycle (ISR) for all 4 
>> channels
> The processor overhead for 100ksps will mean the CPU will be running at close 
> to 60% just to service the interrupts. Not a good idea. Using DMA, CPU will 
> be less than 3%.
>> 3. second interrupt watching 1PPS from GPS, which would reset the Timer 
>> period (as disciplining sampling)
> First, the timer i

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia <rathindhola...@gmail.com> wrote:
> 
> Dear John,
> 
> Thanks for your suggestion. Yes I was thinking in same line but bit 
> differently. I am still a rookie in all this so have few queries in your 
> approach if you can clarify.
> 
> 1. Instead of PRU as oscillator, I was planning to use one of the 4 onboard 
> timers. Wont it be better? why didyou suggested PRU instead of Timer? some 
> benefit?
It depends on your absolute time accuracy requirements. If you are looking at 
100mS accuracy, then by all means use the Timer with interrupts given the 
interrupt latency of Linux. If you want 1uS accuracy, then you need a 
disciplined oscillator which drives a 1MHz counter which can be read by the PRU 
so that you can time tag the ADC samples.  
> 
> 2. My ADC chip (AD7864) has an inbuilt ring output ring register with circles 
> among the outputs of 4 channels every time I pull down "READ" pin. So, do I 
> still need a FIFO?
DMA has to arbitrate for bus access and isn’t efficient if you are only reading 
one or just a few samples at a time. You want to read at least 32 samples at a 
time to make DMA viable; hence you want a FIFO of at least 64 samples with an 
interrupt that occurs when the FIFO is almost full. 
> 
> 3. Why SPI? wont 12 Digital parallel pin faster? and  BBB uses pin addresses 
> then how is DMA different from normal GPIO access? 
Because the SPI driver already supports DMA transfers. 
> 
> 4. For utilizing PRU, are you recommending ASM coding or normal C coding 
> using some library? I ham bit reluctant because of the assembly coding 
> involved because I am not that good at it, yet! 
It doesn’t matter, both will work just fine.


> 
> Thanks a ton,
> Rathin 
> 
> My approach in brief for people's feedback:
> 1. Use Timer Interrupt using on-board timer periodically for generating SOC
> 2. Detect EOC using interrupt from ADC, initiate read cycle (ISR) for all 4 
> channels
The processor overhead for 100ksps will mean the CPU will be running at close 
to 60% just to service the interrupts. Not a good idea. Using DMA, CPU will be 
less than 3%.
> 3. second interrupt watching 1PPS from GPS, which would reset the Timer 
> period (as disciplining sampling)
First, the timer is derived from the CPU PLL which multiplies the CPU crystal 
oscillator. The frequency error can be 2 to 3%. Add to that the Interrupt 
Latency of Linux, and your timing error will be bad. Also remember that the 
timing error is accumulative so you will continue to see time drift. 
Temperature changes will affect the crystal frequency as well.
> 4. Use pipe for passing each buffer to DFT.
> 5. Use the timing info from UART to time-stamp the DFT output 
Timing needs to be done way before you communicate this info. UART have 
significant latency as well. 

Regards,
John
> 
>
> 
> On Sat, Apr 15, 2017 at 4:38 AM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I recommend that you look for a external ADC with a sample FIFO, then the 
> samples are measured at predefined intervals and you could read them with the 
> ARM processor and use the PRU for your timing requirements. I take it you 
> will need a disciplined oscillator sync’d to the GPS 1pps, which can be done 
> with the PRU. Using an ADC with SPI interface and FIFO means you could use 
> DMA to transfer the samples, freeing up the CPU for more important work. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia <rathindhola...@gmail.com 
>> <mailto:rathindhola...@gmail.com>> wrote:
>> 
>> Hello TJF,
>> 
>> Thanks for your suggestion, to clarify my side further, let me elaborate.
>> 
>> 
>> My requirement is 256 (samples per Cycle) * 50(cycles, power frequency) * 6 
>> (channels) = 76.8 k SPS
>> 
>> So I need overall 100k(rounded off) 100k sampling. 
>> 
>> And my input signal is between +- 10 Volts and I don't want to scale for 
>> resolution purposes. Apart from that I need dedicated ADC for each channels 
>> so I'll prefer separate ADC chip. 
>> Does this make sense? Or I am wrong?
>> 
>> Thanks
>> 
>> On Friday, April 14, 2017, TJF <jeli.freih...@gmail.com 
>> <mailto:jeli.freih...@gmail.com>> wrote:
>> Hi Rathin!
>> 
>> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
>> I am willing to interface, 12 bit 4 channel, Simultaneous Sampling 
>> High-Speed ADC (Analog AD7864 
>> <http://www.analog.com/media/en/technical-documentation/data-sheets/AD7864.pdf>)
>>  to BeagleBone Black, and operate it at 100k sampling rate. My present 
>> thoughts are to use 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

I recommend that you look for a external ADC with a sample FIFO, then the 
samples are measured at predefined intervals and you could read them with the 
ARM processor and use the PRU for your timing requirements. I take it you will 
need a disciplined oscillator sync’d to the GPS 1pps, which can be done with 
the PRU. Using an ADC with SPI interface and FIFO means you could use DMA to 
transfer the samples, freeing up the CPU for more important work. 

Regards,
John




> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia  
> wrote:
> 
> Hello TJF,
> 
> Thanks for your suggestion, to clarify my side further, let me elaborate.
> 
> 
> My requirement is 256 (samples per Cycle) * 50(cycles, power frequency) * 6 
> (channels) = 76.8 k SPS
> 
> So I need overall 100k(rounded off) 100k sampling. 
> 
> And my input signal is between +- 10 Volts and I don't want to scale for 
> resolution purposes. Apart from that I need dedicated ADC for each channels 
> so I'll prefer separate ADC chip. 
> Does this make sense? Or I am wrong?
> 
> Thanks
> 
> On Friday, April 14, 2017, TJF  > wrote:
> Hi Rathin!
> 
> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
> I am willing to interface, 12 bit 4 channel, Simultaneous Sampling High-Speed 
> ADC (Analog AD7864 
> )
>  to BeagleBone Black, and operate it at 100k sampling rate. My present 
> thoughts are to use header P8 Digital I/O pins to control the ADC as well as 
> to read the input data from the ADC (using interrupt(s) - EOC). I will also 
> do a DFT on the received data samples.
> 
> Your target isn't very clear. Do you mean 100 k overall sampling rate (2 x 25 
> k)? In this case you could use the internal ADC (up to 4 x 50 k sampling 
> rate, 0-1V8). Otherwise you'll need the external.
> 
> Anyway, it should be possible when you fetch the samples by one PRU, and use 
> the other for DFT. Slow tasks can run on the ARM under Linux.
> 
> Regards
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> 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/ZufgBytqkOI/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to  
> <>beagleboard+unsubscribe@ 
> googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/7f5699a8-b6ab-4e96-8fa2-18cc8343755e%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> Rathin A. Dholakia
> "Dont GO through life, GROW through life"
> 
> 
> -- 
> 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/CAJW6HtQV0Q0hEP9hy8%2BO%3DACnNU1pvjZOrLnt_xyoH-SDXLMNMQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3879F2CA-33BA-444A-A055-A8C9290C6E3C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using PRU to control PWM peripheral on kernel 4.1 - DTO problem?

[John Syne]

> On Apr 2, 2017, at 11:32 AM, Justin Pearson  wrote:
> 
> Hi Jelena, thanks for your message. See my inline responses:
> 
> On Sun, Apr 2, 2017 at 9:39 AM, Jelena Freiherr  > wrote:
> Am Sonntag, 2. April 2017 17:26:10 UTC+2 schrieb Justin Pearson:
> > On the 3.18 kernel, I was able to control the PWM with the PRU without 
> > needing the PRU to initialize the PWM. The trick was to load the PWM capes 
> > "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also 
> > loading Derek's cape to initialize the pruss.) Loading the capes causes 
> > some PWM kernel driver to initialize the PWM registers, I assume. Once 
> > that's done, the PRU just has to tweak a couple registers to change the 
> > duty cycle. Is this trick what you're referring to when you say "The kernel 
> > driver should also work"?
> >
> > Would this trick of pre-loading the capes also work in a 4.x kernel?
> >
> 
> Sorry, I don't know any of the overlays you mentioned. And, as I said, I
> never used any kernel driver for GPIO, QEP, CAP, PWM or ADC. Instead I
> use an all-in-one driver (which I named libpruio), that handles all that
> stuff easier, more flexible and faster than any kernel driver framework.
> In order to get PWM output, there're just a few registers to set (see
> file pruio_pwmss.p in the package), so no need for all that multi source
> overhead.
> 
> Thank you for mentioning libpruio. I don't know very much about how device 
> tree overlays interact with linux kernel drivers, so until I can find a good 
> description of that, I'm inclined to use a more wasteful (but 
> well-documented) method of configuring the I/O. Do you know of a good way to 
> learn the details of how a device tree overlay is used by the kernel to 
> configure the SoC registers? So far I haven't found much good documentation 
> besides Derek Molloy's book.
>  
> BTW: You're developing PRU code and you're using a real time kernel. May
> I ask why? Since the PRUSS are very efficient for real time tasks, I see
> no reason for using additionally a real time kernel.
> 
> My team is working on a time-synchronization platform that aims to 
> synchronize devices' clocks on a network. It's sort of like NTP, but allows 
> users to specify the resolution of the time synchronization that they 
> require. Here is a paper on it for more info:
> 
> https://users.ece.cmu.edu/~agr/resources/publications/RTSS16-timeline.pdf 
> 
> 
Hi Justin

Are you using a disciplined clock on the BBB?

Regards,
John

> We need the real-time Linux kernel for precise time synchronization, so 
> that's why we're using a real-time kernel. Additionally, we're using the PRU 
> to get precise I/O for some distributed control systems.
> 
> Best,
> Justin
> 
>  
> 
> Regards
> 
> PS:
> I just checked Derek's cape. From a first glance I found the line
> 
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> 
> is wrong. The order is important, most specific first. It must be
> 
> compatible = "ti,beaglebone-black", "ti,beaglebone";
> 
> And it does more than just enabling the PRUSS (you're loading
> unnecessary overhead). In the libpruio package there's the tool
> dts_custom, which you can use to easy create, compile and install
> minimal custom overlays (single source, no overhead).
> 
> 
> Am 02.04.2017 um 17:25 schrieb Justin Pearson:
> > Thank you TJF, I never would have known about that register if you hadn't
> > mentioned it. One more question (see below):
> >
> > On Sat, Apr 1, 2017 at 9:20 PM, TJF  > > wrote:
> >
> >> Am Samstag, 1. April 2017 22:18:30 UTC+2 schrieb Justin Pearson:
> >>>
> >>> Are you saying that the only way to get PWM in a 4.x kernel is by
> >>> modifying am33xx-clocks.dtsi?
> >>>
> >>
> >> No. The kernel driver should also work (untested). But in your case
> >> (controlling the PWM subsystem by PRU code) you have to modify that file.
> >> (Or you can develop a loadable kernel module that writes to the register.)
> >>
> >
> > On the 3.18 kernel, I was able to control the PWM with the PRU without
> > needing the PRU to initialize the PWM. The trick was to load the PWM capes
> > "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also
> > loading Derek's cape
> >  >  
> > >
> > to
> > initialize the pruss.) Loading the capes causes some PWM kernel driver to
> > initialize the PWM registers, I assume. Once that's done, the PRU just has
> > to tweak a couple registers to change the duty cycle. Is this trick what
> > you're referring to when you say "*The kernel driver should also work*"?
> >
> > Would this trick of pre-loading the capes 

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

[John Syne]

> On Mar 13, 2017, at 9:24 PM, ags  wrote:
> 
> @William Hermans like you I won't be able to dig into the gory details of 
> loading Linux. This is an interesting read (albeit high-level and prompting 
> more questions). I think I can say a few things without understanding all the 
> details:
> 
> It is correct (from detailed reading of the TI TRM) that 0x8000 is the 
> physical memory address of the L3 DDR.
> If Linux is leaving any physical memory unmapped, unused - that's a shame. 
> Wasted precious resource.
> The PRUSS UIO driver allocates memory and exposes the physical address in 
> userspace. If this is not used, it is also a precious wasted resource.
> 
> Now comes the subjective stuff:
> 
> I'm going to presume that Linux isn't stupid, and not count on it leaving 
> permanently-allocated and undocumented physical memory addresses available 
> for those that know the secret handshake.
> I will use the memory allocated by the PRUSS UIO driver to communicate 
> between userspace the PRUICSS.
> 
> If someone from TI/BeagleBoard.org responds with clarification on where I'm 
> incorrect, I'll adjust my position. As of now, for over two  years I've been 
> asking this same question and gotten no definitive response. Anyone know who 
> came up with the the am335x_pru_package examples?
Please understand, that TI has nothing to do with BeagleBoard.org 
. Also, there is no BeagleBoard.org 
 support staff. We are all users just like yourself 
and we volunteer our time to help others. If no one answers your questions, 
then perhaps your questions are not interesting or no one has the time to 
investigate answers that you need. To answer your questions, we would have to 
read the TRM and then do some experimentation to get the answer. Why should we 
do this work for you when you can do this for yourself. 

Learn how to use the tools and help yourself. For example, clone the 
am335x_pru_package repo and then do a “git blame ” and it will give you 
the e-mail of the person who wrote each line of code for . Pick up a 
good book on GIT as this is a very powerful tool. 

Regards,
John
> 
> Thanks for your input and replies. Much appreciated.
> 
> On Friday, March 10, 2017 at 7:30:25 PM UTC-8, William Hermans wrote:
> Here is another link that should explain it clear enough. 
> http://processors.wiki.ti.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address#Modifying_memory.h
>  
> 
> 
> So I would say that it is not by accident that the base address of 0x800 
> works. In fact, if you think about it a little bit. . Read the opening 
> paragraph labeled "purpose", and replace "DSP" with "PRU", for all intents 
> and purposes. of this discussion.
> 
> 
> On Fri, Mar 10, 2017 at 7:59 PM, William Hermans  > wrote:
> OK, according to some dicumentation I was able to find quickly, address 
> 0x800 is the base address for the start of the DDR memory on the TI EVM 
> board. Which is very similar to the beaglebone in memory layout.
> 
> On Fri, Mar 10, 2017 at 7:38 PM, William Hermans  > wrote:
> Thinking on it for a little longer, I almost want to say that the Address 
> 0x800h is actually the start of Linux's virtual memory map. But I'm not 
> 100% sure.
>  I'm doing my own research for a paying project, so can't really dive into 
> documentation for something else right now . . .
> 
> On Fri, Mar 10, 2017 at 7:24 PM, William Hermans  > wrote:
> 
> 
> On Fri, Mar 10, 2017 at 2:53 PM, ags  
> wrote:
> I've had a hard time getting any definitive responses to questions on the 
> subject of memory access & latency. It is true that the PRU cores have faster 
> access to DRAM that is part of the PRU-ICSS (through the 32-bit interconnect 
> SCR) - though not single-cycle - than to system DDR. However, the ARM core 
> accesses DDR through L3 fabric, but the PRU-ICSS through L4FAST, so I'm 
> thinking that it can access DDR faster than PRU-ICSS memory.
> 
> I've also asked about differences in latency/throughput/contention comparing 
> PRU-ICSS 12KB shared RAM v the 8KB data RAM. No response. Since both 8K data 
> RAM is accessible to both PRU cores, I'm not sure what the benefit of the 
> 12KB shared RAM is (thought I imagine there is, I just can't figure it out).
> 
> Lastly - and even more importantly - is total agreement that you have to be 
> careful about accessing any memory correctly. I have posted several times 
> asking about the am335x_pru_package examples (using UIO). In at least one 
> (https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c
>  
> 

Re: [beagleboard] Why is the SPI0 clock output configured as an input???

[John Syne]

> On Mar 8, 2017, at 5:42 AM, Jon Turner  wrote:
> 
> 
> The pin direction is only relevant for GPIO. For subsystems like SPI, the pin 
> direction is defined by the subsystem, not the pin direction defined by 
> pinctrl-single.
> 
> Regards,
> John
> 
> 
> Hmm, ok. So do the configuration bits have some other interpretation when the 
> pin is not configured
> as a gpio? If so, where is this documented? 
Look at Chapter 9 in the AM3358 Technical Reference Manual. The section on RX 
Active says:

"9.2.2.3 RX Active

The RXACTIVE bit is used to enable and disable the input buffer. This control 
can be used to help with power leakage or device isolation through the I/O. The 
characteristic of the signal is ultimately dictated by the mux mode the pad is 
put into.”

Regards,
John
> 
> Jon 
> 
> -- 
> 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/96bee223-50d9-4913-9194-f4b6a3648e05%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/75399730-65C8-4849-B452-766BBE630643%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Why is the SPI0 clock output configured as an input???

[John Syne]

The pin direction is only relevant for GPIO. For subsystems like SPI, the pin 
direction is defined by the subsystem, not the pin direction defined by 
pinctrl-single.

Regards,
John




> On Mar 7, 2017, at 2:40 PM, Jon Turner  wrote:
> 
> The overlay for the SPI0 interface includes the following lines
>  pinctrl-single,pins = <  
>   0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */  
>   0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */  
>   0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */  
>   0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */  
>  >;  
> 
> Notice the first line, which specifies that the spi0 clock signal is an input 
> with a pullup enabled.
> This does not make sense to me, since every diagram I have seen (for example 
> in Derek Molloy's
> book, Exploring Beaglebone) shows the clock signal as an output from the 
> BeagleBone. I have checked
> the BeagleBone schematic and the processor pin for this signal connects only 
> to the P9 header.
> So the only way it would make sense for this pin to be an input is if the 
> user is expected to have
> a clock generation circuit on the cape. It's hard for me to imagine that this 
> is the intended usage.
> 
> I have seen this same configuration for the overlay in multiple places, so I 
> am guessing it is
> correct, but I cannot understand why. Can someone knowledgable out there 
> please enlighten me?
> 
> Thanks,
> 
> Jon Turner
> 
> 
> -- 
> 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/55a9f2a1-abf0-4225-8b55-e2cdc27eeb47%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C40C55F7-06F8-4520-8287-86281FBA7632%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Why is the SPI0 clock output configured as an input???

[John Syne]

The pin direction is only relevant for GPIO. For subsystems like SPI, the pin 
direction is defined by the subsystem, not the pin direction. 

Regards,
John




> On Mar 7, 2017, at 2:40 PM, Jon Turner  wrote:
> 
> The overlay for the SPI0 interface includes the following lines
>  pinctrl-single,pins = <  
>   0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */  
>   0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */  
>   0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */  
>   0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */  
>  >;  
> 
> Notice the first line, which specifies that the spi0 clock signal is an input 
> with a pullup enabled.
> This does not make sense to me, since every diagram I have seen (for example 
> in Derek Molloy's
> book, Exploring Beaglebone) shows the clock signal as an output from the 
> BeagleBone. I have checked
> the BeagleBone schematic and the processor pin for this signal connects only 
> to the P9 header.
> So the only way it would make sense for this pin to be an input is if the 
> user is expected to have
> a clock generation circuit on the cape. It's hard for me to imagine that this 
> is the intended usage.
> 
> I have seen this same configuration for the overlay in multiple places, so I 
> am guessing it is
> correct, but I cannot understand why. Can someone knowledgable out there 
> please enlighten me?
> 
> Thanks,
> 
> Jon Turner
> 
> 
> -- 
> 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/55a9f2a1-abf0-4225-8b55-e2cdc27eeb47%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1703FD8B-5C9B-435C-884F-509D0D7DE4E3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

[John Syne]

Yeah, I think the OP was asking for BeagleBone Green.

Regards,
John




> On Mar 7, 2017, at 2:15 PM, Gerald Coley <ger...@beagleboard.org> wrote:
> 
> It has already been done, minus a couple of small changes. I suggest you 
> start with what has already been done and cleaned up. A basic ASCII 
> conversion has a lot of things that require clean up.
> 
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29
>  
> <http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29>
> 
> Gerald
> 
> 
> On Tue, Mar 7, 2017 at 4:11 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Hi James,
> 
> You have two options here. Ask Gerald to provide the ascii version of the PCB 
> or contact your local Allegro or Altium user group and ask someone to do the 
> conversion for you. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 7, 2017, at 1:23 PM, jam...@cladnetwork.com 
>> <mailto:jam...@cladnetwork.com> wrote:
>> 
>> Hi John,
>> 
>> Thank you for the advice on the conversion process. 
>> 
>> I created this post after attempting to convert the .brd file available on 
>> the official BeagleBoard wiki using Altium, Ltd's instructions on how to do 
>> so (see here 
>> <http://techdocs.altium.com/display/ADOH/Moving+to+Altium+Designer+from+Cadence+Allegro+PCB+Editor>,
>>  I am using AD16). Converting to ASCII (.alg) is not possible because I do 
>> not have Cadence Allegro (the Altium, Ltd-supplied batch file appears to use 
>> Allegro to open "file.brd", and then save it as "file.alg"). BeagleBoard 
>> does not seem to supply the design files in this format. I have yet to find 
>> the files in ASCII format at this point.
>> 
>> -James
>> 
>> On Tuesday, March 7, 2017 at 4:02:26 PM UTC-5, john3909 wrote:
>> Converting Orcad/Allegro files to Altium is pretty easy if you can get the 
>> Allegro files in ascii format. There are several issues you have to clean 
>> up, especially the copper pour areas which I advise to delete and just 
>> recreate these areas. Some of the components included some artifacts which 
>> need fixing. The universal database that links Schematic and PCB layout will 
>> have some inconsistencies and these need to be resolved. 
>> 
>> I converted the original BBB files which took me a few days to complete. My 
>> advise is generate Gerber files after the final conversion and compare those 
>> to the original Gerber files to ensure you haven’t made any mistakes in the 
>> conversion. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 7, 2017, at 11:13 AM, jam...@cladnetwork.com <> wrote:
>>> 
>>> Hi all,
>>> 
>>> I am the lead electrical engineer for a small company based in New York 
>>> State. We have been using both the Beaglebone Green and Beaglebone Black 
>>> internally for hardware development purposes for the past couple of months 
>>> for an upcoming product. We are early in the process of transitioning to a 
>>> production-grade single board hardware design for said product.
>>> 
>>> I am looking for CAD files for the Beaglebone Green to use as a starting 
>>> point in the board design process. Can anyone here point me towards for 
>>> provide me with Altium Designer files for the BeagleBone Green? We do not 
>>> use Cadence Allegro to design our boards, and have no way of converting the 
>>> available OrCAD/Allegro CAD files to an Altium Designer compatible format. 
>>> 
>>> I would much rather not have to redesign a complicated & nontrivial board 
>>> layout for an open-source hardware product such as this, especially given 
>>> that the open-source nature of BeagleBone was the most motivating factor in 
>>> choosing as a development and prototyping tool. 
>>> 
>>> Note that we are not modifying any part of the BeagleBone Green's design 
>>> (except removing the 2X23 female headers and grove sockets). We are using 
>>> it as a base and adding additional functionality via peripheral components 
>>> that are integrated on the same board. 
>>> 
>>> Thank you for any help that you can provide. 
>>> 
>>> I look forward to hearing back,
>>> James
>>> 
>>> *Disclaimer: I fully understand that these files would come as is, with no 
>>> warranty or guarantee of suitability or merchantability for any purpose.
>>> 
>>> **There is a separate thread for Be

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

[John Syne]

Hi James,

You have two options here. Ask Gerald to provide the ascii version of the PCB 
or contact your local Allegro or Altium user group and ask someone to do the 
conversion for you. 

Regards,
John




> On Mar 7, 2017, at 1:23 PM, jam...@cladnetwork.com wrote:
> 
> Hi John,
> 
> Thank you for the advice on the conversion process. 
> 
> I created this post after attempting to convert the .brd file available on 
> the official BeagleBoard wiki using Altium, Ltd's instructions on how to do 
> so (see here 
> ,
>  I am using AD16). Converting to ASCII (.alg) is not possible because I do 
> not have Cadence Allegro (the Altium, Ltd-supplied batch file appears to use 
> Allegro to open "file.brd", and then save it as "file.alg"). BeagleBoard does 
> not seem to supply the design files in this format. I have yet to find the 
> files in ASCII format at this point.
> 
> -James
> 
> On Tuesday, March 7, 2017 at 4:02:26 PM UTC-5, john3909 wrote:
> Converting Orcad/Allegro files to Altium is pretty easy if you can get the 
> Allegro files in ascii format. There are several issues you have to clean up, 
> especially the copper pour areas which I advise to delete and just recreate 
> these areas. Some of the components included some artifacts which need 
> fixing. The universal database that links Schematic and PCB layout will have 
> some inconsistencies and these need to be resolved. 
> 
> I converted the original BBB files which took me a few days to complete. My 
> advise is generate Gerber files after the final conversion and compare those 
> to the original Gerber files to ensure you haven’t made any mistakes in the 
> conversion. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 7, 2017, at 11:13 AM, jam...@cladnetwork.com  wrote:
>> 
>> Hi all,
>> 
>> I am the lead electrical engineer for a small company based in New York 
>> State. We have been using both the Beaglebone Green and Beaglebone Black 
>> internally for hardware development purposes for the past couple of months 
>> for an upcoming product. We are early in the process of transitioning to a 
>> production-grade single board hardware design for said product.
>> 
>> I am looking for CAD files for the Beaglebone Green to use as a starting 
>> point in the board design process. Can anyone here point me towards for 
>> provide me with Altium Designer files for the BeagleBone Green? We do not 
>> use Cadence Allegro to design our boards, and have no way of converting the 
>> available OrCAD/Allegro CAD files to an Altium Designer compatible format. 
>> 
>> I would much rather not have to redesign a complicated & nontrivial board 
>> layout for an open-source hardware product such as this, especially given 
>> that the open-source nature of BeagleBone was the most motivating factor in 
>> choosing as a development and prototyping tool. 
>> 
>> Note that we are not modifying any part of the BeagleBone Green's design 
>> (except removing the 2X23 female headers and grove sockets). We are using it 
>> as a base and adding additional functionality via peripheral components that 
>> are integrated on the same board. 
>> 
>> Thank you for any help that you can provide. 
>> 
>> I look forward to hearing back,
>> James
>> 
>> *Disclaimer: I fully understand that these files would come as is, with no 
>> warranty or guarantee of suitability or merchantability for any purpose.
>> 
>> **There is a separate thread for BeagleBone Black revC related responses.
>> 
>> 
>> -- 
>> 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/d586a995-398d-4de8-ad07-a2e9b880b393%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/0e33abca-bcb6-4827-8123-48e73b53e32b%40googlegroups.com
>  
> .
> For more 

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

[John Syne]

Converting Orcad/Allegro files to Altium is pretty easy if you can get the 
Allegro files in ascii format. There are several issues you have to clean up, 
especially the copper pour areas which I advise to delete and just recreate 
these areas. Some of the components included some artifacts which need fixing. 
The universal database that links Schematic and PCB layout will have some 
inconsistencies and these need to be resolved. 

I converted the original BBB files which took me a few days to complete. My 
advise is generate Gerber files after the final conversion and compare those to 
the original Gerber files to ensure you haven’t made any mistakes in the 
conversion. 

Regards,
John




> On Mar 7, 2017, at 11:13 AM, jam...@cladnetwork.com wrote:
> 
> Hi all,
> 
> I am the lead electrical engineer for a small company based in New York 
> State. We have been using both the Beaglebone Green and Beaglebone Black 
> internally for hardware development purposes for the past couple of months 
> for an upcoming product. We are early in the process of transitioning to a 
> production-grade single board hardware design for said product.
> 
> I am looking for CAD files for the Beaglebone Green to use as a starting 
> point in the board design process. Can anyone here point me towards for 
> provide me with Altium Designer files for the BeagleBone Green? We do not use 
> Cadence Allegro to design our boards, and have no way of converting the 
> available OrCAD/Allegro CAD files to an Altium Designer compatible format. 
> 
> I would much rather not have to redesign a complicated & nontrivial board 
> layout for an open-source hardware product such as this, especially given 
> that the open-source nature of BeagleBone was the most motivating factor in 
> choosing as a development and prototyping tool. 
> 
> Note that we are not modifying any part of the BeagleBone Green's design 
> (except removing the 2X23 female headers and grove sockets). We are using it 
> as a base and adding additional functionality via peripheral components that 
> are integrated on the same board. 
> 
> Thank you for any help that you can provide. 
> 
> I look forward to hearing back,
> James
> 
> *Disclaimer: I fully understand that these files would come as is, with no 
> warranty or guarantee of suitability or merchantability for any purpose.
> 
> **There is a separate thread for BeagleBone Black revC related responses.
> 
> 
> -- 
> 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/d586a995-398d-4de8-ad07-a2e9b880b393%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3FD8C9DA-768A-461A-98A7-C95F81F2A89C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Real time application development for BBB

[John Syne]

So that tells me you need to stream the temperature measurements, which is what 
the AM335x ADC IIO driver does. Currently the driver is sampling at 800 ksps, 
but you can modify the sampling rate in the ADC overlay.

Regards,
John




> On Mar 2, 2017, at 2:51 AM, avni gupta  wrote:
> 
> Yes, the temperature won't change in milliseconds. But continuous monitoring 
> is required for understanding the trend of failures. The temperatures at 
> busbar and cable joints needs to be monitored.
> 
> 
> On Friday, February 17, 2017 at 10:11:36 AM UTC+5:30, john3909 wrote:
> Again, switchgear is large and won’t change temperature in milliseconds, so I 
> don’t understand why you need real-time temperature monitoring. Are you 
> measuring the arc temperature before extinguishing?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Feb 15, 2017, at 7:40 PM, avni gupta  
>> wrote:
>> 
>> Hi John,
>> 
>> I have to develop a real time temperature monitoring system for switchgear, 
>> where temperature changes and needs to be monitored for complete operation 
>> of the switchgear.
>> 
>> 
>> 
>> 
>> On Wednesday, February 15, 2017 at 10:10:15 PM UTC+5:30, john3909 wrote:
>> Why real-time when temperature won’t change that quickly?
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 14, 2017, at 9:49 PM, avni gupta > wrote:
>>> 
>>> 
>>> I am masters student, doing my internship. I want to work on beaglebone 
>>> black (BBB) and develop a real time application such that the data 
>>> generated from number of sensor nodes comes to sink node, which is 
>>> connected to USB of BBB. How do i proceed? The sensor nodes are temperature 
>>> sensor and the sink is Texas Instrument's (TI) CC2531 USB dongle (works on 
>>> ZigBee Green Power). What OS, what application should i start working on. 
>>> Please help.
>>> 
>>> -- 
>>> 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/5b6d3cfd-cbaa-44da-8e5b-27cb759e7d27%40googlegroups.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 .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/11db1952-5ebe-45c1-969e-6953c5017162%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/543299fb-f850-4848-88b8-5ecfb98cf6aa%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7EB17B0C-3441-4523-A118-F8AAA88344C3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] why is pinmux-helper needed?

[John Syne]

You need to understand how the pins are configured when defined in the 
devicetree. It is the driver that does the pin configuration as defined in the 
devicetree. Without an associated driver, the pins defined in the devicetree 
won’t do anything. When using PRU, there is no driver, so the pins don’t get 
configured and hence that is why pinmux-helper is necessary.

Regards,
John




> On Feb 28, 2017, at 9:32 PM, ags  wrote:
> 
> If there is a better place for this post please move - after all, pinmux is 
> for more than GPIO, right?
> 
> I've been trying to figure out why pinmux-helper is needed. I've searched and 
> found initial RFC and followup in the early years (by Charles Steinkuehler) 
> and I understand the motivation (I think) as stated, but I don't understand 
> the basics behind the why.
> 
> Before pinmux-helper was provided, wasn't it possible to use sysfs to change 
> pinmux and gpio settings for all exported pins? Weren't all pins exported? 
> (If not, couldn't exporting them all have been an alternate solution?) And 
> couldn't loading a device tree fragment be used to change the current state? 
> If changes to pin state were to be made frequently, I can see how those 
> methods would be cumbersome; however, isn't pin state configuration something 
> that is done rather infrequently, as it implies that the BBB is being 
> repurposed and connected to different hardware (physically)?
> 
> This question extends to config-pin utility, as well as the cape-universal 
> (and associated) dtb files. Wasn't all this possible already?
> 
> Let me be clear that I'm not criticizing the work that has been done - rather 
> I'm trying to use the evolution of capes, cape manager, dtb, drivers etc as a 
> way of better understanding how the underlying drivers, device trees, and 
> sysfs controls work.
> 
> -- 
> 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/6ae54709-0f14-4a73-a01b-6efd024f4525%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/E6A2E452-2FE6-426F-8975-467FACE5415E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] usage of internal "realtime" and M4 cores

[John Syne]

> On Feb 27, 2017, at 9:52 PM, MDX  wrote:
> 
> yeah, so looks like i was almost right in my confusion.
> so, if i can prepare each instruction beforehand, can PRU`s be used for servo 
> control? or do i have to learn thumb to use M4/M3 for that?
Any of the 4 PRUs or the Cortex-M4 can be used for servo control. They are all 
more than fast enough for this purpose. 

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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/9a76e1d0-c899-42d1-b079-12d0e01bfbe1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8856C4BD-9F0B-4F29-A721-AA57A781747C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] usage of internal "realtime" and M4 cores

[John Syne]

> On Feb 27, 2017, at 1:42 PM, Juliusz Chroboczek  wrote:
> 
>> The Cortex-M4 processors are similar to the Cortex-M4 micro-controllers
>> available from Texas Instruments. They are mostly used for video
>> compression/decompression, but you can use them to run then as bear bone
> 
> Interesting.
> 
> What about interrupt handling?  I'd expect the Cortex-A15 to have
> outrageous interrupt latencies, can the M4s be used for fast interrupt
> handlers?
Nothing to do with the Cortex-A15, the interrupt latency occurs because Linux 
disables interrupts during critical sections. If you were running bear bones 
code on the Cortex-A15, you would have fast interrupts. Same with Cortex-M4, 
interrupts are fast as long as you handle interrupts quickly and re-enable 
them. Using TI-RTOS, you will also have fast interrupt handling. 
> 
> Is RAM coherent between the A15 and the M4?  What's the M4's bandwidth
> to the RAM?
You need to read Chapter 7 of the AM5728 Technical Reference Manual which shows 
that you can use IPU1 for general purpose application development, but IPU2 is 
dedicated to IVA which is for video encoders/decoders (Chapter 6). There is 
32KB of L1 cache memory which is fast. 

Regards,
John
> 
> -- Juliusz
> 
> -- 
> 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/87zih7nwdk.fsf%40trurl.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4EEEDAA4-866D-4D28-AF90-C0848C430AF0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] usage of internal "realtime" and M4 cores

[John Syne]

The realtime processing cores are PRU which don’t have a pipeline so each 
instruction executes in a single cycle. There are 4 PRUs on the AM5728, but 
they have limited memory so your application is quite small. The Cortex-M4 
processors are similar to the Cortex-M4 micro-controllers available from Texas 
Instruments. They are mostly used for video compression/decompression, but you 
can use them to run then as bear bone using Starterware or use a RTOS like 
TI-RTOS for real-time application. The Cortex-M4 support larger applications 
compared to the PRU. The Cortex-M4 do have a 3-stage pipeline, which means it 
take at least 3 cycles to execute an instruction. From what I recall, the 
Cortex-A15 is running at 1.5GHz, the DSP run at 750MHz, the Cortex-M4 is 
running at 213MHz and the PRU are running at 200MHz. 

To develop code on the Cortex-M4, use Code Composer Studio V7 which is 
available free from TI. Use a JTAG such as USB200 from Blackhawk. 

Regards,
John




> On Feb 27, 2017, at 9:34 AM, MDX  wrote:
> 
> so i am pretty amazed of how big a punch AM5728 packs: 2 fast CPU cores, 2 
> very versatile KeyStone cores (of which i`ll be a happy user very soon thanks 
> to you), 2 "realtime" (whichever they are) ,and 2 Cortex-M4 cores, that i 
> have no idea what purpose they might serve, that limited ISA won`t be helpful 
> to me, unless they can be used to drive some servos, but that is something 
> you don`t need M4`s specific FPU for.
> 
> Can somebody enlighten me in my slight confusion? What pupose do M4 cores 
> serve and what are those "realtime processing cores"?
> 
> -- 
> 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/8bd9d4eb-f7ae-42aa-a80b-e1f7c16016c3%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/436B0D3F-D24C-49E7-8EE1-F5B81E3961D0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.