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 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/ca296f29-c476-45fc-906d-e24595453270n%40googlegroups.com.
