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.
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.
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.
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!
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/
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?
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.