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: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> on behalf of Walter Cromer <walt...@edenconceptsllc.com> Reply-To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> Date: Friday, April 9, 2021 at 12:29 PM To: BeagleBoard <beagleboard@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? | | | | | | | | | | | 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 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 . -- 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 tobeagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a50a177c-ba59-47d7-aaab-8352868a3199n%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/DBBPR03MB6988AE54BE71B8EFDAD8A4BDA7739%40DBBPR03MB6988.eurprd03.prod.outlook.com. #yiv5888052173 #yiv5888052173 -- _filtered {} _filtered {} _filtered {}#yiv5888052173 #yiv5888052173 p.yiv5888052173MsoNormal, #yiv5888052173 li.yiv5888052173MsoNormal, #yiv5888052173 div.yiv5888052173MsoNormal {margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv5888052173 h2 {margin-right:0in;margin-left:0in;font-size:18.0pt;font-family:sans-serif;font-weight:bold;}#yiv5888052173 a:link, #yiv5888052173 span.yiv5888052173MsoHyperlink {color:blue;text-decoration:underline;}#yiv5888052173 span.yiv5888052173Heading2Char {color:#2F5496;}#yiv5888052173 span.yiv5888052173EmailStyle20 {font-family:sans-serif;color:windowtext;}#yiv5888052173 .yiv5888052173MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv5888052173 div.yiv5888052173WordSection1 {}#yiv5888052173 -- 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/426420093.172935.1617989895589%40mail.yahoo.com.
