On 04/01/2023 21:17, BGB wrote:
> On 1/4/2023 11:57 AM, Niklas Holsti wrote:
>> On 2023-01-04 19:35, BGB wrote:
>>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>>
>>>>> Yup. Trying to port software for any other OS to classic MacOS was
>>>>> very
>>>>> time-consuming and frustrating. You had to call yield() frequently,
>>>>> but
>>>>> not so frequently as to waste time, since yield() was not quick. If
>>>>> you
>>>>> hadn't designed this in originally, it was hard to get right. In
>>>>> contrast,
>>>>> porting to current macOS is relatively easy.
>>>>
>>>> And the Mac enthusiasts were telling you that this was a good thing,
>>>> because preemptive multitasking was bad in some way. I forget
>>>> what the argument was, but it was mooted by Apple introducing
>>>> preemptive multitasking.
>>>>
>>>
>>> Preemptive multitasking is pros/cons.
>>> Good for a general user OS,
>>
>>
>> Yes.
>>
>>
>>> not as good for real-time systems.
>>
>>
>> I disagree, as would many others. Depends somewhat on the criticality
>> of the system (requirements to limit complexity).
>>
>
> Say...
>
> Pulsing IO pins at 10s of kHz with regular timing, or else a motor loses
> position, causing a rapidly spinning cutting tool to not be in the
> correct place in relation to a big chunk of steel or similar.

You don't do that purely in software. Even on a dedicated cycle-precise
microcontroller, you don't do that in software. You use hardware - a
PWM module on a microcontroller.

If you have PWM hardware, this is easy to do reliably and accurately.
That includes using a SoC running Linux - for example, the Raspberry Pi
has, I believe, 4 PWM pins. (SoC's often have such PWM peripherals for
backlight control.)

If you don't have PWM hardware, this is very difficult to do reliably at
these speeds. Remember, if you have signals at 10 kHz and you want 1%
precision, that means 1 microsecond timing resolution. Even on a
dedicated microcontroller this is nearly impossible without using
appropriate peripherals.

So the type of OS, if any, is pretty much irrelevant here.

(You can also make the PWM peripheral in FPGA code easily enough. But
unless you already have an FPGA on the system, or have very niche
requirements, it would be overkill for the purpose.)

>
> Many people doing "full custom" machines typically also seem to write
> their own CNC controller software (often using a microcontroller as the
> go-between).

Of course you control the motors with microcontrollers. The
microcontrollers might be hidden - inside a PLC, inside a motor driver,
inside an interface board. The use of "pure" DSPs or FPGAs for motor
control is long dead - microcontrollers do a better job for less money.

>
> I had before tried using a RasPi (for a few experimental machines), but
> task-scheduling within Linux interfered with my ability to get the
> desired level of timing stability.
>
>
> One can use an FPGA or microcontroller, but (if plugging into a PC) are
> mostly limited to options which have an FTDI chip or similar (other
> option being to use an RS232 serial port, which is at least still a
> little easier to find on a PC than a parallel port).
>
> Mostly, this matters in that it means one needs something like an
> LaunchPad or Arduino or something, rather than being able to use a bare
> AVR8 or MSP430 in a DIP socket (since, natively, these lack any way to
> communicate natively over USB; and would usually do so via an FTDI chip
> or similar on the board; with the microcontroller itself using an RS232
> interface or similar to talk to the FTDI chip).
>
> But, yeah, something like the RasPi Pico could also fall into this camp
> (and is arguably a bit more capable than a lot of the AVR based Arduino
> devices).
>

Arduinos and Raspberry Pico's are microcontrollers.

If you want to make a cake, you use a kitchen mixing machine. You don't
use a cement truck mixer, and you don't use an eggcup stirred with a
toothpick. Stop pissing around taking the worst choices from 30 years
ago combined with the worst choices from today - get the right tools for
the job. Use a microcontroller to run the motors, and a PC (Linux,
Windows, embedded, non-embedded, whatever you like) for the GUI.

And no one but the most stubborn and old-fashioned of hobby users cares
about DIP sockets for microcontrollers. If you want to do the soldering
in your kitchen, people do it all the time with much smaller packages -
just watch some youtube videos. And if the smaller packages bother you,
there are thousands of small pre-made microcontroller boards available
for under $10 with USB, PWMs and plenty of processing power all in
easy-to-use packages.

On 05/01/2023 01:17, BGB wrote:
> On 1/4/2023 1:19 PM, David Brown wrote:
>> On 04/01/2023 18:35, BGB wrote:
>>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>>
>>>>> Yup. Trying to port software for any other OS to classic MacOS was
>>>>> very
>>>>> time-consuming and frustrating. You had to call yield() frequently,
>>>>> but
>>>>> not so frequently as to waste time, since yield() was not quick. If
>>>>> you
>>>>> hadn't designed this in originally, it was hard to get right. In
>>>>> contrast,
>>>>> porting to current macOS is relatively easy.
>>>>
>>>> And the Mac enthusiasts were telling you that this was a good thing,
>>>> because preemptive multitasking was bad in some way. I forget
>>>> what the argument was, but it was mooted by Apple introducing
>>>> preemptive multitasking.
>>>>
>>>
>>> Preemptive multitasking is pros/cons.
>>> Good for a general user OS, not as good for real-time systems.
>>>
>>> Sort of issues also when one takes OS's not meant for real-time, and
>>> sort of fudges them into a real-time use-case (such as a CNC
>>> controller).
>>>
>>> Granted, yes, a background task monopolizing the CPU for an extended
>>> period of time would also be bad.
>>>
>>
>> I wonder if you are mixing "pre-emptive" with "time-slicing for tasks
>> of the same priority".  All RTOS's - which are designed for real-time
>> tasks (though you can have a real-time system without an OS at all) -
>> are pre-emptive.  At any time outside short critical regions used to
>> implement primitives like low-level mutexes, a running task can be
>> pre-empted by another task of higher priority that becomes runnable.
>> If higher priority tasks, perhaps triggered by an interrupt, cannot
>> pre-empt running lower priority tasks then you do not have a real-time
>> system.
>>
>
> I am familiar with real-time systems typically implemented more in terms
> of a tight-spinning event-dispatcher loop and a microsecond-accurate clock.
>
> Here, spinning in a loop (or otherwise failing to yeild) is not allowed
> (and a task taking more than a certain number of microseconds can be
> logged as an error).
>
> Though, this was typically with C level scheduling (via structs and
> function pointers), rather than full context switches.
>

That is known as "bare metal" or "main loop" programming - there is no
OS as such. And yes, this is a well-known method of making real-time
embedded systems, and has several advantages over OS-based systems. You
have tighter control over what is going on, you have easier debugging,
you have very easy data sharing (no need for locking or other
synchronisation mechanisms), you eliminate task-switch overhead, and you
need much less ram (since you have only one "thread" and therefore only
one stack).

On the other hand, you usually have poorer separation of tasks, and need
to manually track your state machines and the data needed between each
run of the task functions, which is more effort than with pre-emptive or
cooperative task switching. It can be harder to get accurate timing on
tasks - your speeds are limited by the worst-case run-times of any of
the tasks. You still need some data synchronisation between the task
functions and interrupt routines that handle peripherals and fast
reactions, and these interrupt routines may need to do more work than
you would have in an RTOS system (where the interrupt routine does the
most critical part then wakes a high-priority thread for the rest).

>
> Annoyingly, BJX2 is slow enough that holding 10us with a loop-based
> task-scheduler is not really workable in this case either (so, the
> timing sensitive parts may likely require FPGA logic).
>

No one does loop-based task functions with an expectation of faster than
about 1 millisecond resolution. Higher speeds are handled by timer
interrupt functions and/or hardware peripherals.

(There are also a few hybrid systems, like the XMOS devices, that
combine high-speed cycle-accurate processors with hardware
multi-threading and flexible timer and IO structures.)

>
> Luckily, holding stable <1us timing is a non-issue for an FPGA, and most
> of the other logic has looser requirements (if one excludes motor pulse
> generation, timing loosens to around 100us).
>
>
> With an MSP430, assuming the logic is "simple enough", one can get a
> stable 30us via a 32kHz timer interrupt.
>
> But, also sadly, BJX2's interrupt handling is slow enough that it can't
> really manage a 32kHz timer IRQ (despite having around a 3x higher clock
> speed than the MSP430).
>
> Well, unless maybe I added a dedicated ISR entry point specifically for
> a high-speed timer interrupt, and then have the interrupt handler being
> written in ASM (then one doesn't need to save/restore the entire
> register space).
>

There are a number of techniques used by other microcontroller
processors to improve on that. I could give you some details if you
like, but I have no idea whether they would be practical to implement in
your processor and toolchain.

>
>
> But, OTOH, something like an MSP430 isn't really powerful enough to run
> something like a G-Code interpreter. It is able to run something like a
> motor driver or similar though (so, say, I can use it effectively to run
> an H-Bridge driver and process step/direction pulses or PWM or similar,
> but running G-Code or managing multiple motors at the same time, not so
> much).
>
>
> AVR8 has more RAM and ROM (so can handle more complex logic), but code
> seems to run a little slower (relative to clock speed) if compared with
> an MSP430.
>

The MSP430 is a much more powerful processor than the AVR. If your AVR
is only running a little slower than the MSP430, you are doing something
very odd.

But given that 32-bit Cortex-M microcontrollers can be bought for as
little as $0.20 (in high enough quantity, of course), it is silly to use
an 8-bit or 16-bit processor when you need more processing power or memory.

>
>> On the other hand, if you have lots of tasks of the same priority, all
>> runnable, then there are definitely pros and cons as to whether you
>> allow time-slicing pre-emption.  It can be more efficient, and make
>> inter-process communication easier and caches misses lower if tasks
>> are only paused when they are ready for it (with a "yield()" call).
>> But then you need to write the tasks in a cooperative manner.
>>
>
> Writing purely cooperative scheduled tasks are what is assumed in this
> case.
>
> Granted, if one does write cooperative-scheduled tasks which yield at
> the right moment, then arguably a preemptive scheduler is (merely) a
> safety net for tasks which fail to yield in a timely manner.
>
> But, on an OS like Linux on a RasPi, calling "usleep(0)" almost
> invariably means control wont come back around until 200-500us later,
> which isn't really usable for the sorts of tasks I was using it for.
>

You are trying to shoot sparrows with a cannon, as they say in Norwegian.

And you are apparently doing it without understanding the possibilities
Linux offers. If you want fast response and low jitter for a program in
Linux, you should dedicate a cpu core to the task and put your critical
thread (or threads - but not many!) on that one core. Your jitter, and
things like the "usleep(0)" time, will drop dramatically. Use the
real-time kernel patches too to see another big drop. And of course
make sure your important thread is never blocked accessing the SD-Card -
any files used should be on tmpfs.

> Like, on the RasPi, there is almost invariably something else waiting in
> the background to eat a big chunk of clock-cycles.
>

Core affinities and locking are your friends to stop that. And of
course your real-time task should have a real-time priority.

>>
>> Ubuntu has done a lot to damage the reputation of Linux on desktops by
>> convincing people that they make the "standard" desktop Linux for
>> "ordinary" users, while giving them a design that tries to outdo
>> Microsoft in hideousness and inefficiency.
>>
>
> Basically my sentiment as well.
>
> I had generally preferred RedHat variants, like Fedora and CentOS.
> But, CentOS has nowhere near the mindshare of Ubuntu.
>

On Thursday, January 5, 2023 at 11:31:29 AM UTC+2, David Brown wrote:
> On 05/01/2023 01:17, BGB wrote:
> > On 1/4/2023 1:19 PM, David Brown wrote:
> >> On 04/01/2023 18:35, BGB wrote:
> >>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
> >>>> John Dallman <j...@cix.co.uk> schrieb:
> >>>>
> >>>>> Yup. Trying to port software for any other OS to classic MacOS was
> >>>>> very
> >>>>> time-consuming and frustrating. You had to call yield() frequently,
> >>>>> but
> >>>>> not so frequently as to waste time, since yield() was not quick. If
> >>>>> you
> >>>>> hadn't designed this in originally, it was hard to get right. In
> >>>>> contrast,
> >>>>> porting to current macOS is relatively easy.
> >>>>
> >>>> And the Mac enthusiasts were telling you that this was a good thing,
> >>>> because preemptive multitasking was bad in some way. I forget
> >>>> what the argument was, but it was mooted by Apple introducing
> >>>> preemptive multitasking.
> >>>>
> >>>
> >>> Preemptive multitasking is pros/cons.
> >>> Good for a general user OS, not as good for real-time systems.
> >>>
> >>> Sort of issues also when one takes OS's not meant for real-time, and
> >>> sort of fudges them into a real-time use-case (such as a CNC
> >>> controller).
> >>>
> >>> Granted, yes, a background task monopolizing the CPU for an extended
> >>> period of time would also be bad.
> >>>
> >>
> >> I wonder if you are mixing "pre-emptive" with "time-slicing for tasks
> >> of the same priority". All RTOS's - which are designed for real-time
> >> tasks (though you can have a real-time system without an OS at all) -
> >> are pre-emptive. At any time outside short critical regions used to
> >> implement primitives like low-level mutexes, a running task can be
> >> pre-empted by another task of higher priority that becomes runnable.
> >> If higher priority tasks, perhaps triggered by an interrupt, cannot
> >> pre-empt running lower priority tasks then you do not have a real-time
> >> system.
> >>
> >
> > I am familiar with real-time systems typically implemented more in terms
> > of a tight-spinning event-dispatcher loop and a microsecond-accurate clock.
> >
> > Here, spinning in a loop (or otherwise failing to yeild) is not allowed
> > (and a task taking more than a certain number of microseconds can be
> > logged as an error).
> >
> > Though, this was typically with C level scheduling (via structs and
> > function pointers), rather than full context switches.
> >
> That is known as "bare metal" or "main loop" programming - there is no
> OS as such. And yes, this is a well-known method of making real-time
> embedded systems, and has several advantages over OS-based systems. You
> have tighter control over what is going on, you have easier debugging,
> you have very easy data sharing (no need for locking or other
> synchronisation mechanisms), you eliminate task-switch overhead, and you
> need much less ram (since you have only one "thread" and therefore only
> one stack).
>
> On the other hand, you usually have poorer separation of tasks, and need
> to manually track your state machines and the data needed between each
> run of the task functions, which is more effort than with pre-emptive or
> cooperative task switching. It can be harder to get accurate timing on
> tasks - your speeds are limited by the worst-case run-times of any of
> the tasks. You still need some data synchronisation between the task
> functions and interrupt routines that handle peripherals and fast
> reactions, and these interrupt routines may need to do more work than
> you would have in an RTOS system (where the interrupt routine does the
> most critical part then wakes a high-priority thread for the rest).
> >
> > Annoyingly, BJX2 is slow enough that holding 10us with a loop-based
> > task-scheduler is not really workable in this case either (so, the
> > timing sensitive parts may likely require FPGA logic).
> >
> No one does loop-based task functions with an expectation of faster than
> about 1 millisecond resolution. Higher speeds are handled by timer
> interrupt functions and/or hardware peripherals.
>
>
> (There are also a few hybrid systems, like the XMOS devices, that
> combine high-speed cycle-accurate processors with hardware
> multi-threading and flexible timer and IO structures.)
> >
> > Luckily, holding stable <1us timing is a non-issue for an FPGA, and most
> > of the other logic has looser requirements (if one excludes motor pulse
> > generation, timing loosens to around 100us).
> >
> >
> > With an MSP430, assuming the logic is "simple enough", one can get a
> > stable 30us via a 32kHz timer interrupt.
> >
> > But, also sadly, BJX2's interrupt handling is slow enough that it can't
> > really manage a 32kHz timer IRQ (despite having around a 3x higher clock
> > speed than the MSP430).
> >
> > Well, unless maybe I added a dedicated ISR entry point specifically for
> > a high-speed timer interrupt, and then have the interrupt handler being
> > written in ASM (then one doesn't need to save/restore the entire
> > register space).
> >
> There are a number of techniques used by other microcontroller
> processors to improve on that. I could give you some details if you
> like, but I have no idea whether they would be practical to implement in
> your processor and toolchain.
> >
> >
> > But, OTOH, something like an MSP430 isn't really powerful enough to run
> > something like a G-Code interpreter. It is able to run something like a
> > motor driver or similar though (so, say, I can use it effectively to run
> > an H-Bridge driver and process step/direction pulses or PWM or similar,
> > but running G-Code or managing multiple motors at the same time, not so
> > much).
> >
> >
> > AVR8 has more RAM and ROM (so can handle more complex logic), but code
> > seems to run a little slower (relative to clock speed) if compared with
> > an MSP430.
> >
> The MSP430 is a much more powerful processor than the AVR. If your AVR
> is only running a little slower than the MSP430, you are doing something
> very odd.
>
> But given that 32-bit Cortex-M microcontrollers can be bought for as
> little as $0.20 (in high enough quantity, of course), it is silly to use
> an 8-bit or 16-bit processor when you need more processing power or memory.
> >
> >> On the other hand, if you have lots of tasks of the same priority, all
> >> runnable, then there are definitely pros and cons as to whether you
> >> allow time-slicing pre-emption. It can be more efficient, and make
> >> inter-process communication easier and caches misses lower if tasks
> >> are only paused when they are ready for it (with a "yield()" call).
> >> But then you need to write the tasks in a cooperative manner.
> >>
> >
> > Writing purely cooperative scheduled tasks are what is assumed in this
> > case.
> >
> > Granted, if one does write cooperative-scheduled tasks which yield at
> > the right moment, then arguably a preemptive scheduler is (merely) a
> > safety net for tasks which fail to yield in a timely manner.
> >
> > But, on an OS like Linux on a RasPi, calling "usleep(0)" almost
> > invariably means control wont come back around until 200-500us later,
> > which isn't really usable for the sorts of tasks I was using it for.
> >
> You are trying to shoot sparrows with a cannon, as they say in Norwegian.
>
> And you are apparently doing it without understanding the possibilities
> Linux offers. If you want fast response and low jitter for a program in
> Linux, you should dedicate a cpu core to the task and put your critical
> thread (or threads - but not many!) on that one core. Your jitter, and
> things like the "usleep(0)" time, will drop dramatically. Use the
> real-time kernel patches too to see another big drop. And of course
> make sure your important thread is never blocked accessing the SD-Card -
> any files used should be on tmpfs.
> > Like, on the RasPi, there is almost invariably something else waiting in
> > the background to eat a big chunk of clock-cycles.
> >
> Core affinities and locking are your friends to stop that. And of
> course your real-time task should have a real-time priority.
> >>
> >> Ubuntu has done a lot to damage the reputation of Linux on desktops by
> >> convincing people that they make the "standard" desktop Linux for
> >> "ordinary" users, while giving them a design that tries to outdo
> >> Microsoft in hideousness and inefficiency.
> >>
> >
> > Basically my sentiment as well.
> >
> > I had generally preferred RedHat variants, like Fedora and CentOS.
> > But, CentOS has nowhere near the mindshare of Ubuntu.
> >
> CentOS targets servers as a RHEL clone, not desktops. Scientific Linux,
> as I understand it, is the desktop RHEL clone. (There are probably
> others these days - I have not kept up.) Fedora is Red Hat's "cutting
> edge" desktop.
>
> I did run Fedora for a while, but I am more comfortable with "apt" and
> Debian as a base. I think it is primarily a matter of habit and
> familiarity. But I use pure Debian on servers or other headless
> systems, and Mint on desktops and laptops.
> >
> > Still using Win10 here; partly because MS sort of railroaded everyone
> > into needing to move to Win10 from Win7.
> It was not hard to resist - my Windows machine is Windows 7. The first
> thing I have always done with new Windows systems is update to the
> latest service packs, then disable all updates after that. I have no
> interest in an OS that automagically breaks itself and the programs I
> use by "upgrading". /I/ choose the system for my computers, not Microsoft.
>

On 1/5/2023 2:40 AM, David Brown wrote:
> On 04/01/2023 21:17, BGB wrote:
>> On 1/4/2023 11:57 AM, Niklas Holsti wrote:
>>> On 2023-01-04 19:35, BGB wrote:
>>>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>>>
>>>>>> Yup. Trying to port software for any other OS to classic MacOS was
>>>>>> very
>>>>>> time-consuming and frustrating. You had to call yield()
>>>>>> frequently, but
>>>>>> not so frequently as to waste time, since yield() was not quick.
>>>>>> If you
>>>>>> hadn't designed this in originally, it was hard to get right. In
>>>>>> contrast,
>>>>>> porting to current macOS is relatively easy.
>>>>>
>>>>> And the Mac enthusiasts were telling you that this was a good thing,
>>>>> because preemptive multitasking was bad in some way. I forget
>>>>> what the argument was, but it was mooted by Apple introducing
>>>>> preemptive multitasking.
>>>>>
>>>>
>>>> Preemptive multitasking is pros/cons.
>>>> Good for a general user OS,
>>>
>>>
>>> Yes.
>>>
>>>
>>>> not as good for real-time systems.
>>>
>>>
>>> I disagree, as would many others. Depends somewhat on the criticality
>>> of the system (requirements to limit complexity).
>>>
>>
>> Say...
>>
>> Pulsing IO pins at 10s of kHz with regular timing, or else a motor
>> loses position, causing a rapidly spinning cutting tool to not be in
>> the correct place in relation to a big chunk of steel or similar.
>
> You don't do that purely in software.  Even on a dedicated cycle-precise
> microcontroller, you don't do that in software.  You use hardware - a
> PWM module on a microcontroller.
>
> If you have PWM hardware, this is easy to do reliably and accurately.
> That includes using a SoC running Linux - for example, the Raspberry Pi
> has, I believe, 4 PWM pins.  (SoC's often have such PWM peripherals for
> backlight control.)
>
> If you don't have PWM hardware, this is very difficult to do reliably at
> these speeds.  Remember, if you have signals at 10 kHz and you want 1%
> precision, that means 1 microsecond timing resolution.  Even on a
> dedicated microcontroller this is nearly impossible without using
> appropriate peripherals.
>
> So the type of OS, if any, is pretty much irrelevant here.
>
> (You can also make the PWM peripheral in FPGA code easily enough.  But
> unless you already have an FPGA on the system, or have very niche
> requirements, it would be overkill for the purpose.)
>

Most of the PWM hardware is too limited in some areas:
One can usually set the frequency and duty cycle;
But, not really have it pulse for a specific number of pulses, or apply
ramp-up / ramp-down, ...

One effectively needs something like a PWM that keeps track of how many
pulses had been sent in each direction, and is also able to apply
programmable acceleration / deceleration ramps (so as to not lose steps
during start/stop or if changing direction).

Also, the ramps need to be synchronized across multiple motors such that
ideally the tool doesn't deviate from the toolpath during ramping.

>>
>> Many people doing "full custom" machines typically also seem to write
>> their own CNC controller software (often using a microcontroller as
>> the go-between).
>
> Of course you control the motors with microcontrollers.  The
> microcontrollers might be hidden - inside a PLC, inside a motor driver,
> inside an interface board.  The use of "pure" DSPs or FPGAs for motor
> control is long dead - microcontrollers do a better job for less money.
>

FWIW: A few of my earlier attempts (a "box robot" and "box mill") were
controlling the steppers using bare H-Bridge drivers (built from
discrete components). This used 4 pins per stepper.

The pre-built stepper drivers (with Step/Direction signaling) are a
little more convinient (and less error prone), but still require
reasonably accurate timing.

Comparably, servo drivers are more forgiving (they don't care quite as
much about the accuracy of the pulse timing), but are a lot more expensive.

Say:
NEMA23 stepper: ~ $30 .. $40
Stepper driver: ~ $20 .. $30 (depending on specifics).
$10 .. $16 if under 40V and under 4A.
But, had usually been using a 48V system, so...
Vs:
Hybrid Servo: ~ $200 .. $500

I am considering trying to build another (more specialized) stepper
driver, but mostly because I am thinking it may be possible to free-spin
a stepper like it were a BLDC by using Back-EMF sensing.

In this case, for free-spin mode would use 1-2ms PWM signaling, but was
also considering making it still accept Step/Dir control (so it can also
be used like a stepper, depending on what is needed at the moment).

Was probably going to use an MSP430 for this part.

Granted, something like "buy a servo" would probably be a "technically
better" option (rather than "try to build something to mimic the
behavior of a servo").

Basically, a line of experiments known as "Hey, could you possibly make
a big stepper 'not suck' as a CNC spindle?..."

With a traditional open-loop stepper driver, steppers suck really bad as
spindle motors, but in theory, little stops one from trying to spin them
more like a BLDC (nevermind if stepper motors are more designed for
low-speed high-torque use, rather than high RPM).

Secondary goal being to try to make it able to have properties more like
that of a servo (but hopefully cheaper).

For reasons, the idea currently involves using an 8-wire stepper wired
into a unipolar configuration though (partly to simplify the driver
construction as well as to try to make the Back-EMF sensing easier).
With a bipolar driver design, there isn't really a good way to
separately "sense" the phase voltages while also trying to spin the stepper.

Still waiting on parts at the moment.
For the experiment, will use a "much cheaper" 8-wire NEMA23 for now.
Was originally going to test with a NEMA34, but decided to test with a
NEMA23 instead.

>>
>> I had before tried using a RasPi (for a few experimental machines),
>> but task-scheduling within Linux interfered with my ability to get the
>> desired level of timing stability.
>>
>>
>> One can use an FPGA or microcontroller, but (if plugging into a PC)
>> are mostly limited to options which have an FTDI chip or similar
>> (other option being to use an RS232 serial port, which is at least
>> still a little easier to find on a PC than a parallel port).
>>
>> Mostly, this matters in that it means one needs something like an
>> LaunchPad or Arduino or something, rather than being able to use a
>> bare AVR8 or MSP430 in a DIP socket (since, natively, these lack any
>> way to communicate natively over USB; and would usually do so via an
>> FTDI chip or similar on the board; with the microcontroller itself
>> using an RS232 interface or similar to talk to the FTDI chip).
>>
>> But, yeah, something like the RasPi Pico could also fall into this
>> camp (and is arguably a bit more capable than a lot of the AVR based
>> Arduino devices).
>>
>
> Arduinos and Raspberry Pico's are microcontrollers.
>
>
> If you want to make a cake, you use a kitchen mixing machine.  You don't
> use a cement truck mixer, and you don't use an eggcup stirred with a
> toothpick.  Stop pissing around taking the worst choices from 30 years
> ago combined with the worst choices from today - get the right tools for
> the job.  Use a microcontroller to run the motors, and a PC (Linux,
> Windows, embedded, non-embedded, whatever you like) for the GUI.
>

There are tradeoffs.

One well-known company in the (professional) CNC space has apparently
been using M68020 chips for the past ~ 30 years; along with keeping
pretty much everything in the machine held in battery-backed SRAM (so,
if they screw up the battery-replacement process, such as by pulling
both batteries at the same time, it effectively does a factory reset on
the machine).

The "needs to use a 20 year old desktop PC" option is currently what one
gets for the FOSS based CNC controller options.

> And no one but the most stubborn and old-fashioned of hobby users cares
> about DIP sockets for microcontrollers.  If you want to do the soldering
> in your kitchen, people do it all the time with much smaller packages -
> just watch some youtube videos.  And if the smaller packages bother you,
> there are thousands of small pre-made microcontroller boards available
> for under $10 with USB, PWMs and plenty of processing power all in
> easy-to-use packages.
>

On 1/5/2023 3:31 AM, David Brown wrote:
> On 05/01/2023 01:17, BGB wrote:
>> On 1/4/2023 1:19 PM, David Brown wrote:
>>> On 04/01/2023 18:35, BGB wrote:
>>>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>>>
>>>>>> Yup. Trying to port software for any other OS to classic MacOS was
>>>>>> very
>>>>>> time-consuming and frustrating. You had to call yield()
>>>>>> frequently, but
>>>>>> not so frequently as to waste time, since yield() was not quick.
>>>>>> If you
>>>>>> hadn't designed this in originally, it was hard to get right. In
>>>>>> contrast,
>>>>>> porting to current macOS is relatively easy.
>>>>>
>>>>> And the Mac enthusiasts were telling you that this was a good thing,
>>>>> because preemptive multitasking was bad in some way. I forget
>>>>> what the argument was, but it was mooted by Apple introducing
>>>>> preemptive multitasking.
>>>>>
>>>>
>>>> Preemptive multitasking is pros/cons.
>>>> Good for a general user OS, not as good for real-time systems.
>>>>
>>>> Sort of issues also when one takes OS's not meant for real-time, and
>>>> sort of fudges them into a real-time use-case (such as a CNC
>>>> controller).
>>>>
>>>> Granted, yes, a background task monopolizing the CPU for an extended
>>>> period of time would also be bad.
>>>>
>>>
>>> I wonder if you are mixing "pre-emptive" with "time-slicing for tasks
>>> of the same priority".  All RTOS's - which are designed for real-time
>>> tasks (though you can have a real-time system without an OS at all) -
>>> are pre-emptive.  At any time outside short critical regions used to
>>> implement primitives like low-level mutexes, a running task can be
>>> pre-empted by another task of higher priority that becomes runnable.
>>> If higher priority tasks, perhaps triggered by an interrupt, cannot
>>> pre-empt running lower priority tasks then you do not have a
>>> real-time system.
>>>
>>
>> I am familiar with real-time systems typically implemented more in
>> terms of a tight-spinning event-dispatcher loop and a
>> microsecond-accurate clock.
>>
>> Here, spinning in a loop (or otherwise failing to yeild) is not
>> allowed (and a task taking more than a certain number of microseconds
>> can be logged as an error).
>>
>> Though, this was typically with C level scheduling (via structs and
>> function pointers), rather than full context switches.
>>
>
>
> That is known as "bare metal" or "main loop" programming - there is no
> OS as such.  And yes, this is a well-known method of making real-time
> embedded systems, and has several advantages over OS-based systems.  You
> have tighter control over what is going on, you have easier debugging,
> you have very easy data sharing (no need for locking or other
> synchronisation mechanisms), you eliminate task-switch overhead, and you
> need much less ram (since you have only one "thread" and therefore only
> one stack).
>
> On the other hand, you usually have poorer separation of tasks, and need
> to manually track your state machines and the data needed between each
> run of the task functions, which is more effort than with pre-emptive or
> cooperative task switching.  It can be harder to get accurate timing on
> tasks - your speeds are limited by the worst-case run-times of any of
> the tasks.  You still need some data synchronisation between the task
> functions and interrupt routines that handle peripherals and fast
> reactions, and these interrupt routines may need to do more work than
> you would have in an RTOS system (where the interrupt routine does the
> most critical part then wakes a high-priority thread for the rest).
>

AFAIK, a lot of the RTOS's were basically a glorified high-speed
scheduler and a filesystem driver and memory manager...

>>
>> Annoyingly, BJX2 is slow enough that holding 10us with a loop-based
>> task-scheduler is not really workable in this case either (so, the
>> timing sensitive parts may likely require FPGA logic).
>>
>
> No one does loop-based task functions with an expectation of faster than
> about 1 millisecond resolution.  Higher speeds are handled by timer
> interrupt functions and/or hardware peripherals.
>

The dispatcher loop was spinning with a microsecond timer.
On a RasPi, was able to get mostly down to ~ 10us, apart from the random
larger delays (usually just spinning in a tight loop if there was no
task that needs to run the moment).

This was using the RasPi 1 B+ (1x ARM11 at 700MHz).

Had later experimented with a RasPi 2 B+, but was still not able to
eliminate random delays in my tests.

Each time a task runs, if it needs to do more work later, it would add
itself back to the queue with a target time or delay (in microseconds).

The BJX2 core isn't fast enough to hold 10us in this way though (but,
40us, or ~ 2k cycle, is a little more doable).

For the variants I can shoe-horn onto an XC7S25, sort of need to strip
things down a bit (these versions basically revert the ISA back into a
more simplistic RISC-like form).

Well, and for reasons, a board with an XC7A100T would be expensive
overkill for a CNC controller.

Though, one could make a case that RV32I or similar would make a lot
more sense than BJX2 for this use-case.

>
> (There are also a few hybrid systems, like the XMOS devices, that
> combine high-speed cycle-accurate processors with hardware
> multi-threading and flexible timer and IO structures.)
>

Currently in the BJX2 core, there are two mechanisms:
A 1kHz timer IRQ;
A 1MHz counter;
A cycle counter (50MHz).

Unlike MSP430, can't currently do a 32kHz IRQ, because the normal ISR
handler mechanism can't keep up and a 32kHz timer IRQ would basically
eat the CPU.

>>
>> Luckily, holding stable <1us timing is a non-issue for an FPGA, and
>> most of the other logic has looser requirements (if one excludes motor
>> pulse generation, timing loosens to around 100us).
>>
>>
>> With an MSP430, assuming the logic is "simple enough", one can get a
>> stable 30us via a 32kHz timer interrupt.
>>
>> But, also sadly, BJX2's interrupt handling is slow enough that it
>> can't really manage a 32kHz timer IRQ (despite having around a 3x
>> higher clock speed than the MSP430).
>>
>> Well, unless maybe I added a dedicated ISR entry point specifically
>> for a high-speed timer interrupt, and then have the interrupt handler
>> being written in ASM (then one doesn't need to save/restore the entire
>> register space).
>>
>
> There are a number of techniques used by other microcontroller
> processors to improve on that.  I could give you some details if you
> like, but I have no idea whether they would be practical to implement in
> your processor and toolchain.
>

Dunno.

In any case, would need to keep everything under ~ 1 kilocycle per
interrupt (for a 32kHz IRQ).

Better still if kept under ~ 200 cycles per interrupt, but the issue
here is that this is at the bare edge of just saving and restoring the GPRs.

One could argue for doing banked GPRs in this case, which could at least
leave more cycles for doing actual work.

One other possibility I guess could be to use a set of multiple "one
shot timer" style IRQs, say:
Load a count-down into a one-shot timer;
After N microseconds, it fires off an interrupt;
If another IRQ is needed, the counter register can be reset.

Or, could be configurable as one-shot or a periodic repeat, say:
(19:0): Number of microseconds until timer fires;
(20): 0=One Shot, 1=Periodic (low bits give the repeat period).

This could avoid needing to hang a bunch of logic off of a 32kHz timer
or similar (but would limit the number of such events that could be
scheduled at a time).

If I implemented them sort of like how I did my FM Synth module, could
probably have 32 without too much cost, effectively by round-robin
cycling them.

Couldn't go too much higher, as at 64, it would take more than 1 us to
cycle through all the timers at 50 MHz.

>>
>>
>> But, OTOH, something like an MSP430 isn't really powerful enough to
>> run something like a G-Code interpreter. It is able to run something
>> like a motor driver or similar though (so, say, I can use it
>> effectively to run an H-Bridge driver and process step/direction
>> pulses or PWM or similar, but running G-Code or managing multiple
>> motors at the same time, not so much).
>>
>>
>> AVR8 has more RAM and ROM (so can handle more complex logic), but code
>> seems to run a little slower (relative to clock speed) if compared
>> with an MSP430.
>>
>
> The MSP430 is a much more powerful processor than the AVR.  If your AVR
> is only running a little slower than the MSP430, you are doing something
> very odd.
>

On 05/01/2023 22:28, BGB wrote:
> On 1/5/2023 3:31 AM, David Brown wrote:
>> On 05/01/2023 01:17, BGB wrote:

>>>
>>> Well, unless maybe I added a dedicated ISR entry point specifically
>>> for a high-speed timer interrupt, and then have the interrupt handler
>>> being written in ASM (then one doesn't need to save/restore the
>>> entire register space).
>>>
>>
>> There are a number of techniques used by other microcontroller
>> processors to improve on that.  I could give you some details if you
>> like, but I have no idea whether they would be practical to implement
>> in your processor and toolchain.
>>
>
> Dunno.
>
> In any case, would need to keep everything under ~ 1 kilocycle per
> interrupt (for a 32kHz IRQ).
>
> Better still if kept under ~ 200 cycles per interrupt, but the issue
> here is that this is at the bare edge of just saving and restoring the
> GPRs.
>
>
> One could argue for doing banked GPRs in this case, which could at least
> leave more cycles for doing actual work.
>
>
> One other possibility I guess could be to use a set of multiple "one
> shot timer" style IRQs, say:
>   Load a count-down into a one-shot timer;
>   After N microseconds, it fires off an interrupt;
>   If another IRQ is needed, the counter register can be reset.
>
> Or, could be configurable as one-shot or a periodic repeat, say:
>   (19:0): Number of microseconds until timer fires;
>   (20): 0=One Shot, 1=Periodic (low bits give the repeat period).
>
>
> This could avoid needing to hang a bunch of logic off of a 32kHz timer
> or similar (but would limit the number of such events that could be
> scheduled at a time).
>
> If I implemented them sort of like how I did my FM Synth module, could
> probably have 32 without too much cost, effectively by round-robin
> cycling them.
>
> Couldn't go too much higher, as at 64, it would take more than 1 us to
> cycle through all the timers at 50 MHz.
>
I'm not sure if I follow you entirely here.

For the "typical" microcontroller, you have lots of interrupt sources,
each with their own enable controls and interrupt vector. Smaller and
simpler microcontrollers have just one priority level, but bigger ones
might have 8 or 16 configurable levels. (So if you choose to make a
UART interrupt higher level than a timer interrupt, then the UART
interrupt will be taken even while handling the timer interrupt.)

You don't normally save all GPR's on an interrupt - you only save the
ones you need to. For many processors, toolchains use a keyword or
attribute for interrupt functions to tell the compiler to save registers
that are used, even the "non-volatile" (or "caller-saved") registers.
But the compiler won't save them unless they are used, so if you follow
good practice and keep your interrupt routines short and avoid other
calls, very few registers need to be saved.

For the Cortex-M devices, the processor automatically stacks
caller-saved registers. That means interrupt functions are just normal
functions - any callee-saved registers are saved as normal in the
function. Cortex-M microcontrollers typically have a 12 cycle interrupt
latency, between the interrupt line being triggered and the function
starting.

Obviously if the interrupt function leads to task switching, you'll have
to preserve a lot of registers, but that's usually handled via one
low-priority software interrupt vector.

An AVR program I wrote a long time ago had a timer interrupt that ran at
a rate of 40 processor clocks. That is, the interrupt was triggered,
the vector taken, the code run, the context restored, all in less than
40 clock cycles so that the processor could do other things in the main
loop. That code was all in C (albeit with dedicated registers to avoid
stacking and restoring).

On a 600 MHz Cortex-M7 processor I ran pre-emptive round-robin
scheduling on tasks that were switched out every microsecond, and the
overhead was not more than about 10% of the processor throughput. (This
was just for fun and testing.)

Some processors, such as earlier ARMs, have banks of registers to use
during interrupt handling in order to avoid saving and restoring lots of
registers.

Some processors use "lazy" register saving, especially as an option for
floating point registers (since FP register banks are often big, and are
often unused in interrupt routines).