When I try to run this in Cloud9, I'm getting this error. I'm not sure
where type __far is defined but apparently I'm missing that definition. I
have to copy pru_cfg.h over to /usr/include manually to get this far.
Maybe there are other include files that are missing that it hasn't warned
me about? Sorry be such as neophyte!
/usr/include/pru_cfg.h:242:10: error: unknown type name ‘__far’
volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near),
peripheral));
^~~~~
/usr/include/pru_cfg.h:242:23: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘CT_CFG’
volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near),
peripheral));
^~~~~~
PRU_AnalogReadfromGT.c:15:10: fatal error: pru_intc.h: No such file or
directory
#include <pru_intc.h>
^~~~~~~~~~~~
compilation terminated.
make: *** [/var/lib/cloud9/common/Makefile:215:
/tmp/cloud9-examples/PRU_AnalogReadfromGT.o] Error 1
On Friday, April 9, 2021 at 11:19:47 AM UTC-4 [email protected] 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, [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/5602174c-2868-4c4c-9185-72ab49e86e63n%40googlegroups.com.
