STM32F103C8T6 extreme low power consumption (frequency, periphery)

If you made your own board, post here, unless you built a Maple or Maple mini clone etc
keypunch
Posts: 67
Joined: Tue Aug 02, 2016 2:26 am

Re: STM32F103C8T6 extreme low power consumption (frequency, periphery)

Post by keypunch » Fri Jun 02, 2017 11:04 pm

@ag123

I am likely to run the device on rechargable AA batteries and not a LIPO. Availability is primary factor, and LIPO in colder temperatures is second factor.

For sure not just uC power is part of battery budget calculation. Peripherals for sure, external and built in. Hence my what the real world current draw will be is what I need to know. I asked about the base uC current draw as that is a starting point for choice and what internal functions not using that may reduce current draw before peripherals.

I will be using a DS3231. I assume that will mean the systick counter will not be needed? The design for the personal project I am trying to create has always had a DS3231 in the design from start.

I will not need the USB. I will use an upload method that uses the least flash in terms of overhead. If that means serial download of sketch that will likely be what it will be or maybe STLink.

The primary peripheral has no interrupt. I will likely apply some approach of sleep design in code that uses a timer asuming that does not imply the need for the systick counter to do so.

I may need the 72Mhz later in the greater functionality of the design. I can test the design for the initial base functionality I need to start at 48Mhz to see if that helps in reducting current draw.

I have not decided if and what communications device I will use. The design needs a SD/MicroSD as part of the minimum design. For sure the design only needs the communications device on in what is a user on demand mode. So button or such to toggle on/off when need communications. Expectation is the toggle will be used a couple times a day. How long on I am not sure as depends how long takes to transmit the data. I will not know the transmit time until I prototype one or more communication functionality choices to evaluate. The first stage of functionality will only implement DS3231, SD/MicroSD and one external I2C peripheral that talks to downstream peripherals. The downstream peripherals current draw is about 0.001nA in standby and 1.5mA for a second or less once every several seconds.

Those BLE trackers you mentioned maybe means I would be better using bluetooth communications for data transfer rather than WiFi. Even when a communications device is off it still draws power. The amount of current draw of a idle/off communications device may not be what will make sense for the couple times a day I need the communications device on for. This is similar to the the common suggestion I have a display to display current values. An OLED seems too small and has finite lifespan. A 1602 will be fine for my needs in terms of what would be displayed, but again how much need to look at vs current draw results in my respose to those wanting me to include (Yes it is a one of personal device others may wish to see values the very limited times they wish to.) when I had not even considered doing so in the larger functional design. All I know is a communications device is more important than a display for what I need. If a bluetooth device has low enough current draw when not active doing communications then I will consider. A communication device will be staged above the basic minimum design I have needed for many months. The months delay due mostly to very skewed delivery times big time in order of 120-150 days and odd factor of what I think will be appropriate for what I am trying to acheive that I was wrong about are the delay factors. The former the major reason. When I am incorrect on what I need for a solution I have to figure out what I do to acheive the desired functional goal and then order what I need, ergo adding to the delays.

I was expecting to have a the basic functionality later part of December 2016. I started out my research on if, how, and what I need a year ago. I started my ordering of parts late last summer over to November 2016 where orders as of September 2016 started to take over to well over 60 days. I stopped ordering other parts I would need mostly because I had no idea if what I ordered would arrive. I had no idea orders would take 120-150 days to arrive. That has caused serious delays to what I am trying to make that is important for me and nobody else.

Your points are most helpful.


Regards,

John L. Males
Toronto, Ontario
Canada
02 June 2017 19:04 EDT
02 June 2017 19:42 EDT Typo correction

ag123
Posts: 663
Joined: Thu Jul 21, 2016 4:24 pm

Re: STM32F103C8T6 extreme low power consumption (frequency, periphery)

Post by ag123 » Sat Jun 03, 2017 5:13 pm

the main trouble with systick is *it keeps the mcu awake*
the systick interrupt mainly updates systick_uptime_millis
https://github.com/rogerclarkmelbourne/ ... tick.c#L84
i think this is used by the functions millis(), micros(), and you may be caught off guard but delay() uses millis()
so if you have codes that do

Code: Select all

delay(100) //delay 100ms
you would need to rewrite that not to use delay(),
otherwise once you disable systick interrupt it would run an infinite loop that never exit i.e. infinite delay

doing things the 'tickless' way is the epitome of low power embedded programming, but doing it 'tickless' could mean you need elaborate finite state machines and the whole setup becomes a state-transition based program. e.g. instead of delay(1000) to wait one second, you would need to set a timer interrupt to fire in 1 sec and *call back* your function.
programming changes from call this function to do that
to
don't call us, we'd call you, if there is anything needing your attention
i.e. the system is always asleep, instructions halted except when it is woken up to handle an interrupt
:lol:

in code snippets i've got this 'round robin scheduler' which for now is still pretty much dependent on systick, but of course you could change the systick interval so as to reduce the number of systick interrupts. and of course the ultimate is you simply "WFI" wait for interrupt and that interrupt that you are waiting for is *not systick* (i.e. no systicks) :lol:
http://www.stm32duino.com/viewtopic.php?f=18&t=2117

User avatar
RogerClark
Posts: 6095
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32F103C8T6 extreme low power consumption (frequency, periphery)

Post by RogerClark » Sat Jun 03, 2017 10:32 pm

@ag123

Historically LibMaple used to use nops for delay, but either way, using delay is going to waste power.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest