Multitasking ?

Code tips and tricks for beginners
f1test
Posts: 16
Joined: Tue Nov 29, 2022 3:13 pm
Has thanked: 2 times
Been thanked: 11 times

Multitasking ?

Post by 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
Posts: 361
Joined: Tue Jun 21, 2022 2:17 pm
Location: South coast UK
Has thanked: 197 times
Been thanked: 115 times

Re: Multitasking ?

Post by 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).
User avatar
cicciocb
Site Admin
Posts: 2195
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: Multitasking ?

Post by cicciocb »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Tue Jan 10, 2023 10:45 pm 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.
User avatar
cicciocb
Site Admin
Posts: 2195
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: Multitasking ?

Post by cicciocb »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Wed Jan 11, 2023 9:23 am 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
Posts: 21
Joined: Sun Mar 21, 2021 8:38 am
Has thanked: 262 times
Been thanked: 35 times

Re: Multitasking ?

Post by 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])).
You do not have the required permissions to view the files attached to this post.
User avatar
cicciocb
Site Admin
Posts: 2195
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: Multitasking ?

Post by cicciocb »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Wed Jan 11, 2023 10:18 am 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
Posts: 361
Joined: Tue Jun 21, 2022 2:17 pm
Location: South coast UK
Has thanked: 197 times
Been thanked: 115 times

Re: Multitasking ?

Post by BeanieBots »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Fri Jan 13, 2023 2:50 pm 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 :)
User avatar
cicciocb
Site Admin
Posts: 2195
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: Multitasking ?

Post by cicciocb »

I don't know, something still to explore ...
Make it easy and documenting, is the biggest obstacle :D
Stuart
Posts: 138
Joined: Fri Feb 19, 2021 7:46 pm
Has thanked: 5 times
Been thanked: 20 times

Re: Multitasking ?

Post by 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
Posts: 361
Joined: Tue Jun 21, 2022 2:17 pm
Location: South coast UK
Has thanked: 197 times
Been thanked: 115 times

Re: Multitasking ?

Post by 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).
Post Reply