On Mon, 21 Jun 2021 21:49:01 -0400, Dennis Lee Bieber wrote:
You won't like this: Which ever one satisfies your requirements
-- you
could install GNAT and code in Ada; or suck up a few GB installing Lazarus/FreePascal.
Python was considered the "native" (as in: meant for beginners) language for the R-Pi...
Thing is, your requirements are so high-level that one can't really
declare for any language. At the very least, you are looking at a multi-threaded application, if not multi-process system (threads exist
within a single process, and depending on implementation, can share information easily; multi-process will require designing some
interprocess communication system/protocol -- unfortunately, the only
OSs for which I was comfortable in IPC are AmigaOS (message ports:
linked lists created by processes to which other processes can append "messages"; since the Amiga used a flat address space, all processes
could access any memory -- messages tended to contain just a pointer to
a buffer) and [Open]VMS (mailboxes to which processes can write/read).
If you are going to multi-thread, normally I'd suggest going for Java,
which also has a decent GUI system, SWING, especially using using the 3rd
party RiverLayout layout manager from se.datadosen.
Disclaimer: I know thus works v. well in kit like Lenovo laptops but
haven't yet installed Java on an RPi, so have no idea of the likely
performance or compile speeds.
OTOH, if you'd rather go multi-process, then writing a set of co-
operating processes in C that communicate through a block of shared
memory and use semaphores to co-ordinate access is fairly easy,
especially if you have the UNIX Systems Programming book I recommended.
A third way to go is to write a set of small, single threading C
processes, each carrying out a single, well-defined part of the overall
task.
One of these processes owns a block of shared memory and manages access
to it: the blocks of incoming do not move once they are loaded into the
shared memory by a loader process, where then remain until all operations
on them are complete, and an exporter process has done the final
operation and requested them to be deleted from shared memory.
The other worker processes operate by requesting access to a data block,
which is locked as they get passed its address. After they've done their
thing the worker tells the shared memory owner to release the last block
and requests another: each stored block is either 'available' or marked
as allocated to a worker process.
All interprocess communication is done by standard UNIX message passing,
and is handled by the standard C poll() mechanism, which is brilliant for handling this sort of message queueing.
This sort of multi-process data handling stream works really well and is
quite simple to implement: I designed and implemented a large, high
performance ETL system, running on DEC Alphaserver kit, that transformed incoming data and loaded it into a data warehouse using this approach. It easily exceeded the stated performance requirements and, because each
step was handled by a separate, single threaded process, the code was
both simple and secure.
The process that handles the drive motors is probably going to run at a higher priority than one that is handling a camera and relaying video
over WiFi. Higher than both of those might be the process that handles command receipt and return telemetry. It should spend a lot of time just waiting for commands, and some time packaging telemetry packets -- no
busy loops, since that would interfere with lower level processes (a
busy loop could totally block out the motor control process from
responding to forwarded STOP commands).
You may even find that you only want to run the user-interface on the
R-Pi, with it sending commands to multiple microcontrollers (Arduino,
TIVA C, AdaFruit Metro [which uses CircuitPython natively, but can have
an Arduino compatible loader installed]).
Could also be a good place to use PICAXE chips (despite their rather
horrid compiled, unsigned intreger BASIC (but at least the PICAXE BASIC compiler runs well on an RPI 2B) or even a RaspberryPi PICO.
Don't forget the standard C poll() function I mentioned earlier, which
can handle responses from microcontrollers as well as from other
processes. See 'man 2 poll' for details.
--
Martin | martin at
Gregorie | gregorie dot org
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)