Multitasking ?

[f1test]

Hello
Can a multitask work mode be implemented?

It takes 750ms to read the DS18B20 sensors. For 4 sensors, almost 4 seconds are lost.
How can a led blink every 0.5 seconds and still read the sensors?
Is there something like the millis() function from arduino implemented in Annex?

Is it possible to run part of the code on core0 and the other on core1.

Code :
cls
a=1
pin.mode 2, output

while a>0

a=a+1
wlog a
timp1$ = time$
timp1=TIMEUNIX(timp1$)
Print timp1$
print "start time=";timp1
print "1="; tempr$(26,1)
print "2="; tempr$(26,2)
print "3="; tempr$(26,3)
print "4="; tempr$(26,4)
pin(2)=1-pin(2)
pause 500
timp2$=TIME$
timp2=TIMEUNIX(timp2$)
print " end time";timp2$
print timp2
print " run for "; timp2-timp1; " seconds"
Print " Loop ";a-1;" ended"

Print "*"
Print "*"
print "*"
wend

[BeanieBots]

The problem with your particular example is the way Annex reads the DS18B20 sensor.
The DS18B20 uses a one-wire protocol which is very timing critical. The implementation must wait the full 750mS for the full conversion to complete.
During this wait, even interrupts are locked out.
The only way around it is to have several commands added such as 'start conversion' and 'read data'. Or, better still, a fully user controllable one-wire command set. Even then, all other functions would be paused during the time critical one-wire commands. However, these periods would be extremely short and probably negligeable compared to the delay in any form of multitasking overhead.
I did request such functions for one-wire/DS18B20 a while back but so far no response.

Besides the DS18B20, I don't think there are any other cases where processing is blocked (if anyone knows different, please speak up) so threading by use of timers should be possible except when using a DS18B20.
As for sharing between cores, my understanding is that one core is dedicated to WIFI. (again, please speak up if I have this wrong).

[cicciocb]

Hello
Can a multitask work mode be implemented?

It takes 750ms to read the DS18B20 sensors. For 4 sensors, almost 4 seconds are lost.
How can a led blink every 0.5 seconds and still read the sensors?
Is there something like the millis() function from arduino implemented in Annex?

Is it possible to run part of the code on core0 and the other on core1.

Hi,
Annex is already based on multitasking and multi core.

In particular, for the dual core ESP32, one core (the core 0) is mainly dedicated to the network activities and the other for the basic program.
Many activities are done in parallel (for example the music player) mainly on the core 0 aiming to maintain the performances for the basic.

Very few, function / commands are blocking, in particular the onewire such as the DS18B20 that use a very old code coming from the esp8266 version.

It could be possible in the future to modify the actual behavior with a "non blocking" one but, for the moment, I suggest to use sensors based on I2C.

[cicciocb]

The problem with your particular example is the way Annex reads the DS18B20 sensor.
The DS18B20 uses a one-wire protocol which is very timing critical. The implementation must wait the full 750mS for the full conversion to complete.
During this wait, even interrupts are locked out.
The only way around it is to have several commands added such as 'start conversion' and 'read data'. Or, better still, a fully user controllable one-wire command set. Even then, all other functions would be paused during the time critical one-wire commands. However, these periods would be extremely short and probably negligeable compared to the delay in any form of multitasking overhead.
I did request such functions for one-wire/DS18B20 a while back but so far no response.

Besides the DS18B20, I don't think there are any other cases where processing is blocked (if anyone knows different, please speak up) so threading by use of timers should be possible except when using a DS18B20.
As for sharing between cores, my understanding is that one core is dedicated to WIFI. (again, please speak up if I have this wrong).

For the moment this "update" is not in the todo list but this can evolve depending on the general interest

[MarioL]

Hi,
The resolution of the temperature sensor is user-configurable to 9, 10, 11, or 12 bits, which corresponds to increments of 0.5°C, 0.25°C, 0.125°C, and 0.0625°C, respectively.

immagine.png

In many applications an accuracy of 0.25° is permissible.
So a 10-bit conversion in a time interval of 187.5 ms is a good compromise between time and accuracy.
I propose that we consider implementing 10-bit resolution as an alternative at TEMPR$(pin_number [,ID])).
Better if possible to choose the resolution with function like TEMPR$(pin_number [,bit_res] [,ID])).

[cicciocb]

Hi,
The resolution of the temperature sensor is user-configurable to 9, 10, 11, or 12 bits, which corresponds to increments of 0.5°C, 0.25°C, 0.125°C, and 0.0625°C, respectively.

immagine.png

In many applications an accuracy of 0.25° is permissible.
So a 10-bit conversion in a time interval of 187.5 ms is a good compromise between time and accuracy.
I propose that we consider implementing 10-bit resolution as an alternative at TEMPR$(pin_number [,ID])).
Better if possible to choose the resolution with function like TEMPR$(pin_number [,bit_res] [,ID])).

I bought recently some onewire memory chip AT21CS11, I'll profit to update and improve the DS18B20

[BeanieBots]

I bought recently some onewire memory chip AT21CS11, I'll profit to update and improve the DS18B20

Does that mean we might even get a general purpose one-wire command set? Pretty please

[cicciocb]

I don't know, something still to explore ...
Make it easy and documenting, is the biggest obstacle

[Stuart]

Assuming you only want to collect a temperature reading, the DB18B20 one-wire command is in two parts: a) initiate the conversion, and b) go back and get the result. It does not need to be done in a single blocking command. Other systems (e.g. Picaxe) have the primitives to do it this way. The existing tempr$() command must already do it this way internally so it just needs to be split into two parts. You then initialise by starting a conversion, and each time round the loop you read the result and initiate the next conversion. Simples, no time delay of up to 750mS for the hi-res conversions.

[BeanieBots]

What Stuart says.
It should be similar to sending something by I2C.
Define a pin and send data.
eg onewire.setup(pin)
onewwire$(data)
Then a few examples to 'start conversion', 'read temperature', 'parasitic mode', 'resolution' etc.
If a generic onewire command was available, others could add examples for other devices just like has happened with I2C devices.
It would be up to the user to read the datasheet and find what codes need to be sent for their particular device.
Alternatively, just limit it to the DS18B20 with 'start', 'read' and maybe 'parasitic'.
Not sure you would even need to convert to degrees. Just explain that the raw value is * 16C and let the user convert to C or F as required.

Edit:
Example from PICAXE manual.
main:
owout C.1,%1001,($CC,$44) ; send ‘reset’ then ‘skip ROM’ then ‘convert’ then apply ‘pullup’
pause 750 ; wait 750ms with strong pullup
owout C.1,%0001,($CC,$BE) ; send ‘reset’ then ‘skip ROM’ then ‘read temp’ command
owin C.1,%0000,(b0,b1) ; read in result
sertxd (#w0,CR,LF) ; transmit value
goto main

For those not familiar with PICAXE, C.1 is a reference to pin1 on port C, %1001 is a binary notation number and $CC is a number in hex.
Also, PICAXE only has integer variables. 8-bit (byte) or 16-bit (word). Word values can be referenced by each byte.
In the example above, data is read in to two byte values (b0 and b1) by the owin command and then output to the serial port by the sertxd command as a word value (#w0).