STM8L: implement BG task with the RTC and Wakeup-Timer peripherial

[TG9541]

During an exploration of the STM8L LSE and RTC features I got the following idea:

It may be possible to substitute the TIMx in the STM8 eForth with the "Wakup timer". That would have the advantage that "Active halt" can be used for applications when the console is not needed. Another application would be a BG like feature for the RTC "Alarm A" event. As it uses the same interrupt is the "Wakeup timer" the BG context could be used twice. A possible way for implementing that is refactoring the BG context switch code so that it can be replaced in STM8L applications.

In order to do this the BG task code, including timer initialization, should be factored out of forth.asm so that the option HAS_BACKGROUND can be used for words that need to be "BG-aware".

[TG9541]

I have a POC with the Wakup-Timer running the background task.

An STM8L051F3 with a 10ms background task and my experimental low power console draws a supply current below 20µA.

The spikes starting just before "+1000" in the DEB1 line show the 'IDLE task going back to HALT, waiting for the next console input or for the next Wakeup-Timer event.

[TG9541]

I put the code and a description of the solution into the Gist STM8L051F3: Experimenting with a low-power console .

There is no reason why this shouldn't work with the STM8S AWU peripheral and the 128kHz LSI. Power consumption is expected to be a bit higher but still in the useful range for battery powered applications.

[happytm]

Thank you for your excellent work. I would like to create low power solution for a project where IR receiver is used as a wakeup source like circuit described in last page of following link:

https://www.vishay.com/docs/80067/appoverview.pdf

Is it possible?
Thanks.

[VK6TT]

Yes, I'm confident this could be done. Feel free to ask for help as required as you attempt this. Kind regards Richard

…

On 14/07/2022 9:40 am, happytm wrote: Thank you for your excellent work. I would like to create low power solution for a project where IR receiver is used as a wakeup source like circuit described in last page of following link: https://www.vishay.com/docs/80067/appoverview.pdf Is it possible? Thanks. — Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE7PE247DYRJIZEAV366NYDVT5VXVANCNFSM4TE3JUKQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TG9541]

@happytm as @VK6TT already confirmed that's possible. Low power applications require a fair share of experimenting - independent of the programming language used.

The IR receiver you mention has a specified supply current of 350µA and a standby current of 3.5µA (in the same order as a well tuned STM8L chip). This means that for operation with a small battery (e.g., an LR2032) your application should "know" when to look for a signal. Otherwise the battery life would have to be measured in hours, not months).

[happytm]

@VK6TT and @TG9541 Thank you for you valuable feedback. I think just like app note I would wake STM8L chip for 2 ms and let it sleep for 200 ms. The IR transmission should start with pre-burst of minimum of 202 ms from another mains powered device within few meters with line of sight. That way battery powered never misses IR command from mains powered device.

Thank again.

[TG9541]

@happytm that sounds like a good plan. The overall power consumption might well be within 20µA which means about 1 year of operation from a humble LR2032.
As a hint: a particularly power conserving mode of operation would be the following:

1. active halt
2. WUT interrupt 200ms
3. set IR receiver active
4. set WUT 2ms
5. active halt
6. a) WUT interrupt 2ms, or b) pin-change-interrupt from IR receiver, decode signal
7. set IR receiver stand-by
8. set WUT 198ms
9. active halt -> 2.

It might even be possible to use the pin change interrupt for decoding the signal

[happytm]

@TG9541 Thank you for your suggestions. I just found out about your repository couple of days ago so I am still reading all your material available and try to understand everything.

[VK6TT]

Here is some code I used within a recent project where a receiver was decoding a datastream. The hardware and LiPo battery was all in a credit card size box  about 6mm thick and I managed to squeeze around 20 days out of a charge. I had to do a lot of stuff to tightly control the receiver start up times etc. The actual power consumed by the STM8 was largely irrelevant in the end. The receiver consumed 20mA when running and a data packet was approaching 100mS in length. Some of this might help you, especially the code to set up for low power running and the way I paused the micro for pre-definded lengths of time. I never slowed down the STM8 clock but it was a possibility to be aware of. Once the case was sealed I had no external reset switch, instead I had a reed relay inside the case so a magnet could be used to reset. As such so I had to go to great lengths to automatically reset if no valid signal had been received within a pre-defined time since I hadn't planned to be the person wearing this device. Maybe it will help in some way. Regards Richard \ NAMING CONVENTION \ xxxxx? RETURNS -1|0 \ ?XXXX IS A VARIABLE HOLDING A FLAG \ %XXXXX IS A COUNT \ 'XXXX IS A CONSTANT REPRESENTING AN ADDRESS \ \ TODO: \ \ slow STM8 clock to 1 MHz \ for STM8s0003 : ]C! $35 C, SWAP C, , ] ; IMMEDIATE : ]B? ( c-addr bit -- f )      $905F , 2* $7201 + , , $0290 , $5A5A , $5AFF , ] ; IMMEDIATE : ]B! ( 1|0 addr bit -- )   ROT 0= 1 AND SWAP 2* $10 + + $72 C, C, , ] ; IMMEDIATE $50F0 CONSTANT AWU_CSR1 $800E CONSTANT INT_AWU $50D1 CONSTANT WWDG_CR $8016 CONSTANT EXTI0 \ vector address $7F60 CONSTANT CFG_GCR \ NEW 150320 $50D1 CONSTANT WWDG_CR $500B CONSTANT PC_IDR $50F1 CONSTANT AWU_APR $50F2 CONSTANT AWU_TBR VARIABLE %RST VARIABLE RST_STEP : (PAUSE) \ inner pause loop which encodes the STM8 `HALT` instruction   [ 16 AWU_CSR1 ]C! \ enable AWU   [ $8E C, ] \ HALT for AWU period   [ $0 AWU_TBR ]C! \ to minimise power consumption   ; : PAUSE20 ( -- )    \ halt for 20ms   [ 40 AWU_APR ]C! [ 7 AWU_TBR ]C!  \ load AWU registers   (pause) ; : PAUSE500 ( -- )    \ halt for 500ms   [ 62 AWU_APR ]C! [ $B AWU_TBR ]C!   \ load AWU regs    (pause) ; : PAUSE1824 ( -- )    \ halt for 1824ms  [ 57 AWU_APR ]C! [ $D AWU_TBR ]C!   (pause) ; : SLEEP \ effectively turn off    [ $0 AWU_TBR ]C! \ reduce power consumption    [ 1 PA_CR2 _MUT ]B! \ enable ext int.    [ $8E C, ] \ the HALT instruction ; \ wake-up after about 1.8 seconds :NVM              \ interrupt handler, "headerless" code    SAVEC    AWU_CSR1 C@ \ reading clears the interrupt    IRET ;NVM ( xt ) INT_AWU ! \ EXTI0 handler, forces power on reset :NVM              \ interrupt handler, "headerless" code    SAVEC    [ $80  WWDG_CR ]C! \ lets pretend power on reset    IRET ;NVM ( xt ) EXTI0 ! : RST60S ( -- )    \ halt for 60SECS AND RESET    \ turn off all my hardware with code that was here   [ 20 AWU_APR ]C! [ $F AWU_TBR ]C!   \ load AWU registers    (PAUSE)    [ $80  WWDG_CR ]C!  \ FORCE reset  ; RAM WIPE NVM \ ********** BACKGROUND STUFF : myBG    ' Some Code executing every 82ms was here ; ' myBG constant BCKGND $530E CONSTANT TIM2_PSCR : BGon    $7 TIM2_PSCR C! \ PRESCALER NOW 128, NOT 8 ($3)                    \ 16 TIMES SLOWER BACKGROUND TICK NOW 82 MS    BCKGND BG ! ; \ ^********** BACKGROUND STUFF RAM $5235 CONSTANT UART_CR2 $505A CONSTANT FLASH_CR1 $50C0 CONSTANT CLK_ICKR NVM : SET_LP \ setup for low power    [ $00 UART_CR2 ]c! \ DISABLE UART    [ $f0 CLK_PCKENR1 ]C! \ clock off uart, SPI and I2C new010420    [ 1 FLASH_CR1 2 ]B!  \ new 070320    [ 1 CLK_ICKR 5 ]B! \ MVRoff    \ FLASH and MVR should reduce current 200uA in active halt ; : >RSTCNT ( n -- ) \ delay IN SECONDS before a reset \ every 82 ms increment count. \ At $0800 we reset    1000 * 82 / $800 swap /    DUP    0= IF DROP 1 THEN    RST_STEP !    0 %RST !    ; : main    SET_LP    20 >RSTCNT    BGon    DATA@ \ GO SEE IF WE CAN GET DATA    begin       ACTION }SLEEP }PAUSE2S BATTCHK    again ; RAM WIPE NVM ' MAIN 'Boot ! RAM

…

On 15/07/2022 6:21 am, happytm wrote: @TG9541 <https://github.com/TG9541> Thank you for your suggestions. I just found out about your repository couple of days ago so I am still reading all your material available and try to understand everything. — Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE7PE24CB4TYY7MH3J6Q5VLVUCHILANCNFSM4TE3JUKQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[happytm]

Thank you Richard for the code.

[happytm]

@TG9541 & @VK6TT I have been playing with low power sensor network using 802.11 wifi communication using ESP32 for quite some time and I have created good working proof of concept at:
https://github.com/happytm/BatteryNode/blob/master/examples/test/802.11_Gateway.ino
https://github.com/happytm/BatteryNode/blob/master/examples/test/802.11_remote_battery.ino
https://github.com/happytm/BatteryNode/blob/master/examples/test/802.11_remote_mains.ino

In theory 802.11_remote_battery.ino code is very efficient for conserving battery power (LIR2450 - 100 mAh). If there is enough sleep time for remote sensor battery can last long time. Remote sensors send their data at predefined interval but sometimes Gateway or remote_mains device need sensor data from remote_battery device urgently then gateway or remote_mains can send IR code and this IR circuit can wakeup the remote_battery device before it's predefined wake up time to send sensor data either by transmitting IR code or in case of ESP32 device by sending 802.11 frame.

This is my planned use case.
Thanks.

[TG9541]

@VK6TT thanks for the code - I've added a link to the Wiki example code page (it might be worth putting that into a GitHub Gist).

• a word like (pause) that also accepts a pause time value would make "pausing" even easier
• the Forth Standard words DEFER .. IS (in the library since 2.2.29) makes adding changeable "task code" really easy (e.g., in stm8ef-modbus declare handler and define handler)

[TG9541]

@TG9541 & @VK6TT I have been playing with low power sensor network using 802.11 wifi communication using ESP32 for quite some time and I have created good working proof of concept ...
This is my planned use case. Thanks.

That's interesting - using IR for waking up RF communication. I've once thought about an IR only "very-low-bandwitdh opportunistic" network that operates more like a slow-motion swarm of fireflies than like a military operation.