Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56858 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-04-08 20:53 +1000 |
| Last post | 2017-04-10 07:42 -1000 |
| Articles | 20 on this page of 151 — 21 participants |
Back to article view | Back to comp.lang.forth
polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-08 20:53 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-08 12:29 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 09:50 +1000
Re: polyForth multitasker question David Schultz <abuse@127.0.0.1> - 2017-04-09 19:25 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 10:52 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 08:58 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-15 10:39 +1000
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 11:12 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-10 18:22 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:17 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-11 03:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 14:37 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-09 18:05 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 15:50 -1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-10 07:47 +0200
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 12:20 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 09:11 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 04:20 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 10:53 +0100
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 11:24 +0100
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:05 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-11 14:27 +0100
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 07:08 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-11 18:06 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-11 18:58 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 13:57 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 18:02 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 19:47 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 21:22 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 02:57 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-12 23:17 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 00:13 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:43 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 19:34 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 19:57 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 02:45 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 21:28 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 07:53 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:44 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-14 02:01 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:28 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:23 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:46 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 11:31 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:23 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:06 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 08:13 -0500
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 14:12 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-14 09:30 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 08:46 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-15 13:07 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:27 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 18:18 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 13:53 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 11:34 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 11:31 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-14 12:14 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:46 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:48 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:50 -0700
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:39 +0200
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 11:48 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 22:07 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 16:47 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 11:36 -1000
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 17:07 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 14:17 -1000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 18:27 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 06:53 +0300
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 22:00 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 08:59 +0300
Re: polyForth multitasker question lehs <skydda.barnen@gmail.com> - 2017-04-15 22:19 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 17:26 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 09:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:13 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:28 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:27 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-16 14:45 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 17:50 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 12:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 13:27 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 03:49 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-18 13:47 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 14:30 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 20:58 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-18 11:47 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 19:19 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 04:34 -0500
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 02:00 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 18:10 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 01:41 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 21:38 +1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-19 10:56 +0200
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-19 07:22 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:10 -0700
Re: polyForth multitasker question stephen@mpeforth.com (Stephen Pelc) - 2017-04-18 09:35 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-18 08:01 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-18 09:03 -0700
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 11:07 -0500
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 10:59 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 19:13 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:36 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:27 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 04:32 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:15 -1000
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:07 +0200
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 15:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:36 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:48 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:36 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 14:55 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 15:27 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 23:45 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 21:13 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-17 16:57 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:08 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 20:29 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 15:34 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 19:43 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:03 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 23:50 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 03:55 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 01:38 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 11:50 -0400
Re: polyForth multitasker question john <anon@example.com> - 2017-04-15 12:03 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 12:41 +0000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:14 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:32 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 20:41 -0400
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 14:57 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 20:45 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:56 -0400
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:32 +0200
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:05 -0400
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-15 04:10 -0500
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 03:19 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-13 15:46 +0100
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-14 11:37 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:48 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 05:37 -0500
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 22:12 -0700
Multitasking with Forth processors Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 07:39 +0200
Re: Multitasking with Forth processors Paul Rubin <no.email@nospam.invalid> - 2017-04-11 22:58 -0700
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 03:00 -0400
Re: Multitasking with Forth processors albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:18 +0200
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 17:11 -0400
Re: Multitasking with Forth processors foxaudioresearch@gmail.com - 2017-04-12 13:50 -0700
Re: Multitasking with Forth processors "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:30 -1000
Re: Multitasking with Forth processors Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-14 12:20 +0100
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-14 16:47 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-10 07:42 -1000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 23:50 -0700 |
| Message-ID | <87mvbif9kd.fsf@nightsong.com> |
| In reply to | #57342 |
rickman <gnuarm@gmail.com> writes: > "Wake up the scheduler" is a term full of importance. Dig into that > if you want to understand what is going on. Not sure what you're getting at here. > How much power do you think it takes? What processor? What is the > power source? Meh, processor = something tiny, low powered 8 bitter. Though since we're talking about Forth, maybe a small ARM (Cortex M0) or the like. Power source = watch battery, so average power should be in the 1-digit microamps. > The point is there is a *lot* of ground to cover here. Of course you > don't run a scheduler as a wait loop if you don't need to or if you > don't have the power. But for an interrupt to "wake up" the scheduler > requires a mechanism to do that. Ok, I'm imagining a program something like this (untested): CREATE queue 16 CELLS ALLOT DOES> ( i -- addr ) cells + ; VARIABLE head 0 head ! VARIABLE tail 0 tail ! : incx ( var-addr -- var++ ) dup @ >r r@ 1+ $1F AND swap ! r> ; : empty? ( -- flag ) head @ tail @ = ; : log ( event -- ) head incx queue ! ; : pop ( -- event flag ) empty? IF 0 FALSE ELSE tail incx queue @ TRUE ; : zzz ( -- ) ... ; \ put the processor to sleep : wakeup ( -- ) ... ; \ cleanup ISR stack and re-awaken cpu keycode CONSTANT 37 \ some code to indicate that a key was pressed : key-isr ( -- ) keycode log wakeup ; \ record the keypress and wake up : dispatch ( event -- ) ... ; \ call event handler, with lookup or case stmt : event-loop ( -- ) BEGIN empty? IF zzz ELSE pop dispatch AGAIN ; This isn't a real tasker (just what I'd use for something with a few pushbuttons and other channels). But the idea is that the cpu is in a hard sleep til something interrupts. When the ISR runs, in this case it would re-activate the loop by diddling the return stack so that it looked like "zzz" had returned. The 16-element queue is just in case a few events happen at the same time or faster than the handlers. Maybe it should have some guards to recover from overflow if it happens, but it shouldn't. I've got a cool machined aluminum enclosure for a bike headlamp and have been wanting to someday make a bike light programmed in Forth. I figured that the code would be organized something like the above. The cpu would be stopped almost all the time, but would have handlers for pushbuttons and timers. So pushbutton detection and debouncing would happen in the button event handlers, which would cause more events for cleaned-up input that would adjust settings and light indicators. Timers would trigger software PWM for the main led, battery and temperature monitoring, and stuff like that. Obviously I haven't tested any of this but it seems reasonable from 10000 feet. If I actually ever do anything with it I'll deal with any snags as I encounter them. > BTW, waking up nearly any embedded processor I have used at a 10 Hz > rate would use barely any more power than the timer itself. OK, probably true. But, thinking of the GA144 etc. makes me want to avoid running the processor at all unless there's something to do.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-15 03:55 -0400 |
| Message-ID | <ocsjfv$eg2$1@dont-email.me> |
| In reply to | #57351 |
On 4/15/2017 2:50 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> "Wake up the scheduler" is a term full of importance. Dig into that >> if you want to understand what is going on. > > Not sure what you're getting at here. > >> How much power do you think it takes? What processor? What is the >> power source? > > Meh, processor = something tiny, low powered 8 bitter. Though since > we're talking about Forth, maybe a small ARM (Cortex M0) or the like. > Power source = watch battery, so average power should be in the 1-digit > microamps. > >> The point is there is a *lot* of ground to cover here. Of course you >> don't run a scheduler as a wait loop if you don't need to or if you >> don't have the power. But for an interrupt to "wake up" the scheduler >> requires a mechanism to do that. > > Ok, I'm imagining a program something like this (untested): > > CREATE queue 16 CELLS ALLOT DOES> ( i -- addr ) cells + ; > VARIABLE head 0 head ! VARIABLE tail 0 tail ! > : incx ( var-addr -- var++ ) dup @ >r r@ 1+ $1F AND swap ! r> ; > : empty? ( -- flag ) head @ tail @ = ; > : log ( event -- ) head incx queue ! ; > : pop ( -- event flag ) empty? IF 0 FALSE ELSE tail incx queue @ TRUE ; > > : zzz ( -- ) ... ; \ put the processor to sleep > : wakeup ( -- ) ... ; \ cleanup ISR stack and re-awaken cpu > > keycode CONSTANT 37 \ some code to indicate that a key was pressed > : key-isr ( -- ) keycode log wakeup ; \ record the keypress and wake up > > : dispatch ( event -- ) ... ; \ call event handler, with lookup or case stmt > > : event-loop ( -- ) BEGIN empty? IF zzz ELSE pop dispatch AGAIN ; > > This isn't a real tasker (just what I'd use for something with a few > pushbuttons and other channels). But the idea is that the cpu is in a > hard sleep til something interrupts. When the ISR runs, in this case it > would re-activate the loop by diddling the return stack so that it > looked like "zzz" had returned. The 16-element queue is just in case a > few events happen at the same time or faster than the handlers. Maybe > it should have some guards to recover from overflow if it happens, but > it shouldn't. > > I've got a cool machined aluminum enclosure for a bike headlamp and have > been wanting to someday make a bike light programmed in Forth. I > figured that the code would be organized something like the above. The > cpu would be stopped almost all the time, but would have handlers for > pushbuttons and timers. So pushbutton detection and debouncing would > happen in the button event handlers, which would cause more events for > cleaned-up input that would adjust settings and light indicators. > Timers would trigger software PWM for the main led, battery and > temperature monitoring, and stuff like that. > > Obviously I haven't tested any of this but it seems reasonable from > 10000 feet. If I actually ever do anything with it I'll deal with any > snags as I encounter them. > >> BTW, waking up nearly any embedded processor I have used at a 10 Hz >> rate would use barely any more power than the timer itself. > > OK, probably true. But, thinking of the GA144 etc. makes me want to > avoid running the processor at all unless there's something to do. I don't want to wade through a bunch of code and you complied by not supplying any that was useful. : wakeup ( -- ) ... ; \ cleanup ISR stack and re-awaken cpu What does this code do? I mean what does it mean to "re-awaken" CPU. Tell me what is going on in the CM0 CPU here. The processor is already awake or it wouldn't be executing code. Yes, this is one way to do it, but you need to figure out just how to manage the CPU to make this happen the way you are imagining it. There is a TON of detail. You also didn't give any estimate for what it takes to use a hardware timer to wake up the CPU via interrupt. It only takes the CPU a few instructions to determine there is nothing to do and it can go back to sleep or process the event that was created by the interrupt handler. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-15 01:38 -0700 |
| Message-ID | <87inm6f4lk.fsf@nightsong.com> |
| In reply to | #57353 |
rickman <gnuarm@gmail.com> writes: > What does this code do? I mean what does it mean to "re-awaken" > CPU. Tell me what is going on in the CM0 CPU here. The processor is > already awake or it wouldn't be executing code. Yes, this is one way > to do it, but you need to figure out just how to manage the CPU to > make this happen the way you are imagining it. There is a TON of > detail. I looked at the manual a while back and it seemed to me that the ISR would have to twiddle some registers to get the cpu out of super low power mode. > You also didn't give any estimate for what it takes to use a hardware > timer to wake up the CPU via interrupt. There's some instructions to set up the timer controller to do that. > It only takes the CPU a few instructions to determine there is nothing > to do and it can go back to sleep or process the event that was > created by the interrupt handler. Right, that's the idea. Most of the time the light is switched off and there's nothing to do, so the cpu sleeps. It has to be awake when the light is on, to PWM the light and maybe control a dc-dc converter. Obviously I haven't figured this all out yet, but I think I have a general picture.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-15 11:50 -0400 |
| Message-ID | <octfaf$352$1@dont-email.me> |
| In reply to | #57356 |
On 4/15/2017 4:38 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> What does this code do? I mean what does it mean to "re-awaken" >> CPU. Tell me what is going on in the CM0 CPU here. The processor is >> already awake or it wouldn't be executing code. Yes, this is one way >> to do it, but you need to figure out just how to manage the CPU to >> make this happen the way you are imagining it. There is a TON of >> detail. > > I looked at the manual a while back and it seemed to me that the ISR > would have to twiddle some registers to get the cpu out of super low > power mode. How does the ISR run if the CPU is still in super low power mode? >> You also didn't give any estimate for what it takes to use a hardware >> timer to wake up the CPU via interrupt. > > There's some instructions to set up the timer controller to do that. > >> It only takes the CPU a few instructions to determine there is nothing >> to do and it can go back to sleep or process the event that was >> created by the interrupt handler. > > Right, that's the idea. Most of the time the light is switched off and > there's nothing to do, so the cpu sleeps. It has to be awake when the > light is on, to PWM the light and maybe control a dc-dc converter. > Obviously I haven't figured this all out yet, but I think I have a > general picture. > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-15 12:03 +0100 |
| Message-ID | <MPG.335c0e5c1d041d5c98970b@news.virginmedia.com> |
| In reply to | #57351 |
In article <87mvbif9kd.fsf@nightsong.com>, no.email@nospam.invalid says... > I've got a cool machined aluminum enclosure for a bike headlamp and have > been wanting to someday make a bike light programmed in Forth. I > figured that the code would be organized something like the above. The > cpu would be stopped almost all the time, but would have handlers for > pushbuttons and timers. So pushbutton detection and debouncing would > happen in the button event handlers, which would cause more events for > cleaned-up input that would adjust settings and light indicators. > Timers would trigger software PWM for the main led, battery and > temperature monitoring, and stuff like that. > > Forth is pointless overkill. Buy yourself a microchip PIC from the 16bit family. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-15 12:41 +0000 |
| Message-ID | <2017Apr15.144101@mips.complang.tuwien.ac.at> |
| In reply to | #57342 |
rickman <gnuarm@gmail.com> writes:
>On 4/14/2017 10:43 PM, Paul Rubin wrote:
>> Right. THe ISR would just log the event that the button had been
>> pressed. The calculation then would be done by a scheduled task that
>> picked up the logged event. Thta's why the ISR would wake up the
>> scheduler.
>
>"Wake up the scheduler" is a term full of importance. Dig into that if
>you want to understand what is going on.
It may be full of importance to you, but I googled for it, and it
certainly is not an established term. So what did you want to say
here?
>> I'd want pressing a button to have quick response (in human terms) if
>> possible, like 100 msec. Are you saying to wake up the cpu at 10 hz, 24
>> hours a day? That doesn't sound like a good use of power. I'd only
>> want to wake it when someone actually presses a button, which might be
>> months.
>
>How much power do you think it takes? What processor? What is the
>power source?
The power source for a remote control ist typically a pair of AAA
batteries.
For a MSP430F2xx, supposedly the "World's Lowest-Power MCU",
<http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slay015>
says on Page 4: 100nA LPM4, +WDT 600nA (watchdog timer). So just the
ability to wake up on a timer at 10Hz costs a factor of 6 in power
consumption. Running at 1MIPS takes 300uA for the MSP430F2001 and
515uA for the MSP430F2619, i.e., 3000-5150 times as much as the LPM4
power consumption. If your interrupt takes 50us to determine that no
key has been pressed, and to set up the watchdog timer to wake the MCU
again in 100ms, that adds another 150nA (MSP430F2001) or 257nA
(MSP430F2619) of average power consumption (more than the LPM4 would
consume), reducing battery life even further.
>But for an interrupt to "wake up" the scheduler
>requires a mechanism to do that.
A simple way would be that the scheduler performs a halt instruction
when all tasks wait for some event, and any interrupt causes it to
continue execution, i.e., wakes up the scheduler. Of course, more
complicated schemes are possible (e.g., Intel defines a bunch of C and
S states, with different costs of entering and exiting).
>BTW, waking up nearly any embedded processor I have used at a 10 Hz rate
>would use barely any more power than the timer itself.
True in the example above, but the timer itself costs a lot of power,
and is unnecessary in a remote control.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-15 12:14 -0400 |
| Message-ID | <octgn3$8qm$1@dont-email.me> |
| In reply to | #57371 |
On 4/15/2017 8:41 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 4/14/2017 10:43 PM, Paul Rubin wrote: >>> Right. THe ISR would just log the event that the button had been >>> pressed. The calculation then would be done by a scheduled task that >>> picked up the logged event. Thta's why the ISR would wake up the >>> scheduler. >> >> "Wake up the scheduler" is a term full of importance. Dig into that if >> you want to understand what is going on. > > It may be full of importance to you, but I googled for it, and it > certainly is not an established term. So what did you want to say > here? There are many ways to do wake up a process. Just using the term doesn't expose the complexity. I believe that is what the thread was discussing, not the details of interrupts, but the details of using a scheduler. >>> I'd want pressing a button to have quick response (in human terms) if >>> possible, like 100 msec. Are you saying to wake up the cpu at 10 hz, 24 >>> hours a day? That doesn't sound like a good use of power. I'd only >>> want to wake it when someone actually presses a button, which might be >>> months. >> >> How much power do you think it takes? What processor? What is the >> power source? > > The power source for a remote control ist typically a pair of AAA > batteries. > > For a MSP430F2xx, supposedly the "World's Lowest-Power MCU", > <http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slay015> > says on Page 4: 100nA LPM4, +WDT 600nA (watchdog timer). So just the > ability to wake up on a timer at 10Hz costs a factor of 6 in power > consumption. Running at 1MIPS takes 300uA for the MSP430F2001 and > 515uA for the MSP430F2619, i.e., 3000-5150 times as much as the LPM4 > power consumption. If your interrupt takes 50us to determine that no > key has been pressed, and to set up the watchdog timer to wake the MCU > again in 100ms, that adds another 150nA (MSP430F2001) or 257nA > (MSP430F2619) of average power consumption (more than the LPM4 would > consume), reducing battery life even further. The timer will be running any time you have a time sensitive task, no? So the power used to wake up at 10 Hz by your numbers is just 150 nA. >> But for an interrupt to "wake up" the scheduler >> requires a mechanism to do that. > > A simple way would be that the scheduler performs a halt instruction > when all tasks wait for some event, and any interrupt causes it to > continue execution, i.e., wakes up the scheduler. Of course, more > complicated schemes are possible (e.g., Intel defines a bunch of C and > S states, with different costs of entering and exiting). Yup, there are many ways to skin a cat. >> BTW, waking up nearly any embedded processor I have used at a 10 Hz rate >> would use barely any more power than the timer itself. > > True in the example above, but the timer itself costs a lot of power, > and is unnecessary in a remote control. In a remote control you don't need multiple tasks or interrupts. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-15 17:32 -0700 |
| Message-ID | <877f2lfb08.fsf@nightsong.com> |
| In reply to | #57375 |
rickman <gnuarm@gmail.com> writes: > The timer will be running any time you have a time sensitive task, no? > So the power used to wake up at 10 Hz by your numbers is just 150 nA. In the keypad example there is no activity at all until someone presses a key. So no need to wake up at 10 hz. You can stop all the timers. When someone presses a key you would want to start a timer to be able to handle inputting the entry code (or timing out), debouncing, etc.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-15 20:41 -0400 |
| Message-ID | <ocueeg$84v$1@dont-email.me> |
| In reply to | #57404 |
On 4/15/2017 8:32 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> The timer will be running any time you have a time sensitive task, no? >> So the power used to wake up at 10 Hz by your numbers is just 150 nA. > > In the keypad example there is no activity at all until someone presses > a key. So no need to wake up at 10 hz. You can stop all the timers. > When someone presses a key you would want to start a timer to be able to > handle inputting the entry code (or timing out), debouncing, etc. You are right. If all you need to do is detect the key press then using a single interrupt and no main body of code other than to initialize the system is needed. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-17 14:57 +0000 |
| Message-ID | <2017Apr17.165727@mips.complang.tuwien.ac.at> |
| In reply to | #57375 |
rickman <gnuarm@gmail.com> writes:
>On 4/15/2017 8:41 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 4/14/2017 10:43 PM, Paul Rubin wrote:
>>>> Right. THe ISR would just log the event that the button had been
>>>> pressed. The calculation then would be done by a scheduled task that
>>>> picked up the logged event. Thta's why the ISR would wake up the
>>>> scheduler.
>>>
>>> "Wake up the scheduler" is a term full of importance. Dig into that if
>>> you want to understand what is going on.
>>
>> It may be full of importance to you, but I googled for it, and it
>> certainly is not an established term. So what did you want to say
>> here?
>
>There are many ways to do wake up a process.
This is not about waking up the process, it's about waking up the
scheduler. The scheduler may have found that all tasks are waiting
for an interrupt (the run queue is empty), and may then execute a HALT
instruction, putting the processor to sleep. When an interrupt comes,
it wakes up the processor, and the processor first performs the
interrupt handler, which, say puts a task in the run queue; on
returning from the interrupt, the CPU finds itself in the scheduler
behind the HALT, and then the scheduler looks at the run queue and
switches to the first task there.
>>>> I'd want pressing a button to have quick response (in human terms) if
>>>> possible, like 100 msec. Are you saying to wake up the cpu at 10 hz, 24
>>>> hours a day? That doesn't sound like a good use of power. I'd only
>>>> want to wake it when someone actually presses a button, which might be
>>>> months.
>>>
>>> How much power do you think it takes? What processor? What is the
>>> power source?
>>
>> The power source for a remote control ist typically a pair of AAA
>> batteries.
>>
>> For a MSP430F2xx, supposedly the "World's Lowest-Power MCU",
>> <http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slay015>
>> says on Page 4: 100nA LPM4, +WDT 600nA (watchdog timer). So just the
>> ability to wake up on a timer at 10Hz costs a factor of 6 in power
>> consumption. Running at 1MIPS takes 300uA for the MSP430F2001 and
>> 515uA for the MSP430F2619, i.e., 3000-5150 times as much as the LPM4
>> power consumption. If your interrupt takes 50us to determine that no
>> key has been pressed, and to set up the watchdog timer to wake the MCU
>> again in 100ms, that adds another 150nA (MSP430F2001) or 257nA
>> (MSP430F2619) of average power consumption (more than the LPM4 would
>> consume), reducing battery life even further.
>
>The timer will be running any time you have a time sensitive task, no?
>So the power used to wake up at 10 Hz by your numbers is just 150 nA.
On a remote control, most of the time you have no time sensitive task,
and unless you make the mistake of polling the keys at 10Hz, you can
turn off the timer.
>> True in the example above, but the timer itself costs a lot of power,
>> and is unnecessary in a remote control.
>
>In a remote control you don't need multiple tasks or interrupts.
You want the keys to wake the CPU, so you want the keys to interrupt
the CPU. You can turn the sending of the IR data into a separate
task, or just have one task that checks what key is pressed and then
sends the appropriate signal, and only listens to the keyboard again
when it's done with the signal (probably simpler).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 20:45 -0700 |
| Message-ID | <3f734204-0f5a-41aa-ae0f-aa970676f408@googlegroups.com> |
| In reply to | #57341 |
On Friday, April 14, 2017 at 7:43:11 PM UTC-7, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > They ended up writing the code 100% in interrupts. There was no main > > body of code. Our local software guy who was brought into the project > > late saw that and blew a gasket. > > That's a style that I've heard of. If all the stuff in the ISRs was > quick enough I thought it was considered ok. This technique should by okay most of the time. The story sounds like something that Rickman made up. Everybody got fired because they used this technique, and the program was rewritten from scratch? If the program was working, then that wouldn't have happened. Rickman didn't say that the board was not working or losing data. On a lot of processors, you have multiple kinds of interrupts, each with its own priority. So, you put the time-consuming stuff in a low-priority ISR. This technique could be problematic though if you only have a few kinds of interrupts (the 65c02 only had IRQ and NMI) and so all the interrupts are at the same priority --- afaik, this has not been an issue since the 1980s --- I'm not very familiar with modern processors though, so maybe it is still an issue, at least on some of the low-end processors.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 23:56 -0400 |
| Message-ID | <ocs5fq$dhn$1@dont-email.me> |
| In reply to | #57343 |
On 4/14/2017 11:45 PM, hughaguilar96@gmail.com wrote: > On Friday, April 14, 2017 at 7:43:11 PM UTC-7, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> They ended up writing the code 100% in interrupts. There was no >>> main body of code. Our local software guy who was brought into >>> the project late saw that and blew a gasket. >> >> That's a style that I've heard of. If all the stuff in the ISRs >> was quick enough I thought it was considered ok. > > This technique should by okay most of the time. > > The story sounds like something that Rickman made up. Everybody got > fired because they used this technique, and the program was rewritten > from scratch? If the program was working, then that wouldn't have > happened. Rickman didn't say that the board was not working or losing > data. God Hugh, you make up so much applesauce. I never said anyone got fired because of this program. I never said the program was rewritten from scratch. But it should be no surprise that you fill in the gaps to suit your twisted thinking and then attribute it to me. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-15 14:32 +0200 |
| Message-ID | <oct3to$vei$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57337 |
In article <ocrpc8$nqb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 4/14/2017 5:55 PM, Paul Rubin wrote: > >In the case of a button being pressed the requirement in some cases was >to perform a calculation that could take considerable time (from an MCU >point of view). In the general case you would not want to do that in an >interrupt routine. That is the party line, and I don't get it. Anyway,the code that positions the mirror in the delay line of the ESO telescopes in Paranal has most of the calculations on one of the interrupt levels. (A 68K system with several priorities of interrupts). I know, because I designed and wrote that software. The design critera of the moving mirror (about 10 nm rms) were met. No complaints so far. Yes that's on the nanometer, microsecond scale. > Tying the scheduler to an interrupt is a poor way to >use an interrupt and makes it hard to do anything time critical using >the other interrupts. The scheduler runs infrequently for tasks that >are low priority and have little timing consequence. It all boils down to knowing the hardware and knowing the requirements and making the best of it. > >I don't know if you are that unfamiliar with the use of interrupts or if >you are just pulling my chain. That is harsh to say. Not everything one learns at school pans out in practice. > >Rick C Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-15 12:05 -0400 |
| Message-ID | <octg6l$6v2$1@dont-email.me> |
| In reply to | #57367 |
On 4/15/2017 8:32 AM, Albert van der Horst wrote: > In article <ocrpc8$nqb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 4/14/2017 5:55 PM, Paul Rubin wrote: >> >> In the case of a button being pressed the requirement in some cases was >> to perform a calculation that could take considerable time (from an MCU >> point of view). In the general case you would not want to do that in an >> interrupt routine. > > That is the party line, and I don't get it. Anyway,the code that > positions the mirror in the delay line of the ESO telescopes > in Paranal has most of the calculations on one of the interrupt > levels. > (A 68K system with several priorities of interrupts). > I know, because I designed and wrote that software. > The design critera of the moving mirror (about 10 nm rms) were met. > No complaints so far. > Yes that's on the nanometer, microsecond scale. If the tasks are limited and your priorities simple, you can do anything you wish with interrupts. But when changes are required having lengthy code in interrupts can make it hard to get work done elsewhere. >> Tying the scheduler to an interrupt is a poor way to >> use an interrupt and makes it hard to do anything time critical using >> the other interrupts. The scheduler runs infrequently for tasks that >> are low priority and have little timing consequence. > > It all boils down to knowing the hardware and knowing the requirements > and making the best of it. That is a way of saying each design is special and you have no reason to use a method. Ok, if that's the way you want to use interrupts, fine. But I bet that's not the way you design otherwise. Most of us develop methods to reduce the problem space and simplify solutions. That is much easier than starting from scratch with every design. FPGAs, for example, use synchronous design techniques rather than support any sort of logic you choose to work with. That puts some limitations on what you can do, but it make 99.99% of designs *much* easier to complete. In the same way using interrupts as ways to complete minimal high speed, short latency tasks makes it easier to coordinate multiple interrupts. Putting more code into an interrupt handler can work if your design is not complex, but don't try later to come back and add more interrupts at lower priorities. It can be very difficult because the essential tasks were not separated from the rest of the connected processing. >> I don't know if you are that unfamiliar with the use of interrupts or if >> you are just pulling my chain. > > That is harsh to say. Not everything one learns at school pans > out in practice. School? I don't recall there even being anything in school about this. I learned about interrupts from reading trade magazines and experience. Same with many of the more complex, real world issues in design. We were taught nothing about meta-stability in school, I learned from app notes in FPGAs. Heck, I recall a system at a defense contractor that processed radar pulses that probably had a problem with meta-stability. My superiors likely didn't know anything about it. Using interrupts doesn't have a hard, fast set of rules, but the rules people have learned make it so much easier to use interrupts without having to start from scratch to analyze. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-15 04:10 -0500 |
| Message-ID | <mPGdnUIHxbsMfmzFnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #57329 |
Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: >> the remaining part of the code can be handled by the scheduler waking >> a process on a periodic basis.. The point is the scheduler really >> shouldn't be getting in the path of interrupts other than the >> scheduling timer. There is no need and it just complicates things. > > Why wake a process on a periodic basis if nothing is happening? > Example: an entry keypad on a door, that gets used a few times a day. > There's no reason to burn power waking up every few msec to see if a > button has been pressed. Instead, pressing a button raises an interrupt > that wakes up the scheduler, which then figures out which task is > waiting on the button press. I think that's the wrong way to do it. Let the interrupt handler for the button press wake the task which cares about the button. Theres should only be one such task, and the interrupt handler should know (or be able to find out) which task that is. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-13 03:19 -0700 |
| Message-ID | <baae8ece-10eb-4f85-b45c-9dee0a20fedf@googlegroups.com> |
| In reply to | #57213 |
There nothing to prevent different power management schemes. Forth inc implemented power save in the Forth Next routine to provide control on a very thin time slice but never in the middle of the working code. Or by simply timing Pause you can measure CpU load and go to sleep if needed. ( From my head) : Pulse ( -- n) timer@ Pause timer@ swap - ; : ?sleep. ( --) Pulse threshold < if Gotosleep then ;
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-13 15:46 +0100 |
| Message-ID | <oco2qe$eru$2@dont-email.me> |
| In reply to | #57224 |
On 4/13/2017 11:19, foxaudioresearch@gmail.com wrote: > There nothing to prevent different power management schemes. Forth inc implemented power save in the Forth Next routine to provide control on a very thin time slice but never in the middle of the working code. > > Or by simply timing Pause you can measure CpU load and go to sleep if needed. > > ( From my head) > > : Pulse ( -- n) timer@ Pause timer@ swap - ; > > : ?sleep. ( --) Pulse threshold < if Gotosleep then ; > You are overtrimming (or using the ghastly Google Groups to reply). I don't have a clue to what or whom you are replying. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-14 11:37 -0700 |
| Message-ID | <0313b597-2181-486b-a14a-ae5dc2ffcf94@googlegroups.com> |
| In reply to | #57236 |
On Thursday, April 13, 2017 at 10:46:33 AM UTC-4, Alex wrote: > On 4/13/2017 11:19, foxaudioresearch@gmail.com wrote: > > There nothing to prevent different power management schemes. Forth inc implemented power save in the Forth Next routine to provide control on a very thin time slice but never in the middle of the working code. > > > > Or by simply timing Pause you can measure CpU load and go to sleep if needed. > > > > ( From my head) > > > > : Pulse ( -- n) timer@ Pause timer@ swap - ; > > > > : ?sleep. ( --) Pulse threshold < if Gotosleep then ; > > > > You are overtrimming (or using the ghastly Google Groups to reply). I > don't have a clue to what or whom you are replying. > > -- > Alex Very sorry. iPad and early mornings. I was replying to Paul Rubin who said: "Most schedulers these days have a priority queue of pending timeouts, so the hardware timer is set to wake up when the next timeout is due, the timeout is popped from the queue and serviced, and the scheduler then figures out how long to sleep til the next timeout is due. The scheduler probably also has to wake on interrupts. "
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 09:48 -1000 |
| Message-ID | <ou6dnQFt-aeSS3LFnZ2dnUU7-LHNnZ2d@supernews.com> |
| In reply to | #57224 |
On 4/13/17 12:19 AM, foxaudioresearch@gmail.com wrote: > There nothing to prevent different power management schemes. Forth inc implemented power save in the Forth Next routine to provide control on a very thin time slice but never in the middle of the working code. No, it was the tasker loop that put the processor in sleep mode providing no other tasks were active, until an interrupt signaled completion of whatever operation it was waiting on or a new request (such as a key press). NEXT is not involved (actually, SwiftX doesn't have a NEXT, as it compiles code). > Or by simply timing Pause you can measure CpU load and go to sleep if needed. > > ( From my head) > > : Pulse ( -- n) timer@ Pause timer@ swap - ; > > : ?sleep. ( --) Pulse threshold < if Gotosleep then ; > Your Pulse routine is polling, so the cpu would be active. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-13 05:37 -0500 |
| Message-ID | <dLKdndu3zd9GyXLFnZ2dnUU7-enNnZ2d@supernews.com> |
| In reply to | #57203 |
foxaudioresearch@gmail.com wrote: > > The overall tasking switching in a traditional Forth tasker is actually > handled by the I/O words. > > For example the Forth word emit in a multi-tasking system looks like: > > : EMIT (EMIT) PAUSE ; > > So you output a character and yield to the next task. FYI, given that we're talking about polyFORTH, that's : EMIT 'S 1 TYPE ; or something similar. TYPE always does a PAUSE or a STOP, no matter how it's implemented, so it always allows other tasks to run. If it's a serial terminal, a byte is written to the UART output buffer and the task stops; the last TX interrupt (in the case of EMIT, the only TX interrupt) awakens the task. Likewise for KEY. All of this makes for the most efficient I/O system that I have ever encountered. It enabled a dozen terminals to be run on an IBM PC, with decent interactive response. Andreww.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web