Re: [beagleboard] TI PRU_ADC_onChip example

[Jeff Andich]

This thread doesn’t appear to appear on the revamped beagleboard forums..
correct me if I'm wrong..

Should it be added retroactively or should we create a thread on the new
forums with a link to this?

Thanks!


On Tue, May 11, 2021 at 7:01 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hello Walter and Cheng
>
> I spent 2 hours total doing following
>
> 1)Created Ubuntu 16.04 LTS  Dev Box using VBOX on Win 7
> 2) Created SDK linux SD card using image writer on Windows booted Linux on
> Beaglebone White
> 3) Rebuilt kernel sources created images of customized kernel and replaced
> these on SD card
>
> *I have a full development environ Now !*
>
> Next step add a kernel driver I wrote and understand how use the OCP
> shared RAM to get large amounts of data from PRU to linux
>
> ***
>
>  __   _ _
> |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_
> | |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
> |__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|
>   |___||___|
>
> Arago Project http://arago-project.org am335x-evm ttyS0
>
> Arago 2019.11 am335x-evm ttyS0
>
> am335x-evm login: [  143.131162] NET: Registered protocol family 15
> [  143.545960] Initializing XFRM netlink socket
>
>  __   _ _
> |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_
> | |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
> |__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|
>   |___||___|
>
> Arago Project http://arago-project.org am335x-evm ttyS0
>
> Arago 2019.11 am335x-evm ttyS0
>
> am335x-evm login:
>
>
>
> On Tuesday, May 11, 2021, 02:39:31 PM CDT, 'Mark Lazarewicz' via
> BeagleBoard  wrote:
>
>
> HI Cheng
>
> I have two Beaglebone White and the am335x SK both have JTAG on the board
> so no soldering.
> The key is to follow the labs 1 to 3 only dont use any RPMsg examples
> The other key is the PRU gel script is crucial there is a typo error in
> the instructions about correct .gel file name and how to execute it
> I used CCS 6.0 win 7 and CCS 10 on windows 10
>
> Id be glad to help if I can
>
> The power of the CCS/JTAG is reading memory locations and finding crashes
> quickly its worth the learning curve
>
> Any issues please ask but tell me your CCS version
>
> What I dont like about the PRU  tutorials is all use Linux interaction as
> in interrupts and they assume SDK linux not Debian
>
> Its some work but you could use Windows to create a SDK linux SD card for
> JTAG if problems
>
>  I have several jtags  one is USBV2 and I have yours I also have two BBB
> but even being EE I dont solder
>
> Let me know be glad to help trust me after you master CCS/JTAG you will be
> very happy and have an awesome tool in your belt
>
> Mark
>
>
> On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen 
> wrote:
>
>
> Hi Mark,
>
> Thanks a lot for the updates. I went through the SDK documents and I
> actually got a lot inspiration. Thanks for that.
> I bought an TMDSEMU110-U for debugging. That is recommended from TI
> tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to
> the laptop. Is that how you debugged with JTAG ? I feel this approach is a
> little cumbersome since I need to set up a lot of environments manually.
> But it worked, so I just put up with it for now.
> I think both SDK and Beaglebone has a lot of interesting stuffs worth
> being explored. Appreciate your help!
>
> Regards,
> Cheng
> 在2021年5月8日星期六 UTC-4 下午7:52:41 写道：
>
> Hello Cheng
>
> I learned a few things this weekend I thought I would share
>
> The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows
> 10
>
> You can even debug both PRU0 and PRU1 at the same time examine memory and
> use HW  uart debug to speed up development
>
> The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers
> running on ARM side
>
> I have win 7 and Windows 10 CCS/JTAG installations working one  a
> Beaglebone White and the other AM335X SK
> BBB is also supported
>
> My Last step is building the SDK  linux kernel from scratch  with rproc
> kernel modules loaded  from a VirtualBox Ubuntu VM on Win 7
>
> The Linux  SDK has binaries for the ARM side *so a  Native Linux BOX is
> NOT REQUIRED(but recommended )*
>
> *CCS DOES NOT require linux to load and debug PRU *
>
> For those that want to learn ARM TI RTOS Win 10 is required to build
>
> The SDK documents I saved as the wiki is disappearing are awesome I found
> some very detailed PRU documentation that talks about everything from
> running TI PRU firmware On PRU ICCS for complex Industrial protocols as
> well a custom PRU code
>
> The facts about clock cycles also were discussed. All of it in can be
> found by following the documentation tar ball I sent I you.
>
> I think too many people panic dont want to run SDK L

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 Hello Walter and Cheng
I spent 2 hours total doing following
1)Created Ubuntu 16.04 LTS  Dev Box using VBOX on Win 72) Created SDK linux SD 
card using image writer on Windows booted Linux on Beaglebone White 3) Rebuilt 
kernel sources created images of customized kernel and replaced these on SD 
card 
I have a full development environ Now !
Next step add a kernel driver I wrote and understand how use the OCP  shared 
RAM to get large amounts of data from PRU to linux
***
 _                    _           _         _|  _  |___ ___ ___ ___   | 
 _  |___ ___  |_|___ ___| |_|     |  _| .'| . | . |  |   __|  _| . | | | -_|  
_|  _||__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|              |___| 
                   |___|
Arago Project http://arago-project.org am335x-evm ttyS0
Arago 2019.11 am335x-evm ttyS0
am335x-evm login: [  143.131162] NET: Registered protocol family 15[  
143.545960] Initializing XFRM netlink socket
 _                    _           _         _|  _  |___ ___ ___ ___   | 
 _  |___ ___  |_|___ ___| |_|     |  _| .'| . | . |  |   __|  _| . | | | -_|  
_|  _||__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|              |___| 
                   |___|
Arago Project http://arago-project.org am335x-evm ttyS0
Arago 2019.11 am335x-evm ttyS0
am335x-evm login:


On Tuesday, May 11, 2021, 02:39:31 PM CDT, 'Mark Lazarewicz' via 
BeagleBoard  wrote:  
 
  HI Cheng
I have two Beaglebone White and the am335x SK both have JTAG on the board so no 
soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg 
examples The other key is the PRU gel script is crucial there is a typo error 
in the instructions about correct .gel file name and how to execute it I used 
CCS 6.0 win 7 and CCS 10 on windows 10
Id be glad to help if I can 
The power of the CCS/JTAG is reading memory locations and finding crashes 
quickly its worth the learning curve
Any issues please ask but tell me your CCS version 
What I dont like about the PRU  tutorials is all use Linux interaction as in 
interrupts and they assume SDK linux not Debian
Its some work but you could use Windows to create a SDK linux SD card for JTAG 
if problems
 I have several jtags  one is USBV2 and I have yours I also have two BBB but 
even being EE I dont solder
Let me know be glad to help trust me after you master CCS/JTAG you will be very 
happy and have an awesome tool in your belt
Mark

On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen  
wrote:  
 
 Hi Mark, 
Thanks a lot for the updates. I went through the SDK documents and I actually 
got a lot inspiration. Thanks for that. 
I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials 
of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is 
that how you debugged with JTAG ? I feel this approach is a little cumbersome 
since I need to set up a lot of environments manually. But it worked, so I just 
put up with it for now. I think both SDK and Beaglebone has a lot of 
interesting stuffs worth being explored. Appreciate your help!
Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道：

 Hello Cheng
I learned a few things this weekend I thought I would share
The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 
You can even debug both PRU0 and PRU1 at the same time examine memory and use 
HW  uart debug to speed up development
The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers running 
on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one  a Beaglebone 
White and the other AM335X SK BBB is also supported 
My Last step is building the SDK  linux kernel from scratch  with rproc kernel 
modules loaded  from a VirtualBox Ubuntu VM on Win 7
The Linux  SDK has binaries for the ARM side so a  Native Linux BOX is NOT 
REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU 
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some 
very detailed PRU documentation that talks about everything from running TI PRU 
firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by 
following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont 
read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading 
to confusion 
The SDK has done an excellent job of documenting this unfortunately unless your 
actually using the SDK all of this is hidden and I guess they are taking down 
some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that 
don't care about details they just want a working kernel and a

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 HI Cheng
I have two Beaglebone White and the am335x SK both have JTAG on the board so no 
soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg 
examples The other key is the PRU gel script is crucial there is a typo error 
in the instructions about correct .gel file name and how to execute it I used 
CCS 6.0 win 7 and CCS 10 on windows 10
Id be glad to help if I can 
The power of the CCS/JTAG is reading memory locations and finding crashes 
quickly its worth the learning curve
Any issues please ask but tell me your CCS version 
What I dont like about the PRU  tutorials is all use Linux interaction as in 
interrupts and they assume SDK linux not Debian
Its some work but you could use Windows to create a SDK linux SD card for JTAG 
if problems
 I have several jtags  one is USBV2 and I have yours I also have two BBB but 
even being EE I dont solder
Let me know be glad to help trust me after you master CCS/JTAG you will be very 
happy and have an awesome tool in your belt
Mark

On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen  
wrote:  
 
 Hi Mark, 
Thanks a lot for the updates. I went through the SDK documents and I actually 
got a lot inspiration. Thanks for that. 
I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials 
of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is 
that how you debugged with JTAG ? I feel this approach is a little cumbersome 
since I need to set up a lot of environments manually. But it worked, so I just 
put up with it for now. I think both SDK and Beaglebone has a lot of 
interesting stuffs worth being explored. Appreciate your help!
Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道：

 Hello Cheng
I learned a few things this weekend I thought I would share
The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 
You can even debug both PRU0 and PRU1 at the same time examine memory and use 
HW  uart debug to speed up development
The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers running 
on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one  a Beaglebone 
White and the other AM335X SK BBB is also supported 
My Last step is building the SDK  linux kernel from scratch  with rproc kernel 
modules loaded  from a VirtualBox Ubuntu VM on Win 7
The Linux  SDK has binaries for the ARM side so a  Native Linux BOX is NOT 
REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU 
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some 
very detailed PRU documentation that talks about everything from running TI PRU 
firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by 
following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont 
read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading 
to confusion 
The SDK has done an excellent job of documenting this unfortunately unless your 
actually using the SDK all of this is hidden and I guess they are taking down 
some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that 
don't care about details they just want a working kernel and actually making 
one script to build linux makes sense as supporting keystroke errors and 
inability to read docs in a chronological orderly way would be a nightmare.
So in summary In my humble Opinion if your goal is writing Linux apps on a open 
source board the SDK probally is NOT for you.
If your goal is barebones, TI  RTOS , board bring up, custom hardware , DSP 
programming Cortex M4 programming , advanced PRU apps or learning or adding 
Linux Device drivers the SDK is a great asset.
Mark


On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen  
wrote:  
 
 Hi Walter, 

Sorry for the late reply. 
The most important part I modified for TI's makefile is to make sure that the 
firmware is loaded into remoteproc1. I basically replaced the loading procedure 
in the shell script with Molly's version which I attached below. I also added 
the entire include file and modified some of the constants and variable names 
in the c code because compiler reports errors of unrecognized header file and 
variables. But except those, it runs pretty well. 

start:
ifneq ($(PRU_DIR),)
 @echo write_init_pins.sh
 @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
 @echo "-    Starting PRU $(PRUN)"
 @echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
 ti-mct-heap-check -c
 sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe 
/sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print 
$$1') \
 --filter ./$(TA

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Mark, 

Thanks a lot for the updates. I went through the SDK documents and I 
actually got a lot inspiration. Thanks for that. 
I bought an TMDSEMU110-U for debugging. That is recommended from TI 
tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to 
the laptop. Is that how you debugged with JTAG ? I feel this approach is a 
little cumbersome since I need to set up a lot of environments manually. 
But it worked, so I just put up with it for now. 
I think both SDK and Beaglebone has a lot of interesting stuffs worth being 
explored. Appreciate your help!

Regards,
Cheng
在2021年5月8日星期六 UTC-4 下午7:52:41 写道：

> Hello Cheng
>
> I learned a few things this weekend I thought I would share
>
> The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 
> 10 
>
> You can even debug both PRU0 and PRU1 at the same time examine memory and 
> use HW  uart debug to speed up development
>
> The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers 
> running on ARM side
>
> I have win 7 and Windows 10 CCS/JTAG installations working one  a 
> Beaglebone White and the other AM335X SK 
> BBB is also supported 
>
> My Last step is building the SDK  linux kernel from scratch  with rproc 
> kernel modules loaded  from a VirtualBox Ubuntu VM on Win 7
>
> The Linux  SDK has binaries for the ARM side *so a  Native Linux BOX is 
> NOT REQUIRED(but recommended )*
>
> *CCS DOES NOT require linux to load and debug PRU *
>
> For those that want to learn ARM TI RTOS Win 10 is required to build
>
> The SDK documents I saved as the wiki is disappearing are awesome I found 
> some very detailed PRU documentation that talks about everything from 
> running TI PRU firmware On PRU ICCS for complex Industrial protocols as 
> well a custom PRU code
>
> The facts about clock cycles also were discussed. All of it in can be 
> found by following the documentation tar ball I sent I you.
>
> I think too many people panic dont want to run SDK Linux or use CCS /JTAG 
> dont read through all the documents as they dont want to go that route.
>
> Thats fine but the basic fundamentals of the whole SOC are then missed 
> leading to confusion 
>
> The SDK has done an excellent job of documenting this unfortunately unless 
> your actually using the SDK all of this is hidden and I guess they are 
> taking down some wikis so kind of sad this data will be lost.
>
> The approach in this group is wonderful especially for Linux App types 
> that don't care about details
>  they just want a working kernel and actually making one script to build 
> linux makes sense as supporting keystroke errors and inability to read docs 
> in a chronological orderly way would be a nightmare.
>
> So in summary In my humble Opinion if your goal is writing Linux apps on a 
> open source board the SDK probally is NOT for you.
>
> If your goal is barebones, TI  RTOS , board bring up, custom hardware , 
> DSP programming Cortex M4 programming , advanced PRU apps or learning or 
> adding Linux Device drivers the SDK is a great asset.
>
> Mark
>
>
>
> On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hi Walter, 
>
> Sorry for the late reply. 
> The most important part I modified for TI's makefile is to make sure that 
> the firmware is loaded into remoteproc1. I basically replaced the loading 
> procedure in the shell script with Molly's version which I attached below. 
> I also added the entire include file and modified some of the constants and 
> variable names in the c code because compiler reports errors of 
> unrecognized header file and variables. But except those, it runs pretty 
> well. 
>
> start:
> ifneq ($(PRU_DIR),)
> @echo write_init_pins.sh
> @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
> @echo "-Starting PRU $(PRUN)"
> @echo start > $(PRU_DIR)/state
> else ifeq ($(PROC),tidl)
> ti-mct-heap-check -c
> sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v 
> vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && 
> print $$1') \
> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w 
> /usr/share/mjpg-streamer/www"
> else
> ./$(TARGET)$(EXE)
> endif
>
>
> Regards,
> Cheng
>
>
> Walter Cromer  于2021年5月4日周二 下午4:02写道：
>
> I am glad to have helped a little bit.   Stick with it.  When it clicks 
> and you start really moving forward I think you'll be pleased.
>
> Can you share the changes to the Makefile that you made?  I'm curious if 
> it might help me.
>
> Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  
> I include the step id too and check that.  I am using switch-case to check 
> the step and put the analog input into the right variable in my code.   It 
> might be slighter faster with an if-elseif but I like the neatness of the 
> switch-case and until it causes me timing problems, I'm sticking with it.
>
> I am also fairly certain the ADC can be read faster.  I have the ADC in 
> one-shot mode and delay

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

Mark makes some excellent points.  I started developing C on the ARM side
under Linux before needing to start using PRUs.  I had not spent much time
in the TRM while working on the host side because I didn't need to.  It
really bit me until I did.  Once I really dug into the TRM and started to
understand the SOC at a hardware level, things began to progress much
better and faster.  And, going through the PRU Optimizing C/C++ Compiler
manual and PRU-ICSS/PRU_ICSSG Getting Started Guide on Linux helped too.
 What DID NOT HELP was that TI has not finished moving the wiki pages over
to a new resource but at least they made them available for download.

And, finally, this group of people have been awesome to help!



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, May 8, 2021 at 7:52 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hello Cheng
>
> I learned a few things this weekend I thought I would share
>
> The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows
> 10
>
> You can even debug both PRU0 and PRU1 at the same time examine memory and
> use HW  uart debug to speed up development
>
> The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers
> running on ARM side
>
> I have win 7 and Windows 10 CCS/JTAG installations working one  a
> Beaglebone White and the other AM335X SK
> BBB is also supported
>
> My Last step is building the SDK  linux kernel from scratch  with rproc
> kernel modules loaded  from a VirtualBox Ubuntu VM on Win 7
>
> The Linux  SDK has binaries for the ARM side *so a  Native Linux BOX is
> NOT REQUIRED(but recommended )*
>
> *CCS DOES NOT require linux to load and debug PRU *
>
> For those that want to learn ARM TI RTOS Win 10 is required to build
>
> The SDK documents I saved as the wiki is disappearing are awesome I found
> some very detailed PRU documentation that talks about everything from
> running TI PRU firmware On PRU ICCS for complex Industrial protocols as
> well a custom PRU code
>
> The facts about clock cycles also were discussed. All of it in can be
> found by following the documentation tar ball I sent I you.
>
> I think too many people panic dont want to run SDK Linux or use CCS /JTAG
> dont read through all the documents as they dont want to go that route.
>
> Thats fine but the basic fundamentals of the whole SOC are then missed
> leading to confusion
>
> The SDK has done an excellent job of documenting this unfortunately unless
> your actually using the SDK all of this is hidden and I guess they are
> taking down some wikis so kind of sad this data will be lost.
>
> The approach in this group is wonderful especially for Linux App types
> that don't care about details
>  they just want a working kernel and actually making one script to build
> linux makes sense as supporting keystroke errors and inability to read docs
> in a chronological orderly way would be a nightmare.
>
> So in summary In my humble Opinion if your goal is writing Linux apps on a
> open source board the SDK probally is NOT for you.
>
> If your goal is barebones, TI  RTOS , board bring up, custom hardware ,
> DSP programming Cortex M4 programming , advanced PRU apps or learning or
> adding Linux Device drivers the SDK is a great asset.
>
> Mark
>
>
>
> On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen 
> wrote:
>
>
> Hi Walter,
>
> Sorry for the late reply.
> The most important part I modified for TI's makefile is to make sure that
> the firmware is loaded into remoteproc1. I basically replaced the loading
> procedure in the shell script with Molly's version which I attached below.
> I also added the entire include file and modified some of the constants and
> variable names in the c code because compiler reports errors of
> unrecognized header file and variables. But except those, it runs pretty
> well.
>
> start:
> ifneq ($(PRU_DIR),)
> @echo write_init_pins.sh
> @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
> @echo "-Starting PRU $(PRUN)"
> @echo start > $(PRU_DIR)/state
> else ifeq ($(PROC),tidl)
> ti-mct-heap-check -c
> sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v
> vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ &&
> print $$1') \
> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w
> /usr/share/mjpg-streamer/www"
> else
> ./$(TARGET)$(EXE)
> endif
>
>
> Regards,
> Cheng
>
>
> Walter Cromer  于2021年5月4日周二 下午4:02写道：
>
> I am glad to have helped a little bit.   Stick with it.  When it clicks
> and you start really moving forward I think you'll be pleased.
>
> Can you share the changes to the Makefile that you made?  I'm curious if
> it might help me.
>
> Right now I am readin

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 Update AM335x SDK evaluation 

Sucess!! rebuild kernel sources in VBOX  next will test my LInux on ARM on a 
board with RPROC drivers  and lastly revist CCS and JTAG in Ubuntu VBOX as an 
option I prefer CCS on Windows but do recall CCS Linux is needed for Linux 
debugging

Final eval steps use CCS to measure PRU instruction timings following the Labs


 OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
mark@mark-VirtualBox:~/ti-processor-sdk-linux-am335x-evm-06.03.00.106/board-support/linux-4.19.94+gitAUTOINC+be5389fd85-gbe5389fd85$
 





On Sat May 08 2021 18:52:36 GMT-0500 (CDT), 'Mark Lazarewicz' via 
BeagleBoard  wrote:  
 
  Hello Cheng
I learned a few things this weekend I thought I would share
The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 
You can even debug both PRU0 and PRU1 at the same time examine memory and use 
HW  uart debug to speed up development
The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers running 
on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one  a Beaglebone 
White and the other AM335X SK BBB is also supported 
My Last step is building the SDK  linux kernel from scratch  with rproc kernel 
modules loaded  from a VirtualBox Ubuntu VM on Win 7
The Linux  SDK has binaries for the ARM side so a  Native Linux BOX is NOT 
REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU 
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some 
very detailed PRU documentation that talks about everything from running TI PRU 
firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by 
following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont 
read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading 
to confusion 
The SDK has done an excellent job of documenting this unfortunately unless your 
actually using the SDK all of this is hidden and I guess they are taking down 
some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that 
don't care about details they just want a working kernel and actually making 
one script to build linux makes sense as supporting keystroke errors and 
inability to read docs in a chronological orderly way would be a nightmare.
So in summary In my humble Opinion if your goal is writing Linux apps on a open 
source board the SDK probally is NOT for you.
If your goal is barebones, TI  RTOS , board bring up, custom hardware , DSP 
programming Cortex M4 programming , advanced PRU apps or learning or adding 
Linux Device drivers the SDK is a great asset.
Mark


On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen  
wrote:  
 
 Hi Walter, 

Sorry for the late reply. 
The most important part I modified for TI's makefile is to make sure that the 
firmware is loaded into remoteproc1. I basically replaced the loading procedure 
in the shell script with Molly's version which I attached below. I also added 
the entire include file and modified some of the constants and variable names 
in the c code because compiler reports errors of unrecognized header file and 
variables. But except those, it runs pretty well. 

start:
ifneq ($(PRU_DIR),)
 @echo write_init_pins.sh
 @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
 @echo "-    Starting PRU $(PRUN)"
 @echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
 ti-mct-heap-check -c
 sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe 
/sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print 
$$1') \
 --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w 
/usr/share/mjpg-streamer/www"
else
 ./$(TARGET)$(EXE)
endif

Regards,Cheng


Walter Cromer  于2021年5月4日周二 下午4:02写道：

I am glad to have helped a little bit.   Stick with it.  When it clicks and you 
start really moving forward I think you'll be pleased.
Can you share the changes to the Makefile that you made?  I'm curious if it 
might help me.
Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  I 
include the step id too and check that.  I am using switch-case to check the 
step and put the analog input into the right variable in my code.   It might be 
slighter faster with an if-elseif but I like the neatness of the switch-case 
and until it causes me timing problems, I'm sticking with it.
I am also fairly certain the ADC can be read faster.  I have the ADC in 
one-shot mode and delay before I kick it off again.   I've also run this with 
no averaging, 4 averages, and 16 averages and it makes very little difference 
in timing for me.
Walter

On Tuesday, May 4, 2021 at 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 Hello Cheng
I learned a few things this weekend I thought I would share
The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 
You can even debug both PRU0 and PRU1 at the same time examine memory and use 
HW  uart debug to speed up development
The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers running 
on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one  a Beaglebone 
White and the other AM335X SK BBB is also supported 
My Last step is building the SDK  linux kernel from scratch  with rproc kernel 
modules loaded  from a VirtualBox Ubuntu VM on Win 7
The Linux  SDK has binaries for the ARM side so a  Native Linux BOX is NOT 
REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU 
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some 
very detailed PRU documentation that talks about everything from running TI PRU 
firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by 
following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont 
read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading 
to confusion 
The SDK has done an excellent job of documenting this unfortunately unless your 
actually using the SDK all of this is hidden and I guess they are taking down 
some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that 
don't care about details they just want a working kernel and actually making 
one script to build linux makes sense as supporting keystroke errors and 
inability to read docs in a chronological orderly way would be a nightmare.
So in summary In my humble Opinion if your goal is writing Linux apps on a open 
source board the SDK probally is NOT for you.
If your goal is barebones, TI  RTOS , board bring up, custom hardware , DSP 
programming Cortex M4 programming , advanced PRU apps or learning or adding 
Linux Device drivers the SDK is a great asset.
Mark


On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen  
wrote:  
 
 Hi Walter, 

Sorry for the late reply. 
The most important part I modified for TI's makefile is to make sure that the 
firmware is loaded into remoteproc1. I basically replaced the loading procedure 
in the shell script with Molly's version which I attached below. I also added 
the entire include file and modified some of the constants and variable names 
in the c code because compiler reports errors of unrecognized header file and 
variables. But except those, it runs pretty well. 

start:
ifneq ($(PRU_DIR),)
 @echo write_init_pins.sh
 @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
 @echo "-    Starting PRU $(PRUN)"
 @echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
 ti-mct-heap-check -c
 sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe 
/sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print 
$$1') \
 --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w 
/usr/share/mjpg-streamer/www"
else
 ./$(TARGET)$(EXE)
endif

Regards,Cheng


Walter Cromer  于2021年5月4日周二 下午4:02写道：

I am glad to have helped a little bit.   Stick with it.  When it clicks and you 
start really moving forward I think you'll be pleased.
Can you share the changes to the Makefile that you made?  I'm curious if it 
might help me.
Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  I 
include the step id too and check that.  I am using switch-case to check the 
step and put the analog input into the right variable in my code.   It might be 
slighter faster with an if-elseif but I like the neatness of the switch-case 
and until it causes me timing problems, I'm sticking with it.
I am also fairly certain the ADC can be read faster.  I have the ADC in 
one-shot mode and delay before I kick it off again.   I've also run this with 
no averaging, 4 averages, and 16 averages and it makes very little difference 
in timing for me.
Walter

On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:

Hi Walter, 

Thank you so much for the reply. I think my setup is exactly the same as what 
you have (win10 and BBB wireless). That really motivated me to see somebody 
else successfully run the system with the same setup. 
I actually made some preliminary progress after two nights brooding and I am 
able to read out ADC data through rpmsg. Thanks a lot for your tips. 

I think the problem is still in the makefile and environment. As you mentioned, 
you are using makefile from PRUcookbook while I started off with TI's built-in 
makefile.  I believe there is a couple of slight difference between Debian 
system an

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Walter,

Sorry for the late reply.
The most important part I modified for TI's makefile is to make sure that
the firmware is loaded into remoteproc1. I basically replaced the loading
procedure in the shell script with Molly's version which I attached below.
I also added the entire include file and modified some of the constants and
variable names in the c code because compiler reports errors of
unrecognized header file and variables. But except those, it runs pretty
well.

start:
ifneq ($(PRU_DIR),)
@echo write_init_pins.sh
@$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
@echo "-Starting PRU $(PRUN)"
@echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
ti-mct-heap-check -c
sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v
vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ &&
print $$1') \
--filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w
/usr/share/mjpg-streamer/www"
else
./$(TARGET)$(EXE)
endif


Regards,
Cheng


Walter Cromer  于2021年5月4日周二 下午4:02写道：

> I am glad to have helped a little bit.   Stick with it.  When it clicks
> and you start really moving forward I think you'll be pleased.
>
> Can you share the changes to the Makefile that you made?  I'm curious if
> it might help me.
>
> Right now I am reading the ADC every 2.7ms.  I'm reading three channels.
> I include the step id too and check that.  I am using switch-case to check
> the step and put the analog input into the right variable in my code.   It
> might be slighter faster with an if-elseif but I like the neatness of the
> switch-case and until it causes me timing problems, I'm sticking with it.
>
> I am also fairly certain the ADC can be read faster.  I have the ADC in
> one-shot mode and delay before I kick it off again.   I've also run this
> with no averaging, 4 averages, and 16 averages and it makes very little
> difference in timing for me.
>
> Walter
>
> On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:
>
>> Hi Walter,
>>
>> Thank you so much for the reply. I think my setup is exactly the same as
>> what you have (win10 and BBB wireless). That really motivated me to see
>> somebody else successfully run the system with the same setup.
>> I actually made some preliminary progress after two nights brooding and I
>> am able to read out ADC data through rpmsg. Thanks a lot for your tips.
>>
>> I think the problem is still in the makefile and environment. As you
>> mentioned, you are using makefile from PRUcookbook while I started off with
>> TI's built-in makefile.  I believe there is a couple of slight difference
>> between Debian system and TI SDK environment which turns out to be critical
>> in compiling. I carefully compared the difference between two makefiles and
>> created one which is close to the makefile in the PRUcookbook. That works
>> like a charm.
>>
>> Next step I also want to explore precise timing and see how fast the adc
>> can run. May I ask what is the speed you are reading out from ADC?
>>
>> Regards,
>> Cheng
>>
>> 在2021年5月3日星期一 UTC-4 上午11:24:23 写道：
>>
>>> I just went through this pain and the people in this group were awesome
>>> help.
>>>
>>> I needed to read three analog inputs and it was a bear but once I got
>>> it, it has been going well.
>>>
>>> You don't mention the OS of your development platform or I may have
>>> missed it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire
>>> learning system for this expects a Linux development platform so it's not
>>> as useful as it could be if you are on Windows.  I didn't want to go to the
>>> trouble of even bringing up a virtual Linux on my Windows box for this.  I
>>> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's
>>> no easy way to transfer your compiled firmware to the BBB from within it
>>> according to TI.   So I just do everything on the Beagle and it meets my
>>> needs.
>>>
>>> I use the cloud9 IDE that ships with the BeagleBones for coding both the
>>> ARM and PRU code.  This environment compiles the ARM-side code and executes
>>> it just like any normal host (aka Linux, aka ARM) program just fine.
>>>  However, to compile the PRU code and load it I go over to a PUTTY session
>>> and use the make files from Mark Yoders' PRU Cookbook (
>>> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but
>>> my programs aren't huge or extremely complex (yet) and this works for me.
>>> I don't have and don't want to invest in a debug probe so debugging the PRU
>>> code can be a pain and slow.  The only option really is to use RPMsg almost
>>> like printf to send messages back at key points in the PRU code to let me
>>> know where it is executing and what's happening.  (Purists and more
>>> advanced developers are barfing and laughing at me right now I am sure.)
>>>
>>> I strongly encourage you to get the Technical Reference Manual for the
>>> TI ARM335x and specifically spend time with the Touchscreen Controller
>>

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Hi Jeff
Hope all is well good to here from you 

Yes saw that I think that's why someone told Walter there's no way to get code 
into PRU with CCS. It's obvious that the poster was using CCS fine to debug PRU 
code it's only the examples with RPMSg where JTAG is blocked. This to me means  
the ARM has a Lock on some shared resources. I've also seen comments take the 
Linux SD card out🤔 when using CCS JTAG. 
The PRU resources are so limited I'm thinking any PRU  application would need 
to remove RPMSG after the application is working. it's really a glorified 
printf debugger .
In the event you see PRU freezes or crashes JTAG is invaluable and you could 
remove the Rpmsg from the code while debugging.

Back to your  DSP comments Jeff. 
On OMAP4 the key to debugging the DSP with CCS was a gel file that basically 
holds ARM off from interfering. If you look at the link I provided and re-read 
the user provides his gel script in theory if your PRU or DSP code needed no 
muxing done  by the  ARM you debug your DSP or PRU code with CCS and JTAG and 
you dummy up input Data from ARM but you hold the ARM in reset while you debug 
the PRU or DSP. We did that on a OMAP L 138 the DSP ran the Matlab control 
theory loop. DSP can access DDR and a big shared SRAM.
Once our ARM DSP IPC all worked you really can't debug one side it's like 
halting a wifi transmission in the middle the communication will fail right.
My point is you hold off the ARM with a gel script hold it in reset then load a 
gel script that initializes the DDR Ram and loads the code and starts the DSP. 
The problem these gel files are inhouse TI  tribal knowledge or seem to be lost 
between CCS version.
A good example is the Am335x SDK has those same example you were running on 57x 
with a PRU CCS JTAG tutorial. I went through that on a Beaglebone white and CCS 
6.0 the PRU_CAPE. Gel file was flakey I had no Cape. It was good enough to re 
learn CCS 6 on am335x on windows 7 but I quickly punted I'm running CCS 10 on 
windows 10 on the Beaglebone white which has JTAG built in. But get this they 
abandoned Starter ware they folded it into the SDK Linux PDK the .org page says 
starterware is supported it's not. It also says that you can use the Linux  SDK 
on any version of Linux so I think Cheng started installing it on the 
Beaglebone bone yikes.
This am335x PRU is very limited. We used one PRU for a UART for DSP and the 
other PRU was an LCD segment controller.
We also a TI 28xx quadrature encoder the DSP read over SPI. The clock on these 
DSP is way faster than a PRU. The DSP control loop ran ever 100 nS. 
This PRU at 200MHZ that's 50 instructions in assembler it couldn't work as hard 
as a DSP.
Walter has a fairly simple loop he had working on ARM side reading ADC but he 
was getting unacceptable delay so he's learning PRU.
I don't know my Beaglebone white really isn't supported anymore I've got a 
barebones ARM ADC running on it I'm unwilling to give up JTAG and CCS I do have 
several black's and the JTAG sockets but don't feel soldering ambitious.
 my Am335x SK EVM already runs SDK Linux has JTAG onboard and has more memory 
like the black. Looks like I was building uboot on a Linux Ubuntu laptop  I 
definitely remember building SDK  Linux kernel and running defconfig and 
finally learned how to add remove module's and features from the kernel that 
was in 2015. 

I guess it's better late than never my only concern is that pin muxing of that 
SDK kernel has to be outdated but I'll take the risk if I can build my Kernel's 
source's. You can't deliver a product if you can't rebuild source code right 
Jeff??? Still there.🤔
On  barebones ARM pinmuxin depending on what peripherals you need on your 
project that's why starterware is no longer supported it becomes ifdef 
nightmare but the c code is obvious.
 it's the cache, MMU code that's complex then fold in open source TCP/IP wow no 
way you going to get a barebones ARM project going in less a year's using 
console uart printfs. 

That FTDI UART/ JTAG onboard  the devboard the hardware guys were old school 
they definitely knew what someone doing low level development needed. That was 
the Beaglebone white and the $200 am335x SK 
The black ditched the JTAG onboard and doubled the RAM.
Unfortunately everyone using anything after the bone  black hasn't hair Left 🤣 
because they spend their Life waiting on printf from DSP on x15 and PRU. 
Win 10 CCS10 Black hawk x15 your blazing Jeff unfortunately I don't see anybody 
beyond you in this group seeing the value of CCS. 
Most of these guys on this group  are ARM Linux application guys they don't 
need CCS for that. And anybody else using the  X15 DSP will probably use RPMSg. 
I want to stay positive but I can't make a $$$ investment in any .org board 
again that doesn't have a working JTAG connector on it so if I want to do DSP I 
gotta go backwards to my OMAP L138 board.
For you I can check out all the .gel that came with  CSS 10 as well as what 
gels come i

Re: [beagleboard] TI PRU_ADC_onChip example

[Jeff Andich]

Very informative thread guys!

Interesting article in E2E on accessing shared memory and RPMsg..

This statement by Jason Reader

“…Also, if you are testing an RPMsg project you will need to use the
pruss_remoteproc Linux module to load the code and not CCS over JTAG. …”

could be a clue as to the issue I was having attempting to load the C66
with JTAG after remoteproc initially loaded the RPMsg example project.  The
stock example program was referred to in a post a couple of months ago  (
https://forum.beagleboard.org/t/status-running-ti-sdk-built-c66-dsp-example-exe-on-bb-x15-beagleboard-debian/27469
). If I allowed remoteproc to load the C66 example program, and downloaded
only the symbol file for DSP1/C66 via CCS/JTAG, I was able to set and reach
breakpoints.  However, if I disabled remoteproc’s loading of the exe and
attempted to load the entire C66 executable via JTAG, I got an error
message ( from memory, remoteproc ID not found).  I will reproduce and post
up the detail  in a separate post…




On Tue, May 4, 2021 at 5:20 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Cheng
>
> Yes difference between the two Linux is why the E2E wants to know which
> Linux you running.
>
> Walter
>
> Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user
> is using SDK Linux.
>
> Perhaps the code examples will help you solve your freeze up. It's
> possible ARM Linux is using that memory.
>
> Looks like the TI PRU expert is very helpful as long as your using the SDK.
>
>
> https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Tue, May 4, 2021 at 3:02 PM, Walter Cromer
>  wrote:
>
> I am glad to have helped a little bit.   Stick with it.  When it clicks
> and you start really moving forward I think you'll be pleased.
>
> Can you share the changes to the Makefile that you made?  I'm curious if
> it might help me.
>
> Right now I am reading the ADC every 2.7ms.  I'm reading three channels.
> I include the step id too and check that.  I am using switch-case to check
> the step and put the analog input into the right variable in my code.   It
> might be slighter faster with an if-elseif but I like the neatness of the
> switch-case and until it causes me timing problems, I'm sticking with it.
>
> I am also fairly certain the ADC can be read faster.  I have the ADC in
> one-shot mode and delay before I kick it off again.   I've also run this
> with no averaging, 4 averages, and 16 averages and it makes very little
> difference in timing for me.
>
> Walter
>
> On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:
>
> Hi Walter,
>
> Thank you so much for the reply. I think my setup is exactly the same as
> what you have (win10 and BBB wireless). That really motivated me to see
> somebody else successfully run the system with the same setup.
> I actually made some preliminary progress after two nights brooding and I
> am able to read out ADC data through rpmsg. Thanks a lot for your tips.
>
> I think the problem is still in the makefile and environment. As you
> mentioned, you are using makefile from PRUcookbook while I started off with
> TI's built-in makefile.  I believe there is a couple of slight difference
> between Debian system and TI SDK environment which turns out to be critical
> in compiling. I carefully compared the difference between two makefiles and
> created one which is close to the makefile in the PRUcookbook. That works
> like a charm.
>
> Next step I also want to explore precise timing and see how fast the adc
> can run. May I ask what is the speed you are reading out from ADC?
>
> Regards,
> Cheng
>
> 在2021年5月3日星期一 UTC-4 上午11:24:23 写道：
>
> I just went through this pain and the people in this group were awesome
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it,
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire
> learning system for this expects a Linux development platform so it's not
> as useful as it could be if you are on Windows.  I didn't want to go to the
> trouble of even bringing up a virtual Linux on my Windows box for this.  I
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's
> no easy way to transfer your compiled firmware to the BBB from within it
> according to TI.   So I just do everything on the Beagle and it meets my
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the
> ARM and PRU code.  This environment compiles the ARM-side code and executes
> it just like any normal host (aka Linux, aka ARM) program just fine.
>  However, to compile 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Cheng
Yes difference between the two Linux is why the E2E wants to know which Linux 
you running.
Walter
Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user is 
using SDK Linux.
Perhaps the code examples will help you solve your freeze up. It's possible ARM 
Linux is using that memory.
Looks like the TI PRU expert is very helpful as long as your using the SDK.
https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru

Sent from Yahoo Mail on Android 
 
  On Tue, May 4, 2021 at 3:02 PM, Walter Cromer 
wrote:   I am glad to have helped a little bit.   Stick with it.  When it 
clicks and you start really moving forward I think you'll be pleased.
Can you share the changes to the Makefile that you made?  I'm curious if it 
might help me.
Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  I 
include the step id too and check that.  I am using switch-case to check the 
step and put the analog input into the right variable in my code.   It might be 
slighter faster with an if-elseif but I like the neatness of the switch-case 
and until it causes me timing problems, I'm sticking with it.
I am also fairly certain the ADC can be read faster.  I have the ADC in 
one-shot mode and delay before I kick it off again.   I've also run this with 
no averaging, 4 averages, and 16 averages and it makes very little difference 
in timing for me.
Walter

On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:

Hi Walter, 

Thank you so much for the reply. I think my setup is exactly the same as what 
you have (win10 and BBB wireless). That really motivated me to see somebody 
else successfully run the system with the same setup. 
I actually made some preliminary progress after two nights brooding and I am 
able to read out ADC data through rpmsg. Thanks a lot for your tips. 

I think the problem is still in the makefile and environment. As you mentioned, 
you are using makefile from PRUcookbook while I started off with TI's built-in 
makefile.  I believe there is a couple of slight difference between Debian 
system and TI SDK environment which turns out to be critical in compiling. I 
carefully compared the difference between two makefiles and created one which 
is close to the makefile in the PRUcookbook. That works like a charm. 

Next step I also want to explore precise timing and see how fast the adc can 
run. May I ask what is the speed you are reading out from ADC? 

Regards,Cheng

在2021年5月3日星期一 UTC-4 上午11:24:23 写道：

I just went through this pain and the people in this group were awesome help.
I needed to read three analog inputs and it was a bear but once I got it, it 
has been going well.
You don't mention the OS of your development platform or I may have missed it.  
I'm on a Windows 10 box and using a BBB Wireless.  TI's entire learning system 
for this expects a Linux development platform so it's not as useful as it could 
be if you are on Windows.  I didn't want to go to the trouble of even bringing 
up a virtual Linux on my Windows box for this.  I did install Code Composer 
Studio (CCS) from TI, but gave up on it.  There's no easy way to transfer your 
compiled firmware to the BBB from within it according to TI.   So I just do 
everything on the Beagle and it meets my needs.
I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM 
and PRU code.  This environment compiles the ARM-side code and executes it just 
like any normal host (aka Linux, aka ARM) program just fine.   However, to 
compile the PRU code and load it I go over to a PUTTY session and use the make 
files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I don't 
have and don't want to invest in a debug probe so debugging the PRU code can be 
a pain and slow.  The only option really is to use RPMsg almost like printf to 
send messages back at key points in the PRU code to let me know where it is 
executing and what's happening.  (Purists and more advanced developers are 
barfing and laughing at me right now I am sure.)  
I strongly encourage you to get the Technical Reference Manual for the TI 
ARM335x and specifically spend time with the Touchscreen Controller chapter.  
If you need precise timing, you'll want to spend time in the Industrial 
Ethernet Peripheral chapter too.   These are powerful tools once you understand 
them.
Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it.  
One thing that really tripped me up was their implementation of the __far 
keyword.   GCC doesn't recognize that and I didn't understand what was going on 
at first.  
As Mark commented, some people encourage using remoteproc, some encourage using 
libpruio and some still use the uio. TI supports remoteproc and I expect them 
to be around so I went with remoteproc.  It may have its drawbacks but 

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I am glad to have helped a little bit.   Stick with it.  When it clicks and 
you start really moving forward I think you'll be pleased.

Can you share the changes to the Makefile that you made?  I'm curious if it 
might help me.

Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  I 
include the step id too and check that.  I am using switch-case to check 
the step and put the analog input into the right variable in my code.   It 
might be slighter faster with an if-elseif but I like the neatness of the 
switch-case and until it causes me timing problems, I'm sticking with it.

I am also fairly certain the ADC can be read faster.  I have the ADC in 
one-shot mode and delay before I kick it off again.   I've also run this 
with no averaging, 4 averages, and 16 averages and it makes very little 
difference in timing for me.

Walter

On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:

> Hi Walter, 
>
> Thank you so much for the reply. I think my setup is exactly the same as 
> what you have (win10 and BBB wireless). That really motivated me to see 
> somebody else successfully run the system with the same setup. 
> I actually made some preliminary progress after two nights brooding and I 
> am able to read out ADC data through rpmsg. Thanks a lot for your tips. 
>
> I think the problem is still in the makefile and environment. As you 
> mentioned, you are using makefile from PRUcookbook while I started off with 
> TI's built-in makefile.  I believe there is a couple of slight difference 
> between Debian system and TI SDK environment which turns out to be critical 
> in compiling. I carefully compared the difference between two makefiles and 
> created one which is close to the makefile in the PRUcookbook. That works 
> like a charm. 
>
> Next step I also want to explore precise timing and see how fast the adc 
> can run. May I ask what is the speed you are reading out from ADC? 
>
> Regards,
> Cheng
>
> 在2021年5月3日星期一 UTC-4 上午11:24:23 写道：
>
>> I just went through this pain and the people in this group were awesome 
>> help.
>>
>> I needed to read three analog inputs and it was a bear but once I got it, 
>> it has been going well.
>>
>> You don't mention the OS of your development platform or I may have 
>> missed it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
>> learning system for this expects a Linux development platform so it's not 
>> as useful as it could be if you are on Windows.  I didn't want to go to the 
>> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
>> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
>> no easy way to transfer your compiled firmware to the BBB from within it 
>> according to TI.   So I just do everything on the Beagle and it meets my 
>> needs.
>>
>> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
>> ARM and PRU code.  This environment compiles the ARM-side code and executes 
>> it just like any normal host (aka Linux, aka ARM) program just fine.  
>>  However, to compile the PRU code and load it I go over to a PUTTY session 
>> and use the make files from Mark Yoders' PRU Cookbook (
>> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but 
>> my programs aren't huge or extremely complex (yet) and this works for me.  
>> I don't have and don't want to invest in a debug probe so debugging the PRU 
>> code can be a pain and slow.  The only option really is to use RPMsg almost 
>> like printf to send messages back at key points in the PRU code to let me 
>> know where it is executing and what's happening.  (Purists and more 
>> advanced developers are barfing and laughing at me right now I am sure.)  
>>
>> I strongly encourage you to get the Technical Reference Manual for the TI 
>> ARM335x and specifically spend time with the Touchscreen Controller 
>> chapter.  If you need precise timing, you'll want to spend time in the 
>> Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
>> you understand them.
>>
>> Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
>> it.  One thing that really tripped me up was their implementation of the 
>> __far keyword.   GCC doesn't recognize that and I didn't understand what 
>> was going on at first.  
>>
>> As Mark commented, some people encourage using remoteproc, some encourage 
>> using libpruio and some still use the uio. TI supports remoteproc and I 
>> expect them to be around so I went with remoteproc.  It may have its 
>> drawbacks but it is working just fine for me.  I can't comment on the other 
>> two as I have not tried them.   Also, I've found the TI E2E forum's 
>> moderators to be patient with me as a neophyte.   But the Google group's 
>> members do have wider experience.
>>
>> FYI - watch out for how TI puts some register settings that cross nibble 
>> or byte boundaries.  It can really bite you!  Take a look at the 

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Mark, 

Thanks a lot for the detailed explanation regarding the SDK. I actually 
made the examples work in the end. Like you said, there is difference 
between SDK Linux and Debian Linux. My approach is similar to what Walter 
refers. My understanding now is examples from TI needs to be modified 
properly (mainly makefile) so that it can be applied to the Debian system 
without any problem. I haven't finished going through the reference you 
provided, but they have been tremendous help. 
Thanks again!

Regards,
Cheng


在2021年5月1日星期六 UTC-4 下午12:46:03 写道：

> << , but it requires a company email to do so. 
>
> Hello Cheng 
>
> I want to Help you  but it appears my message is lost in translation
>
> What it sounds like to me  is TI pays these engineers $$ to answer 
> questions and does not want to waste time and $$$ with users that dont 
> follow their well written instructions *which say use SDK Yocto Linux on 
> the ARM for this example.*
>
> For me I start with a working example with instructions and documentation 
> then modifyit
>
> If I undertsand correctly you have *never* had an example working
>
> If you like breaking examples and working on projects that ONLY works from 
> a unix script and hides all the details then this is the correct group to 
> to ask questions (-:
>
> I suggest you try the example *you found*  following the intructions 
> exactly.  if you cant or wont do that switch to DEbian/Cookbook
>
> But if you do the latter I suggest don't change things follow the 
> instructions
>
> What is interesting is a Linux C application program should work correctly 
> if it was coded generic especially when both Linux variants are for the 
> same chip. Trying to figure out what is different between Linux variants to 
> me is not productive its not my focus for you maybe it is.
>
> Perhaps the Linux in the SDK was configured differently which implies it 
> handle PRU slightly different Im not surprised by this.
>
> Perhaps you can find what's different that may be a valid approach that 
> works for you and maybe someone can help. I think Dennis gave you a good 
> clue.
>
> I will watch the thread hopefully I can be of help should you choose to 
> follow the path E2E and the SDK layed out for you
>
> Cheers
>
> On Friday, April 30, 2021, 07:52:09 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hey Mark, 
>
> Thanks for spending time for replying. I really appreciate it. 
> I totally agree with you that one should spend time investigating first. I 
> apologize if they are dumb questions, but I have stuck there for two weeks. 
> I am more a circuit guy and just started picking up Beaglebone as a hobby 
> and potential career expansion. 
>
> My first intention is to post in TI E2E support forums 
> , but it requires a company email to do so. If this 
> particular .org is not a good place for rookie questions, would you please 
> advise some place for suitable for discussion?
>
> Regarding to the documents, are you referring to processor SDK Linux 
> Software Developer's guide? If that is the one, I did follow its 
> instructions, but maybe I missed something. I will go over it again. If 
> that's not the one, which document are you referring to? I also went 
> through PRUcookbook and Exploring BeagleBone by Derek Molly. Not a lot are 
> mentioned regarding this topic. 
>
> The code is built-in in the Beaglebone Black, this is one of the reasons I 
> am confused why it cannot be compiled. One can also download freely from TI 
> github (
> https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/
> ). 
>
> Again thanks for the advice and suggestion. I am very glad that there is 
> such a nice place that I can call for help and I hope after some practice I 
> am also able to contribute here. 
>
> Regards,
> Cheng
>
> 在2021年4月30日星期五 UTC-4 下午5:09:01 写道：
>
> Hello 
>
> I know the code. It's all explained in the SDK documention. I also like 
> these examples.
> Your asking questions about an SDK that's supported by Texas Instruments. 
> You do understand this .org group you posted in may contain TI employees 
> but is NOT TI support it's Beagle board Debian.
>
>  I think if you read the documents you will understand the answers
>
>  I'm sure you could compile this with some work the sdk instructions talk 
> about This. 
>
> Hypothetical question ❓
> If the instructions told you a virtual box build was not supported and not 
> recommended would you use one anyway and then ask the person who told you 
> not too do this why it doesn't work.
>
> I'm struggling to be nice in this reply.
>
>  I remember asking questions as a young engineer that clearly showed I 
> made zero effort to research anything.
>
> Then one day I got some really critical replies about my skills.
>
> Do some reading then if stuck ask questions
>
> Or better yet follow what the sdk instructions suggest.
>
> If you found this code  on internet and don't have a TI account or are not 
>

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Walter, 

Thank you so much for the reply. I think my setup is exactly the same as 
what you have (win10 and BBB wireless). That really motivated me to see 
somebody else successfully run the system with the same setup. 
I actually made some preliminary progress after two nights brooding and I 
am able to read out ADC data through rpmsg. Thanks a lot for your tips. 

I think the problem is still in the makefile and environment. As you 
mentioned, you are using makefile from PRUcookbook while I started off with 
TI's built-in makefile.  I believe there is a couple of slight difference 
between Debian system and TI SDK environment which turns out to be critical 
in compiling. I carefully compared the difference between two makefiles and 
created one which is close to the makefile in the PRUcookbook. That works 
like a charm. 

Next step I also want to explore precise timing and see how fast the adc 
can run. May I ask what is the speed you are reading out from ADC? 

Regards,
Cheng

在2021年5月3日星期一 UTC-4 上午11:24:23 写道：

> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed 
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
> learning system for this expects a Linux development platform so it's not 
> as useful as it could be if you are on Windows.  I didn't want to go to the 
> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
> no easy way to transfer your compiled firmware to the BBB from within it 
> according to TI.   So I just do everything on the Beagle and it meets my 
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
> ARM and PRU code.  This environment compiles the ARM-side code and executes 
> it just like any normal host (aka Linux, aka ARM) program just fine.  
>  However, to compile the PRU code and load it I go over to a PUTTY session 
> and use the make files from Mark Yoders' PRU Cookbook (
> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
> programs aren't huge or extremely complex (yet) and this works for me.  I 
> don't have and don't want to invest in a debug probe so debugging the PRU 
> code can be a pain and slow.  The only option really is to use RPMsg almost 
> like printf to send messages back at key points in the PRU code to let me 
> know where it is executing and what's happening.  (Purists and more 
> advanced developers are barfing and laughing at me right now I am sure.)  
>
> I strongly encourage you to get the Technical Reference Manual for the TI 
> ARM335x and specifically spend time with the Touchscreen Controller 
> chapter.  If you need precise timing, you'll want to spend time in the 
> Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
> you understand them.
>
> Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
> it.  One thing that really tripped me up was their implementation of the 
> __far keyword.   GCC doesn't recognize that and I didn't understand what 
> was going on at first.  
>
> As Mark commented, some people encourage using remoteproc, some encourage 
> using libpruio and some still use the uio. TI supports remoteproc and I 
> expect them to be around so I went with remoteproc.  It may have its 
> drawbacks but it is working just fine for me.  I can't comment on the other 
> two as I have not tried them.   Also, I've found the TI E2E forum's 
> moderators to be patient with me as a neophyte.   But the Google group's 
> members do have wider experience.
>
> FYI - watch out for how TI puts some register settings that cross nibble 
> or byte boundaries.  It can really bite you!  Take a look at the 
> STEPCONFIGn registers implementation of averaging to see what I mean.
>
> I hope this helps!
>
> On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote:
>
>> <<> , but it requires a company email to do so. 
>>
>> Hello Cheng 
>>
>> I want to Help you  but it appears my message is lost in translation
>>
>> What it sounds like to me  is TI pays these engineers $$ to answer 
>> questions and does not want to waste time and $$$ with users that dont 
>> follow their well written instructions *which say use SDK Yocto Linux on 
>> the ARM for this example.*
>>
>> For me I start with a working example with instructions and documentation 
>> then modifyit
>>
>> If I undertsand correctly you have *never* had an example working
>>
>> If you like breaking examples and working on projects that ONLY works 
>> from a unix script and hides all the details then this is the correct group 
>> to to ask questions (-:
>>
>> I suggest you try the example *you found*  following the intructions 
>> exactly. 

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I haven't posted the question about this code to the E2E forum as I think 
it must have something to do with permissions.

I don't know if they support Cloud9 on E2E.  I haven't asked any questions 
specific to Cloud9.

And, I don't do any kernel development.  It's above me right now.  I'm 
grateful for all those who do work in this space!
But I write all my code directly on the BBB using cloud9.  I guess until 
recently I didn't look for any other way to do it. 

Walter

On Monday, May 3, 2021 at 8:29:03 PM UTC-4 lazarman wrote:

> Walter
>
> This below code you posted in another thread was what I was referring to. 
> Does the E2E forum support cloud 9 dev on BBB??? 
>
>
> I'm also curious how you actually build/modify your Linux kernel with no 
> Linux box.
>
> Walter Cromer
>  wrote:
> changed the code to this and get the same error.
>
> fd = open ("/dev/mem", O_RDONLY | O_SYNC);   // not sure O_SYNC is 
> necessary since this is a read-only open situation
>
> Servo tester!!!
> ERROR: could not open /dev/mem.
>
> make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1
> rm /tmp/cloud9-examples/pwm-test.o
>
>
>
>
> Show more
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 3:02 PM, Walter Cromer
>  wrote:
>
> I'm using Debian and Cloud9 running on the Beagle.  The Windows 10 box is 
> really just providing a browser 'terminal' to the Beagle.
>
> What compiler errors?  Do you mean __far?   I don't think I asked about 
> that on E2E.  I just realized my mistake and did some reading to understand 
> it.  It's not an issue anymore.
>
>
> On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote:
>
> Walter
>
> Yes I remember everything about your application including the Debian  ARM 
> Linux application delays nobody seemed to have answers on fixing.
>
> Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
> understand. What is E2E saying about your compiler errors your asking about 
> in this group???
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 2:35 PM, Walter Cromer
>  wrote:
>
> It was disappointing, to say the least that they said there wasn't an easy 
> way to transfer the firmware but I believe that's what they meant.   
>
> I had my application running on the ARM side just fine but we just 
> couldn't get the deterministic timing we require for our application.  
> That's why I went to the PRUs.We're getting awesome results on the 
> timing now and RPMsg is fast enough on the transfer to get us the data for 
> analysis that we need.  Right now my problem is that I need to put 10 to 15 
> samples in an array and do some basic slope and standard deviation 
> calculations on the values in the array but when I add that, I'm getting 
> that my program won't fit into memory.  I'm working now to learn how to 
> initialize all my variables in the shared memory space.  That's locking up 
> the BBB every time right now.   I'm following Molloy's book but it's not 
> getting me there so far. 
>
>
> On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:
>
> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
>  wrote:
>
> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your developme

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Walter
This below code you posted in another thread was what I was referring to. Does 
the E2E forum support cloud 9 dev on BBB??? 

I'm also curious how you actually build/modify your Linux kernel with no Linux 
box.
Walter Cromer wrote:changed the code to this and 
get the same error.
fd = open ("/dev/mem", O_RDONLY | O_SYNC);   // not sure O_SYNC is necessary 
since this is a read-only open situation

Servo tester!!!ERROR: could not open /dev/mem.
make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1rm 
/tmp/cloud9-examples/pwm-test.o



Show more

Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 3:02 PM, Walter Cromer 
wrote:   I'm using Debian and Cloud9 running on the Beagle.  The Windows 10 box 
is really just providing a browser 'terminal' to the Beagle.
What compiler errors?  Do you mean __far?   I don't think I asked about that on 
E2E.  I just realized my mistake and did some reading to understand it.  It's 
not an issue anymore.

On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote:

Walter
Yes I remember everything about your application including the Debian  ARM 
Linux application delays nobody seemed to have answers on fixing.

Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
understand. What is E2E saying about your compiler errors your asking about in 
this group???
Mark

Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 2:35 PM, Walter Cromer 
wrote:  

It was disappointing, to say the least that they said there wasn't an easy way 
to transfer the firmware but I believe that's what they meant.   
I had my application running on the ARM side just fine but we just couldn't get 
the deterministic timing we require for our application.  That's why I went to 
the PRUs.    We're getting awesome results on the timing now and RPMsg is fast 
enough on the transfer to get us the data for analysis that we need.  Right now 
my problem is that I need to put 10 to 15 samples in an array and do some basic 
slope and standard deviation calculations on the values in the array but when I 
add that, I'm getting that my program won't fit into memory.  I'm working now 
to learn how to initialize all my variables in the shared memory space.  That's 
locking up the BBB every time right now.   I'm following Molloy's book but it's 
not getting me there so far. 

On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:

#  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
There's no easy way to #transfer your compiled firmware to the BBB from #within 
it according to TI.   
Hi Walter

This doesn't look correct or sound like TI.JTAG loads code extremely fast 
especially on the ARM. If you're referring to PRU code I've also done that as 
well.
Your overall  approach is fine imo just slow and a work in progress and yes 
they are helpful in E2E .
CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
 unfortunately again in  my opinion a complex control loop would run on a DSP 
this PRU is too resource limited.
It's purpose is offloading 
Glad to see your making progress 
I don't know if you saw a comment I completed your project all on the ARM side 
barebones very quickly unfortunately I don't recommend this for a beginner. To 
attempt this  you really need a low level understanding of ARM so your current 
approach is probably your best choice








Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 10:24 AM, Walter Cromer 
wrote:  

I just went through this pain and the people in this group were awesome help.
I needed to read three analog inputs and it was a bear but once I got it, it 
has been going well.
You don't mention the OS of your development platform or I may have missed it.  
I'm on a Windows 10 box and using a BBB Wireless.  TI's entire learning system 
for this expects a Linux development platform so it's not as useful as it could 
be if you are on Windows.  I didn't want to go to the trouble of even bringing 
up a virtual Linux on my Windows box for this.  I did install Code Composer 
Studio (CCS) from TI, but gave up on it.  There's no easy way to transfer your 
compiled firmware to the BBB from within it according to TI.   So I just do 
everything on the Beagle and it meets my needs.
I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM 
and PRU code.  This environment compiles the ARM-side code and executes it just 
like any normal host (aka Linux, aka ARM) program just fine.   However, to 
compile the PRU code and load it I go over to a PUTTY session and use the make 
files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I don't 
have and don't want to invest in a debug probe so debugging the PRU code can be 
a pain and slow.  The only option really is to use RPMsg almost like printf to 
send messages back at key points in the PRU code to

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I'm using Debian and Cloud9 running on the Beagle.  The Windows 10 box is 
really just providing a browser 'terminal' to the Beagle.

What compiler errors?  Do you mean __far?   I don't think I asked about 
that on E2E.  I just realized my mistake and did some reading to understand 
it.  It's not an issue anymore.


On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote:

> Walter
>
> Yes I remember everything about your application including the Debian  ARM 
> Linux application delays nobody seemed to have answers on fixing.
>
> Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
> understand. What is E2E saying about your compiler errors your asking about 
> in this group???
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 2:35 PM, Walter Cromer
>  wrote:
>
> It was disappointing, to say the least that they said there wasn't an easy 
> way to transfer the firmware but I believe that's what they meant.   
>
> I had my application running on the ARM side just fine but we just 
> couldn't get the deterministic timing we require for our application.  
> That's why I went to the PRUs.We're getting awesome results on the 
> timing now and RPMsg is fast enough on the transfer to get us the data for 
> analysis that we need.  Right now my problem is that I need to put 10 to 15 
> samples in an array and do some basic slope and standard deviation 
> calculations on the values in the array but when I add that, I'm getting 
> that my program won't fit into memory.  I'm working now to learn how to 
> initialize all my variables in the shared memory space.  That's locking up 
> the BBB every time right now.   I'm following Molloy's book but it's not 
> getting me there so far. 
>
>
> On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:
>
> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
>  wrote:
>
> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed 
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
> learning system for this expects a Linux development platform so it's not 
> as useful as it could be if you are on Windows.  I didn't want to go to the 
> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
> no easy way to transfer your compiled firmware to the BBB from within it 
> according to TI.   So I just do everything on the Beagle and it meets my 
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
> ARM and PRU code.  This environment compiles the ARM-side code and executes 
> it just like any normal host (aka Linux, aka ARM) program just fine.  
>  However, to compile the PRU code and load it I go over to a PUTTY session 
> and use the make files from Mark Yoders' PRU Cookbook (
> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
> programs aren't huge or extremely complex (yet) and this works for me.  I 
> don't have and don't want to invest in a debug probe so debugging the PRU 
> code can be a pain and slow.  The only option really is to use RPMsg almost 
> like printf to send messages back at key points in the PRU code to let me 
> know where it is executing and what's happening.  (Purists and more 
> advanced developers are barfing and laughi

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Walter
Yes I remember everything about your application including the Debian  ARM 
Linux application delays nobody seemed to have answers on fixing.

Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
understand. What is E2E saying about your compiler errors your asking about in 
this group???
Mark

Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 2:35 PM, Walter Cromer 
wrote:   It was disappointing, to say the least that they said there wasn't an 
easy way to transfer the firmware but I believe that's what they meant.   
I had my application running on the ARM side just fine but we just couldn't get 
the deterministic timing we require for our application.  That's why I went to 
the PRUs.    We're getting awesome results on the timing now and RPMsg is fast 
enough on the transfer to get us the data for analysis that we need.  Right now 
my problem is that I need to put 10 to 15 samples in an array and do some basic 
slope and standard deviation calculations on the values in the array but when I 
add that, I'm getting that my program won't fit into memory.  I'm working now 
to learn how to initialize all my variables in the shared memory space.  That's 
locking up the BBB every time right now.   I'm following Molloy's book but it's 
not getting me there so far. 

On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:

#  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
There's no easy way to #transfer your compiled firmware to the BBB from #within 
it according to TI.   
Hi Walter

This doesn't look correct or sound like TI.JTAG loads code extremely fast 
especially on the ARM. If you're referring to PRU code I've also done that as 
well.
Your overall  approach is fine imo just slow and a work in progress and yes 
they are helpful in E2E .
CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
 unfortunately again in  my opinion a complex control loop would run on a DSP 
this PRU is too resource limited.
It's purpose is offloading 
Glad to see your making progress 
I don't know if you saw a comment I completed your project all on the ARM side 
barebones very quickly unfortunately I don't recommend this for a beginner. To 
attempt this  you really need a low level understanding of ARM so your current 
approach is probably your best choice








Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 10:24 AM, Walter Cromer 
wrote:  

I just went through this pain and the people in this group were awesome help.
I needed to read three analog inputs and it was a bear but once I got it, it 
has been going well.
You don't mention the OS of your development platform or I may have missed it.  
I'm on a Windows 10 box and using a BBB Wireless.  TI's entire learning system 
for this expects a Linux development platform so it's not as useful as it could 
be if you are on Windows.  I didn't want to go to the trouble of even bringing 
up a virtual Linux on my Windows box for this.  I did install Code Composer 
Studio (CCS) from TI, but gave up on it.  There's no easy way to transfer your 
compiled firmware to the BBB from within it according to TI.   So I just do 
everything on the Beagle and it meets my needs.
I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM 
and PRU code.  This environment compiles the ARM-side code and executes it just 
like any normal host (aka Linux, aka ARM) program just fine.   However, to 
compile the PRU code and load it I go over to a PUTTY session and use the make 
files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I don't 
have and don't want to invest in a debug probe so debugging the PRU code can be 
a pain and slow.  The only option really is to use RPMsg almost like printf to 
send messages back at key points in the PRU code to let me know where it is 
executing and what's happening.  (Purists and more advanced developers are 
barfing and laughing at me right now I am sure.)  
I strongly encourage you to get the Technical Reference Manual for the TI 
ARM335x and specifically spend time with the Touchscreen Controller chapter.  
If you need precise timing, you'll want to spend time in the Industrial 
Ethernet Peripheral chapter too.   These are powerful tools once you understand 
them.
Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it.  
One thing that really tripped me up was their implementation of the __far 
keyword.   GCC doesn't recognize that and I didn't understand what was going on 
at first.  
As Mark commented, some people encourage using remoteproc, some encourage using 
libpruio and some still use the uio. TI supports remoteproc and I expect them 
to be around so I went with remoteproc.  It may have its drawbacks but it is 
working just fine for me.  I can't comment on the other two as I have not tried 
the

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

It was disappointing, to say the least that they said there wasn't an easy 
way to transfer the firmware but I believe that's what they meant.   

I had my application running on the ARM side just fine but we just couldn't 
get the deterministic timing we require for our application.  That's why I 
went to the PRUs.We're getting awesome results on the timing now and 
RPMsg is fast enough on the transfer to get us the data for analysis that 
we need.  Right now my problem is that I need to put 10 to 15 samples in an 
array and do some basic slope and standard deviation calculations on the 
values in the array but when I add that, I'm getting that my program won't 
fit into memory.  I'm working now to learn how to initialize all my 
variables in the shared memory space.  That's locking up the BBB every time 
right now.   I'm following Molloy's book but it's not getting me there so 
far. 


On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:

> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
>  wrote:
>
> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed 
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
> learning system for this expects a Linux development platform so it's not 
> as useful as it could be if you are on Windows.  I didn't want to go to the 
> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
> no easy way to transfer your compiled firmware to the BBB from within it 
> according to TI.   So I just do everything on the Beagle and it meets my 
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
> ARM and PRU code.  This environment compiles the ARM-side code and executes 
> it just like any normal host (aka Linux, aka ARM) program just fine.  
>  However, to compile the PRU code and load it I go over to a PUTTY session 
> and use the make files from Mark Yoders' PRU Cookbook (
> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
> programs aren't huge or extremely complex (yet) and this works for me.  I 
> don't have and don't want to invest in a debug probe so debugging the PRU 
> code can be a pain and slow.  The only option really is to use RPMsg almost 
> like printf to send messages back at key points in the PRU code to let me 
> know where it is executing and what's happening.  (Purists and more 
> advanced developers are barfing and laughing at me right now I am sure.)  
>
> I strongly encourage you to get the Technical Reference Manual for the TI 
> ARM335x and specifically spend time with the Touchscreen Controller 
> chapter.  If you need precise timing, you'll want to spend time in the 
> Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
> you understand them.
>
> Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
> it.  One thing that really tripped me up was their implementation of the 
> __far keyword.   GCC doesn't recognize that and I didn't understand what 
> was going on at first.  
>
> As Mark commented, some people encourage using remoteproc, some encourage 
> using libpruio and some still use the uio. TI supports remoteproc and I 
> expect them to be around so I went with remoteproc.  It may have its 
> drawbacks but it is working just fine for me.  I can't comment on the other 
> two as I have not tried them.   Also, I've found the TI E2E forum's 
> moderators to be patient with me as 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

#  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
There's no easy way to #transfer your compiled firmware to the BBB from #within 
it according to TI.   
Hi Walter

This doesn't look correct or sound like TI.JTAG loads code extremely fast 
especially on the ARM. If you're referring to PRU code I've also done that as 
well.
Your overall  approach is fine imo just slow and a work in progress and yes 
they are helpful in E2E .
CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
 unfortunately again in  my opinion a complex control loop would run on a DSP 
this PRU is too resource limited.
It's purpose is offloading 
Glad to see your making progress 
I don't know if you saw a comment I completed your project all on the ARM side 
barebones very quickly unfortunately I don't recommend this for a beginner. To 
attempt this  you really need a low level understanding of ARM so your current 
approach is probably your best choice








Sent from Yahoo Mail on Android 
 
  On Mon, May 3, 2021 at 10:24 AM, Walter Cromer 
wrote:   I just went through this pain and the people in this group were 
awesome help.
I needed to read three analog inputs and it was a bear but once I got it, it 
has been going well.
You don't mention the OS of your development platform or I may have missed it.  
I'm on a Windows 10 box and using a BBB Wireless.  TI's entire learning system 
for this expects a Linux development platform so it's not as useful as it could 
be if you are on Windows.  I didn't want to go to the trouble of even bringing 
up a virtual Linux on my Windows box for this.  I did install Code Composer 
Studio (CCS) from TI, but gave up on it.  There's no easy way to transfer your 
compiled firmware to the BBB from within it according to TI.   So I just do 
everything on the Beagle and it meets my needs.
I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM 
and PRU code.  This environment compiles the ARM-side code and executes it just 
like any normal host (aka Linux, aka ARM) program just fine.   However, to 
compile the PRU code and load it I go over to a PUTTY session and use the make 
files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I don't 
have and don't want to invest in a debug probe so debugging the PRU code can be 
a pain and slow.  The only option really is to use RPMsg almost like printf to 
send messages back at key points in the PRU code to let me know where it is 
executing and what's happening.  (Purists and more advanced developers are 
barfing and laughing at me right now I am sure.)  
I strongly encourage you to get the Technical Reference Manual for the TI 
ARM335x and specifically spend time with the Touchscreen Controller chapter.  
If you need precise timing, you'll want to spend time in the Industrial 
Ethernet Peripheral chapter too.   These are powerful tools once you understand 
them.
Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it.  
One thing that really tripped me up was their implementation of the __far 
keyword.   GCC doesn't recognize that and I didn't understand what was going on 
at first.  
As Mark commented, some people encourage using remoteproc, some encourage using 
libpruio and some still use the uio. TI supports remoteproc and I expect them 
to be around so I went with remoteproc.  It may have its drawbacks but it is 
working just fine for me.  I can't comment on the other two as I have not tried 
them.   Also, I've found the TI E2E forum's moderators to be patient with me as 
a neophyte.   But the Google group's members do have wider experience.   FYI - 
watch out for how TI puts some register settings that cross nibble or byte 
boundaries.  It can really bite you!  Take a look at the STEPCONFIGn registers 
implementation of averaging to see what I mean.
I hope this helps!
On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote:

 << 
wrote:  
 
 Hey Mark, 
Thanks for spending time for replying. I really appreciate it. I totally agree 
with you that one should spend time investigating first. I apologize if they 
are dumb questions, but I have stuck there for two weeks. I am more a circuit 
guy and just started picking up Beaglebone as a hobby and potential career 
expansion. 
My first intention is to post in TI E2E support forums, but it requires a 
company email to do so. If this particular .org is not a good place for rookie 
questions, would you please advise some place for suitable for discussion?
Regarding to the documents, are you referring to processor SDK Linux Software 
Developer's guide? If that is the one, I did follow its instructions, but maybe 
I missed something. I will go over it again. If that's not the one, which 
document are you referring to? I also went through PRUcookbook and Exploring 
BeagleBone by Derek Molly. Not a lot ar

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I just went through this pain and the people in this group were awesome 
help.

I needed to read three analog inputs and it was a bear but once I got it, 
it has been going well.

You don't mention the OS of your development platform or I may have missed 
it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
learning system for this expects a Linux development platform so it's not 
as useful as it could be if you are on Windows.  I didn't want to go to the 
trouble of even bringing up a virtual Linux on my Windows box for this.  I 
did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
no easy way to transfer your compiled firmware to the BBB from within it 
according to TI.   So I just do everything on the Beagle and it meets my 
needs.

I use the cloud9 IDE that ships with the BeagleBones for coding both the 
ARM and PRU code.  This environment compiles the ARM-side code and executes 
it just like any normal host (aka Linux, aka ARM) program just fine.  
 However, to compile the PRU code and load it I go over to a PUTTY session 
and use the make files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I 
don't have and don't want to invest in a debug probe so debugging the PRU 
code can be a pain and slow.  The only option really is to use RPMsg almost 
like printf to send messages back at key points in the PRU code to let me 
know where it is executing and what's happening.  (Purists and more 
advanced developers are barfing and laughing at me right now I am sure.)  

I strongly encourage you to get the Technical Reference Manual for the TI 
ARM335x and specifically spend time with the Touchscreen Controller 
chapter.  If you need precise timing, you'll want to spend time in the 
Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
you understand them.

Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
it.  One thing that really tripped me up was their implementation of the 
__far keyword.   GCC doesn't recognize that and I didn't understand what 
was going on at first.  

As Mark commented, some people encourage using remoteproc, some encourage 
using libpruio and some still use the uio. TI supports remoteproc and I 
expect them to be around so I went with remoteproc.  It may have its 
drawbacks but it is working just fine for me.  I can't comment on the other 
two as I have not tried them.   Also, I've found the TI E2E forum's 
moderators to be patient with me as a neophyte.   But the Google group's 
members do have wider experience.
   
FYI - watch out for how TI puts some register settings that cross nibble or 
byte boundaries.  It can really bite you!  Take a look at the STEPCONFIGn 
registers implementation of averaging to see what I mean.

I hope this helps!

On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote:

> << , but it requires a company email to do so. 
>
> Hello Cheng 
>
> I want to Help you  but it appears my message is lost in translation
>
> What it sounds like to me  is TI pays these engineers $$ to answer 
> questions and does not want to waste time and $$$ with users that dont 
> follow their well written instructions *which say use SDK Yocto Linux on 
> the ARM for this example.*
>
> For me I start with a working example with instructions and documentation 
> then modifyit
>
> If I undertsand correctly you have *never* had an example working
>
> If you like breaking examples and working on projects that ONLY works from 
> a unix script and hides all the details then this is the correct group to 
> to ask questions (-:
>
> I suggest you try the example *you found*  following the intructions 
> exactly.  if you cant or wont do that switch to DEbian/Cookbook
>
> But if you do the latter I suggest don't change things follow the 
> instructions
>
> What is interesting is a Linux C application program should work correctly 
> if it was coded generic especially when both Linux variants are for the 
> same chip. Trying to figure out what is different between Linux variants to 
> me is not productive its not my focus for you maybe it is.
>
> Perhaps the Linux in the SDK was configured differently which implies it 
> handle PRU slightly different Im not surprised by this.
>
> Perhaps you can find what's different that may be a valid approach that 
> works for you and maybe someone can help. I think Dennis gave you a good 
> clue.
>
> I will watch the thread hopefully I can be of help should you choose to 
> follow the path E2E and the SDK layed out for you
>
> Cheers
>
> On Friday, April 30, 2021, 07:52:09 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hey Mark, 
>
> Thanks for spending time for replying. I really appreciate it. 
> I totally agree with you that one should spend time investigating first. I 
> apologize if they are dumb questions, but I have stu

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 << wrote:  
 
 Hey Mark, 
Thanks for spending time for replying. I really appreciate it. I totally agree 
with you that one should spend time investigating first. I apologize if they 
are dumb questions, but I have stuck there for two weeks. I am more a circuit 
guy and just started picking up Beaglebone as a hobby and potential career 
expansion. 
My first intention is to post in TI E2E support forums, but it requires a 
company email to do so. If this particular .org is not a good place for rookie 
questions, would you please advise some place for suitable for discussion?
Regarding to the documents, are you referring to processor SDK Linux Software 
Developer's guide? If that is the one, I did follow its instructions, but maybe 
I missed something. I will go over it again. If that's not the one, which 
document are you referring to? I also went through PRUcookbook and Exploring 
BeagleBone by Derek Molly. Not a lot are mentioned regarding this topic. 
The code is built-in in the Beaglebone Black, this is one of the reasons I am 
confused why it cannot be compiled. One can also download freely from TI github 
(https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/).
 
Again thanks for the advice and suggestion. I am very glad that there is such a 
nice place that I can call for help and I hope after some practice I am also 
able to contribute here. 
Regards,Cheng
在2021年4月30日星期五 UTC-4 下午5:09:01 写道：

Hello 
I know the code. It's all explained in the SDK documention. I also like these 
examples.Your asking questions about an SDK that's supported by Texas 
Instruments. You do understand this .org group you posted in may contain TI 
employees but is NOT TI support it's Beagle board Debian.
 I think if you read the documents you will understand the answers
 I'm sure you could compile this with some work the sdk instructions talk about 
This. 
Hypothetical question ❓If the instructions told you a virtual box build was not 
supported and not recommended would you use one anyway and then ask the person 
who told you not too do this why it doesn't work.
I'm struggling to be nice in this reply.
 I remember asking questions as a young engineer that clearly showed I made 
zero effort to research anything.
Then one day I got some really critical replies about my skills.
Do some reading then if stuck ask questions
Or better yet follow what the sdk instructions suggest.
If you found this code  on internet and don't have a TI account or are not 
eligible for ITAR restrictions to download the sdk  you have a big problem.
I see you have a Gmail account





Sent from Yahoo Mail on Android 
 


  On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen wrote:  

Hi all, 
I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip example and ran into a few questions. I wonder if you can help 
me with. 
The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru module 
and read out ADC value. I am using a Beaglebone Black wireless.Here is the 
basic procedures.
FILE STRUCTUREPRU_ADC  |  |--pru_adc_firmware.c firmware loaded into PRU0  |  
|--pru_adc_userspace       |--pru_adc_userspace.c userspace code that interacts 
with PRU0
BUILD FIRMWARE & USERSPACE CODE$ cd 
/examples/am335x/PRU_ADC_onChip/$ make clean$ 
make$ cd pru_adc_userspace/$ make clean$ make
My BBB wireless can compile pru code successfully because I installed PRU_CGT 
compiler. But it is unable to compile ARM code. I think that is because ARM_CCT 
cross-compiler toochain environment is missing, in another word, I need to 
install processor-sdk-am335x
My first questions is can I install processor-sdk-am335x  into Debian system I 
currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused 
about the relationship between this SDK and Debian system. Why is the tutorial 
asking me to compile pru_adc_userspace.c  in the Beaglebone. I thought it is 
supposed to be executed in a cross-compilation environment.
I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But when I 
tried to run the program, it shows the following error. 
Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to 
initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30
Attached is the excerpt where the problem happened. Could anyone help me with 
some hints of what is going on here? Much appreciated. 

struct shared_struct message;
 /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = 
"/dev/rpmsg_pru30";
 /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; 
ofp = fopen(outputFilename, "r");
 if (ofp == NULL) {
 printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to 
initialize PRU using sysfs interface.\n");
 FILE *sysfs_node; char firmware[] = 
"/sys/class/remoteproc/

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Mark, 

Thanks a lot for the response.
I think the idea in this processor SDK Linux tutorial 

 is 
to create Linux SD card from the Processor SDK Linux package, which 
somewhat echoes with your suggestion. 
I guess what confuses me is that in README.txt of the example, it just says 
"build firmware & userspace code" in the directory, which I assume both are 
done in BBB. Firmware is straightforward to build, because there is PRU 
code generation tools - compiler 
. I already used 
cross-compiler to build Userspace (ARM side) code. In the meantime, I just 
wonder if that can also be done in current BBB system. I will definitely 
study the document you suggest. Thanks!

In addition, the bigger problem is actually rpmsg_pru30 issue. That 
literally prevents me from running any rpmsg functions. As Dennis 
mentioned, this might be a device tree problem? I need to spend some time 
on this. 

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午9:06:24 写道：

> Cheng
>
> I'm actually using the SDK now so be careful about generic advise
> the instructions are for  Ubuntu not Debian
> 'Since I had questions myself right now  I realized this PRU code you have 
> just a small part of the SDK
> My point was you never read the SDK quick start
> Please do so here is the doc tarball
> '
> 12. Documentation Tarball — Processor SDK RTOS Documentation 
> 
>
> If you search the group on X15 and DSP Jeff Aused the SDK and ran the 
> binary on Debian(For the DSP with remore proc)
>
> So yes you can use Debian to load the PRU firmware you need a 
> corresponding ARM binary for that code. Jeff used the SDK to build that
>
> I dont know where you read to compile SDK examples on BBB its not 
> something I read
>
> So use Ubuntu box as instructions tell you too
>
> OR
>
> wait to see if Jeff Andlich can tell you if its feasable to attempt to 
> install the SDK on the board itself and compile the code  that doesn't 
> sound right to me
>
> OR
>
> create an account on E2E ask the people who designed the SDK especially if 
> your confused
>
> I can answer CCS JTAG barebone ARM questiion about SDK not interested in 
> Linux
>
> Please read the tarball in  the link
>
> Regard
> '
>
>
> On Friday, April 30, 2021, 03:09:09 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hi all, 
>
> I am practicing PRU skills through some TI examples. I am playing with 
> PRU_ADC_onChip 
>
> example
>  
> and ran into a few questions. I wonder if you can help me with. 
>
> The nice thing about this example is it has a README.txt with all the 
> procedures. The idea is to use rpmsg to communicate between arm and pru 
> module and read out ADC value. 
> I am using a Beaglebone Black wireless.
> Here is the basic procedures.
>
> FILE STRUCTURE
> PRU_ADC
>   |
>   |--pru_adc_firmware.c firmware loaded into PRU0
>   |
>   |--pru_adc_userspace
>|--pru_adc_userspace.c userspace code that interacts with PRU0
>
> BUILD FIRMWARE & USERSPACE CODE
> $ cd /examples/am335x/PRU_ADC_onChip/
> $ make clean
> $ make
> $ cd pru_adc_userspace/
> $ make clean
> $ make
>
> My BBB wireless can compile pru code successfully because I installed 
> PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
> because ARM_CCT cross-compiler toochain environment is missing, in another 
> word, I need to install processor-sdk-am335x
>
> My first questions is can I install processor-sdk-am335x  into Debian 
> system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
> confused about the relationship between this SDK and Debian system. Why is 
> the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
> I thought it is supposed to be executed in a cross-compilation environment.
>
> I ended up installing processor-sdk-am335x on my linux desktop and 
> compiled successfully. Then I copied the generated file back to BBB 
> wireless. But when I tried to run the program, it shows the following 
> error. 
>
> Reading voltage at ADC Channel: 5
> /dev/rpmsg_pru30 could not be opened.
> Trying to initialize PRU using sysfs interface.
> ERROR: Could not open /dev/rpmsg_pru30
>
> Attached is the excerpt where the problem happened. Could anyone help me 
> with some hints of what is going on here? Much appreciated. 
>
>
> struct shared_struct message;
>
> /* use character device /dev/rpmsg_pru30 */
> char outputFilename[] = "/dev/rpmsg_pru30";
>
> /* test that /dev/rpmsg_pru30 exists */
> FILE *ofp;
> uint16_t returnedVoltage;
> ofp = fopen(outputFilename, "r");
>
> if (ofp == NULL) {
>
> printf("/dev/rpmsg_pru30 could not be opened. \n");
> printf("Trying to initialize PRU usi

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 Cheng
I'm actually using the SDK now so be careful about generic advisethe 
instructions are for  Ubuntu not Debian'Since I had questions myself right now  
I realized this PRU code you have just a small part of the SDKMy point was you 
never read the SDK quick startPlease do so here is the doc tarball'12. 
Documentation Tarball — Processor SDK RTOS Documentation

If you search the group on X15 and DSP Jeff Aused the SDK and ran the binary on 
Debian(For the DSP with remore proc)
So yes you can use Debian to load the PRU firmware you need a corresponding ARM 
binary for that code. Jeff used the SDK to build that
I dont know where you read to compile SDK examples on BBB its not something I 
read
So use Ubuntu box as instructions tell you too
OR
wait to see if Jeff Andlich can tell you if its feasable to attempt to install 
the SDK on the board itself and compile the code  that doesn't sound right to me
OR
create an account on E2E ask the people who designed the SDK especially if your 
confused
I can answer CCS JTAG barebone ARM questiion about SDK not interested in Linux
Please read the tarball in  the link
Regard'

On Friday, April 30, 2021, 03:09:09 PM CDT, Cheng Chen 
 wrote:  
 
 Hi all, 
I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip example and ran into a few questions. I wonder if you can help 
me with. 
The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru module 
and read out ADC value. I am using a Beaglebone Black wireless.Here is the 
basic procedures.
FILE STRUCTUREPRU_ADC  |  |--pru_adc_firmware.c firmware loaded into PRU0  |  
|--pru_adc_userspace       |--pru_adc_userspace.c userspace code that interacts 
with PRU0
BUILD FIRMWARE & USERSPACE CODE$ cd 
/examples/am335x/PRU_ADC_onChip/$ make clean$ 
make$ cd pru_adc_userspace/$ make clean$ make
My BBB wireless can compile pru code successfully because I installed PRU_CGT 
compiler. But it is unable to compile ARM code. I think that is because ARM_CCT 
cross-compiler toochain environment is missing, in another word, I need to 
install processor-sdk-am335x
My first questions is can I install processor-sdk-am335x  into Debian system I 
currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused 
about the relationship between this SDK and Debian system. Why is the tutorial 
asking me to compile pru_adc_userspace.c  in the Beaglebone. I thought it is 
supposed to be executed in a cross-compilation environment.
I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But when I 
tried to run the program, it shows the following error. 
Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to 
initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30
Attached is the excerpt where the problem happened. Could anyone help me with 
some hints of what is going on here? Much appreciated. 

struct shared_struct message;
 /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = 
"/dev/rpmsg_pru30";
 /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; 
ofp = fopen(outputFilename, "r");
 if (ofp == NULL) {
 printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to 
initialize PRU using sysfs interface.\n");
 FILE *sysfs_node; char firmware[] = 
"/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = 
"PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == 
NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } 
fwrite(&firmwareName, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); 
fclose(sysfs_node);
 char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = 
"start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { 
printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(&start, 
sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node);
 /* give RPMSG time to initialize */ sleep(3);
 ofp = fopen(outputFilename, "r");
 if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); 
exit(EXIT_FAILURE); } }






-- 
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/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.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

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hey Mark, 

Thanks for spending time for replying. I really appreciate it. 
I totally agree with you that one should spend time investigating first. I 
apologize if they are dumb questions, but I have stuck there for two weeks. 
I am more a circuit guy and just started picking up Beaglebone as a hobby 
and potential career expansion. 

My first intention is to post in TI E2E support forums , 
but it requires a company email to do so. If this particular .org is not a 
good place for rookie questions, would you please advise some place for 
suitable for discussion?

Regarding to the documents, are you referring to processor SDK Linux 
Software Developer's guide? If that is the one, I did follow its 
instructions, but maybe I missed something. I will go over it again. If 
that's not the one, which document are you referring to? I also went 
through PRUcookbook and Exploring BeagleBone by Derek Molly. Not a lot are 
mentioned regarding this topic. 

The code is built-in in the Beaglebone Black, this is one of the reasons I 
am confused why it cannot be compiled. One can also download freely from TI 
github 
(https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/).
 

Again thanks for the advice and suggestion. I am very glad that there is 
such a nice place that I can call for help and I hope after some practice I 
am also able to contribute here. 

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午5:09:01 写道：

> Hello 
>
> I know the code. It's all explained in the SDK documention. I also like 
> these examples.
> Your asking questions about an SDK that's supported by Texas Instruments. 
> You do understand this .org group you posted in may contain TI employees 
> but is NOT TI support it's Beagle board Debian.
>
>  I think if you read the documents you will understand the answers
>
>  I'm sure you could compile this with some work the sdk instructions talk 
> about This. 
>
> Hypothetical question ❓
> If the instructions told you a virtual box build was not supported and not 
> recommended would you use one anyway and then ask the person who told you 
> not too do this why it doesn't work.
>
> I'm struggling to be nice in this reply.
>
>  I remember asking questions as a young engineer that clearly showed I 
> made zero effort to research anything.
>
> Then one day I got some really critical replies about my skills.
>
> Do some reading then if stuck ask questions
>
> Or better yet follow what the sdk instructions suggest.
>
> If you found this code  on internet and don't have a TI account or are not 
> eligible for ITAR restrictions to download the sdk  you have a big problem.
>
> I see you have a Gmail account
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen
>  wrote:
>
> Hi all, 
>
> I am practicing PRU skills through some TI examples. I am playing with 
> PRU_ADC_onChip 
>
> example
>  
> and ran into a few questions. I wonder if you can help me with. 
>
> The nice thing about this example is it has a README.txt with all the 
> procedures. The idea is to use rpmsg to communicate between arm and pru 
> module and read out ADC value. 
> I am using a Beaglebone Black wireless.
> Here is the basic procedures.
>
> FILE STRUCTURE
> PRU_ADC
>   |
>   |--pru_adc_firmware.c firmware loaded into PRU0
>   |
>   |--pru_adc_userspace
>|--pru_adc_userspace.c userspace code that interacts with PRU0
>
> BUILD FIRMWARE & USERSPACE CODE
> $ cd /examples/am335x/PRU_ADC_onChip/
> $ make clean
> $ make
> $ cd pru_adc_userspace/
> $ make clean
> $ make
>
> My BBB wireless can compile pru code successfully because I installed 
> PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
> because ARM_CCT cross-compiler toochain environment is missing, in another 
> word, I need to install processor-sdk-am335x
>
> My first questions is can I install processor-sdk-am335x  into Debian 
> system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
> confused about the relationship between this SDK and Debian system. Why is 
> the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
> I thought it is supposed to be executed in a cross-compilation environment.
>
> I ended up installing processor-sdk-am335x on my linux desktop and 
> compiled successfully. Then I copied the generated file back to BBB 
> wireless. But when I tried to run the program, it shows the following 
> error. 
>
> Reading voltage at ADC Channel: 5
> /dev/rpmsg_pru30 could not be opened.
> Trying to initialize PRU using sysfs interface.
> ERROR: Could not open /dev/rpmsg_pru30
>
> Attached is the excerpt where the problem ha

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Hello 
I know the code. It's all explained in the SDK documention. I also like these 
examples.Your asking questions about an SDK that's supported by Texas 
Instruments. You do understand this .org group you posted in may contain TI 
employees but is NOT TI support it's Beagle board Debian.
 I think if you read the documents you will understand the answers
 I'm sure you could compile this with some work the sdk instructions talk about 
This. 
Hypothetical question ❓If the instructions told you a virtual box build was not 
supported and not recommended would you use one anyway and then ask the person 
who told you not too do this why it doesn't work.
I'm struggling to be nice in this reply.
 I remember asking questions as a young engineer that clearly showed I made 
zero effort to research anything.
Then one day I got some really critical replies about my skills.
Do some reading then if stuck ask questions
Or better yet follow what the sdk instructions suggest.
If you found this code  on internet and don't have a TI account or are not 
eligible for ITAR restrictions to download the sdk  you have a big problem.
I see you have a Gmail account





Sent from Yahoo Mail on Android 
 
  On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen wrote:   Hi 
all, 
I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip example and ran into a few questions. I wonder if you can help 
me with. 
The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru module 
and read out ADC value. I am using a Beaglebone Black wireless.Here is the 
basic procedures.
FILE STRUCTUREPRU_ADC  |  |--pru_adc_firmware.c firmware loaded into PRU0  |  
|--pru_adc_userspace       |--pru_adc_userspace.c userspace code that interacts 
with PRU0
BUILD FIRMWARE & USERSPACE CODE$ cd 
/examples/am335x/PRU_ADC_onChip/$ make clean$ 
make$ cd pru_adc_userspace/$ make clean$ make
My BBB wireless can compile pru code successfully because I installed PRU_CGT 
compiler. But it is unable to compile ARM code. I think that is because ARM_CCT 
cross-compiler toochain environment is missing, in another word, I need to 
install processor-sdk-am335x
My first questions is can I install processor-sdk-am335x  into Debian system I 
currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused 
about the relationship between this SDK and Debian system. Why is the tutorial 
asking me to compile pru_adc_userspace.c  in the Beaglebone. I thought it is 
supposed to be executed in a cross-compilation environment.
I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But when I 
tried to run the program, it shows the following error. 
Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to 
initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30
Attached is the excerpt where the problem happened. Could anyone help me with 
some hints of what is going on here? Much appreciated. 

struct shared_struct message;
 /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = 
"/dev/rpmsg_pru30";
 /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; 
ofp = fopen(outputFilename, "r");
 if (ofp == NULL) {
 printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to 
initialize PRU using sysfs interface.\n");
 FILE *sysfs_node; char firmware[] = 
"/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = 
"PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == 
NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } 
fwrite(&firmwareName, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); 
fclose(sysfs_node);
 char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = 
"start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { 
printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(&start, 
sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node);
 /* give RPMSG time to initialize */ sleep(3);
 ofp = fopen(outputFilename, "r");
 if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); 
exit(EXIT_FAILURE); } }






-- 
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/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.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 be