TI PRU_ADC_onChip example

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 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);
}
}

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 :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

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

  The key is probably in the phrase "cross-compiler"... If you are
compiling ON the Beagle, you are using the "native" compiler, not a
cross-compiler ("cross" implies a toolchain that runs on a different
OS/architecture but which builds binary files meant for the target of the
toolchain -- but you are ON ARM, building FOR ARM).

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.

  Cross compilation is used mostly for a couple of reasons: either the
target system does not support a native compiler (you aren't going to run a
compiler on something like a Tiva C board, or an Arduino Due [both of which
run ARM M-series processors] -- though the native compiler on a
Beagle/Debian might be able to build files that can be downloaded to such
boards); the target board is not yet built -- in which case one is likely
going to be "running" the code using something like QEMU or other software
emulation of the hardware system; the target board has a compiler, but the
speed of the cross-compiler environment is much faster (consider a
hyper-threaded 64-bit processor -- which is seen as 8-cores by the OS, each
running at 2.5-3.5GHz, with 12GB of RAM, vs a single 32-bit core running at
1GB with less than 1GB of RAM).

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

  This is a different matter, and likely means the device tree
configuration is not set correctly -- over the last few years there have
been two INCOMPATIBLE means of accessing the PRU. RemoteProc/RPMsg is the
newer system, pru_uio is older -- current images for the Beagle load
RemoteProc -- check /boot/uEnv.txt to see what version your system is
loading...

###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

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 写道:

Cheng

I’m actually using the SDK now so be careful about generic advise
the instructions are for Ubuntu not Debian
'Since I had questions myself right now I realized this PRU code you have just a small part of the SDK
My point was you never read the SDK quick start
Please do so here is the doc tarball

12. Documentation Tarball — Processor SDK RTOS Documentation

If you search the group on X15 and DSP Jeff Aused the SDK and ran the binary on Debian(For the DSP with remore proc)

So yes you can use Debian to load the PRU firmware you need a corresponding ARM binary for that code. Jeff used the SDK to build that

I dont know where you read to compile SDK examples on BBB its not something I read

So use Ubuntu box as instructions tell you too

OR

wait to see if Jeff Andlich can tell you if its feasable to attempt to install the SDK on the board itself and compile the code that doesn’t sound right to me

OR

create an account on E2E ask the people who designed the SDK especially if your confused

I can answer CCS JTAG barebone ARM questiion about SDK not interested in Linux

Please read the tarball in the link

Regard

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 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);
}
}

Hey Dennis,

Thanks for the reply. It makes a lot sense for cross-compiler. Thanks for the explanation.
I am pretty sure I am running on 4.19.x-ti kernel.
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo

I don’t have any problem running other PRU examples. I also noticed that the original firmware is not running at first. But once it is loaded, it seems ok. I tried creating /dev/rpmsg by using “echo hello > /dev/rpmsg_pru30” before running example code. But it would leads to program freeze. I am also exploring direct memory access method to save acquired values in shared memory, but I haven’t got any results yet.

I think I will investigate into the device tree issue as you suggested. Thanks!

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午8:45:57 写道:

Hi Mark,

Thanks a lot for the response.
I think the idea in this processor SDK Linux tutorial is to create Linux SD card from the Processor SDK Linux package, which somewhat echoes with your suggestion.
I guess what confuses me is that in README.txt of the example, it just says “build firmware & userspace code” in the directory, which I assume both are done in BBB. Firmware is straightforward to build, because there is PRU code generation tools - compiler. I already used cross-compiler to build Userspace (ARM side) code. In the meantime, I just wonder if that can also be done in current BBB system. I will definitely study the document you suggest. Thanks!

In addition, the bigger problem is actually rpmsg_pru30 issue. That literally prevents me from running any rpmsg functions. As Dennis mentioned, this might be a device tree problem? I need to spend some time on this.

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午9:06:24 写道:

Hi Cheng

The tarball has step by step instructions for that example you mentioned in initial post.
you need that when starting out.

Why? because few in this group use SDK. Unfortunately you have no choice to ask questions here.

When code doesn’t work on ARM you will get advise to use cookbook and Debian or even worse use libpruio​:wink::persevere: in this group then you will really be confused.

You asked howto to run sdk examples on Debian linux

Your problems are

  1. the instructions say use Ubuntu to install the SDK and build PRU code and Linux Application code in the SDK ie it’s built on a Ubuntu LTS PC a specific version of Ubuntu as well.

  2. the ARM example code you build to talk to PRU is designed for SDK Linux not Debian

#1 above may be possible to overcome . BUT instead

you could just take the SDK ARM example binary
and the PRU firmware binary if it exist in SDK binary directory and put them on the ARM. What’s in SDK directories how the example works step by step are described in SDK pdf.( I sent a link to tarball docs start there read how to install apSDK and host requirements )

#2
Jeff built both sperm and PRU binary in his SDK and put them on Debian and said it it worked on Debian

I don’t know where Jeff installed his SDK but I doubt he put it on the BBB I don’t recommend that.

No body seems to understand my instructions in this group ive been told so if its not clear ask. Its all described in SDK

Lastly I repeat

Your going to be told don’t use SDK use cookbook or libpruio🤔 and Debian on ARM if you try this SDK example and it doesn’t work it’s already started your having problems asking questions correct?

If you got an account on E2E

They would say why aren’t you using SDK Linux we don’t support Debian

Understand?

You have nowhere to go you can’t get in E2E

Understand?

I like the SDK myself but I did see Cookbook has similar RPM Message example and Marks documented that really well

What happened there? Isn’t there an RPMSG ADC example?

Anyway you would not have any problems if you ran SDK linux with the code example you have and in theory it should work on Debian the differences are the SDK linux vs the Yocto SDK Linux maybe muxing I don’t know.

My am335x starter kit board i have at home came with SDK linux running on the ARM and my Beaglebone white I’m using with CCS has JTAG built in and has Ubuntu on the SD card I just pull it out.

That’s why I understand what’s happening.

I started out 5 years ago I tried Ubuntu on bone white followed this group’s instructions it was easy then I bought EVM and learned Yocto SDK Linux building at that time if I had questions answers were in the SDK off tutorial and E2E forum would support me. Their board their SDK.

Don’t feel bad every month someone asks the same questions you did.

they say “I found this PRU example in the SDK can I run this on Debian?”

I say yes it will work what you are attempting.

but I can’t help you when Linux doesn’t run your code and gets errors and when you ask for help in this group I expect you will be told use the Cookbook examples.

Do yourself a favor make a choice again I give you 3 choices

  1. install sdk on Ubuntu box build code for ARM and PRU use SDK Linux on SD card to test this example code.

Or

  1. use Debian and cookbook examples.

Or best solution in my opinion

  1. do #1 first
    get it working correctly
    buy 2nd SD card put Debian on it
    then try the binaries you build from #1 on Debian

Everybody asks to mix both solutions your asking for trouble and wasted time trust me.

Always Use the recommended linux host to build SDK or Debian and the SDK.

To ignore instructions that describe host then ask for help is insane

If you want grief use Fedora virtual machine on win 3 pc to build Debian and ask in this group why it doesn’t work. You will get silence or be sent in 100 directions at once :disappointed_relieved::rofl::grinning_face_with_smiling_eyes::grinning:

Mark

<In addition, the bigger problem is actually rpmsg_pru30 issue. That literally <prevents me from running any rpmsg functions. As Dennis mentioned, this <might be a device tree problem? I need to spend some time on this.

Which Linux are you using on ARM when you see this error ?

I also sent another earlier reply trying explain this was likely to happen if you are not running the SDK linux on ARM.

Can you confirm what you are running on ARM please?

Mark

<<<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

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 写道:

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!

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

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.

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

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.

Walter

This below code you posted in another thread was what I was referring to. Does the E2E forum support cloud 9 dev on BBB???

I’m also curious how you actually build/modify your Linux kernel with no Linux box.

Walter Cromer

changed the code to this and get the same error.

fd = open ("/dev/mem", O_RDONLY | O_SYNC); // not sure O_SYNC is necessary since this is a read-only open situation

Servo tester!!!
ERROR: could not open /dev/mem.

make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1
rm /tmp/cloud9-examples/pwm-test.o

I haven’t posted the question about this code to the E2E forum as I think it must have something to do with permissions.

I don’t know if they support Cloud9 on E2E. I haven’t asked any questions specific to Cloud9.

And, I don’t do any kernel development. It’s above me right now. I’m grateful for all those who do work in this space!
But I write all my code directly on the BBB using cloud9. I guess until recently I didn’t look for any other way to do it.

Walter

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:23wal...@edenconceptsllc.com 写道:

Hi Mark,

Thanks a lot for the detailed explanation regarding the SDK. I actually made the examples work in the end. Like you said, there is difference between SDK Linux and Debian Linux. My approach is similar to what Walter refers. My understanding now is examples from TI needs to be modified properly (mainly makefile) so that it can be applied to the Debian system without any problem. I haven’t finished going through the reference you provided, but they have been tremendous help.

Thanks again!

Regards,
Cheng

在2021年5月1日星期六 UTC-4 下午12:46:03 写道:

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