RT Kernel

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

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.

Reply to
Deloptes
Loading thread data ...

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

formatting link

---druck

Reply to
druck

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

formatting link

Real-Time patches for the Linux Kernel: PREEMPT_RT:

formatting link
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):

formatting link

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:

formatting link

This should work on the Pi3:

formatting link

And this with the Pi2:

formatting link

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

formatting link

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.

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

That's true for "usually", though it's not always the case:

formatting link

Also, with LinuxCNC:

formatting link

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

On Thu, 7 Jan 2021 17:26:20 +0000, Folderol declaimed the following:

formatting link
""" This means that if you want to try it out you'll have to build it yourself. The general kernel-building instructions are here:
formatting link
... uilding.md

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

Code: Select all

git clone --depth=1

formatting link

you will need:

Code: Select all

git clone --depth=1

formatting link
-b rpi-4.14.y-rt """
formatting link

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

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
Reply to
Folderol

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
Reply to
Folderol

On Sat, 9 Jan 2021 10:05:11 +0000, Folderol declaimed the following:

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

formatting link

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

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(

formatting link
Top-posting! \_^_/ >What's the most annoying thing on Usenet?

Reply to
Scott Alfter

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.