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, [email protected] 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... >> >> <https://unix.stackexchange.com/questions/65969/what-makes-the-linux-scheduler-seem-unpredictable> >> >> >> >> 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 >> <[email protected]> wrote: >> >> >> [email protected] 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/55b15f32-c44a-4977-8390-e91615c5e788n%40googlegroups.com.
