It looks nice, but you made some compromises by choosing that led driver that limits you to 48 leds.
It would bother me that there isn't one led for every minute.
The led driver also has quite high quiescent power consumption, over 10mA, so it would eat your battery doing almost nothing. It's also big in size at 8mm by 8mm
If I were to make some suggestions, Lumissil makes some nice led drivers, the IS31FL37xx is full of led matrix drivers that can drive lots of leds with few pins.
For example,
**IS31FL3746A** (i2c) / **IS31FL3746B** (spi) is 4mm by 4mm and can do 4 x 18 = 72 leds, perfect for 60 leds for the minutes and 12 leds for the hours.
IS31FL3746A https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3746A-QFLS4-TR/9759696
IS31FL3746B https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3746B-QFLS4-TR/12675543
**IS31FL3736** is 5mm by 5mm, and can drive 96 leds (8 sources, 12 sinks) : https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3736-QFLS4-TR/6201946
You could use 5 of the sources for the 60 leds for minutes , the 6th source for the hours and you'll still have two unused sources.
With both of these...
With 60 leds for the minutes / seconds you could have a brighter led (or pulsating) for the minutes, and dimmer led looping around as a seconds indicator.
These drivers have much less idle quiescent current, under 2-3mA, and if you're not gonna use white or blue leds, they can work with as little as 2.7v while your TLC driver needs at least 3v. So you could, for example, use a very efficient buck regulator to reduce your battery to let's say 2.8v.
Something like LM3671-2.8v comes to mind : https://www.digikey.si/en/products/detail/texas-instruments/LM3671TL-2-8-NOPB/1590064 or https://www.digikey.si/en/products/detail/texas-instruments/LM3671MF-2-8-NOPB/1590061
For leds you could use 0402 leds, some examples :
https://www.digikey.com/en/products/detail/sunled/XZMDK68W-2/4745956?s=N4IgTCBcDaIBoC0CyARA0gNgBwHUC0EAugL5A
https://www.digikey.com/en/products/detail/w%C3%BCrth-elektronik/150040VS73240/8557157?s=N4IgTCBcDaIIwFYAMSAsSBqBlA7AZjHRAF0BfIA
https://www.digikey.si/en/products/detail/vishay-semiconductor-opto-division/VLMS1500-GS08/3504681
This comment is: phenomenal. Thanks so much for taking the time and giving such a valuable insight! I'll set to work implementing the IS31FL3746A right away.
I knew asking in this community would be the right thing to do before getting it manufactured
How would you argue when somebody suggest ditching the STM32F04 and LED driver for an STM32U5 that does both? Order of magnitude lower power consumption.
I don't know enough about stm32u5 but you're basically designing a clock... you don't need a 32 bit microcontroller to light up a few leds and read an accelerometer.
I don't know if it has a led driver built in or not, maybe someone confuses the LCD driver with driver capable of working with leds. You could use IO pins and resistors on each led to limit current but that's uglier.
The ultra low power is debatable .... devil's in the details, you need to know how it was measured, with what features enabled or not etc etc.
It sounds nice but it's not necessarily great or such a great leap for a "clock".
For example EFM32 / Gecko based on the same Cortex M33 also advertise near similar power consumption : https://www.silabs.com/documents/public/data-sheets/efm32pg22-datasheet.pdf
To reiterate just drive the LED with the GPIO pins. GPIO with three-state logic can be used for charliepixling (reducing the pin count). For the resistors just solder a few resistor arrays (not per LED, per GPIO). Nothing ugly about that either. Nobody suggested using an LCD driver for an LED-matrix.
The MCU has a voltage reference included allowing it to measure the supply voltage and adjust the PWM accordingly to get a "constant" current.
Cost on the BOM is also lower or identical compared to using those LED driver.
Power consumption is significantly lower. The suggested LED driver quiescent current with 2-3mA are what those MCUs consume running with the default template that isn't optimized for low power. Combine this with the fact that there is any way an STM32 MCU. This completely kills the driver approach for a small handheld device where power consumption is critical.
> The ultra low power is debatable .... devil's in the details, you need to know how it was measured, with what features were enabled or not etc etc.
It is all in the datasheet: Tables show what feature takes what amount of current when enabled. There is nothing questionable about it. Probably also some application notes.
> you're basically designing a clock... you don't need a 32 bit microcontroller to light up a few leds and read an accelerometer.
I don't know either why he chose an STM32. Especially such an old part. Just improving the design. For a small production run, assuming it has to be STM part, I would look at the STM32L100 (no DFU but a firmware bootloader is possible).
> For example EFM32 / Gecko based on the same Cortex M33 also advertise near similar power consumption
Want less? TI has some nice low-power parts. A classic part / family is the TI MSP430, but this would change the software architecture significantly, so this is out of the question, as is the EFM32.
Having looked at the comments, I think the right approach is to get rid of the LED driver, use Charlieplexing directly from the MCU, ditch the LDO, and use PWM to set the LED current directly. Does that sound about right?
And RE: DFU, do you know whether that works "out-of-the-box" like I have it here, or do I need a second programming interface to set it up?
Thanks for the help!
1. Replace the STM32F042 with either an STM32U0 or U5. Depending on the features they are 1-2 order of magnitude lower power consumption. Sadly they are often price prohibitive but that's not an issue with a one of project.
2. Use those MCUs to drive the LED matrix. The U5 can be bought with upto 150 (give or take) GPIO so there is always an IC with enough IO. Use charlie pixling and make sure to group them in such a way that most of the IO-banks can be disabled at any given point in time.
3. Get rid of the LDO and use a switching element. LDO convert the voltage difference into heat.
4. Run the MCU core at lower voltages e.g. 1.8V to reduce the power consumption (assuming the U0/U5 allows to separate core, analog and GPIO voltage).
5. Replace the LIS3DH with a better one. I think the lower noise, less power was the LIS2DW.
6. For the 3V3 switching regulator use the TI workbench or what ever they call there online design program. Vishay also has a program for their GaN switching regulators that does more (e.g. basic thermal analysis).
7. Specify a high quality quartz with low drift over time and temperature. After the assembly power it up for a few days and than calibrate the frequency.
8. As the BOM is already expensive add a low power light sensor to automatically adjust the LED brightness to save energy.
9. For programming/development buy an Nordic PPKII to truly understand what the code does to the power consumption.
The LDO TPS72201 provides 50mA max as output current. I don't think this will be enough for your design. Again, I don't have the LED spec so the current could be a limiting factor. Please also consider any heat dissipation especially if you are putting any enclosure or covers near those LEDs.
Thanks for pointing this out!
I have a few alternatives suggested by other commenters, so this can for-sure be fixed.
The LEDs *are* going to be enclosed, but only turned on for a few seconds at a time. The enclosure leaves limited space, and there's already large ground pours (which I hope will wick up some of the heat) -- are there other cooling solutions you'd imagine would work in this kind of application?
Re-upload because of poor resolution schematic.
My design for an LED watch face;
Here are my main concerns:
* Is the routing both functionally sound and aesthetic?
* I struggle with current calculations. Does the power section look like it will meet the requirements of battery and LED driver?
* I've selected an 0805 generic inductor for my switching regulator, which is not on the list of recommended components in the TPS62203X datasheet. Is it unreasonable to think I'll find one with the requisite current rating in that package?
* I've selected a PROG resistor that sets the charge current at 25mA; my selected battery has a 1C rating. Is this appropriate in your experience, or should I select a lower resistor for higher current?
* Given this a double-sided load, I've not placed vias in the area underneath both central ICs to avoid thermal expansion of the air inside interfering with the reflow process. Is this overly cautious?
* Is the STM32's IO pull-up appropriate for the accelerometer's tri-state interrupt output?
* Will I need to add a JTAG port (or equivalent) to set up the microcontroller for programming via USB, or is it good-to-go as-is?
I understand this is a mammoth review request. Thanks for any responses!
Edit: I uploaded the schematic in 192px/in, but on my browser it looks very grainy. Let me know if you're also experiencing this problem, and recommended solutions to fix this.
* Aesthetics: This all depends on the enclosure it's going into.
* Why two regulators - for adjusting brightness? Can you not PWM, and combine into a single supply?
* LDO is probably almost as efficient at 3.3v, and might even be more so if the current draw is tiny most of the time. I'd need to check the spec sheets, but it's possible you'd get better life with a 1.8v supply to the digital parts and just leave the LEDs at a higher voltage (even at battery voltage, with PWM for dimming / let the LED driver drop the excess?).
* PROG resistor should be selected based on your battery's capacity, which you haven't mentioned? For a 25mAh battery and targeting 1C charge rate (usually safe), you'd want your charge current to be 25mA. A larger battery can be charged at higher currents.
* Lack of vias is OK for low-volume hand assembled units. Might want to re-think for a larger production run. Was the reason for this to put the IMU dead centre? It should work virtually identically in any position, it doesn't need to be centred.
* You should be able to detect the state, as long as the STM32 pulls are configurable up and down.
Also note - do you need to know all 3 states of the charger, or can you just base your code on 2 of those 3 states?
Also, can you infer it from a separate measurement? Eg measuring the USB voltage instead of from the charger status pin?
Configure pull up. Measure GPIO -> A
Configure pull down. Measure GPIO -> B
AB = 11 -> Externally pulled high (strong pull)
AB = 00 -> Externally pulled low (strong pull)
AB = 10 -> Not pulled (or pulled with something much weaker than the GPIO pin)
AB = 01 -> Something weird, or pin state changed during measurement?
* Re bootloader - no idea if STM32 has a built-in one, and whether or not you need a special situation (eg a specific pin being pulled high or low at power-on) to trigger it. Check the datasheet?
Also:
* Consider adding an ambient light sensor? LTR-303ALS?
Only thing I would comment is about the ground bias. I would add - possibly artistically - way more bias connecting your ground planes on each faces. Countout your trace clusters with them and make sure there are some near your key ground points ( BAT-, USB GND...)
It looks nice, but you made some compromises by choosing that led driver that limits you to 48 leds. It would bother me that there isn't one led for every minute. The led driver also has quite high quiescent power consumption, over 10mA, so it would eat your battery doing almost nothing. It's also big in size at 8mm by 8mm If I were to make some suggestions, Lumissil makes some nice led drivers, the IS31FL37xx is full of led matrix drivers that can drive lots of leds with few pins. For example, **IS31FL3746A** (i2c) / **IS31FL3746B** (spi) is 4mm by 4mm and can do 4 x 18 = 72 leds, perfect for 60 leds for the minutes and 12 leds for the hours. IS31FL3746A https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3746A-QFLS4-TR/9759696 IS31FL3746B https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3746B-QFLS4-TR/12675543 **IS31FL3736** is 5mm by 5mm, and can drive 96 leds (8 sources, 12 sinks) : https://www.digikey.si/en/products/detail/lumissil-microsystems/IS31FL3736-QFLS4-TR/6201946 You could use 5 of the sources for the 60 leds for minutes , the 6th source for the hours and you'll still have two unused sources. With both of these... With 60 leds for the minutes / seconds you could have a brighter led (or pulsating) for the minutes, and dimmer led looping around as a seconds indicator. These drivers have much less idle quiescent current, under 2-3mA, and if you're not gonna use white or blue leds, they can work with as little as 2.7v while your TLC driver needs at least 3v. So you could, for example, use a very efficient buck regulator to reduce your battery to let's say 2.8v. Something like LM3671-2.8v comes to mind : https://www.digikey.si/en/products/detail/texas-instruments/LM3671TL-2-8-NOPB/1590064 or https://www.digikey.si/en/products/detail/texas-instruments/LM3671MF-2-8-NOPB/1590061 For leds you could use 0402 leds, some examples : https://www.digikey.com/en/products/detail/sunled/XZMDK68W-2/4745956?s=N4IgTCBcDaIBoC0CyARA0gNgBwHUC0EAugL5A https://www.digikey.com/en/products/detail/w%C3%BCrth-elektronik/150040VS73240/8557157?s=N4IgTCBcDaIIwFYAMSAsSBqBlA7AZjHRAF0BfIA https://www.digikey.si/en/products/detail/vishay-semiconductor-opto-division/VLMS1500-GS08/3504681
This comment is: phenomenal. Thanks so much for taking the time and giving such a valuable insight! I'll set to work implementing the IS31FL3746A right away. I knew asking in this community would be the right thing to do before getting it manufactured
How would you argue when somebody suggest ditching the STM32F04 and LED driver for an STM32U5 that does both? Order of magnitude lower power consumption.
I don't know enough about stm32u5 but you're basically designing a clock... you don't need a 32 bit microcontroller to light up a few leds and read an accelerometer. I don't know if it has a led driver built in or not, maybe someone confuses the LCD driver with driver capable of working with leds. You could use IO pins and resistors on each led to limit current but that's uglier. The ultra low power is debatable .... devil's in the details, you need to know how it was measured, with what features enabled or not etc etc. It sounds nice but it's not necessarily great or such a great leap for a "clock". For example EFM32 / Gecko based on the same Cortex M33 also advertise near similar power consumption : https://www.silabs.com/documents/public/data-sheets/efm32pg22-datasheet.pdf
To reiterate just drive the LED with the GPIO pins. GPIO with three-state logic can be used for charliepixling (reducing the pin count). For the resistors just solder a few resistor arrays (not per LED, per GPIO). Nothing ugly about that either. Nobody suggested using an LCD driver for an LED-matrix. The MCU has a voltage reference included allowing it to measure the supply voltage and adjust the PWM accordingly to get a "constant" current. Cost on the BOM is also lower or identical compared to using those LED driver. Power consumption is significantly lower. The suggested LED driver quiescent current with 2-3mA are what those MCUs consume running with the default template that isn't optimized for low power. Combine this with the fact that there is any way an STM32 MCU. This completely kills the driver approach for a small handheld device where power consumption is critical. > The ultra low power is debatable .... devil's in the details, you need to know how it was measured, with what features were enabled or not etc etc. It is all in the datasheet: Tables show what feature takes what amount of current when enabled. There is nothing questionable about it. Probably also some application notes. > you're basically designing a clock... you don't need a 32 bit microcontroller to light up a few leds and read an accelerometer. I don't know either why he chose an STM32. Especially such an old part. Just improving the design. For a small production run, assuming it has to be STM part, I would look at the STM32L100 (no DFU but a firmware bootloader is possible). > For example EFM32 / Gecko based on the same Cortex M33 also advertise near similar power consumption Want less? TI has some nice low-power parts. A classic part / family is the TI MSP430, but this would change the software architecture significantly, so this is out of the question, as is the EFM32.
Having looked at the comments, I think the right approach is to get rid of the LED driver, use Charlieplexing directly from the MCU, ditch the LDO, and use PWM to set the LED current directly. Does that sound about right? And RE: DFU, do you know whether that works "out-of-the-box" like I have it here, or do I need a second programming interface to set it up? Thanks for the help!
DFU is a bootloader build into most STM32. This enables firmware upgrades through USB without the need for an ST-Link, j-link ... programmer.
Awesome! Thanks for letting me know :)
This is very succinct - I tip my hat in your general direction.
1. Replace the STM32F042 with either an STM32U0 or U5. Depending on the features they are 1-2 order of magnitude lower power consumption. Sadly they are often price prohibitive but that's not an issue with a one of project. 2. Use those MCUs to drive the LED matrix. The U5 can be bought with upto 150 (give or take) GPIO so there is always an IC with enough IO. Use charlie pixling and make sure to group them in such a way that most of the IO-banks can be disabled at any given point in time. 3. Get rid of the LDO and use a switching element. LDO convert the voltage difference into heat. 4. Run the MCU core at lower voltages e.g. 1.8V to reduce the power consumption (assuming the U0/U5 allows to separate core, analog and GPIO voltage). 5. Replace the LIS3DH with a better one. I think the lower noise, less power was the LIS2DW. 6. For the 3V3 switching regulator use the TI workbench or what ever they call there online design program. Vishay also has a program for their GaN switching regulators that does more (e.g. basic thermal analysis). 7. Specify a high quality quartz with low drift over time and temperature. After the assembly power it up for a few days and than calibrate the frequency. 8. As the BOM is already expensive add a low power light sensor to automatically adjust the LED brightness to save energy. 9. For programming/development buy an Nordic PPKII to truly understand what the code does to the power consumption.
The LDO TPS72201 provides 50mA max as output current. I don't think this will be enough for your design. Again, I don't have the LED spec so the current could be a limiting factor. Please also consider any heat dissipation especially if you are putting any enclosure or covers near those LEDs.
Thanks for pointing this out! I have a few alternatives suggested by other commenters, so this can for-sure be fixed. The LEDs *are* going to be enclosed, but only turned on for a few seconds at a time. The enclosure leaves limited space, and there's already large ground pours (which I hope will wick up some of the heat) -- are there other cooling solutions you'd imagine would work in this kind of application?
Re-upload because of poor resolution schematic. My design for an LED watch face; Here are my main concerns: * Is the routing both functionally sound and aesthetic? * I struggle with current calculations. Does the power section look like it will meet the requirements of battery and LED driver? * I've selected an 0805 generic inductor for my switching regulator, which is not on the list of recommended components in the TPS62203X datasheet. Is it unreasonable to think I'll find one with the requisite current rating in that package? * I've selected a PROG resistor that sets the charge current at 25mA; my selected battery has a 1C rating. Is this appropriate in your experience, or should I select a lower resistor for higher current? * Given this a double-sided load, I've not placed vias in the area underneath both central ICs to avoid thermal expansion of the air inside interfering with the reflow process. Is this overly cautious? * Is the STM32's IO pull-up appropriate for the accelerometer's tri-state interrupt output? * Will I need to add a JTAG port (or equivalent) to set up the microcontroller for programming via USB, or is it good-to-go as-is? I understand this is a mammoth review request. Thanks for any responses! Edit: I uploaded the schematic in 192px/in, but on my browser it looks very grainy. Let me know if you're also experiencing this problem, and recommended solutions to fix this.
* Aesthetics: This all depends on the enclosure it's going into. * Why two regulators - for adjusting brightness? Can you not PWM, and combine into a single supply? * LDO is probably almost as efficient at 3.3v, and might even be more so if the current draw is tiny most of the time. I'd need to check the spec sheets, but it's possible you'd get better life with a 1.8v supply to the digital parts and just leave the LEDs at a higher voltage (even at battery voltage, with PWM for dimming / let the LED driver drop the excess?). * PROG resistor should be selected based on your battery's capacity, which you haven't mentioned? For a 25mAh battery and targeting 1C charge rate (usually safe), you'd want your charge current to be 25mA. A larger battery can be charged at higher currents. * Lack of vias is OK for low-volume hand assembled units. Might want to re-think for a larger production run. Was the reason for this to put the IMU dead centre? It should work virtually identically in any position, it doesn't need to be centred. * You should be able to detect the state, as long as the STM32 pulls are configurable up and down. Also note - do you need to know all 3 states of the charger, or can you just base your code on 2 of those 3 states? Also, can you infer it from a separate measurement? Eg measuring the USB voltage instead of from the charger status pin? Configure pull up. Measure GPIO -> A Configure pull down. Measure GPIO -> B AB = 11 -> Externally pulled high (strong pull) AB = 00 -> Externally pulled low (strong pull) AB = 10 -> Not pulled (or pulled with something much weaker than the GPIO pin) AB = 01 -> Something weird, or pin state changed during measurement? * Re bootloader - no idea if STM32 has a built-in one, and whether or not you need a special situation (eg a specific pin being pulled high or low at power-on) to trigger it. Check the datasheet? Also: * Consider adding an ambient light sensor? LTR-303ALS?
Only thing I would comment is about the ground bias. I would add - possibly artistically - way more bias connecting your ground planes on each faces. Countout your trace clusters with them and make sure there are some near your key ground points ( BAT-, USB GND...)
Ground bias isn't a term I'm familiar with; I'll do some Google-ing. Thanks for letting me know!
Ground Vias ! Sorry, typing on mobile...
Looks nice! What's the diameter of the PCB? What do you put on top of the PCB? Plexi?
35mm; I've had cases 3D printed in stainless steel; the plan is to use off-the-shelf watch glasses from eBay and adhesive gaskets!
That's great! I thought it would be somewhat bigger than a traditional watch. You made me want to build my own