Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55835 > unrolled thread

microsecond resolution delay and time

Back to article view | Back to comp.lang.forth

Contents

  microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-15 18:06 -0700
    Re: microsecond resolution delay and time hughaguilar96@gmail.com - 2017-03-15 21:48 -0700
      Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 07:42 -0700
    Re: microsecond resolution delay and time stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 10:29 +0000
      Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 07:57 -0700
        Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 08:04 -0700
        Re: microsecond resolution delay and time stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 16:14 +0000
          Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 10:00 -0700
        Re: microsecond resolution delay and time Brad Eckert <hwfwguy@gmail.com> - 2017-03-21 11:59 -0700
          Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 10:57 -0700
            Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-25 21:42 -0400
              Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 19:08 -0700
                Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 00:09 -0400
                  Re: microsecond resolution delay and time Paul Rubin <no.email@nospam.invalid> - 2017-03-25 22:18 -0700
                    Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 02:48 -0400
                  Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:21 -0700
                Re: microsecond resolution delay and time hughaguilar96@gmail.com - 2017-03-25 23:12 -0700
                  Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:32 -0700
    Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 11:20 -0700
      Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 18:28 -0700
        Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-25 21:44 -0400
          Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 19:00 -0700
            Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 03:00 -0400
              Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:39 -0700
                Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-27 18:10 -0400

Page 1 of 2  [1] 2  Next page →

#55835 — microsecond resolution delay and time

In the latest kforth development snapshot, linked below, I've added the words US and US@ which are analagous to the standard Forth words MS and MS@ :

US ( u -- )  \ delay for u microseconds

US@ ( -- u ) \ return the time elapsed in microseconds from the start of the Forth system

The delay provided by US is a polled delay and not a sleep delay; hence, it provides much greater precision than a sleep delay, but is not immune to system interrupts. The following simple code snippet shows how one may obtain data for determining the precision of the delay on a system; however, to date, I've only run some simple tests to satisfy myself that it is adequate for my purpose (on my system):

: delays ( u -- u1 u2 ... uu ) 0 ?DO us@ 1 us us@ swap - LOOP ;

The word DELAYS leaves the elapsed clock time for each of the u delays on the stack. The mean and standard deviation may then be computed for the elapsed times, though the histogram may be more useful. System interrupts will lead to elapsed times which vary by more than the 1 microsecond delay performed in each loop.

Feel free to comment on the existing practice and nomenclature in other Forth systems for delay and time words which return time values at greater than millisecond precision, and user experience with such words.

Krishna

--
Latest kforth development snapshot:

ftp://ccreweb.org/software/kforth/linux/develop/1.5.x/kforth-x86-linux-2017-03-15.tar.gz

sha256sum

527b3fdc6c0ecb50f595ebf0736426f901823ff9d5d41cd13201d80c606f40b9  kforth-x86-linux-2017-03-15.tar.gz

[toc] | [next] | [standalone]

#55840

On Wednesday, March 15, 2017 at 6:06:43 PM UTC-7, krishna...@ccreweb.org wrote:
> In the latest kforth development snapshot, linked below, I've added the words US and US@ which are analagous to the standard Forth words MS and MS@ :
> 
> US ( u -- )  \ delay for u microseconds
> 
> US@ ( -- u ) \ return the time elapsed in microseconds from the start of the Forth system

There is no such thing as MS@ in ANS-Forth --- that is why ANS-Forth can't be used for writing games --- it is called TICKS in VFX, but that is non-standard.

Most likely, the reason why MS@ (or TICKS or whatever you want to call it) was not included in ANS-Forth is that one or more of the ANS-Forth committee were selling games or at least wanted to write games and sell them --- they made MS@ non-standard so that the Forth community couldn't write games in competition with them --- at least, not without first writing MS@ in assembly-language, which they hoped would be beyond their ability.

The ANS-Forth standard is all about telling the Forth community what they can't do --- primarily, they can't compete against the ANS-Forth committee (at least, not without becoming non-standard).

[toc] | [prev] | [next] | [standalone]

#55851

On Wednesday, March 15, 2017 at 11:48:12 PM UTC-5, hughag...@gmail.com wrote:
> On Wednesday, March 15, 2017 at 6:06:43 PM UTC-7, krishna...@ccreweb.org wrote:
> > In the latest kforth development snapshot, linked below, I've added the words US and US@ which are analagous to the standard Forth words MS and MS@ :
> > 
> > US ( u -- )  \ delay for u microseconds
> > 
> > US@ ( -- u ) \ return the time elapsed in microseconds from the start of the Forth system
> 
> There is no such thing as MS@ in ANS-Forth ...

Yes, you're correct that there is no MS@ in standard Forth. I believe several Forth systems provide an equivalent word.

[toc] | [prev] | [next] | [standalone]

#55848

On Wed, 15 Mar 2017 18:06:41 -0700 (PDT), krishna.myneni@ccreweb.org
wrote:

>Feel free to comment on the existing practice and nomenclature in other For=
>th systems for delay and time words which return time values at greater tha=
>n millisecond precision, and user experience with such words.

On a few rare occasions we have had to return a 64 bit number of
milliseconds, but in these cases working in seconds would have 
been easier.

For microseconds, most OSes can return you something, but its
granularity and reliability may/will be suspect for small numbers
of microseconds. In embedded systems, our habit is just to read
a timer set to count microseconds.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#55852

On Thursday, March 16, 2017 at 5:29:23 AM UTC-5, Stephen Pelc wrote:
> On Wed, 15 Mar 2017 18:06:41 -0700 (PDT), krishna.myneni@ccreweb.org
> wrote:
> 
> >Feel free to comment on the existing practice and nomenclature in other Forth systems for delay and time words which return time values at greater than millisecond precision, and user experience with such words.
> 
> On a few rare occasions we have had to return a 64 bit number of
> milliseconds, but in these cases working in seconds would have 
> been easier.
>

Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?

> For microseconds, most OSes can return you something, but its
> granularity and reliability may/will be suspect for small numbers
> of microseconds. In embedded systems, our habit is just to read
> a timer set to count microseconds.
> 

On modern desktops running linux, the clock speed is adequate to obtain microsecond granularity when using the C library function gettimeofday(). Even on my 15-year old system at home, the minimum granularity is about 4 microseconds. The reliability of the delays are suspect of course due to system interrupts on a desktop, and this is where micro-controllers have an advantage, since interrupts can be disabled and enabled as needed.

Incidentally, owing to the fact that gettimeofday() does not guarantee monoticity of the time or the absence of discontinuous jumps, POSIX now recommends the use of clock_gettime().

[toc] | [prev] | [next] | [standalone]

#55853

On Thursday, March 16, 2017 at 9:57:22 AM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, March 16, 2017 at 5:29:23 AM UTC-5, Stephen Pelc wrote:

> Even on my 15-year old system at home, the minimum granularity is about 4 microseconds....

I take that back. Even on my old system the minimum granularity is 1 microseconds:

10 0 DO us@ LOOP .s

		32145380
		32145379
		32145377
		32145376
		32145375
		32145373
		32145372
		32145371
		32145369
		32145367
 ok

[toc] | [prev] | [next] | [standalone]

#55854

On Thu, 16 Mar 2017 07:57:20 -0700 (PDT), krishna.myneni@ccreweb.org
wrote:

>> On a few rare occasions we have had to return a 64 bit number of
>> milliseconds, but in these cases working in seconds would have=20
>> been easier.

>Do you mean that millisecond resolution was not necessary for your applicat=
>ion(s), or that you simply needed a rescaling of the milliseconds count bac=
>k into seconds?

On a 32 bit system, a 32 bit millisecond ticker overflows every 24
days or so. If you need to handle millisecond delays, e.g. to time a
relay changover, and you need to handle periods longer than 24 days,
a 64 bit milliseconds counter can be useful.

On embedded systems, seconds counters tend to come from a Real Time
Clock (RTC) clocked from a 32768 Hz crystal. This is not synchronised
to the clock that produces milliecond pulses. Most people prefer
to use only one clock for time measurement.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#55855

On Thursday, March 16, 2017 at 11:14:48 AM UTC-5, Stephen Pelc wrote:
> On Thu, 16 Mar 2017 07:57:20 -0700 (PDT), krishna.myneni@ccreweb.org
> wrote:
> 
> >> On a few rare occasions we have had to return a 64 bit number of
> >> milliseconds, but in these cases working in seconds would have=20
> >> been easier.
> 
> >Do you mean that millisecond resolution was not necessary for your applicat=
> >ion(s), or that you simply needed a rescaling of the milliseconds count bac=
> >k into seconds?
> 
> On a 32 bit system, a 32 bit millisecond ticker overflows every 24
> days or so. If you need to handle millisecond delays, e.g. to time a
> relay changover, and you need to handle periods longer than 24 days,
> a 64 bit milliseconds counter can be useful.
> ....

This is an even more important point for microsecond timers as well. A 32-bit microseconds counter will overflow (wrap) after only 1 hr 11 min. This means the polled delays should be performed with 64 bit comparisons within the code, and that a word like US@ should return a 64 bit number rather than a 32-bit number. Therefore it would be useful to change the return type to a "ud" for US@ on a 32-bit system:

US  ( u -- )
US@ ( -- ud )

The implementation for both words needs to use sufficient size variables to avoid overflows/wraparounds for a reasonable length of time, which will be different for embedded systems and desktops.

Krishna

[toc] | [prev] | [next] | [standalone]

#56033

On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
> 
> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
> 
I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).

[toc] | [prev] | [next] | [standalone]

#56284

On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
> > 
> > Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
> > 
> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).

If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).

Here's a link to an expensive one, but cheaper ones (~$100) can be found.

http://www.thinksrs.com/products/SC10.htm

Krishna

[toc] | [prev] | [next] | [standalone]

#56309

On 3/25/2017 1:57 PM, krishna.myneni@ccreweb.org wrote:
> On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
>> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
>>>
>>> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
>>>
>> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).
>
> If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).
>
> Here's a link to an expensive one, but cheaper ones (~$100) can be found.
>
> http://www.thinksrs.com/products/SC10.htm

Well, sure, an ovenized oscillator would be great.  But why stop there? 
Get an atomic clock oscillator while you're at it.  Did you notice he 
mentioned keeping the oscillator running while the CPU is in sleep mode?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#56312

On Saturday, March 25, 2017 at 8:42:46 PM UTC-5, rickman wrote:
> On 3/25/2017 1:57 PM, krishna.myneni@ccreweb.org wrote:
> > On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
> >> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
> >>>
> >>> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
> >>>
> >> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).
> >
> > If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).
> >
> > Here's a link to an expensive one, but cheaper ones (~$100) can be found.
> >
> > http://www.thinksrs.com/products/SC10.htm
> 
> Well, sure, an ovenized oscillator would be great.  But why stop there? 
> Get an atomic clock oscillator while you're at it.  Did you notice he 
> mentioned keeping the oscillator running while the CPU is in sleep mode?
> 

Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. The oscillator I linked to has a power consumption between 3 to 8 W, depending on the ambient temperature. Of course, I suggested a no-power low-tech option, which was to thermally insulate the standard crystal oscillator, but apparently your short-term memory register doesn't hold much information.

Cheers,
Krishna

[toc] | [prev] | [next] | [standalone]

#56315

On 3/25/2017 10:08 PM, krishna.myneni@ccreweb.org wrote:
> On Saturday, March 25, 2017 at 8:42:46 PM UTC-5, rickman wrote:
>> On 3/25/2017 1:57 PM, krishna.myneni@ccreweb.org wrote:
>>> On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
>>>> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
>>>>>
>>>>> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
>>>>>
>>>> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).
>>>
>>> If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).
>>>
>>> Here's a link to an expensive one, but cheaper ones (~$100) can be found.
>>>
>>> http://www.thinksrs.com/products/SC10.htm
>>
>> Well, sure, an ovenized oscillator would be great.  But why stop there?
>> Get an atomic clock oscillator while you're at it.  Did you notice he
>> mentioned keeping the oscillator running while the CPU is in sleep mode?
>>
>
> Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. The oscillator I linked to has a power consumption between 3 to 8 W, depending on the ambient temperature. Of course, I suggested a no-power low-tech option, which was to thermally insulate the standard crystal oscillator, but apparently your short-term memory register doesn't hold much information.

I'm just commenting on the fact that he is talking about an RC 
oscillator built into a CPU which is powered down between operations. 
Insulation may help some with that.  But if it isn't heated to a 
constant temperature (ovenized) this is only changing the response time 
and not the actual extent of the temperature excursions.

In fact, since the CPU is powered up and down, adding insulation may 
*increase* the temperature excursions as the unit warms up to a higher 
operating temperature.  Better might be a good heat sink directly on the 
CPU to minimize the self heating impact.  It would require some 
knowledge of the operating details to know which is better.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#56318

rickman <gnuarm@gmail.com> writes:
> Better might be a good heat sink directly on the CPU to minimize the
> self heating impact.

What about measuring the temperature and compensating in software?  That
would need a spare A/D pin and some hopefully cheap external analog part.

[toc] | [prev] | [next] | [standalone]

#56321

On 3/26/2017 1:18 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Better might be a good heat sink directly on the CPU to minimize the
>> self heating impact.
>
> What about measuring the temperature and compensating in software?  That
> would need a spare A/D pin and some hopefully cheap external analog part.

I think Brad is pretty happy with what he has.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#56339

On Saturday, March 25, 2017 at 11:10:01 PM UTC-5, rickman wrote:
> On 3/25/2017 10:08 PM, krishna.myneni@ccreweb.org wrote:
> > On Saturday, March 25, 2017 at 8:42:46 PM UTC-5, rickman wrote:
> >> On 3/25/2017 1:57 PM, krishna.myneni@ccreweb.org wrote:
> >>> On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
> >>>> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
> >>>>>
> >>>>> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
> >>>>>
> >>>> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).
> >>>
> >>> If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).
> >>>
> >>> Here's a link to an expensive one, but cheaper ones (~$100) can be found.
> >>>
> >>> http://www.thinksrs.com/products/SC10.htm
> >>
> >> Well, sure, an ovenized oscillator would be great.  But why stop there?
> >> Get an atomic clock oscillator while you're at it.  Did you notice he
> >> mentioned keeping the oscillator running while the CPU is in sleep mode?
> >>
> >
> > Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. The oscillator I linked to has a power consumption between 3 to 8 W, depending on the ambient temperature. Of course, I suggested a no-power low-tech option, which was to thermally insulate the standard crystal oscillator, but apparently your short-term memory register doesn't hold much information.
> 
> I'm just commenting on the fact that he is talking about an RC 
> oscillator built into a CPU which is powered down between operations. 
> Insulation may help some with that.  But if it isn't heated to a 
> constant temperature (ovenized) this is only changing the response time 
> and not the actual extent of the temperature excursions.
> 
> In fact, since the CPU is powered up and down, adding insulation may 
> *increase* the temperature excursions as the unit warms up to a higher 
> operating temperature.  Better might be a good heat sink directly on the 
> CPU to minimize the self heating impact.  It would require some 
> knowledge of the operating details to know which is better.
> 

Ok, I assumed Brad was talking about an external oscillator. Even simple microcontrollers such as PICs have an external clock input. Yes, I agree, if the oscillator is integrated inside the CPU, stabilizing it with thermal insulation might not be a great idea. Better to use an external oscillator if better accuracy is needed.

Krishna

[toc] | [prev] | [next] | [standalone]

#56320

On Saturday, March 25, 2017 at 7:08:56 PM UTC-7, krishna...@ccreweb.org wrote:
> Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. 

Isn't Kforth a desktop-computer Forth system? 

If you are going to build test equipment, or anything else that needs hard real-time, then you would use a micro-controller and do without any OS. Is this what Kforth is for???

[toc] | [prev] | [next] | [standalone]

#56340

On Sunday, March 26, 2017 at 1:12:28 AM UTC-5, hughag...@gmail.com wrote:
> On Saturday, March 25, 2017 at 7:08:56 PM UTC-7, krishna...@ccreweb.org wrote:
> > Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. 
> 
> Isn't Kforth a desktop-computer Forth system? 
> 
> If you are going to build test equipment, or anything else that needs hard real-time, then you would use a micro-controller and do without any OS. Is this what Kforth is for???

Yest, kForth is a desktop system, and yes, to do repeatable real-time processes at the microsecond level, I would use a microcontroller (except maybe back in the days of DOS, when the processor interrupts could still be turned on and off by the user without adverse side effects). However, being able to obtain the microsecond time count has its uses on a modern desktop also. As I demonstrated, the time resolution for US2@ can easily be a microsecond (or less) on a typical desktop, so the granularity is fine. The problem is repeatability since interrupts can cause problems. However, in some cases, one can use the elapsed time with microsecond resolution as an indicator of whether or not the executing code, e.g. for a measurement, was interrupted. This can be useful for a recurring process.

KM

[toc] | [prev] | [next] | [standalone]

#56287

On Wednesday, March 15, 2017 at 8:06:43 PM UTC-5, krishna...@ccreweb.org wrote:
> In the latest kforth development snapshot, linked below, I've added the words US and US@ which are analagous to the standard Forth words MS and MS@ :
> 
> US ( u -- )  \ delay for u microseconds
> 
> US@ ( -- u ) \ return the time elapsed in microseconds from the start of the Forth system
> ...

As a result of feedback from Stephen Pelc, I've updated US@ in the latest development snapshot, not yet posted, to return an unsigned double instead of an unsigned single integer, to avoid the wrapping. The naming of the time words in kForth now may need refinement. In the present version, they are,

MS  ( u -- )  \ delay for u milliseconds (Standard Forth)
MS@ ( -- u )  \ return the time elapsed in milliseconds
US  ( u -- )  \ delay for u microseconds
US@ ( -- ud ) \ return the time elapsed in microseconds

Since US, and US@ are new non-standard words, there is freedom to rename them. MS@ is a non-standard word, but has been in use for a long time now, and it would break a lot of code for me to change its behavior to return an unsigned double. I'm thinking of the following names, then:

MS    ( u -- )    \ delay for u milliseconds (Standard Forth)
MS@   ( -- u )    \ return elapsed time in milliseconds
MS-D@ ( -- ud )   \ return elapsed time in ms as ud
US    ( u -- )    \ delay for u microseconds
US-D@ ( -- ud )   \ return the time elapsed in microseconds

This set of words will not break any of my past code, with the exception of recently used instances of US@, which can be easily updated.

Krishna

[toc] | [prev] | [next] | [standalone]

#56307

On Saturday, March 25, 2017 at 1:20:38 PM UTC-5, krishna...@ccreweb.org wrote:
> 
> MS    ( u -- )    \ delay for u milliseconds (Standard Forth)
> MS@   ( -- u )    \ return elapsed time in milliseconds
> MS-D@ ( -- ud )   \ return elapsed time in ms as ud
> US    ( u -- )    \ delay for u microseconds
> US-D@ ( -- ud )   \ return the time elapsed in microseconds
> 

Actually, I think I prefer MS2@ and US2@ instead of MS-D@ and US-D@. The D@ implies a signed number.

KM

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web