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 <[email protected]> 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 <[email protected]>
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<lazarman> 写道：
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 <[email protected]>
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 <[email protected]> 于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 [email protected] 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<[email protected]> 写道：
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:
<<<My first intention is to post in TI E2E support forums, 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 <[email protected]>
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<lazarman> 写道：
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<[email protected]> 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
<PATH_TO_PRU_SW_SUPPORT_PACKAGE>/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 [email protected].
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/39813de1-fa27-41d7-9422-7ef375ae36b4n%40googlegroups.com.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/W5jMCO3fu84/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/ca296f29-c476-45fc-906d-e24595453270n%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CAAOtuRfyiDxEL_N23_%2B1KFzH7EAt%2BapifqpkUCdGHn077Sc7Ww%40mail.gmail.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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/001a2631-6ba3-4687-a7e9-8ccc129fd8edn%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/415823638.1704058.1620761960753%40mail.yahoo.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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/41569860.1752102.1620774038633%40mail.yahoo.com.
