RT Kernel

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either
systemd or pulseaudio.

Actually, this is already better than the official OS when running purely with
ALSA.

--  
W J G


Re: RT Kernel
Quoted text here. Click to load it

Just curious - have you found the standard kernel insufficient for your  
needs? and what are those needs?

My, admittedly limited, experience if this area has never pushed me to  
an RT kernel. And when I did research the move to RT (many years ago)  
I'm not sure it'd have been much better. Maybe things have got better.






Re: RT Kernel
On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)

Quoted text here. Click to load it

I don't know that it will make a difference on the Pi, but it certainly does on
Intel and AMD processors. Typically I can go from 8mS latency down to 2mS on
complex Yoshimi 10-12 Channel performances.

--  
W J G


Re: RT Kernel
Quoted text here. Click to load it

Ok that's certainly worth it. Sorry I can't help re. RT linux kernel and RPI.
Maybe try the advanced section of the RPI forum? Though I do find that it's not often "advanced".

Re: RT Kernel
On a sunny day (Thu, 7 Jan 2021 20:35:13 -0000 (UTC)) it happened Jim Jackson

Quoted text here. Click to load it

Linux, RT or not, is not a real time system.
It is a multi-tasker.
I usually design some extra hardware if things need to run fast and continuously.
hardware that includes buffers.
example:
 http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/

Much these days can perhaps be done with an FPGA hat (have not tried that).
Else you will need to do some electronic design, soldering, etc.
In any case you also need to write the software to interface to that,
You need to specify your requirements.

Sometimes a simple PIC micro-controller is all you need to add to get past the task switch interrupt..
But it will need to be programmed too.
  

  

Re: RT Kernel
Jan Panteltje wrote:

Quoted text here. Click to load it

I know a guy from the mailing lists (Gene Hasket) that is operating some CNC
and was complaining about lack of RT in linux. He is using some patched
kernel from somewhere - I do not recall the details, but it is really a
problem that Linux is not applicable to time sensitive applications.

Re: RT Kernel
  Re: Re: RT Kernel
  By: Deloptes to Jan Panteltje on Fri Jan 08 2021 09:56 am

 > I know a guy from the mailing lists (Gene Hasket) that is operating some CNC
 > and was complaining about lack of RT in linux. He is using some patched
 > kernel from somewhere - I do not recall the details, but it is really a
 > problem that Linux is not applicable to time sensitive applications.

There is a quote somewhere from Linus, in the lines of "You are crazy if you
want to use Linux for your CNC toolchain, but in case you are that crazy, here
is this RealTime version of the kernel."

I have heard one of the reasons lots of industrial applications run MS-DOS or
Freedos is because the OS is a non-os and you don't have to deal with such a
thing as a scheduler.

--
gopher://gopher.richardfalken.com/1/richardfalken

Re: RT Kernel
On Fri, 08 Jan 2021 09:56:13 +0100

Quoted text here. Click to load it

    Problem ? It's a fact and always will be that multi-tasking
operating systems and real time processing don't go together unless the
real time demands are very long relative to the processing speed (eg.
payroll).

    Time was we used MS-DOS for burning CDs rather than unix because
it only took one late write to make a coaster, buffering and faster
processors means that we can now burn blu-ray discs from a multi-tasking OS
and almost never make a coaster. That doesn't make unix a real time OS it
just means that the timescales have shrunk.

--  
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: RT Kernel
On Fri, 8 Jan 2021 09:27:35 +0000

Quoted text here. Click to load it

Well, some 10 years ago, the firm I used to work for designed a print register
control system running on Linux retrofitted to a printing press. This was a
press that spilt the printed sheet into four ribbons, lined them up one on top
of the other, and also timed the cut and fold. I was there the first time it was
run. A gaggle of bigwigs were there, and as the press operator started the
machine one of them asked when it would be in register. By the time the printing
itself was stable, and they picked up one of the folded sheets, it was in
register on all four sheets within 2mm.

Fun facts:
The machine had rated top speed of 36,000 copies per hour - 10 A3 size per
second. On an emulated press, our system could manage at least 60,000. Modern
presses do 100,000

Quoted text here. Click to load it

Even on an old eeePC900 by adjusting the priorities I can see the audio and
interface threads are running on different cores, so with modern high count CPU
cores, and GPUs the distinction is becoming moot. I don't know how to do it
myself, but a *lot* of audio processing is very simple parallel operations -
the thing that GPUs excel at!

--  
W J G


Re: RT Kernel
Folderol wrote:

Quoted text here. Click to load it

do you mean that it were be better using the GPU for time sensitive
operations?

Re: RT Kernel
On 08/01/2021 11:42, Deloptes wrote:
Quoted text here. Click to load it
I think what he means is that a *lot* of audio processing - and that is  
essentially complex digital filtering - is very simple parallel operations.
I wrote quite a lot of it for fun - essentially the biggest CPU chewers  
for me were reverberators - loads of different delays multiplied by  
constant factors and added together (or subtracted).

Actually I am not sure how that would sit in parallel cores - I suppose  
you would do partial results. The problem is of course that you need to  
access the same delay line in memory for all cores, and its actually  
those accesses that take the cycles. Assuming you have a fast floating  
point multiplym anyway.


--  
Canada is all right really, though not for the whole weekend.

"Saki"

Re: RT Kernel
On Fri, 8 Jan 2021 13:10:22 +0000

Quoted text here. Click to load it

Good point. I hadn't thought of access time!

--  
W J G


Re: RT Kernel

Quoted text here. Click to load it

s/Hasket/Heskett/
He's a regular on the debian-users mailing list.

Quoted text here. Click to load it

Ah, finally, someone else who realizes that payroll is a real-time
application.

Quoted text here. Click to load it

I'm still nervous about doing other things while burning a CD.
On the other hand, the only coasters I've produced were due to
hardware problems (usually dust bunnies in the drive).

--  
/~\  Charlie Gibbs                  |  "Some of you may die,
We've slightly trimmed the long signature. Click to see the full one.
Re: RT Kernel
Quoted text here. Click to load it

Depends over what time period your sensitivity is!

Re: RT Kernel
Quoted text here. Click to load it

3D printers pretty much always have some sort of microcontroller running
them directly...anything from an 8-bit AVR on up to ARM-compatible devices
like the LPC176x or STM32Fx families.  Any of these are sufficient for
accurately firing stepper motors, monitoring endstops and thermistors, etc.  
in a Cartesian or CoreXY printer configuration; more advanced kinematics
(such as Delta or SCARA) sees more benefits from a 32-bit controller.  

To the extent that a Raspberry Pi is involved in 3D printing, it's usually
just streaming gcode to the printer's microcontroller.  Even if you're
running something like Klipper (which shifts more of the motion-control work
to the Raspberry Pi), you're still streaming some sort of simplified command
sequence to a microcontroller that provides the necessary realtime control.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

Re: RT Kernel
Scott Alfter wrote:

Quoted text here. Click to load it

Quoted text here. Click to load it

Thank you and all of you for the educational discussion.
I was also thinking of such approach, but I do not know if there are some
ready to use solutions for CNCs - I might have a look into the AVR world. I
build one evaluation board some time ago and it could be fun playing with

Quoted text here. Click to load it

Quoted text here. Click to load it

I guess the problem is more the coordination of the motors and sensors.
based on what you say this must take place in the external for example AVR
controller.
I do not think a CNC is so simple as 3D printer. It is at least more
expensive but I saw recently there are some mini CNCs on the market as
well.




Re: RT Kernel
Quoted text here. Click to load it

The principles are the same: move two or more axes in a coordinated manner
to position a toolhead where it needs to be.  The toolhead could be
anything: an extruder for 3D printing, a router for milling, a laser for
engraving or cutting, a pick-and-place toolhead for automated electronics
assembly, or whatever.  Gcode was originally developed for CNC milling and
has been adapted to other purposes.

What makes even the most basic mill more expensive than the most basic 3D
printer (now available for under $100 if you're not too picky) is the more
robust hardware needed: stronger frames, more powerful motors, etc.  You
could run a mill with the same Arduino Mega and RAMPS stack commonly used
with 3D printers, with the possible exception of needing to hack in more
robust motor controllers.  (The postage-stamp-sized motor controllers
commonly used in 3D printing are adequate for the NEMA 17 and smaller motors
used in 3D printers.  They'll probably let the magic smoke out if you try
driving too large a motor with them.)

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?


Re: RT Kernel
Quoted text here. Click to load it

That's true for "usually", though it's not always the case:
https://github.com/Wallacoloo/printipi

Also, with LinuxCNC:
http://soundproofingforum.co.uk/rpi_linuxcnc/raspberrypilinuxcnc.htm

--  
__          __
#_ < |\| |< _#

Re: RT Kernel
On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:

Quoted text here. Click to load it
Have you talked to Microware? http://www.microware.com/

They are in the process of porting OS/9 to the RaspberryPi and Beaglebone.

OS-9 was originally implemented on a 6809 and was designed from the  
ground up as a real-time OS rather than a general purpose, multi user  
one, which was how I used it. I ran the 68000 port for several years as  
my main computer. This was on a 68020 system, where it did everything I  
needed for several years (until the hardware collapsed) and I was  
pleasantly surprised by its performance and the lack of bugs in both OS  
and compilers/utilities.

The only thing that moved me off it and onto Linux was the death of its  
hardware.


--  
--  
Martin    | martin at
We've slightly trimmed the long signature. Click to see the full one.
Re: RT Kernel
On Thu, 7 Jan 2021 21:56:05 -0000 (UTC)

Quoted text here. Click to load it

I had looked at it when I heard about it, but it would require a *total*
rewrite of Yoshimi, and would no longer be free - so not going to happen on my
watch!

--  
W J G


Site Timeline