Hello Walter
I think so nice novel approach. Since the 2nd PRU is started manualy from
command line in Linux you shouldnt get clobbered as thats what that memory is
for the PRU code and Resource Tables from my reading. Id guess address
translation is required. shared RAM could be used as well I know that works
thinks are much simpler when ARM is in supervisor mode no userland but I
digress.I saw your latest post I think that issue has come up before maybe
search the group I might be wrong maybe poke around in the OCP dir see whats
there. How these directories get created should be documented perhaps in some
Linux readme none of this tribal knowledge exists in barebone arm its straight
C code muxing. Searching E2E I saw a thread blaming Linux for CCS/JTAG issues
on PRU theres definately many angry confused users out there I appreciate the
difficulty in supporting a complex chip but sorting all this can be daunting. I
installed CCCS 10 Win10 for a TI simple Link radio project and Im seeing grayed
out feature Id rather avoid CCS on Linux. I've installed CCS on at least a
dozen projects on windows never had issues I am still confused as at one point
some features and Processors were not free. These wikis in the past have been
very helpful I see some migration going on with that documentation a bit scary.
Lastly I found some PRU examples digging in E2E Im more apt to start with
those vs cookbook they mention CCS6. If I delve into Linux/PRU it would be the
RPMsg examples and I have a sneaky hunch the command line build example may
work fine using sdk linux but from past experience the CCS/JTAG require xml and
gel files to hold the ARM core off and do muxing and low level setup of memory.
Hopefully I can share something useful. Does Cookbook have RPMsg examples?
Mark
On Friday, April 16, 2021, 07:49:22 AM CDT, Walter Cromer
<walt...@edenconceptsllc.com> wrote:
As I get a better understanding and experience this may change, but right now
I don't think it can handle the volume of data we need to move between systems.
And, that volume is only needed during R&D. The production system will not
need to keep that data.
So, my plan is to instance arrays on the ARM side and use RPMSG to pass the
addresses to the PRU. The PRU code will translate that to ARM addresses. As
the data is collected it will be stored in arrays local to the PRUs (in the 8k
or 12k memory spaces). When the time-sensitive data collection is completed,
the PRU array will contain the data. Then we'll just copy it over the ARM
addresses.
My assumption is that since the ARM instances the arrays in memory, Linux will
not overwrite those locations so they'll be 'safe'. I'll probably use RPMSG to
alert ARM that the data is going to be transferred and wait on an 'ack' from
the ARM before copying it over.
Seems like it should work.
On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote:
Hello TJF
Looks very powerful and code is very generic and well thought out. I thought
you couldn't code?🤣
I'm on tablet forgive my laziness where are the ADC examples located in c
language if possible
Looks like you support multiple languages nice.
I'm guessing below reference you mentioned is the am335x TRM or are you
referring to the ARM intellectual property for ADC?
It's also possible to directly write to the step configuration in AdcSet::St_p
by writing to the member variables Confg and Delay. See ARM Reference Guide,
chapter 12 for details on ADC configurations.
Thanks. Did you write this library? It's quite a bit to wrap ones mind around.
How long dis this take to develop.
I've got a basic understanding of how RPMSG works I'd like to understand how
libpruio handles the data exchange.
I'm wondering why Walter isn't using RPMSG he's talking about using the other
unused PRU memory to store data and have ARM read it. I'm trying to see if
that's doable for my own understanding. Certainly would not be good if that PRU
loaded code from ARM. The Linux part I'm unfamiliar with. From my reading it
sounds like starting PRU is manually done from linux command line.
Loading and debugging PRU code seems to me to be slow and time consuming
compared to jtag.
Lastly in the unlikely event a modified libpruio example crashes what is the
debug mechanisms beyond dmsg saying dude you crashed go recompile and reload.
Are console output echoed back.
Thanks in advance also any data sharing examples in libpruio?Mark
Sent from Yahoo Mail on Android
On Fri, Apr 16, 2021 at 12:47 AM, TJF<jeli.f...@gmail.com> wrote:
wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 18:35:20
UTC+2:
So, STEPENABLE lets me enable the steps that I want to be executed. (I missed
that concept before.)
So if I had an application that had a sensor A that needs to be read every 10ms
and sensor B that only needs to be read every minute, I could wire channel 1 to
sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it
to step 2.
Then at startup, when I want to read both sensors, I enable steps 1 and 2 but
not 3-16. This saves time on the read as channels 3-7 aren't needed and steps
3-16 aren't needed so I don't use them. Then after the initial read when I
don't need to read sensor B until a minute passes, I can change STEPENABLE so
only step 1 is enabled and execute a read every 10 ms. Only sensor A would be
read. Then at one minute intervals, I change STEPENABLE so steps 1 & 2 are
enabled and when read is triggered, sensors A and B are read.
There're 17 steps, one charge step and 16 sample steps. Each step configures
not only the multiplexer (chanel 0-7), but also an open delay and a sample
delay, as well as an avaraging number. That's explained at AdcUdt::setStep(),
including a hint where to find further information in the ARM TRM.
In order to write to the STEPENABLE register you've to stop the sequencer,
write the new value and restart the sequencer again. This is 3 times L3
operation, which need at least 3 PRU cycles each (perhaps more in case of heavy
travel). How do you what to ensure accurate ADC timing?
The outnumber of step registers isn't thought of macroscopic asymmetry (in your
case sample channel A and B at 10 ms and ignore the B value for a minute). It's
made for microscopic asymmetry, ie when you want to sample A twice as often as
B.
--
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/def726b2-31f2-469b-a9fc-70fc429ffa59n%40googlegroups.com.
--
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/36b51d01-0f46-44e0-89df-90489d42cec4n%40googlegroups.com.
--
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/1382253891.1601633.1618579400980%40mail.yahoo.com.
