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
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
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: Re: RT Kernel By: Deloptes to Jan Panteltje on Fri Jan 08 2021 09:56 am
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
Have you talked to Microware?
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
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
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
On a sunny day (Thu, 7 Jan 2021 20:35:13 -0000 (UTC)) it happened Jim Jackson wrote in :
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:
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.
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/
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
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
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
Fair point.
-- -- Martin | martin at Gregorie | gregorie dot org
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"
Good point. I hadn't thought of access time!
-- W J G
s/Hasket/Heskett/ He's a regular on the debian-users mailing list.
Ah, finally, someone else who realizes that payroll is a real-time application.
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, \ / | 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)
Depends over what time period your sensitivity is!
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(
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.