• RT Kernel

    From Folderol@3:770/3 to All on Thu Jan 7 17:26:20 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Folderol on Thu Jan 7 19:55:15 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Jim Jackson on Thu Jan 7 20:27:55 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Folderol on Thu Jan 7 20:35:13 2021
    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".

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Folderol on Thu Jan 7 21:56:05 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Martin Gregorie on Thu Jan 7 22:25:31 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Folderol on Thu Jan 7 23:37:36 2021
    On Thu, 07 Jan 2021 22:25:31 +0000, Folderol wrote:

    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!

    Does this mean that OS/9 doesn't have C++ yet?
    Pity, because its process scheduler beats the crap out of Linux.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jan Panteltje@3:770/3 to jj@franjam.org.uk on Fri Jan 8 06:55:58 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Deloptes@3:770/3 to Jan Panteltje on Fri Jan 8 09:56:13 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Deloptes on Fri Jan 8 09:27:35 2021
    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/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Martin Gregorie on Fri Jan 8 10:35:24 2021
    On Thu, 7 Jan 2021 23:37:36 -0000 (UTC)
    Martin Gregorie <martin@mydomain.invalid> wrote:

    On Thu, 07 Jan 2021 22:25:31 +0000, Folderol wrote:

    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!

    Does this mean that OS/9 doesn't have C++ yet?
    Pity, because its process scheduler beats the crap out of Linux.


    It's not that, it's more a matter of all the linux based dependencies, the GUI and the drivers for the Pi GPU. Then there's the theading. Yoshimi uses 4 separate threads. Highest priority for the audio, lowest for the CLI and GUI.

    --
    W J G

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Ahem A Rivet's Shot on Fri Jan 8 11:16:43 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Folderol on Fri Jan 8 11:31:23 2021
    On Fri, 08 Jan 2021 10:35:24 +0000, Folderol wrote:

    On Thu, 7 Jan 2021 23:37:36 -0000 (UTC)
    Martin Gregorie <martin@mydomain.invalid> wrote:

    On Thu, 07 Jan 2021 22:25:31 +0000, Folderol wrote:

    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!

    Does this mean that OS/9 doesn't have C++ yet?
    Pity, because its process scheduler beats the crap out of Linux.


    It's not that, it's more a matter of all the linux based dependencies,
    the GUI and the drivers for the Pi GPU. Then there's the theading.
    Yoshimi uses 4 separate threads. Highest priority for the audio, lowest
    for the CLI and GUI.

    Fair point.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Deloptes@3:770/3 to Folderol on Fri Jan 8 12:42:25 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Deloptes on Fri Jan 8 13:10:22 2021
    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"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Falken@1:123/115 to Deloptes on Fri Jan 8 10:49:50 2021
    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
    --- SBBSecho 3.12-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Folderol@3:770/3 to The Natural Philosopher on Fri Jan 8 16:28:53 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Charlie Gibbs@3:770/3 to Ahem A Rivet's Shot on Fri Jan 8 18:06:01 2021
    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)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Deloptes on Fri Jan 8 18:06:59 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to deloptes@gmail.com on Fri Jan 8 20:18:22 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Deloptes@3:770/3 to Scott Alfter on Fri Jan 8 21:36:39 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Folderol on Fri Jan 8 20:40:51 2021
    On 07/01/2021 17:26, Folderol 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.

    This was the second link in a google search for "Raspberry Pi real time extensions"

    https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-perfor mance-test

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Scott Alfter on Fri Jan 8 23:54:46 2021
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Folderol on Fri Jan 8 23:38:47 2021
    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.

    You don't say what you're actually doing. I gather that it's some
    software audio synth, and I don't know anything about that
    application. I'm guessing it's probably existing Linux software
    though, so suggestions such as building for bare-metal or another
    OS are presumably not worthwhile.

    There's a lot of info here, though not Pi-specific. Setting CPU
    frequency scaling to "performance" was important for my application
    (I also needed to disable video output on HDMI/Composite): https://wiki.linuxaudio.org/wiki/system_configuration

    Real-Time patches for the Linux Kernel:
    PREEMPT_RT: https://wiki.linuxfoundation.org/realtime/start
    Xenomai
    RTAI

    There is a PREEMPT_RT patched Linux distro for the Pi (this one
    worked alright for me on a Pi Zero and seems to be fairly actively
    developed, there might be others that I've forgotten about): https://guysoft.wordpress.com/2017/10/09/realtimepi/

    When I say "worked alright", I mean that it booted and probably
    did everything that could be expected from it. Fiddling with the
    scheduler settings and process priority still wasn't enough to
    prevent _any_ task switching by the scheduler during the
    timing-critical part of the code I was trying to run. Either
    PREEMPT_RT or one of the other projects had some special calls
    that controlled the kernel at a deeper level from user-space, but
    the documentation was too light for me to really figure it out.

    Projects such as LinuxCNC are possibly optimised for the real-time
    Linux kernel in more advanced ways that I couldn't figure out myself.

    In Debian/Devuan it may be possible to install a pre-built Real-Time
    patched kernel as a package, depending on which Pi model you're using
    (more details in these questions please!). Based on this page: https://wiki.debian.org/RaspberryPi

    This should work on the Pi3: https://packages.debian.org/buster/kernel/linux-image-4.19.0-8-rt-arm64

    And this with the Pi2: https://packages.debian.org/buster/kernel/linux-image-4.19.0-12-rt-armmp

    It doesn't look like there's a PREEMPT_RT armel package to suit the
    Pi 1 and Pi Zero. I'm not sure which Debian arch. the Pi4 is
    compatible with (arm64, like the Pi3?).

    [you can probably ignore the rest if you are trying to run audio
    software, because I doubt it will work]

    It's also possible on the Pi to disable all the system interrupts
    from user-space (newest versions of the example code are later in
    the thread):
    https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=52393

    I used a variation of that, where before disbling the interrupts
    and starting the protected bit of code, I checked that there weren't
    any "tick" interrupts due before it would be finished. That at the
    very least keeps the system clock accurate, if not also preventing
    other problems.

    RPi OS's default dwc_otg USB driver written by the Pi Foundation
    crashes when the FIQ (Fast Interrupt) is disabled while USB device
    is connected (testing on a Pi Zero). At one point there was an
    undocumented setting to tell it not to use FIQ, but it doesn't seem
    to work anymore. I'm using the alternative dwc2 driver (an "official"
    Linux one) which doesn't have that problem. You configure that by
    adding this line to /boot/config.txt:
    dtoverlay=dwc2,dr_mode=otg

    Note that disabling interrupts is probably only a good idea if your
    program is doing everything you need by itself at that time. I don't
    imagine that it would work if you're outputting audio through ALSA,
    or writing to a file, or anything else "Linuxy" at the same time.

    The "proper" way to disable interrupts is within a linux kernel
    driver module, using function calls such as local_irq_disable. But
    you're probably not going to want to split this program you're trying
    to run into one piece that runs in user-space and another that runs
    in kernel-space. I've been trying to do that for my application, and
    as of yesterday have given up for the moment.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Jan 8 22:54:22 2021
    On Thu, 7 Jan 2021 17:26:20 +0000, Folderol <general@musically.me.uk>
    declaimed the following:

    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.


    https://www.raspberrypi.org/forums/viewtopic.php?t=206750
    """
    This means that if you want to try it out you'll have to build it yourself.
    The general kernel-building instructions are here: https://www.raspberrypi.org/documentati ... uilding.md

    You will need to amend the instructions slightly - where it says

    Code: Select all

    git clone --depth=1 https://github.com/raspberrypi/linux

    you will need:

    Code: Select all

    git clone --depth=1 https://github.com/raspberrypi/linux -b rpi-4.14.y-rt
    """
    https://www.raspberrypi.org/documentation/linux/kernel/building.md



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to druck on Sat Jan 9 09:45:16 2021
    On Fri, 8 Jan 2021 20:40:51 +0000
    druck <news@druck.org.uk> wrote:

    On 07/01/2021 17:26, Folderol 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.

    This was the second link in a google search for "Raspberry Pi real time >extensions"

    https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-perfo rmance-test

    ---druck

    Thanks for that.
    Very interesting indeed.
    It seems there is far less difference overall than on Intel/AMD CPUs, and although latency is considerably improved it's at the cost of overall performance. For light to medium amounts of audio processing it's not worth the
    bother.

    --
    W J G

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Computer Nerd Kev on Sat Jan 9 10:05:11 2021
    On Fri, 8 Jan 2021 23:38:47 +0000 (UTC)
    not@telling.you.invalid (Computer Nerd Kev) wrote:

    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.

    You don't say what you're actually doing. I gather that it's some
    software audio synth, and I don't know anything about that
    application. I'm guessing it's probably existing Linux software
    though, so suggestions such as building for bare-metal or another
    OS are presumably not worthwhile.

    There's a lot of info here, though not Pi-specific. Setting CPU
    frequency scaling to "performance" was important for my application
    (I also needed to disable video output on HDMI/Composite): >https://wiki.linuxaudio.org/wiki/system_configuration

    Real-Time patches for the Linux Kernel:
    PREEMPT_RT: https://wiki.linuxfoundation.org/realtime/start
    Xenomai
    RTAI

    There is a PREEMPT_RT patched Linux distro for the Pi (this one
    worked alright for me on a Pi Zero and seems to be fairly actively
    developed, there might be others that I've forgotten about): >https://guysoft.wordpress.com/2017/10/09/realtimepi/

    Thanks for all this further information.
    It is indeed a software synthesiser, but a very unusual one. Whereas most of these either work on sound samples, or previously generated wavetables, Yoshimi
    creates everything on-the-fly from mathematical formulae. These can make dynamic changes within individual cycles, resulting in incredibly rich sounds.

    I do quite a lot of work on the overall structure but don't touch these sound 'engines' - I leave that to those with far better understanding or the mathematics!

    --
    W J G

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Jan 9 17:16:25 2021
    On Sat, 9 Jan 2021 10:05:11 +0000, Folderol <general@musically.me.uk>
    declaimed the following:

    Thanks for all this further information.
    It is indeed a software synthesiser, but a very unusual one. Whereas most of >these either work on sound samples, or previously generated wavetables, Yoshimi
    creates everything on-the-fly from mathematical formulae. These can make >dynamic changes within individual cycles, resulting in incredibly rich sounds.

    Sounds like something inspired by Casio Phase-Distortion (CZ series in the 80s). While there /was/ a cosine table stored in memory, the system adjusted the "phase" during readout (essentially reading part of the table faster than other parts while keeping the same total cycle time) to change
    the wave shape of the DCO (a square wave effectively was read the rising
    part of the curve so fast is looked vertical, then the top so slow it
    looked flat, fast drop, slow bottom...).

    https://en.wikipedia.org/wiki/Phase_distortion_synthesis


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to deloptes@gmail.com on Sun Jan 10 22:28:58 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)