Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #25585 > unrolled thread

RT Kernel

Back to article view | Back to comp.sys.raspberry-pi

Contents

  RT Kernel Folderol <general@musically.me.uk> - 2021-01-07 17:26 +0000
    Re: RT Kernel Jim Jackson <jj@franjam.org.uk> - 2021-01-07 19:55 +0000
      Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-07 20:27 +0000
        Re: RT Kernel Jim Jackson <jj@franjam.org.uk> - 2021-01-07 20:35 +0000
          Re: RT Kernel Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-08 06:55 +0000
            Re: RT Kernel Deloptes <deloptes@gmail.com> - 2021-01-08 09:56 +0100
              Re: RT Kernel Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 09:27 +0000
                Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-08 11:16 +0000
                  Re: RT Kernel Deloptes <deloptes@gmail.com> - 2021-01-08 12:42 +0100
                    Re: RT Kernel The Natural Philosopher <tnp@invalid.invalid> - 2021-01-08 13:10 +0000
                      Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-08 16:28 +0000
                Re: RT Kernel Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-08 18:06 +0000
              Re: RT Kernel nospam.Richard.Falken@f1.n770.z6534.fidonet.org (Richard Falken) - 2021-01-08 10:49 +1300
              Re: RT Kernel Jim Jackson <jj@franjam.org.uk> - 2021-01-08 18:06 +0000
              Re: RT Kernel Scott Alfter <scott@alfter.diespammersdie.us> - 2021-01-08 20:18 +0000
                Re: RT Kernel Deloptes <deloptes@gmail.com> - 2021-01-08 21:36 +0100
                  Re: RT Kernel Scott Alfter <scott@alfter.diespammersdie.us> - 2021-01-10 22:28 +0000
                Re: RT Kernel not@telling.you.invalid (Computer Nerd Kev) - 2021-01-08 23:54 +0000
    Re: RT Kernel Martin Gregorie <martin@mydomain.invalid> - 2021-01-07 21:56 +0000
      Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-07 22:25 +0000
        Re: RT Kernel Martin Gregorie <martin@mydomain.invalid> - 2021-01-07 23:37 +0000
          Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-08 10:35 +0000
            Re: RT Kernel Martin Gregorie <martin@mydomain.invalid> - 2021-01-08 11:31 +0000
    Re: RT Kernel druck <news@druck.org.uk> - 2021-01-08 20:40 +0000
      Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-09 09:45 +0000
    Re: RT Kernel not@telling.you.invalid (Computer Nerd Kev) - 2021-01-08 23:38 +0000
      Re: RT Kernel Folderol <general@musically.me.uk> - 2021-01-09 10:05 +0000
        Re: RT Kernel Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-09 17:16 -0500
    Re: RT Kernel Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 22:54 -0500

Page 1 of 2  [1] 2  Next page →

#25585 — RT Kernel

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

[toc] | [next] | [standalone]

#25589

On 2021-01-07, Folderol <general@musically.me.uk> wrote:
> 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.
>

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.

[toc] | [prev] | [next] | [standalone]

#25590

On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)
Jim Jackson <jj@franjam.org.uk> wrote:

>On 2021-01-07, Folderol <general@musically.me.uk> wrote:
>> 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.
>>  
>
>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.

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

[toc] | [prev] | [next] | [standalone]

#25591

On 2021-01-07, Folderol <general@musically.me.uk> wrote:
> On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)
> Jim Jackson <jj@franjam.org.uk> wrote:
>
>>On 2021-01-07, Folderol <general@musically.me.uk> wrote:
>>> 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.
>>>  
>>
>>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.
>
> 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.
>

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".

[toc] | [prev] | [next] | [standalone]

#25596

On a sunny day (Thu, 7 Jan 2021 20:35:13 -0000 (UTC)) it happened Jim Jackson
<jj@franjam.org.uk> wrote in <slrnrves41.2qk.jj@iridium.wf32df>:

>On 2021-01-07, Folderol <general@musically.me.uk> wrote:
>> On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)
>> Jim Jackson <jj@franjam.org.uk> wrote:
>>
>> 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.
>>
>
>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".

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.
 

 

[toc] | [prev] | [next] | [standalone]

#25597

Jan Panteltje wrote:

> 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.

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.

[toc] | [prev] | [next] | [standalone]

#25598

On Fri, 08 Jan 2021 09:56:13 +0100
Deloptes <deloptes@gmail.com> wrote:

> 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.

	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
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[toc] | [prev] | [next] | [standalone]

#25602

On Fri, 8 Jan 2021 09:27:35 +0000
Ahem A Rivet's Shot <steveo@eircom.net> wrote:

>On Fri, 08 Jan 2021 09:56:13 +0100
>Deloptes <deloptes@gmail.com> wrote:
>
>> 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.  

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

>	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.
>

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

[toc] | [prev] | [next] | [standalone]

#25604

Folderol wrote:

> 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!

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

[toc] | [prev] | [next] | [standalone]

#25605

On 08/01/2021 11:42, Deloptes wrote:
> Folderol wrote:
> 
>> 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!
> 
> do you mean that it were be better using the GPU for time sensitive
> operations?
> 
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"

[toc] | [prev] | [next] | [standalone]

#25614

On Fri, 8 Jan 2021 13:10:22 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

>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.
>
>

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

-- 
W J G

[toc] | [prev] | [next] | [standalone]

#25617

On 2021-01-08, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Fri, 08 Jan 2021 09:56:13 +0100
> Deloptes <deloptes@gmail.com> wrote:
>
>> 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.

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

> 	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).

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

> 	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.

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,
\ /  <cgibbs@kltpzyxm.invalid>      |  but it's a sacrifice
 X   I'm really at ac.dekanfrus     |  I'm willing to make."
/ \  if you read it the right way.  |    -- Lord Farquaad (Shrek)

[toc] | [prev] | [next] | [standalone]

#25615

  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

[toc] | [prev] | [next] | [standalone]

#25616

On 2021-01-08, Deloptes <deloptes@gmail.com> wrote:
> .... snip ....
> kernel from somewhere - I do not recall the details, but it is really a
> problem that Linux is not applicable to time sensitive applications.

Depends over what time period your sensitivity is!

[toc] | [prev] | [next] | [standalone]

#25621

In article <rt96nd$jp6$1@dont-email.me>, Deloptes  <deloptes@gmail.com> wrote:
>Jan Panteltje wrote:
>
>> 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.
>
>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.

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?

[toc] | [prev] | [next] | [standalone]

#25622

Scott Alfter wrote:

> 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.
> 

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

> 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.

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.

[toc] | [prev] | [next] | [standalone]

#25724

In article <rtafon$4sh$1@dont-email.me>, Deloptes  <deloptes@gmail.com> wrote:
>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.

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?

[toc] | [prev] | [next] | [standalone]

#25629

Scott Alfter <scott@alfter.diespammersdie.us> wrote:
> 
> 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.

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

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

[toc] | [prev] | [next] | [standalone]

#25593

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

> Does anyone know if it is reasonably easy to get an RT kernel running on
> the Pi?
>
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
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#25594

On Thu, 7 Jan 2021 21:56:05 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:

>On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:
>
>> Does anyone know if it is reasonably easy to get an RT kernel running on
>> the Pi?
>>  
>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.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web