How to sleep for short fixed time?

Hi, I’ve been using this lovely scheduler with great success with my Maple clones. However, I am missing one key feature of that scheduler which is the low power mode.
When the scheduler has no tasks to run on that millis(), it’l sleep the MCU for 1 ms. This works great for AVR, but I am having trouble implementing on the STM32Duino side.

I would like to something similar to the AVR side, with a sleep that’s open for all interrupts, especially the millis update interrupt.

According to https://github.com/stm32duino/STM32LowPower , the minimum RTC clock sleep is 1000 ms, so obviously not good.

My current attempt can be found at my fork.

Any pointers would be welcome.

What about this : https://github.com/hocarm/STM32F103-Tut … _hal_pwr.c ?

Or this topics:
https://www.stm32duino.com/viewtopic.php?t=2964
https://www.stm32duino.com/viewtopic.php?t=658

G**gle is your friend

https://www.stm32duino.com/viewtopic.php?t=658

Where do you think I got most of my info and repo links?

try this
//wait for interrupts and events
asm("wfe");


That looks very interesting… I wonder what the effect would be of adding this to your program:
extern "C" void yield(void) {
asm("wfe");
}


note that on stm32 there is only a single thread of execution, henceasm("wfe");

MoDu…

I assume you read AN2629.

Why do you need low-power, unit powered by batteries? Why the task schedular? I’m familiar with FreeRTOS and use it often under Arduino but with the ESP32.

You probably found this old thread about low-power, https://www.stm32duino.com/viewtopic.php?t=298 but that did not have the complexity of a task scheduler.

Personally, you may want to look into FreeRTOS on STM32: https://www.google.com/search?q=freerto … 3+lowpower

hi ray,
i found freertos to be difficult to use in mm/bp that in part due to having only 20k of memory, memory is fragmented in freertos scheme and each task allocated its own stack etc which further fragments memory.
i’m using an event loop
void loop() {
if(systick_fired) {
systick_fired = 0;
EventLoop.processevent();
}
//wait for interrupts and events
asm("wfe");
}

void systick_handler(void) {
systick_fired++;
}


Thank you all for your comments, I’ll report back as soon as get my tools again and do some tests. And apparently there was some reading I missed, so I’m on it first.

[mrburnette – Tue Sep 11, 2018 1:24 am] – Why do you need low-power, unit powered by batteries?

Yes, almost all my projects are battery powered. Besides, I try to make low power as principle, you won’t catch me running delay loops. Maybe it’s because I spent years making BLE devices last months on a coin cell battery :p

[mrburnette – Tue Sep 11, 2018 1:24 am] – Why the task schedular? I’m familiar with FreeRTOS and use it often under Arduino but with the ESP32.

I am very comfortable with OOP oriented schedulers so it’s my first choice: it allows me to build complex timing logic with ease. As for RTOS, I followed that trail for a while but came to the conclusion that the overhead, both memory-wise and project complexity wise, was not worth it for the only (apparent) benefit of more accurate timing, when the scheduler has transparent low/power feature. I also abstracted the Task/Scheduler interface, so I can flip to an RTOS if I want, but so far I love these small schedulers. Besides, most RTOSs are built for C and static functions, hence why I had my shot at layering OOP on top of FreeRTOS on STM32Duino.

things are more elaborate than the simple loop above but this scheme works really well, the stack is unwound after each event handler class handles the event,

Can’t argue with working code.

As for RTOS, I followed that trail for a while but came to the conclusion that the overhead, both memory-wise and project complexity wise, was not worth it for the only (apparent) benefit of more accurate timing, when the scheduler has transparent low/power feature.

You’re a professional, I do not need to try and convince you of anything. Go forth and have fun.

Ray

[mrburnette – Wed Sep 12, 2018 12:44 am] –
You’re a professional, I do not need to try and convince you of anything. Go forth and have fun.

Goodness, I’m no professional, at least not when it comes to Embedded. I took your suggestion seriously because I’m here to learn, that’s why I justified my choice: if you see any fault in my logic or other angle I’m not seeing, please do tell

As for my conclusion, it seems I wasn’t the only one.

[ag123 – Tue Sep 11, 2018 7:29 am] – using this i think it is possible to make things work in mm/bp where otherwise you would run out of memory

Yes, that is the exactly the behaviour I’m replicating, albeit including it in a scheduler library.

MoDu:

I’m educated as an EE and worked in Corporate before retiring in 2010. My coding experience was entirely mini-computers until I purchased a P.E.T. and later an Apple II and started writing in assembler. Later, I wrote using the IBM PC and at that time, even in corporate, 1M of RAM was common and maybe an extended memory card if you were lucky. One learns to be frugile with RAM. And that darn Intel architecture in a P.I.T.A. back in those days.

These days the compiler and linker for ARM are simply wonderful … C++ on an AVR with 2K (or less) of SRAM.

When I asked “why” your explanation was satisfactory – because you can and you are comfortable in your own hacking ability. You are in an elite group here, so I did not have anything to add, except to wish you fun. I certainly do not offer such a response to the majority of the forum users as for the masses, it is best to walk in the middle of the path rather than get off the path and explore in the bush.

Ray

[mrburnette – Wed Sep 12, 2018 12:08 pm] – One learns to be frugile with RAM. And that darn Intel architecture in a P.I.T.A. back in those days.

Bringing back some off-topic reminiscences of playing ‘chess’ on a Sinclair ZX80… Entire application + storage + text mode frame buffer in 1kB of RAM (although I am sure there were some call-outs to routines in the 4kB of ROM). I put ‘chess’ in quotes as the AI opponent was really not very good .

Modern MCUs make the first home computers really look like the dinosaurs that they are…

Ray,

Thank you for your kind words.

These days the compiler and linker for ARM are simply wonderful … C++ on an AVR with 2K (or less) of SRAM.

Couldn’t agree more. It’s the reason I personally fell in love with embedded programming again.