Author Topic: STM32, ghetto style  (Read 149380 times)

0 Members and 1 Guest are viewing this topic.

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #300 on: November 03, 2014, 12:20:26 am »
I don't have your chip so I cannot tell you how it will work on a F05.

However, I tried the following on a F03 chip and it works as expected.

Here is the code:

Code: [Select]
#include <stm32f0xx.h> //stm32f030f4
#include "stm32f0xx_rcc.h" //we use rcc
#include "gpio.h"

//connection
#define LED_PORT GPIOA
#define LED_A (1<<1)
#define LED_C (1<<2)

void SystemCoreClockHSIPLL2(uint32_t RCC_PLLMul_x) {
RCC_DeInit(); //reset rcc
RCC_PLLCmd(DISABLE); //disable PLL
RCC_HSICmd(ENABLE); //enable hsi;
RCC_HCLKConfig(RCC_SYSCLK_Div1); //set sysclk divider
//RCC_PCLK1Config(RCC_HCLK_Div1); //set pclk1/2 dividers
//RCC_PCLK2Config(RCC_HCLK_Div1);
/**

* @brief  Configures the PLL clock source and multiplication factor.
* @note   This function must be used only when the PLL is disabled.
*
* @param  RCC_PLLSource: specifies the PLL entry clock source.
*          This parameter can be one of the following values:
*            @arg RCC_PLLSource_HSI_Div2: HSI oscillator clock selected as PLL clock source
*            @arg RCC_PLLSource_PREDIV1: PREDIV1 clock selected as PLL clock entry
*            @arg RCC_PLLSource_HSI48 HSI48 oscillator clock selected as PLL clock source, applicable only for STM32F072 devices
*            @arg RCC_PLLSource_HSI: HSI clock selected as PLL clock entry, applicable only for STM32F072 devices
* @note   The minimum input clock frequency for PLL is 2 MHz (when using HSE as
*         PLL source).
*
* @param  RCC_PLLMul: specifies the PLL multiplication factor, which drive the PLLVCO clock
*          This parameter can be RCC_PLLMul_x where x:[2,16]
*
* @retval None
*/
RCC_PLLConfig(RCC_CFGR_PLLSRC_HSI_Div2, RCC_PLLMul_x); //configure pll / divider. _x=[2..16]
RCC_PLLCmd(ENABLE); //enable pll
while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET) continue; //wait for pll to be ready
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); //set pll as sysclk
while (RCC_GetSYSCLKSource() != RCC_CFGR_SWS_PLL/*0x08*/) continue; //wait for PLL to be ready

SystemCoreClockUpdate(); //update SystemCoreClock
}

//delays some
void delay(uint32_t dly) {
while (dly--) NOP();
}

int main(void) {
mcu_init();
SystemCoreClockHSIPLL2(RCC_PLLMul_12); //go to 48Mhz
PIN_SET(LED_PORT, LED_A); PIN_OUT(LED_PORT, LED_A);
PIN_CLR(LED_PORT, LED_C); PIN_OUT(LED_PORT, LED_C);
while(1) {
PIN_FLP(LED_PORT, LED_A | LED_C);
delay(100000);
    }
}

In addition to SystemCoreClock, the speed at which the led is blinked varies visibly as I change the PLL multiplier.

So your issues are probably somewhere else.

Tried it and again it fails with the PLL enabling.
Fixed the flash referencing thing though, apparently i had a filter set on my source folders  :palm: .
I'm gonna swap the chip out tomorrow with a new one, maybe the chip got overheated or smth..

Exact code that i used:
Code: [Select]
#include <stm32f0xx.h> //stm32f030f4
#include "stm32f0xx_rcc.h" //we use rcc
#include "stm32f0xx_gpio.h"


//connection
#define LED_PORT GPIOF
#define LED_A (1<<6)
#define LED_C (1<<7)

void SystemCoreClockHSIPLL2(uint32_t RCC_PLLMul_x) {
RCC_DeInit(); //reset rcc
RCC_PLLCmd(DISABLE); //disable PLL
RCC_HSICmd(ENABLE); //enable hsi;
RCC_HCLKConfig(RCC_SYSCLK_Div1); //set sysclk divider
//RCC_PCLK1Config(RCC_HCLK_Div1); //set pclk1/2 dividers
//RCC_PCLK2Config(RCC_HCLK_Div1);
/**

* @brief  Configures the PLL clock source and multiplication factor.
* @note   This function must be used only when the PLL is disabled.
*
* @param  RCC_PLLSource: specifies the PLL entry clock source.
*          This parameter can be one of the following values:
*            @arg RCC_PLLSource_HSI_Div2: HSI oscillator clock selected as PLL clock source
*            @arg RCC_PLLSource_PREDIV1: PREDIV1 clock selected as PLL clock entry
*            @arg RCC_PLLSource_HSI48 HSI48 oscillator clock selected as PLL clock source, applicable only for STM32F072 devices
*            @arg RCC_PLLSource_HSI: HSI clock selected as PLL clock entry, applicable only for STM32F072 devices
* @note   The minimum input clock frequency for PLL is 2 MHz (when using HSE as
*         PLL source).
*
* @param  RCC_PLLMul: specifies the PLL multiplication factor, which drive the PLLVCO clock
*          This parameter can be RCC_PLLMul_x where x:[2,16]
*
* @retval None
*/
RCC_PLLConfig(RCC_CFGR_PLLSRC_HSI_Div2, RCC_PLLMul_x); //configure pll / divider. _x=[2..16]
RCC_PLLCmd(ENABLE); //enable pll
while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET) continue; //wait for pll to be ready
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); //set pll as sysclk
while (RCC_GetSYSCLKSource() != RCC_CFGR_SWS_PLL/*0x08*/) continue; //wait for PLL to be ready

SystemCoreClockUpdate(); //update SystemCoreClock
}

//delays some
void delay(uint32_t dly) {
while (dly--) asm("NOP");
}

int main(void) {
SystemCoreClockHSIPLL2(RCC_PLLMul_12); //go to 48Mhz
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOF, ENABLE);
GPIO_InitTypeDef gis;
gis.GPIO_Mode = GPIO_Mode_OUT;
gis.GPIO_OType = GPIO_OType_PP;
gis.GPIO_Pin = LED_A | LED_C;
gis.GPIO_PuPd = GPIO_PuPd_NOPULL;
gis.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(LED_PORT,&gis);
LED_PORT->ODR &= ~(LED_A | LED_C);

while(1) {
LED_PORT->ODR ^= (LED_A | LED_C);
delay(100000);
    }
}
« Last Edit: November 03, 2014, 12:27:07 am by Ribster »
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #301 on: November 03, 2014, 12:30:36 am »
You will need to route clock to the led port, and one of the two pins should be set and the other cleared - unless you used a probe on the pins.

If you don't have the led connected, you should check the value of SystemCoreClock while stepping through the code.

To see if the chip is damaged, you can simply boot up to main() and just flip the pins - commenting out the PLL portion of the code. If it doesn't run, the issue is somewhere else.
================================
https://dannyelectronics.wordpress.com/
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #302 on: November 03, 2014, 09:25:58 pm »
Small update: Just tested the code on an STM32F051 discovery board and it does work as expected.
I'm going to desolder the sucker, i'm not trusting this. Thanks everybody for the help so far. I've learned a lot in the process.
And sorry for hijacking your thread, but i thought it was relevant and knew you could help me ;).

Greetings
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #303 on: November 04, 2014, 05:51:01 pm »
I'm using CooCox now. Fully on Windows. When i program my board to use your code it only works when i use a multiplier of 2.
So i only can enable the PLL when my systemclock frequency is 8MHz.
Just plain STM32F051, standard project with GPIO and RCC resource.
I'm really scratching my head here, i'm lost. The moment i select a PLL multiplier >2, the chip resets when i enable the PLL..

Greetings
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: us
Re: STM32, ghetto style
« Reply #304 on: November 04, 2014, 07:13:37 pm »
Quote
the chip resets when i enable the PLL..
Can you implement individual  fault handlers, and figure out WHY it's resetting (and exactly where)?
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #305 on: November 04, 2014, 07:54:27 pm »
Not having the particular chip, I can only offer limited help.

the f0 chips share the same clock module so what works for a f03 should work for a f05.

second, those chips don't reset as traditional 8 bitters. So when you say that the chip resets, what exactly does it mean? After the -reset-, where is the execution at?

what exactly is the code you are running? Did you make changes to the start up files? How about preprocessor macros? ...

it is best to be more specific.
================================
https://dannyelectronics.wordpress.com/
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #306 on: November 04, 2014, 08:12:26 pm »
If the code works again on your f051-disco, the problem source should be clear.
Also, I read somewhere that current Coocox is buggy. a few versions back and the functions work as expected. You should either try that, or setup your own Eclipse environment with gnu-arm-eabi compilers and STM plug-ins. Then you can use the STM standard peripheral lib in the last version, which should work flawless.
_Or_ you could open an own thread, as this is again and continuesly quite off-topic for STM32 ghetto style and a way more concrete problem with non-ghetto STM ;)
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #307 on: November 04, 2014, 10:25:26 pm »
Hey guys,

Thanks for helping me out.

This is the code i'm using for the F0 discovery:
Code: [Select]
#include <stm32f0xx.h> //stm32f030f4
#include "stm32f0xx_rcc.h" //we use rcc
#include "stm32f0xx_gpio.h"
#include "stm32f0xx_flash.h"

//connection
#define LED_PORT GPIOC
#define LED_A (1<<8)
#define LED_C (1<<9)

void SystemCoreClockHSIPLL2(uint32_t RCC_PLLMul_x) {
RCC_DeInit(); //reset rcc
RCC_PLLCmd(DISABLE); //disable PLL
RCC_HSICmd(ENABLE); //enable hsi;
RCC_HCLKConfig(RCC_SYSCLK_Div1); //set sysclk divider
//RCC_PCLK1Config(RCC_HCLK_Div1); //set pclk1/2 dividers
//RCC_PCLK2Config(RCC_HCLK_Div1);
/**

* @brief  Configures the PLL clock source and multiplication factor.
* @note   This function must be used only when the PLL is disabled.
*
* @param  RCC_PLLSource: specifies the PLL entry clock source.
*          This parameter can be one of the following values:
*            @arg RCC_PLLSource_HSI_Div2: HSI oscillator clock selected as PLL clock source
*            @arg RCC_PLLSource_PREDIV1: PREDIV1 clock selected as PLL clock entry
*            @arg RCC_PLLSource_HSI48 HSI48 oscillator clock selected as PLL clock source, applicable only for STM32F072 devices
*            @arg RCC_PLLSource_HSI: HSI clock selected as PLL clock entry, applicable only for STM32F072 devices
* @note   The minimum input clock frequency for PLL is 2 MHz (when using HSE as
*         PLL source).
*
* @param  RCC_PLLMul: specifies the PLL multiplication factor, which drive the PLLVCO clock
*          This parameter can be RCC_PLLMul_x where x:[2,16]
*
* @retval None
*/
FLASH_SetLatency(FLASH_Latency_1);
FLASH_PrefetchBufferCmd(ENABLE);
RCC_PLLConfig(RCC_CFGR_PLLSRC_HSI_Div2, RCC_PLLMul_x); //configure pll / divider. _x=[2..16]
RCC_PLLCmd(ENABLE); //enable pll
while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET) continue; //wait for pll to be ready
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); //set pll as sysclk
while (RCC_GetSYSCLKSource() != RCC_CFGR_SWS_PLL/*0x08*/) continue; //wait for PLL to be ready

SystemCoreClockUpdate(); //update SystemCoreClock
}

//delays some
void delay(uint32_t dly) {
while (dly--) __asm("NOP");
}

int main(void) {
SystemCoreClockHSIPLL2(RCC_PLLMul_12); //go to 48Mhz

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOC, ENABLE);
GPIO_InitTypeDef gis;
gis.GPIO_Mode = GPIO_Mode_OUT;
gis.GPIO_OType = GPIO_OType_PP;
gis.GPIO_Pin = LED_A | LED_C;
gis.GPIO_PuPd = GPIO_PuPd_NOPULL;
gis.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(LED_PORT,&gis);
LED_PORT->ODR &= ~(LED_A);
LED_PORT->ODR |= (LED_C);

while(1) {
LED_PORT->ODR ^= (LED_A | LED_C);
delay(1000000);
    }
}

The code for my board differs only in led pins.
When i set the multiplier at 2 and at 12, the discovery board shows remarkable difference in toggling speed.

On my custom board, when i use the multiplier of 2, the leds toggle and everything works on 8MHz (as per SystemClock on debug)
When i use the multiplier of 3, it gives me 12MHz.

When i look at the SystemCoreClockUpdate() routine on my custom board, RCC->CFGR & RCC_CFGR_SWS does not give me 0x08. So PLL isn't used as system clock.
This is only when the multiplier is 2 or 3, else it resets and i cannot debug the chip.
The moment i use a multiplier of 4 and up, the chip does nothing and attached you can see the nRST pin.. So it cycles the reset line.
The schematic in attachment also.

Greetings
« Last Edit: November 04, 2014, 10:28:11 pm by Ribster »
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #308 on: November 04, 2014, 10:34:17 pm »
If the code works again on your f051-disco, the problem source should be clear.
Also, I read somewhere that current Coocox is buggy. a few versions back and the functions work as expected. You should either try that, or setup your own Eclipse environment with gnu-arm-eabi compilers and STM plug-ins. Then you can use the STM standard peripheral lib in the last version, which should work flawless.
_Or_ you could open an own thread, as this is again and continuesly quite off-topic for STM32 ghetto style and a way more concrete problem with non-ghetto STM ;)

Hey, i have no problems with creating a new topic. Just say it if i'm pushing this thread :), i know i'm on a thin line here :p..
Thought it was a simple problem, but apparently it's bigger then i thought.
I'm supprised that i am having this problems on the F051. No one ever had these kind of problems with the ghetto f030 ?
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #309 on: November 04, 2014, 11:22:03 pm »
The discovery and the custom board use the same chip? If so the code is working and there is something unique about the custom board.

btw, there is no mechanism I know of where the chip will reset itself by pulling the reset line. This is interesting.

you said you cannot debug? What are you using for debugging?
================================
https://dannyelectronics.wordpress.com/
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #310 on: November 04, 2014, 11:42:50 pm »
No, i use the 48pin LQFP and the discovery uses the 64 pin.
My code works for both though.
I've read somewhere that some faults pull down the reset line, so that's why i checked for it.

When i step through my code when the configuration is set to multiplier >3, the moment i execute "RCC->CR |= RCC_CR_PLLON;" i lose connection to the chip.
At that moment my chip resets.
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #311 on: November 05, 2014, 12:44:34 am »
I ran your code, with minor changed to output on different pins, on my stm32f030 and it worked as expected.

Quote
I've read somewhere that some faults pull down the reset line,

You are right about that. It is stated in the reset and clock control section. and the reset state is output to the RESET pin.

Something weird is happening here.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #312 on: November 05, 2014, 01:47:26 am »
Furthermore, I simulated it in keil on stm32f051r8, and it worked just as expected.

I think the issue is hardware related for your custom board. Maybe decoupling? cross soldering? wrong wiring?....
================================
https://dannyelectronics.wordpress.com/
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #313 on: November 05, 2014, 11:57:14 pm »
Okay, you guys are gonna kill me for this..
VDDA wasn't connected on my board...
The good news is, i will shut up now because it's solved :).
Thanks for the support  :-+
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #314 on: November 06, 2014, 12:11:49 am »
Progress!

================================
https://dannyelectronics.wordpress.com/
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: STM32, ghetto style
« Reply #315 on: November 06, 2014, 12:46:42 am »
Yes it is!
Problems are really the best way to learn the internals of a microcontroller.
On to the next problem :p
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #316 on: November 07, 2014, 06:14:15 am »
Ok, first of two boost ICs arrived today, NCP1402. This will allow to feed the STM32F030 with a single alkaline battery.
Unfortunately, the inductors and Schottky diodes didn't arrive yet. I could improvise with 1N4148, but I don't dare to wick a coil "somehow" and hope that it swings sufficiently.
I'm also still waiting for the BL8530 step-ups which are significantly cheaper.

I think I need to extend the test to efficiency at standard conditions as well (fresh charges battery, measure voltage and current on the input side and then again on the output side for starters). That hopefully is helpful for deciding which buck or boost circuit to choose for using these tiny and mighty µCs in mobile applications.
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #317 on: November 07, 2014, 01:29:17 pm »
ON makes quite a few of those LED drivers that can function as regulators (both up and/or down).

With a small load, a small coil (the datasheet says 47uh) + 1n4148 should work.
================================
https://dannyelectronics.wordpress.com/
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #318 on: November 07, 2014, 03:28:43 pm »
50 pieces of CD54 47µH are somewhere between China Mainland and Germany, finding their way to my hands :D

Interesting hint with those ON semi LED drivers. Will look around a little. For my taste that is an interesting shootout between different power supply variants for our µCs. :)
« Last Edit: November 07, 2014, 03:36:21 pm by Koepi »
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #319 on: November 07, 2014, 03:55:24 pm »
Agreed.

However, the type of regulators to go may be highly application specific. For example, smps wins hands down for high current, high voltage drop applications, because of their efficiency. However, for low-power, sleep-dominated applications, low-quiescent current ldos may be better as smps becomes incredibly inefficient in those cases.

That's where some unique topologies may be interesting to try, like the ON chip you picked, or the gated oscillator types.
================================
https://dannyelectronics.wordpress.com/
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #320 on: November 07, 2014, 07:48:33 pm »
Started to think about a measurement scenario and decided to first take my µC 4-digit-7-segment LED clock which is fed by a LiIon battery and stableized with the LDO. This really seems to show the efficiency while I'm not yet sure how to calculate it correctly - simply the ratio of A in versus A out?

Killed the 400mA fuse of my multimeter during the test; had a 500mA one in an old, unused multimeter which I replaced the broken fuse with now. Had to start all over to make sure the values are comparable.

I'll start with the table and play around with the numbers a little, adding the efficiency as Wattage in/out ratio.

Vin was 3,901V from the LiIon battery.

LDOVoutmAinmAoutNoLoad µAmWinmWoutEff %
MCP17003.2831.891.881.37,376,1783,71
PAM31013.3031.961.8857.67,656,2181,21
MCP1825S3.3341.971.9344.07,686,4383,73
RT91663.2601.871.866.17,296,0683,12

As comparison, using the battery directly to feed the clock results in a 2.41mA load, which are 9,40mW. It is more efficient to use a LDO?!
« Last Edit: November 07, 2014, 09:28:47 pm by Koepi »
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #321 on: November 07, 2014, 08:04:44 pm »
Quote
simply the ratio of A in versus A out?

Technically yes but practically, that measurement is not as meaningful.

A more "efficient" regulator, particularly a ldo, is one that can work with minimum drop-out voltage and has the least idle current. So if you will, a voltage efficiency would be Vout / minimum Vin (not Vout / Vin), and a current efficiency would be Iout / Iin.

The issue with your measurements is that with sufficiently high Vin - Vout, they all look equally "efficient" - the power inefficiencies are really caused by the voltage drop (which is the same for all regulators, until Vin is sufficiently close to Vout).

To me, if you care about efficiency, you are likely in a low-power application and for a ldo, the current efficiency is much more important. Voltage efficiency is important when battery life is considered.
================================
https://dannyelectronics.wordpress.com/
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #322 on: November 07, 2014, 09:00:29 pm »
You are right, as you can see in the mA(in) of the MCP1700 and RT9166 - they consume the least power for driving the clock. Interestingly, the RT9166 looks even more efficient as the Wattage-ratio suggests compared with the MCP1700.

Hopefully tomorrow morning the 47µH coils are in the post so I can start with fiddling with boosters :)

Edit: Ah, the reason for using a LDO instead of battery directly leading to a better energy usage is that the resistors and LEDs pull more current at higher voltage.
« Last Edit: November 07, 2014, 11:06:07 pm by Koepi »
 

Offline Koepi

  • Regular Contributor
  • *
  • Posts: 64
  • Country: de
Re: STM32, ghetto style
« Reply #323 on: November 08, 2014, 10:54:28 am »
Lucky me, the coils arrived!

Built the NCP1402 to the sample from it's datasheet, only replaced the diode by a 1N4148 as the SS14 are still on their way. I was thrilled whether this could work at all - but it does! The efficiency sure suffers, but for the first test I think it's great! The self-built ghetto circuit has only 1/3rd the size of a PCB you can buy!

I used a STM32F030 dimming an LED as load now, so I have two load peaks which show a bigger bandwidth. This tiny bugger drives the µC with a single everyday AA battery! :)
« Last Edit: November 08, 2014, 11:42:53 am by Koepi »
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM32, ghetto style
« Reply #324 on: November 08, 2014, 12:54:49 pm »
The efficiency would go up with a schottky diode for sure. However, it follows the general observation that smps has lower efficiency at lower load conditions. That makes them less desirable at battery-powered and low load) applications - cell phones are different.

Have you tried lt1073? It is one of those gated oscillator types - it stops working when the output has reached the desired output levels. Quite pricey, however.
================================
https://dannyelectronics.wordpress.com/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf