We are controlling fluid flow by controlling two valves. (I am being a bit obscure because there are some proprietary processes involved.)
We start the flow and then read two sensors that are 'watching' the fluid for an event. There is an event 'start' in the fluid and then a following event 'end' that we determine by watching the values from the sensors. I believe this 'watch' part will be handled by the PRU firmware. When the event is over, the valves are turned off. We believe that the ARM will handle the valve control and UI. The C code running under Linux has completely missed events because of its non-deterministic operation. The communication between ARM and PRU programs should consist of 1 - start / stop reading the sensors - considering just flipping a bit in a memory location both can access for this. ARM will have write access, PRU will just monitor it. (I don't really know how to do this yet. Still learning.) 2 - raw data collected about the event by the PRU doesn't really have to be accessed by the ARM in normal operation. (For R&D, we'd probably like to have it though.) Every sensor reading has to have its corresponding timestamp but all this data can be tossed once it is consumed. The PRU will need to be able to do some statistics on it like mean, mode, std. dev. 3 - if conditions are met, the PRU needs to tell the ARM. considering just flipping a bit in a memory location the PRU can write to and the ARM can only read from for this. The valve on/off can handle delays of 50 ms with no issue at all. (I'm an old dog learning new tricks. Years ago my hands-on experience was with Motorola 68xx and 68xxx series processors so I was comfortable writing directly to memory locations, registers, etc. It took me a while on returning to this to get comfortable with sysfs but I definitely see the limitations in projects like this one! Thanks for your patience and help!) On Friday, April 9, 2021 at 1:38:37 PM UTC-4 lazarman wrote: > Hi > > ??but I think the BBBw can easily sample at this ????rate, right? > > Asking about ARM/linux side ? or > > PRU side > > Polling or Interrupt? > > Explain you delay details at least delay duration and what your app does > with data would help. > > The calculation I mentioned seeing people reply about were on the PRU. > > Keep in mind there's overhead to get Data from PRU to ARM. > > The timing becomes critical when you need to react from the data you > read quickly. If that's not the case your just talking about how many > sample's you use to control right? That's why I would expand a bit on your > application. > > I've worked on stuff that read and reacted in 10 microseconds closed loop > plastic pressing for example that was easily achieved in 1988 > microprocessor speeds > > I've also worked on control loops that ran faster than 1 micro second on > a similar processor OMAP L138 in that case the code ran on the DSP I forget > the clock speed. In this case the motor control ran every 100 nanosecond I > believe but it's used TI RTOS. > > If the delay on Linux isn't acceptable add some details I mentioned > hopefully the two guys who calculated PRU latencies will reply or I will > find that post if possible. > > Again it's probably highly likely even a polled PRU app can read Data > quickly dependant on conversation rates time I'm assuming you need the ARM > to get Data in 100 microseconds? > > I'm not sure the transfer rate between PRU and ARM us determistic if linux > is used . > > Hopefully this makes sense if not ask but I'd follow up with more detail > > Mark > > > *From: *"beagl...@googlegroups.com" <beagl...@googlegroups.com> on behalf > of Walter Cromer <wal...@edenconceptsllc.com> > *Reply-To: *"beagl...@googlegroups.com" <beagl...@googlegroups.com> > *Date: *Friday, April 9, 2021 at 12:29 PM > *To: *BeagleBoard <beagl...@googlegroups.com> > *Subject: *Re: [beagleboard] Re: Periodic delay reading analog inputs > with C, will PRUs solve it and is it worth it? > > > > Thanks, I'll check that out! > > On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote: > > Hi, > > I believe there are some simple ADC-read example directly in the image > under /var/lib/cloud9/Techlab/.challenges, or here: > https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c > > They are labeled for PocketBeagle but it's the same ti-am335x chip so they > should work easily on the BBB. > > Hope it helps! > > Pierrick > > Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a > écrit : > > Understood. Our application won't require FAA or FDA approval but it > definitely needs the more deterministic performance of a bare bones app so > I'm heading in the direction of the ADC being read by a PRU program and > communicating back to the ARM for other processes (UI, reading other > non-time-sensitive inputs, etc.). > > On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote: > > 1) > > *Linux* is not a real-time operating system (OS) in and of itself. ... > “The idea is to run critical applications like the control loop on VxWorks > and then run non-*deterministic* analytics on *Linux*. > > > > Hard realtime apps like closed loop positioning used in pressing > plants,automation,fighter planes etc etc don't use Linux. Determinism > required by safety critical systems certified by FAA would require you > found delay measured it to calculate worst case as well as validated > software. > > > > > https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.&text=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux. > > > > > > > > What makes the Linux scheduler seem unpredictable? > <https://unix.stackexchange.com/questions/65969/what-makes-the-linux-scheduler-seem-unpredictable> > What makes the Linux scheduler seem unpredictable? > > The question refers to the output of a multi-threaded application, where > each thread merely prints its ID (user assigned number) on the standard > output. Here all threads have equal priority and com... > > > > > > 2) I say no depends on how much delay is acceptable there are buses > between shared memory etc it will improve over using ARM. > > > > Ideal situation is a barebone app designed with minimal interrupt latency > followed by an RTOS that's guaranteed to meet latency specs especially one > certified by FAA or FDA of course these are expensive > > > > > > > > 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 9, 2021 at 8:23 AM, TJF > > <jeli.f...@gmail.com> wrote: > > > > wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 > UTC+2: > > I'm looking at some example code and there references to ADC_TSC. I > realize this is a reference to the Touchscreen controller which provides > the ADC functionality. And I suspect this refers to the base memory > address of the chip but I cannot find where that is defined in any header > files anywhere. It would help me to follow these examples if I knew where > that reference was. > > > > Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] > and low level code (assembler) in file src/pruio/pruio_adc.p. > > > > > > Unfortunately, too, the examples are Python and I'm not a Python > programmer. I work in C. So I'm having to dig through this and learn > some Python at the same time. Not a bad thing but time consuming! > > > > Python examples are in folder src/python. FreeBASIC examples are in > folder src/examples. And C examples are in folder src/c_examples. Find an > overview at > > > > > https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html > > > > Regards > > > > -- > 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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%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/a50a177c-ba59-47d7-aaab-8352868a3199n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/a50a177c-ba59-47d7-aaab-8352868a3199n%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/DBBPR03MB6988AE54BE71B8EFDAD8A4BDA7739%40DBBPR03MB6988.eurprd03.prod.outlook.com > > <https://groups.google.com/d/msgid/beagleboard/DBBPR03MB6988AE54BE71B8EFDAD8A4BDA7739%40DBBPR03MB6988.eurprd03.prod.outlook.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/7d489acc-124f-46c6-bfab-8b6a7af58fa3n%40googlegroups.com.
