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 > <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 Mon, May 3, 2021 at 2:35 PM, Walter Cromer > <wal...@edenconceptsllc.com> 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 > <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 Mon, May 3, 2021 at 10:24 AM, Walter Cromer > <wal...@edenconceptsllc.com> 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: > > <<<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 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/88525d79-e91c-470f-9800-ab96cb985398n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/88525d79-e91c-470f-9800-ab96cb985398n%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/438168a2-e668-4e78-9892-573aa337158dn%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/438168a2-e668-4e78-9892-573aa337158dn%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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/43d6c35f-85ab-404b-92e2-5db459ee88c6n%40googlegroups.com.
