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 >>>> <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 < >>>> [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 >>>> <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 >>>> <[email protected]> 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 [email protected]. >>>> 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 [email protected]. >>>> 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 > [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAOtuRfyiDxEL_N23_%2B1KFzH7EAt%2BapifqpkUCdGHn077Sc7Ww%40mail.gmail.com.
