Hi,
Often a digital censor is used to measure the temperature in a room.
On an ESP32 a NTC Thermistor is also a good alternative.

After some tests I now use:
- The Steinhart-Hart equation to calculate the temperature of the NTC.
- The ADC calibration bits of the ESP32. (Factory defaults)
- Multisampling
- A ring buffer

You can download the source ntc_sh.fth at:
http://home.kpn.nl/~josv/ from the Smart home page

The Steinhart-Hart equation should run on most ANSI Forth-systems
with a floating point extension.
(tested under Cforth, Gforth and Win32forth)

To monitor the NTC you need to add some ADC words if
you do not use cforth (LWIP branch).

Jos

On 17/09/2022 1:33 am, Jos Ven wrote:
> Hi,
> Often a digital censor is used to measure the temperature in a room.
> On an ESP32 a NTC Thermistor is also a good alternative.

Don't know much about ESP32 but how is a thermistor a good alternative
to a LM35 etc for this particular application? I mention this as a
Rinnai heater owner who has struggled with its hopeless temperature
sensing ability.

Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> On 17/09/2022 1:33 am, Jos Ven wrote:
> > Hi,
> > Often a digital censor is used to measure the temperature in a room.
> > On an ESP32 a NTC Thermistor is also a good alternative.
> Don't know much about ESP32 but how is a thermistor a good alternative
> to a LM35 etc for this particular application? I mention this as a
> Rinnai heater owner who has struggled with its hopeless temperature
> sensing ability.

Hi,
An ESP32 is a cheap MCU with several ADC's.
My objective was only to measure the temperature in a room.

> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.

Not always, a thermistor lacks a digital output.
The response of a thermistor is non-lineair.
One advantage of a thermistor is that it can be mounted to a plate.
Not sure if you can do so easy with a LM35.
Jos

On 17/09/2022 7:57 pm, Jos Ven wrote:
> Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> ...
>> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
>
> Not always, a thermistor lacks a digital output.
> The response of a thermistor is non-lineair.
> One advantage of a thermistor is that it can be mounted to a plate.
> Not sure if you can do so easy with a LM35.
> Jos

LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
easy (saddle clamp). Price difference for a few units is negligible.
Simpler software :)

Op zaterdag 17 september 2022 om 14:37:56 UTC+2 schreef dxforth:
> On 17/09/2022 7:57 pm, Jos Ven wrote:
> > Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> > ...
> >> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
> >
> > Not always, a thermistor lacks a digital output.
> > The response of a thermistor is non-lineair.
> > One advantage of a thermistor is that it can be mounted to a plate.
> > Not sure if you can do so easy with a LM35.
> > Jos
> LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
> easy (saddle clamp). Price difference for a few units is negligible.
> Simpler software :)

Thank you.
It seems there is not much room for a thermistor.
Jos

On 18/09/2022 2:57 am, Jos Ven wrote:
> Op zaterdag 17 september 2022 om 14:37:56 UTC+2 schreef dxforth:
>> On 17/09/2022 7:57 pm, Jos Ven wrote:
>>> Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
>>> ...
>>>> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
>>>
>>> Not always, a thermistor lacks a digital output.
>>> The response of a thermistor is non-lineair.
>>> One advantage of a thermistor is that it can be mounted to a plate.
>>> Not sure if you can do so easy with a LM35.
>>> Jos
>> LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
>> easy (saddle clamp). Price difference for a few units is negligible.
>> Simpler software :)
>
> Thank you.
> It seems there is not much room for a thermistor.
> Jos

There are several sensors in the range LM35, LM34, LM335. Shocked to
discover National Semiconductor had been taken over by Texas Instruments...

> There are several sensors in the range LM35, LM34, LM335. Shocked to

Maybe something like this: https://www.ebay.com/itm/275434342506
....or like this one: https://www.ebay.com/itm/402606493588
Not that expensive, so it may be worth to try them.

On Sunday, September 18, 2022 at 12:04:43 AM UTC-4, dxforth wrote:
> On 18/09/2022 2:57 am, Jos Ven wrote:
> > Op zaterdag 17 september 2022 om 14:37:56 UTC+2 schreef dxforth:
> >> On 17/09/2022 7:57 pm, Jos Ven wrote:
> >>> Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> >>> ...
> >>>> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
> >>>
> >>> Not always, a thermistor lacks a digital output.
> >>> The response of a thermistor is non-lineair.
> >>> One advantage of a thermistor is that it can be mounted to a plate.
> >>> Not sure if you can do so easy with a LM35.
> >>> Jos
> >> LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
> >> easy (saddle clamp). Price difference for a few units is negligible.
> >> Simpler software :)
> >
> > Thank you.
> > It seems there is not much room for a thermistor.
> > Jos
> There are several sensors in the range LM35, LM34, LM335. Shocked to
> discover National Semiconductor had been taken over by Texas Instruments...

??? Really? That happened, what 10, 15 years ago?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Sunday, September 18, 2022 at 8:56:33 PM UTC+1, gnuarm.del...@gmail.com wrote:
> On Sunday, September 18, 2022 at 12:04:43 AM UTC-4, dxforth wrote:
> > On 18/09/2022 2:57 am, Jos Ven wrote:
> > > Op zaterdag 17 september 2022 om 14:37:56 UTC+2 schreef dxforth:
> > >> On 17/09/2022 7:57 pm, Jos Ven wrote:
> > >>> Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> > >>> ...
> > >>>> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
> > >>>
> > >>> Not always, a thermistor lacks a digital output.
> > >>> The response of a thermistor is non-lineair.
> > >>> One advantage of a thermistor is that it can be mounted to a plate.
> > >>> Not sure if you can do so easy with a LM35.
> > >>> Jos
> > >> LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
> > >> easy (saddle clamp). Price difference for a few units is negligible.
> > >> Simpler software :)
> > >
> > > Thank you.
> > > It seems there is not much room for a thermistor.
> > > Jos
> > There are several sensors in the range LM35, LM34, LM335. Shocked to
> > discover National Semiconductor had been taken over by Texas Instruments...
> ??? Really? That happened, what 10, 15 years ago?

2011. I confess I thought it was earlier than that

On Sunday, September 18, 2022 at 5:16:22 PM UTC-4, Jon Nicoll wrote:
> On Sunday, September 18, 2022 at 8:56:33 PM UTC+1, gnuarm.del...@gmail.com wrote:
> > On Sunday, September 18, 2022 at 12:04:43 AM UTC-4, dxforth wrote:
> > > On 18/09/2022 2:57 am, Jos Ven wrote:
> > > > Op zaterdag 17 september 2022 om 14:37:56 UTC+2 schreef dxforth:
> > > >> On 17/09/2022 7:57 pm, Jos Ven wrote:
> > > >>> Op zaterdag 17 september 2022 om 05:40:21 UTC+2 schreef dxforth:
> > > >>> ...
> > > >>>> Don't know much about ESP32 but how is a thermistor a good alternative to a LM35 etc.
> > > >>>
> > > >>> Not always, a thermistor lacks a digital output.
> > > >>> The response of a thermistor is non-lineair.
> > > >>> One advantage of a thermistor is that it can be mounted to a plate.
> > > >>> Not sure if you can do so easy with a LM35.
> > > >>> Jos
> > > >> LM35 is analog out (10mV/C). Flat-sided plastic pack makes mounting
> > > >> easy (saddle clamp). Price difference for a few units is negligible.
> > > >> Simpler software :)
> > > >
> > > > Thank you.
> > > > It seems there is not much room for a thermistor.
> > > > Jos
> > > There are several sensors in the range LM35, LM34, LM335. Shocked to
> > > discover National Semiconductor had been taken over by Texas Instruments...
> > ??? Really? That happened, what 10, 15 years ago?
> 2011. I confess I thought it was earlier than that

Maybe you are thinking of Harris? I think TI acquired their logic lines some time ago and they have some overlap with National logic devices, which I think National acquired with Fairchild Semi in the late 80s. Fairchild was a hell of an entrepreneur. He started lots of companies, which helped define their respective industries.

I believe I've seen the same part sold by TI under two slightly different part numbers, because each was acquired from a different company. I know they are actually different because they still use the original data sheets with the TI name stuck somewhere. These were FFs and the action of asserting both set and reset simultaneously was different. I ended up doing a survey of available devices and found different behaviors from several sources.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On 19/09/2022 5:56 am, Lorem Ipsum wrote:
> On Sunday, September 18, 2022 at 12:04:43 AM UTC-4, dxforth wrote:
>> Shocked to
>> discover National Semiconductor had been taken over by Texas Instruments...
>
> ??? Really? That happened, what 10, 15 years ago?

It's always a shock to discover players which had such a large influence
in one's early years and career had gone the way of the dodo. I won't
ask for minute's silence instead leave folks to mourn in their own way.

On Sunday, September 18, 2022 at 9:18:59 PM UTC-5, dxforth wrote:

> It's always a shock to discover players which had such a large influence
> in one's early years and career had gone the way of the dodo. I won't
> ask for minute's silence instead leave folks to mourn in their own way.

Updates for my Dell chromebook ended in July; it had reached its end-of-life
date (AUE). I only had it for about three years. A purchaser needs to check
the AUE before buying to see how long the particular chromebook will be
supported.
With my chromebook now unsupported and I need more memory anyway I started
looking for a new one. I checked Chrome's list of partners and was
surprised that Dell wasn't listed. I checked around and found that Dell
had been outsourcing its chromebook to Taiwan and now
that company, ASUS, sells that chromebook under its brand. It appears Dell
lost its chomebook because of outsourcing decisions.
More checking found these Taiwan companies are just store fronts for
mainland China; manufacturing is mainland at some big hub (Suzhou) west
of Shanghai where most of worlds computers are built including the likes
of HP and ACR.
I just did another search to get the name of manufacturing town that
I had found in July. Search results are now much different; harder
to link ASUS and others to the mainland. Ask where ASUS is manufactured
and get that it's headquarters is in Taiwan (Not what I asked!).
--
me

On 19/09/2022 11:49 pm, S Jack wrote:
> On Sunday, September 18, 2022 at 9:18:59 PM UTC-5, dxforth wrote:
>
>> It's always a shock to discover players which had such a large influence
>> in one's early years and career had gone the way of the dodo. I won't
>> ask for minute's silence instead leave folks to mourn in their own way.
>
> Updates for my Dell chromebook ended in July; it had reached its end-of-life
> date (AUE). I only had it for about three years. A purchaser needs to check
> the AUE before buying to see how long the particular chromebook will be
> supported.

Caveat emptor. Even so, there may be nothing from the manufacturer to
indicate what support it will provide. Like you I got burned with a
Samsung phone that never received an Android update contrary to other
regions for the same model. For me the update was critical to run a
COVID check-in app. I now take the view anything requiring connection
to the internet is inherently obsolete. Brand loyalty - forget it.

On Monday, September 19, 2022 at 9:04:23 PM UTC-5, dxforth wrote:
> On 19/09/2022 11:49 pm, S Jack wrote:
> > On Sunday, September 18, 2022 at 9:18:59 PM UTC-5, dxforth wrote:
> >
> >> It's always a shock to discover players which had such a large influence
> >> in one's early years and career had gone the way of the dodo. I won't
> >> ask for minute's silence instead leave folks to mourn in their own way.
> >
> > Updates for my Dell chromebook ended in July; it had reached its end-of-life
> > date (AUE). I only had it for about three years. A purchaser needs to check
> > the AUE before buying to see how long the particular chromebook will be
> > supported.
> Caveat emptor. Even so, there may be nothing from the manufacturer to
> indicate what support it will provide. Like you I got burned with a
> Samsung phone that never received an Android update contrary to other
> regions for the same model. For me the update was critical to run a
> COVID check-in app. I now take the view anything requiring connection
> to the internet is inherently obsolete. Brand loyalty - forget it.

here is the Google site to check a chromebook model for its scheduled end-of-life:https://support.google.com/chrome/a/answer/6220366?

On Friday, September 16, 2022 at 5:33:57 PM UTC+2, Jos Ven wrote:
> The Steinhart-Hart equation should run on most ANSI Forth-systems
> with a floating point extension.
> (tested under Cforth, Gforth and Win32forth)
I ported it to 4tH. The only problems I found was:
- A separate FP stack (not a problem - I got both);
- The use of FVALUE - I had to replace that one;
- You can't erase FLOATs (or any other non-character datatype). So I made a replacement. It's not required, since all 4tH memory is zeroed on startup - but still.
The rest was quietly handled by some stubs (KEY) and the preprocessor.
> To monitor the NTC you need to add some ADC words if
> you do not use cforth (LWIP branch).
I faked those sensors with a bit of S/W. 1500 mV gave me about room temperature. And then let it run and see the temperature slowly sway ;-)

Hans Bezemer

Op vrijdag 23 september 2022 om 18:01:25 UTC+2 schreef the.bee...@gmail.com:
> On Friday, September 16, 2022 at 5:33:57 PM UTC+2, Jos Ven wrote:
> > The Steinhart-Hart equation should run on most ANSI Forth-systems
> > with a floating point extension.
> > (tested under Cforth, Gforth and Win32forth)
> I ported it to 4tH. The only problems I found was:
> - A separate FP stack (not a problem - I got both);
> - The use of FVALUE - I had to replace that one;
> - You can't erase FLOATs (or any other non-character datatype). So I made a replacement. It's not required, since all 4tH memory is zeroed on startup - but still.
> The rest was quietly handled by some stubs (KEY) and the preprocessor.
> > To monitor the NTC you need to add some ADC words if
> > you do not use cforth (LWIP branch).
> I faked those sensors with a bit of S/W. 1500 mV gave me about room temperature. And then let it run and see the temperature slowly sway ;-)
>
> Hans Bezemer

Op vrijdag 23 september 2022 om 18:01:25 UTC+2 schreef th..ail.com:
> On Friday, September 16, 2022 at 5:33:57 PM UTC+2, Jos Ven wrote:
> > The Steinhart-Hart equation should run on most ANSI Forth-systems
> > with a floating point extension.
> > (tested under Cforth, Gforth and Win32forth)
> I ported it to 4tH. The only problems I found was:
> - A separate FP stack (not a problem - I got both);
> - The use of FVALUE - I had to replace that one;
> - You can't erase FLOATs (or any other non-character datatype). So I made a replacement. It's not required, since all 4tH memory is zeroed on startup - but still.
> The rest was quietly handled by some stubs (KEY) and the preprocessor.
> > To monitor the NTC you need to add some ADC words if
> > you do not use cforth (LWIP branch).
> I faked those sensors with a bit of S/W. 1500 mV gave me about room temperature. And then let it run and see the temperature slowly sway ;-)
>
> Hans Bezemer

Hi,

Thank you for looking so close to my source.

In the other Forth systems, I got the following:
For Cforth:
- Has no find
- Must use f# to get a float on the stack

For Gforth version 0.7.9_20210930:
- Has no f#

What happens in your Forth when you use:
create &buf 4 floats allot
&buf f@ f.

Jos

On Sunday, September 25, 2022 at 12:01:57 PM UTC+2, Jos Ven wrote:
> Thank you for looking so close to my source.
I should thank you! It was a an entertaining and satisfying exercise.
> In the other Forth systems, I got the following:
> For Cforth:
> - Has no find
> - Must use f# to get a float on the stack
Guilty on both. I used [DEFINED] for it. I don't have F# either (name clash),
but its equivalent is F%.

And as I said: I don't have FVALUE or a "true" KEY? The latter is an alias
for FALSE. And finally: MS has a resolution of 1000 MS ;-)

> What happens in your Forth when you use:
create &buf
Creates a table for R/O integer constants;

4 floats
Throws the size for 4 floating points numbers on the stack (not
quite - but let's not go into detail);

allot
Syntax error: No such word. In order to do what you want to do
I have to write:

4 FLOATS ARRAY &BUF

That does it.

> &buf f@ f.
No problem. It will work as intended.

Hans Bezemer

BTW, here is a list of changes to your code:

> cr decimal fclear
FCLEAR initializes floating point properly

> f% 3300 fvariable Vs latest f! \ In mV, measure it
> f% 10000 fvariable R0 latest f! \ 10K
> f% 298.15e0 fconstant T0 \ Temperature in Kelvin at 25C
> f% 273.15e0 fconstant 0C \ Temperature in Kelvin at 0C
> f% 0.7556958984e-3 fvariable A_sh latest f!
> f% 2.334204104e-4 fvariable B_sh latest f!
> f% 0.6102744539e-7 fvariable C_sh latest f!
> : 1/f ( F: f - 1/f ) f% 1 fswap f/ ;
Obviously due to the use of F% and FVALUE conversion

> Vs f@ s>f f- ;
> fdup R0 f@ f* Vs f@ frot f- f/ ;
> fln fdup fdup fdup f* f* C_sh f@ f* \ C*(ln(Rnct))^3
> fswap B_sh f@ f* f+
> A_sh f@ f+ \ 1/T
> cr .( A: ) A_sh f@ f.
> cr .( B: ) B_sh f@ f.
> cr .( C: ) C_sh f@ f.
> cr .( Vs: ) Vs f@ f. ( mV )
> cr .( Resistor R0:) R0 f@ f.
Obviously to the conversion of FVALUE to FVARIABLE

> cr .( Rt:) f% 29456 fdup f>s . ntc-sh
Another due to the use of F%

> [defined] adc-mv [if] \ For Cforth on a ESP32:
Here you got your FIND

> 32 constant /adc_chars
I don't do prefixed numbers

> /adc_chars floats array &adc_chars
Here you got my ARRAY

> 1500000 value Mv \ fake sensor reading
> : read-adc-mv drop Mv 1000 / 10001 choose 5000 - +to Mv ;
> : init-adc drop drop drop ;
This is my fake sensor

> cr .( to monitor the NTC.) cr cr
> [then]
Obviously - I can't QUIT here

> f% 1.292290081e-3 A_sh f!
> f% 2.164041451e-4 B_sh f!
> f% 0.8776278596e-7 C_sh f!
> f% 0 fvariable av-trim latest f! \ if needed
> cr .( A ) A_sh f@ f.
> cr .( B ) B_sh f@ f.
> cr .( C ) C_sh f@ f.
> cr .( av-trim :) av-trim f@ f.
> cr .( Vs :) Vs f@ f.
> cr .( Resistor R0:) R0 f@ f.
More FVALUE and F% stuff

> 10 constant #samples
I don't do prefixed numbers

> 60 constant /ring-buf \ To reduce the ADC noise further
In 4tH, you can't initialize with a VALUE

> /ring-buf floats array &ring-buf
Here you got my ARRAY again

> f% 0 ring-buf-count /ring-buf min dup 0
Obviously due to the use of F%

> dup 3 3 init-adc 3 set-precision
I just liked a slightly higher precision ;-)

> 0 to ring-buf-count
I split this line in two lines

> /ring-buf 0 ?do f% 0 &ring-buf i floats + f! loop \ erase
All memory is zero-ed at startup, but let's stay in the spirit ;-)

> ring-buf-count . av-ntc av-trim f@ f+ f.
Another victim of FVALUE

> 5 monitor-ntc
In 4tH, you have to start something. If not, it just compiles it
and quits immediately.

Running your program (first 12 "measurements"):

$ pp4th -x ntc_sh.4pp

ntc_sh.fth the Steinhart-Hart equation.

ntc-sh ( Rt - Celsius ) can be used.

adc-mv ( adc_chars reading - mV ) is missing.
See: https://github.com/MitchBradley/cforth/tree/WIP
Or define your own accurate read-adc-mv and init-adc here
to monitor the NTC.

Parameters for NTC B57164K0103:
A 0.0012922900810
B 0.0002164041451
C 0.0000000877627

av-trim :0.00
Vs :33
Resistor R0:10

To monitor the NTC on adc-channel 5 enter: 5 monitor-ntc

Sec C
1 21.0
2 21.0
3 21.0
4 21.1
5 21.2
6 21.2
7 21.2
8 21.2
9 21.2
10 21.2
11 21.2
12 21.2

Op zondag 25 september 2022 om 14:04:17 UTC+2 schreef the.bee..om:
> On Sunday, September 25, 2022 at 12:01:57 PM UTC+2, Jos Ven wrote:
> > Thank you for looking so close to my source.
> I should thank you! It was a an entertaining and satisfying exercise.
> > In the other Forth systems, I got the following:
> > For Cforth:
> > - Has no find
> > - Must use f# to get a float on the stack
> Guilty on both. I used [DEFINED] for it. I don't have F# either (name clash),
> but its equivalent is F%.
>
> And as I said: I don't have FVALUE or a "true" KEY? The latter is an alias
> for FALSE. And finally: MS has a resolution of 1000 MS ;-)
> > What happens in your Forth when you use:
> create &buf
> Creates a table for R/O integer constants;
>
> 4 floats
> Throws the size for 4 floating points numbers on the stack (not
> quite - but let's not go into detail);
>
> allot
> Syntax error: No such word. In order to do what you want to do
> I have to write:
>
> 4 FLOATS ARRAY &BUF
>
> That does it.
>
> > &buf f@ f.
> No problem. It will work as intended.
>
> Hans Bezemer
>
> BTW, here is a list of changes to your code:
>
> > cr decimal fclear
> FCLEAR initializes floating point properly
>
> > f% 3300 fvariable Vs latest f! \ In mV, measure it
> > f% 10000 fvariable R0 latest f! \ 10K
> > f% 298.15e0 fconstant T0 \ Temperature in Kelvin at 25C
> > f% 273.15e0 fconstant 0C \ Temperature in Kelvin at 0C
> > f% 0.7556958984e-3 fvariable A_sh latest f!
> > f% 2.334204104e-4 fvariable B_sh latest f!
> > f% 0.6102744539e-7 fvariable C_sh latest f!
> > : 1/f ( F: f - 1/f ) f% 1 fswap f/ ;
> Obviously due to the use of F% and FVALUE conversion
>
> > Vs f@ s>f f- ;
> > fdup R0 f@ f* Vs f@ frot f- f/ ;
> > fln fdup fdup fdup f* f* C_sh f@ f* \ C*(ln(Rnct))^3
> > fswap B_sh f@ f* f+
> > A_sh f@ f+ \ 1/T
> > cr .( A: ) A_sh f@ f.
> > cr .( B: ) B_sh f@ f.
> > cr .( C: ) C_sh f@ f.
> > cr .( Vs: ) Vs f@ f. ( mV )
> > cr .( Resistor R0:) R0 f@ f.
> Obviously to the conversion of FVALUE to FVARIABLE
>
> > cr .( Rt:) f% 29456 fdup f>s . ntc-sh
> Another due to the use of F%
>
> > [defined] adc-mv [if] \ For Cforth on a ESP32:
> Here you got your FIND
>
> > 32 constant /adc_chars
> I don't do prefixed numbers
>
> > /adc_chars floats array &adc_chars
> Here you got my ARRAY
>
> > 1500000 value Mv \ fake sensor reading
> > : read-adc-mv drop Mv 1000 / 10001 choose 5000 - +to Mv ;
> > : init-adc drop drop drop ;
> This is my fake sensor
>
> > cr .( to monitor the NTC.) cr cr
> > [then]
> Obviously - I can't QUIT here
>
> > f% 1.292290081e-3 A_sh f!
> > f% 2.164041451e-4 B_sh f!
> > f% 0.8776278596e-7 C_sh f!
> > f% 0 fvariable av-trim latest f! \ if needed
> > cr .( A ) A_sh f@ f.
> > cr .( B ) B_sh f@ f.
> > cr .( C ) C_sh f@ f.
> > cr .( av-trim :) av-trim f@ f.
> > cr .( Vs :) Vs f@ f.
> > cr .( Resistor R0:) R0 f@ f.
> More FVALUE and F% stuff
>
> > 10 constant #samples
> I don't do prefixed numbers
>
> > 60 constant /ring-buf \ To reduce the ADC noise further
> In 4tH, you can't initialize with a VALUE
>
> > /ring-buf floats array &ring-buf
> Here you got my ARRAY again
>
> > f% 0 ring-buf-count /ring-buf min dup 0
> Obviously due to the use of F%
>
> > dup 3 3 init-adc 3 set-precision
> I just liked a slightly higher precision ;-)
>
> > 0 to ring-buf-count
> I split this line in two lines
>
> > /ring-buf 0 ?do f% 0 &ring-buf i floats + f! loop \ erase
> All memory is zero-ed at startup, but let's stay in the spirit ;-)
>
> > ring-buf-count . av-ntc av-trim f@ f+ f.
> Another victim of FVALUE
>
> > 5 monitor-ntc
> In 4tH, you have to start something. If not, it just compiles it
> and quits immediately.
>
> Running your program (first 12 "measurements"):
>
> $ pp4th -x ntc_sh.4pp
>
> ntc_sh.fth the Steinhart-Hart equation.
>
> ntc-sh ( Rt - Celsius ) can be used.
>
> adc-mv ( adc_chars reading - mV ) is missing.
> See: https://github.com/MitchBradley/cforth/tree/WIP
> Or define your own accurate read-adc-mv and init-adc here
> to monitor the NTC.
>
>
> Parameters for NTC B57164K0103:
> A 0.0012922900810
> B 0.0002164041451
> C 0.0000000877627
>
> av-trim :0.00
> Vs :33
> Resistor R0:10
>
> To monitor the NTC on adc-channel 5 enter: 5 monitor-ntc
>
> Sec C
> 1 21.0
> 2 21.0
> 3 21.0
> 4 21.1
> 5 21.2
> 6 21.2
> 7 21.2
> 8 21.2
> 9 21.2
> 10 21.2
> 11 21.2
> 12 21.2

> I used [DEFINED] for it.
That was an extra problem under Cforth.
Cforth has no [DEFINED].
In the end I was forced to use catch.

Jos

On Sunday, September 25, 2022 at 2:42:20 PM UTC+2, Jos Ven wrote:
> That was an extra problem under Cforth.
> Cforth has no [DEFINED].
> In the end I was forced to use catch.

Well, you won't be able to completely discard that CForth solution,
but according to your own stack comments and those I retrieved
from CForths Github, may be this helps?

: (defined) parse-word $find nip ;
: [defined] (defined) ; immediate
: [undefined] (defined) 0= ; immediate

Unfortunately, I couldn't find any documentation there, so it's
still a guess.

Hans Bezemer

On 27/09/2022 1:27 am, Hans Bezemer wrote:
> On Sunday, September 25, 2022 at 2:42:20 PM UTC+2, Jos Ven wrote:
>> That was an extra problem under Cforth.
>> Cforth has no [DEFINED].
>> In the end I was forced to use catch.
>
> Well, you won't be able to completely discard that CForth solution,
> but according to your own stack comments and those I retrieved
> from CForths Github, may be this helps?
>
> : (defined) parse-word $find nip ;
> : [defined] (defined) ; immediate
> : [undefined] (defined) 0= ; immediate
>
> Unfortunately, I couldn't find any documentation there, so it's
> still a guess.

This def from Cforth indicates $find has unbalanced output:

: $defined ( "name" -- adr len 0 | xt +-1 ) safe-parse-word $find ;

try:

: (defined) $defined ?dup >r 2drop r> ;
: [defined] (defined) ; immediate
: [undefined] (defined) 0= ; immediate

I doubt Cforth was ever intended to be standard.

Op maandag 26 september 2022 om 17:27:04 UTC+2 schreef the.be.om:
> On Sunday, September 25, 2022 at 2:42:20 PM UTC+2, Jos Ven wrote:
> > That was an extra problem under Cforth.
> > Cforth has no [DEFINED].
> > In the end I was forced to use catch.
> Well, you won't be able to completely discard that CForth solution,
> but according to your own stack comments and those I retrieved
> from CForths Github, may be this helps?
>
> : (defined) parse-word $find nip ;
> : [defined] (defined) ; immediate
> : [undefined] (defined) 0= ; immediate
>
> Unfortunately, I couldn't find any documentation there, so it's
> still a guess.
>
> Hans Bezemer

Thanks,

Cforth has [ifdef] so [defined] is not needed.
When I writing ntc_sh.fth I was looking for a
solution that has the least impact.

Jos

On Monday, September 26, 2022 at 7:18:06 PM UTC+2, dxforth wrote:
> This def from Cforth indicates $find has unbalanced output:
> : $defined ( "name" -- adr len 0 | xt +-1 ) safe-parse-word $find ;

Not according to this definition (or the stack comment must be wrong):

: $find ( str cnt -- str 0 | cfa flag ) pad place pad find ;

I can only do a proper job when the documentation is correct ;-)

Hans Bezemer

On Monday, September 26, 2022 at 7:18:06 PM UTC+2, dxforth wrote:
> I doubt Cforth was ever intended to be standard.
I doubt it too. On the other hand, I had little trouble with the rest of it.
I have little trouble with $FIND as well - although I do find its use in
conditional compilation butt ugly.

My eyes always scan for "square bracket" words in order to pick out
the stuff that is compilation specific. Part of that habit is that in 4tH
virtually everything compilation related IS bracketed.

And sure - in the Forth world is not a major sin to make something that
is non-standard. What I find unforgivable is when the most important
words related to picking version specific stuff is missing:

(1) A word or constant related to that specific version - it may double
as something useful, e.g. in 4tH the word 4TH# holds the version number;
(2) [DEFINED] and/or [UNDEFINED].

Ad 1. In C this is pretty common. __TURBOC__, __MINGW__, __GCC__ are
a few examples.

Ad 2. This way you can catch specific stuff like:
[UNDEFINED] gforth [IF] : [IFDEF] [COMPILE] [DEFINED] [COMPILE] [IF] ; [THEN]

It's the easiest way to cater for all those tiny little differences. Although 4tH is not
the champion where standards are concerned, I made plenty of programs that
can be fed to either 4tH or Gforth without any edits.

That's why I'm always a bit, let's say: disappointed when I encounter a compiler
that doesn't get that little thing right.

Hans Bezemer

On 27/09/2022 6:43 am, Hans Bezemer wrote:
> On Monday, September 26, 2022 at 7:18:06 PM UTC+2, dxforth wrote:
>> This def from Cforth indicates $find has unbalanced output:
>> : $defined ( "name" -- adr len 0 | xt +-1 ) safe-parse-word $find ;
>
> Not according to this definition (or the stack comment must be wrong):
>
> : $find ( str cnt -- str 0 | cfa flag ) pad place pad find ;
>
> I can only do a proper job when the documentation is correct ;-)

Seems to be missing from the zip I d/loaded. Not sure I want to dig further...

On 27/09/2022 7:23 am, Hans Bezemer wrote:
> On Monday, September 26, 2022 at 7:18:06 PM UTC+2, dxforth wrote:
>> I doubt Cforth was ever intended to be standard.
>
> I doubt it too. On the other hand, I had little trouble with the rest of it.
> I have little trouble with $FIND as well - although I do find its use in
> conditional compilation butt ugly.
> ...
> And sure - in the Forth world is not a major sin to make something that
> is non-standard.

And surprising since Bradley was such a key player in standardization.
Perhaps he decided to go back to his roots.