What other real time apps have people worked on?
Lorem Ipsum <gnuarm.del...@gmail.com> writes:
What other real time apps have people worked on?A guy I knew made one of those gizmos with a row of LEDs on a motorized swinging rod, so that flashing the leds at the right times would show messages in the air. I don't know whether that was written in Forth
though. There is a good chance that it was.
Another buddy has made tons of cool realtime stuff with PIC
microprocessors but generally programmed in assembler. I don't think he
uses Forth at all.
I worked on a voice communication program (the realtime aspect was
keeping up with the sample rate of the audio converters) but it was in
C, long before I got interested in Forth.
I know people who have built RepRap 3D printers. Those use software for
motor control, I believe. Probably not in Forth.
Generally, processors and logic are now so cheap that it's often easier
to shovel stuff off to peripherals that in the old days would have been
done in software. I.e. most MCU's these days have UARTs, PWM, etc. that
might have formerly been done by software bit banging. That gets rid of
a fair amount of realtime code.
I don't agree that using UARTs and PWMs gets rid of real time coding.
It just works with longer time intervals, so the requirements are more relaxed.
I guess I should have asked, what real time Forth apps have people
worked on?
On Monday, December 19, 2022 at 12:31:08 AM UTC-5, Paul Rubin wrote:
Lorem Ipsum <gnuarm.del...@gmail.com> writes:
What other real time apps have people worked on?A guy I knew made one of those gizmos with a row of LEDs on a motorized swinging rod, so that flashing the leds at the right times would show messages in the air. I don't know whether that was written in Forth
though. There is a good chance that it was.
Another buddy has made tons of cool realtime stuff with PIC
microprocessors but generally programmed in assembler. I don't think he uses Forth at all.
I worked on a voice communication program (the realtime aspect was
keeping up with the sample rate of the audio converters) but it was in
C, long before I got interested in Forth.
I know people who have built RepRap 3D printers. Those use software for motor control, I believe. Probably not in Forth.
Generally, processors and logic are now so cheap that it's often easierI don't agree that using UARTs and PWMs gets rid of real time coding. It just works with longer time intervals, so the requirements are more relaxed.
to shovel stuff off to peripherals that in the old days would have been done in software. I.e. most MCU's these days have UARTs, PWM, etc. that might have formerly been done by software bit banging. That gets rid of
a fair amount of realtime code.
I guess I should have asked, what real time Forth apps have people worked on?
How often are Forth programs realtime applications?working.
Some time back I was playing with reading an LED display that was multiplexed. I needed to read the multiplexed driver lines and turn that into a number. Very real time. The hard part was figuring out the timing points, but eventually I got it
It didn't require timers or anything from the MCU, other than reading a port as fast as possible. So other than detecting the transitions, this was not so hard.
What other real time apps have people worked on?
How often are Forth programs realtime applications?
Some time back I was playing with reading an LED display that was >multiplexed. I needed to read the multiplexed driver lines and turn
that into a number. Very real time. The hard part was figuring out the >timing points, but eventually I got it working.
It didn't require timers or anything from the MCU, other than reading a
port as fast as possible. So other than detecting the transitions, this
was not so hard.
What other real time apps have people worked on?
--
Rick C.
How often are Forth programs realtime applications?working.
Some time back I was playing with reading an LED display that was multiplexed. I needed to read the multiplexed driver lines and turn that into a number. Very real time. The hard part was figuring out the timing points, but eventually I got it
It didn't require timers or anything from the MCU, other than reading a port as fast as possible. So other than detecting the transitions, this was not so hard.
What other real time apps have people worked on?
On 19/12/2022 04:04, Lorem Ipsum wrote:working.
How often are Forth programs realtime applications?
Some time back I was playing with reading an LED display that was multiplexed. I needed to read the multiplexed driver lines and turn that into a number. Very real time. The hard part was figuring out the timing points, but eventually I got it
It didn't require timers or anything from the MCU, other than reading a port as fast as possible. So other than detecting the transitions, this was not so hard.
What other real time apps have people worked on?
https://www.denisonmayesgroup.com/Rubicon-default.htm
The controller uses an 8MHz RTX2001 and ADSP2111 IIRC. The RTX code is
Forth generated with an MPE cross-compiler, the ADSP code is assembler.
It's hard real time, generating control waveforms etc, though the ADSP
does the PIDish control loop.
As you can see from the PC, this was a while back. One great feature of
a stack machine for real-time is interrupt response time - no need to
stack a load of stuff, it's already there. [Yes, I know things have
moved on a bit...]
One great feature of
a stack machine for real-time is interrupt response time - no need to
stack a load of stuff, it's already there.
I guess I should have asked, what real time Forth apps have people
worked on?
Clive Arthur <cl...@nowaytoday.co.uk> writes:
One great feature ofIf the stack items are in main memory, then yes, but then the machine
a stack machine for real-time is interrupt response time - no need to >stack a load of stuff, it's already there.
is always slow.
If the stack items are in a dedicated memory on-chip, as on Chuck
Moore's designs since at least the uP20, it can run a lot faster, but
for interrupts you need to make these stacks larger (just as some
register machines have a second register file for dealing with
interrupts); AFAIK Chuck Moore's designs since the uP20 do not support interrupts. And for context switching you need to save the whole
stack contents to main memory.
Lorem Ipsum <gnuarm.del...@gmail.com> writes:
I guess I should have asked, what real time Forth apps have peopleAlso I don't know if it counts, but lots of signal processing apps are
worked on?
real time. A sample arrives, put into a digital filter, and the filter output must be emitted at the same sample rate as the input.
On Tuesday, December 20, 2022 at 2:44:49 PM UTC-5, Paul Rubin wrote:Simpler stuff can be run on MCUs.
Lorem Ipsum <gnuarm.del...@gmail.com> writes:Sure, but not so commonly done in Forth. In fact, not so commonly done on anything other than DSP processors.
I guess I should have asked, what real time Forth apps have peopleAlso I don't know if it counts, but lots of signal processing apps are
worked on?
real time. A sample arrives, put into a digital filter, and the filter output must be emitted at the same sample rate as the input.
Clive Arthur <clive@nowaytoday.co.uk> writes:
One great feature of
a stack machine for real-time is interrupt response time - no need to
stack a load of stuff, it's already there.
If the stack items are in main memory, then yes, but then the machine
is always slow.
If the stack items are in a dedicated memory on-chip, as on Chuck
Moore's designs since at least the uP20, it can run a lot faster, but
for interrupts you need to make these stacks larger (just as some
register machines have a second register file for dealing with
interrupts); AFAIK Chuck Moore's designs since the uP20 do not support >interrupts. And for context switching you need to save the whole
stack contents to main memory.
- anton
As regard with interrupts. I can't see that there is anything that
has to be saved, operating on a stack machine, apart from the
registers the interrupt routine uses, which may be very restricted.
I'm not really sure, but inserting the hardware RDTSC timer
instruction in every sourceline, as I do for the iForth profiler,
slows down the code by a factor of three or four (at least).
gnuarm.del...@gmail.com schrieb am Mittwoch, 21. Dezember 2022 um 03:56:19 UTC+1:
On Tuesday, December 20, 2022 at 2:44:49 PM UTC-5, Paul Rubin wrote:
Lorem Ipsum <gnuarm.del...@gmail.com> writes:Sure, but not so commonly done in Forth. In fact, not so commonly done on anything other than DSP processors.
I guess I should have asked, what real time Forth apps have people worked on?Also I don't know if it counts, but lots of signal processing apps are real time. A sample arrives, put into a digital filter, and the filter output must be emitted at the same sample rate as the input.
Simpler stuff can be run on MCUs.
DSPs are specialized but otherwise "rather dumb". By far most of the work to build HW/SW circuits around DSPs means feeding them without delays or time jitter
and processing their outputs. This work requires programmable MCUs. I would not
call their task simpler. It is more the other way round.
Sorry, I should have mentioned that the sequence is CPUID RDTSC, where >CPUID forces serialization (necessary on multi-core).
On Wednesday, December 21, 2022 at 12:40:19 PM UTC+1, Marcel Hendrix wrote:
I'm not really sure, but inserting the hardware RDTSC timer
instruction in every sourceline, as I do for the iForth profiler,
slows down the code by a factor of three or four (at least).
Sorry, I should have mentioned that the sequence is CPUID RDTSC, where >CPUID forces serialization (necessary on multi-core).
-marcel
As Koopman argued: fast real-time forbids a cache
In article <2022Dec2...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Clive Arthur <cl...@nowaytoday.co.uk> writes:
One great feature of
a stack machine for real-time is interrupt response time - no need to >>stack a load of stuff, it's already there.
If the stack items are in main memory, then yes, but then the machine
is always slow.
If the stack items are in a dedicated memory on-chip, as on ChuckIn my implementation of pre emptive multi tasking each task has
Moore's designs since at least the uP20, it can run a lot faster, but
for interrupts you need to make these stacks larger (just as some
register machines have a second register file for dealing with >interrupts); AFAIK Chuck Moore's designs since the uP20 do not support >interrupts. And for context switching you need to save the whole
stack contents to main memory.
equivalent resources as the main task: stacks, user area, terminal
input buffer, plus a restricted (but arbitrary size) area where it can compile its own definitions.
As regard with interrupts. I can't see that there is anything that
has to be saved, operating on a stack machine, apart from the
registers the interrupt routine uses, which may be very restricted.
On Wednesday, December 21, 2022 at 10:44:52 AM UTC+1, none albert wrote:
[..]
As regard with interrupts. I can't see that there is anything thatAs Koopman argued: fast real-time forbids a cache, and without
has to be saved, operating on a stack machine, apart from the
registers the interrupt routine uses, which may be very restricted.
cache, performance will not be competitive.
I'm not really sure, but inserting the hardware RDTSC timer
instruction in every sourceline, as I do for the iForth profiler,
slows down the code by a factor of three or four (at least).
On Wednesday, December 21, 2022 at 4:04:06 AM UTC-5, minf...@arcor.de wrote:jitter" is pretty vague. The DSP chip is just a means of performing calculations rapidly, so specific timing goals can be met. Synchronization requires a particular mechanism. That's true regardless of the device implementing the DSP code.
gnuarm.del...@gmail.com schrieb am Mittwoch, 21. Dezember 2022 um 03:56:19 UTC+1:
On Tuesday, December 20, 2022 at 2:44:49 PM UTC-5, Paul Rubin wrote:
Lorem Ipsum <gnuarm.del...@gmail.com> writes:Sure, but not so commonly done in Forth. In fact, not so commonly done on anything other than DSP processors.
I guess I should have asked, what real time Forth apps have people worked on?Also I don't know if it counts, but lots of signal processing apps are real time. A sample arrives, put into a digital filter, and the filter output must be emitted at the same sample rate as the input.
Simpler stuff can be run on MCUs.
DSPs are specialized but otherwise "rather dumb". By far most of the work toNot sure what you are saying. MCUs are less adapted to implementing DSP algorithms. DSP chips are specifically designed for it. As such, DSP chips can implement more demanding applications, while MCUs can not. "feeding them without delays or time
build HW/SW circuits around DSPs means feeding them without delays or time jitter
and processing their outputs. This work requires programmable MCUs. I would not
call their task simpler. It is more the other way round.
Not at all sure what you mean by saying DSP chips are "rather dumb".
There are CPU devices that try to be a middle ground between DSP and MCUs. They have DSP CPUs at their core, but include the sort of peripheral devices that are commonly included with MCUs.
I read the documentation if the Orange pi one plus.
There is a counter, starting from power up. You can read it, from
whatever the four cores. How come serialisation come in?
gnuarm.del...@gmail.com schrieb am Mittwoch, 21. Dezember 2022 um 15:52:37 UTC+1:jitter" is pretty vague. The DSP chip is just a means of performing calculations rapidly, so specific timing goals can be met. Synchronization requires a particular mechanism. That's true regardless of the device implementing the DSP code.
On Wednesday, December 21, 2022 at 4:04:06 AM UTC-5, minf...@arcor.de wrote:
gnuarm.del...@gmail.com schrieb am Mittwoch, 21. Dezember 2022 um 03:56:19 UTC+1:
On Tuesday, December 20, 2022 at 2:44:49 PM UTC-5, Paul Rubin wrote:
Lorem Ipsum <gnuarm.del...@gmail.com> writes:Sure, but not so commonly done in Forth. In fact, not so commonly done on anything other than DSP processors.
I guess I should have asked, what real time Forth apps have people worked on?Also I don't know if it counts, but lots of signal processing apps are
real time. A sample arrives, put into a digital filter, and the filter
output must be emitted at the same sample rate as the input.
Simpler stuff can be run on MCUs.
DSPs are specialized but otherwise "rather dumb". By far most of the work toNot sure what you are saying. MCUs are less adapted to implementing DSP algorithms. DSP chips are specifically designed for it. As such, DSP chips can implement more demanding applications, while MCUs can not. "feeding them without delays or time
build HW/SW circuits around DSPs means feeding them without delays or time jitter
and processing their outputs. This work requires programmable MCUs. I would not
call their task simpler. It is more the other way round.
Not at all sure what you mean by saying DSP chips are "rather dumb".
There are CPU devices that try to be a middle ground between DSP and MCUs. They have DSP CPUs at their core, but include the sort of peripheral devices that are commonly included with MCUs.
This is obviously a misunderstanding. ISTM that you are very focussed on CPU technology,
please correct me if I am wrong. OTOH for me, those DSPs are just a small albeit central
part of a greater complex system that includes AD/DA converters, analog signal conditioning,
error correction, de-/normalization, perhaps managing short and long term storage,
perhaps compression and decompression, etc.
On Wednesday, December 21, 2022 at 6:40:19 AM UTC-5, Marcel Hendrix wrote:
As Koopman argued: fast real-time forbids a cache, and without
cache, performance will not be competitive.
That's an odd statement. The GA144 runs at up to 700 MIPS on a 180 nm process with no cache.
That's pretty competitive...
I'm not sure what you are getting at. The topic of this thread is Forth real time systems.
You made a statement that I asked for clarification on, and now you are branching the discussion.
What are you trying to discuss?
Lorem Ipsum <gnuarm.del...@gmail.com> writes:
On Wednesday, December 21, 2022 at 6:40:19 AM UTC-5, Marcel Hendrix wrote: >> As Koopman argued: fast real-time forbids a cache, and without
cache, performance will not be competitive.
That's an odd statement. The GA144 runs at up to 700 MIPS on a 180 nm process with no cache.Each core has a 64 words of memory, for a whopping total of 9216 words (20.25KB) for all 144 cores (but of course each core can only access
its own 64 words).
That's pretty competitive...
Is it? Can you name any design wins?
Even if the GA144 had been available in 2002, when 180nm was the
current thing, it would not have been competetive. E.g., the
Willamette (180nm Pentium 4) runs at up to 6000 MIPS on a 180nm
process, has an 8KB data cache, a 12K uop Trace cache, and 256KB L2
cache. The Palomino (180nm Athlon XP) runs at 5200MIPS on a 180nm
process and has 64KB data and 64KB instruction cache and 256KB L2
cache.
GA144 fans might argue that the Willamette and the Palomino have only
one core while the GA144 has 144, but nobody wants to program 144
cores, if each has access to only 64 words of memory.
gnuarm.del...@gmail.com schrieb am Mittwoch, 21. Dezember 2022 um 18:26:50 UTC+1:
I'm not sure what you are getting at. The topic of this thread is Forth real time systems.Isn't it obvious?
You made a statement that I asked for clarification on, and now you are branching the discussion.
What are you trying to discuss?
Try to build a RT Forth on a DSP alone.
IOW classic Forth multitasking
is monolithic.
When it was invented, multicores and distributed systems (outside big frames) did not exist yet. For synchronized realtime apps between different CPUs on a MCU board,
let alone networked (sub)systems, you need sync and inter-CPU communication mechanisms
(even if it is only a common beat or watchdog hardware line).
For big distributed systems Golangs goroutines went into the right direction. For small systems
Forth can be excellent, but it is missing many things for practical realtime apps on board level.
I don't mean single-CPU Arduinos and the like here.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:49:46 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |