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 <chen...@gmail.com> > 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 <wal...@edenconceptsllc.com> 于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<wal...@edenconceptsllc.com> 写道： > > 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 > <https://e2e.ti.com/>, 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 <chen...@gmail.com> > 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 > <https://e2e.ti.com/>, 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 > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen > <chen...@gmail.com> wrote: > > Hi all, > > I am practicing PRU skills through some TI examples. I am playing with > PRU_ADC_onChip > > <https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_ADC_onChip?h=master>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 <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 beagleboard...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard...@googlegroups.com. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/beagleboard/39813de1-fa27-41d7-9422-7ef375ae36b4n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/39813de1-fa27-41d7-9422-7ef375ae36b4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 > beagleboard...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/ca296f29-c476-45fc-906d-e24595453270n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/ca296f29-c476-45fc-906d-e24595453270n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard...@googlegroups.com. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/beagleboard/CAAOtuRfyiDxEL_N23_%2B1KFzH7EAt%2BapifqpkUCdGHn077Sc7Ww%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CAAOtuRfyiDxEL_N23_%2B1KFzH7EAt%2BapifqpkUCdGHn077Sc7Ww%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/001a2631-6ba3-4687-a7e9-8ccc129fd8edn%40googlegroups.com.
