John, One of the things RT lines adds the stuff you are talking about. RTAI has the ability to crete a "hard real time thread" in addition to the normal POSIX threads. These are run from a different scheduler. Normal Linux POSIX threads run only if the real time system has any left over CPU time.
Maybe thing this way. RTAI runs the normal Linux OS in it's idle loop. I think this is a slight simplification. What really happens best as I can tell s the RTAI catches all the hardware (including timer) interrupts ahead of Linux One more think that is important for performance. RT threads can run in Kernel space. Sounds dangerous and it can be but if you need real time access to hardware you need this. Some years ago I wrote a CCD camera controler and user RTLink, before it split with RTAI. It run on an Intel based PC chassis ad it directly controls the pins on the CCD chip to move charge across the chip and route the pixels through amplifies, sample and hold and ADC. It did image stabilization my moving the car charge on the chip to compensate for subject motion. Obviously we needed sub-microsecond timing. You can get it if you run in Kernel space with interrupts disabled. But Ethernet and disk I/O may not works unless you can find a way to put in some calls to "wait()" RTAI also has soft real time tasks and can run them insure space. Basically you get a range of task types The way my camera worked is typical of the way RT linux is used. The RT task that ran in Kernel space place data on a queue. Then in user space was a soft RT task that read the queue and wrote the data to disk. The pixels had to be clocked off the CCD chip at an exact rate but that could be written to disk at any time so long as the queue did not over flow and we made it really big. I notice that modern dSLRs work the same way. There is a RAM buffer that holds a dozen of so frame. This was an astronomical camera used for stellar photometry. It was good to have it Linux based because you can log in via SSH and control the camera for 3,000 miles away SO in short, yes all the things you'd expect in an RTOS are there, plus it runs normal Linux too. That said, the robot system I'm working on right now is using normal Linus on a Raspberry Pi3 but the Pi3 has a serial link to an ARM M4 (STM32F411) that in terns controls the hardware. The STM32 runs a true RTOS. The Pi3 does navigation and motion planning, the M4 does real time execution and the is as a 16-core Xeon system that handles higher level tasks. It s designed t thee each computer can do something if the one above it is not powered up. On Sat, Jun 23, 2018 at 9:06 PM John Dammeyer <jo...@autoartisans.com> wrote: > But we are still talking about a Multi-Tasking, Round Robin Priority Driven > OS right? Like 3 tasks with the same priority are time sliced with equal > processing time? Inter task communication done with pipes. A task can > suspend on a pipe until it's written to by another one. A task that sits > in > a while loop only gets X processor time before it's swapped out. > > It's just that if you set up a loop to sleep for 95mS and process for 5mS > there's a possibility that the system will be busy doing Python Garbage > collection and it won't wake up exactly 100mS later. > > Most of the stuff I do is on smaller microprocessors with co-operative > multi-threaded state machines. No while loops allowed within a state since > there is no pre-emption. Any time critical operations are generated off > timer interrupts. > > One of the features I use are what I call recurring timers. Once started > and armed the code can wait in a state until the timer is done. Inside the > interrupt routine the timer is immediately started again but not armed. > After the thread code sees the timer is done, it re-arms and processes what > it needs to do before returning. Even if there is a 10mS latency before > the > thread were to deal with the timer it does the 5mS worth of work and then > returns to wait for the timer to expire again. That will happen 85mS > later > since it was restarted inside the interrupt routine. Genearally I don't > see > that sort of latency so although there's jitter there's usually only 1% or > so. Not good for stepper motors but fine for a lot of other automation > tasks. > > John > > > > > > -----Original Message----- > > From: Jon Elson [mailto:el...@pico-systems.com] > > Sent: June-23-18 8:13 PM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] Raspberry Pi PREEMPT-RT > > > > On 06/23/2018 06:52 PM, John Dammeyer wrote: > > > Hi Jon, > > > > > > So you are confirming that standard Linux like Ubuntu for a PC, the > Raspian > > > for the Pi or the Debian for the Beagle is just a multi-user OS and > also > not > > > real time. > > > > > Yes, the standard OS is not real time. If the OS has a RT > > option applied to it, it will append something > > to indicate that. One of my systems shows this : > > > > Linux jelinux 4.6.0-0.bpo.1-rt-amd64 #1 SMP PREEMPT RT > > Debian 4.6.3-1~bpo8+1 (2016-07-13) x86_64 GNU/Linux > > > > Jon > > > > > > ---------------------------------------------------------------------------- > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
