Hallo, wie die meisten wissen, die mehr als nur SystemInit() benutzen sind die Busse AHBx und APBx mit diversen Prescalern bestückt. Ob ich nun den APB2 auf 1:2 herunter takte und dafür den Prescaler der SPI etwas höher setze spielt keine Rolle. Es sind viele Kombinationen denkbar wie ein Ziel erreicht werden kann. Auch Extremfälle sind möglich, dass ein Timer nur fast jede Sekunde einmal taktet. Die Kette ist aus dem kopf Systemtakt -> PLL -> Prescaler HCLK -> Prescaler AHBx/APBx -> Prescaler Timer/SPI usw. Das ermöglicht Vorteiler von vielen Bits, die SPI könnte mit 1Hz laufen. Gibt es bei dem Wust an Möglichkeiten ein Ziel was man verfolgen sollte? Was reduziert den Stromverbrauch am meisten? was ist unsinnig? Beispiel: Der F103 zieht bei Full-Speed (72Mhz) auf allen Kanälen ca 60mA. Und die GPIO betreffend: Die KOnfiguration Speed_2Mhz, 10Mhz, 50Mhz beim F1xx ist ja durch die Vortaktung auch betroffen, nur wie stellt sich die Frage. Taktet man den Buss extrem runter, wie verhalten sich die Pins dann? Vielleicht hat da ja mal jemand ein Konzept, welches Ziel man verfolgen sollte? Gruss, Christian
Wenn Du Strom sparen willst, musst Du die Busse so langsam wie möglich laufen lassen. Dabei musst Du natuerlich jedes Device am Bus betrachten. Sobald Du einen Timer am Bus mit einer hochauflösenden PWM hast, wirst Du aber den Bus mit maximaler Geschwindigkeit laufen lassen.Das ist das Spannungsfeld. Die GPIO Einstellung Speed_2Mhz, 10Mhz, 50Mhz ist von der Busgeschwindigkeit unabhängig und bestimmt hauptsächlich die Flankensteilheit. Was Du dafür brauchst, bestimmen die Lasten an den GPIOs.
Uwe B. schrieb: > Die GPIO Einstellung Speed_2Mhz, 10Mhz, 50Mhz ist von der > Busgeschwindigkeit unabhängig und bestimmt hauptsächlich die > Flankensteilheit. Diese Geschichte lese ich überall, nur steht das nirgendwo im Datenblatt, dass diese Einstellung was mit der Flankensteilheit zu tun hat, die ja auch bei Digital-Endstufen nur schwer zu beeinflussen ist. Messungen bestätigen das jedenfalls nicht. Egal was ich dort eintrage, ein Pin toggelt bei mir mit 12,5 Mhz maximal auf manuelle Weise.
Am (schnellen) Oszi kann man eindeutig sehen, dass sich die Flankensteilheit mit der GPIO Speed verändert. Deutlicher wird es, wenn man den Ausgang noch kapazitiv belastet, z.B. mit 50 pF. Siehe dazu auch im Datenblatt die Tabelle I/O AC characteristics, z.B. beim STM32F411 Rev 4 Seite 99, Tabelle 55.
Christian J. schrieb: > Diese Geschichte lese ich überall, nur steht das nirgendwo im > Datenblatt, dass diese Einstellung was mit der Flankensteilheit zu tun > hat, die ja auch bei Digital-Endstufen nur schwer zu beeinflussen ist. > Messungen bestätigen das jedenfalls nicht. Der hat unterschiedlich dicke FETs an den Pins. Mit der unvermeidlichen Lastkapazität ergibt sich die entspr. Flankensteilheit. Christian J. schrieb: > Egal was ich dort eintrage, > ein Pin toggelt bei mir mit 12,5 Mhz maximal auf manuelle Weise. Mit den niedrigeren Einstellungen würde man da eventuell nur einen Sinus oder fast gar nix auf dem Oszi sehen.
Christian J. schrieb: > Uwe B. schrieb: >> Die GPIO Einstellung Speed_2Mhz, 10Mhz, 50Mhz ist von der >> Busgeschwindigkeit unabhängig und bestimmt hauptsächlich die >> Flankensteilheit. > > Diese Geschichte lese ich überall, nur steht das nirgendwo im > Datenblatt, dass diese Einstellung was mit der Flankensteilheit zu tun > hat, die ja auch bei Digital-Endstufen nur schwer zu beeinflussen ist. > Messungen bestätigen das jedenfalls nicht. Egal was ich dort eintrage, > ein Pin toggelt bei mir mit 12,5 Mhz maximal auf manuelle Weise. STM32F4 -> RM0090 GPIO->GPIOx_OSPEEDR: Note: Refer to the product datasheets for the values of OSPEEDRy bits versus VDD range and external load. STM32F405/7 DOC022152rev5 Suche "OSPEEDRy" -> Input/output AC characteristics Alles beschrieben, sogar mit Bildern...
Christian J. schrieb: > Gibt es bei dem Wust an Möglichkeiten ein Ziel was man verfolgen sollte? > Was reduziert den Stromverbrauch am meisten? was ist unsinnig? Alles, was du da anführst, ist unsinnig. Stromverbrauch reduziert man über Ruhephasen, nicht über geringeren Takt. Der Prozessor sollte immer mit maximaler Frequenz takten, denn höherer Takt heisst auch, schneller (und länger) im Sleep-Modus. Man kann sich das ganz einfach zusammenrechnen. Maximallast heisst laut Datenblatt 50mA. Der Takt senkt die Stromaufnahme nur näherungsweise linear, d.h. wenn du bei 125kHz taktest, dann liegt die Stromaufnahme immernoch bei 1,08mA. Dabei erhöht sich aber die Verarbeitungsdauer, so dass du jetzt bei bspw. 100% Prozessorlast bist. Wenn du aber mit vollem Takt arbeitest, dann sinkt die Auslastung auf 0,2% (0,125/72), der Rest ist Wartezeit. Diese Wartezeit wird mit einem Sleep-Modus überbrückt. Wir haben jetzt also für den Zeitraum, in dem tatsächlich etwas gemacht wird, 50mA Stromaufnahme, und in der restlichen Zeit 950µA. Damit kannst du die mittlere Stromaufnahme berechnen: 0,950mA*(1-0,125/72) + 50mA*0,125/72 = 1,035mA. Dabei habe ich jetzt den ungünstigsten Stromsparmodus (runtertakten+Sleepmode) des STM32 zugrundegelegt. Wenn man in der Hardware die Vorzugslagen sauber definiert, dann könnte man auch den Stop-Mode verwenden, der nochmal deutlich sparsamer ist - zu Lasten der Aufwachzeit. Ehrlich gesagt gibt es aber für stromsparende Anwendungen deutlich besser geeignete Controller (Stichwort Wakeup on Interrupt, Low-Power-Peripherie, port level retention usw.) wie die EFM32-Familie. Ich habe in meinem früheren Leben ein EFM32-Design mit dynamischem RAM, FRAM, Flash, GSM und GPS entwickelt, das am Ende eine Ruhestromaufnahme von ~90µA hatte inkl. GPS und FRAM (Rest ausgeschalten) hatte. Alles aus, nur Controller mit RAM- und pin-retention und nicht-abschaltbare Peripherie lag das Design bei ~15µA inkl. Schaltregler. Die mittlere Stromaufnahme inkl. GSM-Betrieb lag bei 200µA, wenn ich mich recht entsinne. Solche Werte erreicht man aber nicht, wenn man im Nachgang noch hier und da ein wenig Strom sparen möchte. Das Design war vom ersten Tag an auf niedrigen Ruhestrom ausgelegt und dimensioniert. Ich benutze mittlerweile auch überwiegend STM32, weil der Stromverbrauch bei meinen derzeitigen Projekten keine Rolle spielt. Bei batteriebetriebenen Geräten würde ich aber kaum etwas anderes als EFM32 einsetzen, mit Abstrichen bei der Applikation kann man noch einen XLP-PIC oder MSP430 verwenden, wobei zumindest letzterer gegenüber den EFM32 meiner Ansicht nach mehr Nach- als Vorteile hat und der Mehrverbrauch des EFM32, wenn überhaupt, dann eher im homöopathischen Bereich liegt.
Frank B. schrieb: > Alles, was du da anführst, ist unsinnig. Stromverbrauch reduziert man > über Ruhephasen, nicht über geringeren Takt. Es ging auch um die Device Clocks. Da ist so langsam wie möglich richtig! Und beim Prozessortakt kommen noch die Voltage regulator setting dazu. Zwar nicht bein F103, aber bei den meisten anderen Familien. Wenn es ums Stromsparen geht, wuerde ich auf den L4 umschwenken und eine grossen Bogen um F103 machen...
Christian J. schrieb: > Uwe B. schrieb: >> Die GPIO Einstellung Speed_2Mhz, 10Mhz, 50Mhz ist von der >> Busgeschwindigkeit unabhängig und bestimmt hauptsächlich die >> Flankensteilheit. > > Diese Geschichte lese ich überall, nur steht das nirgendwo im > Datenblatt, dass diese Einstellung was mit der Flankensteilheit zu tun > hat, die ja auch bei Digital-Endstufen nur schwer zu beeinflussen ist. > Messungen bestätigen das jedenfalls nicht. Egal was ich dort eintrage, > ein Pin toggelt bei mir mit 12,5 Mhz maximal auf manuelle Weise. https://vjordan.info/log/fpga/stm32-bare-metal-start-up-and-real-bit-banging-speed.html
Dr. Pinguin schrieb: > https://vjordan.info/log/fpga/stm32-bare-metal-start-up-and-real-bit-banging-speed.html Der Lin sagt wenig (oder nicht) über die Pin Speed aber viel über die Pin Toggle Speed...
> restlichen Zeit 950µA. > Damit kannst du die mittlere Stromaufnahme berechnen: > > 0,950mA*(1-0,125/72) + 50mA*0,125/72 = 1,035mA. > > Dabei habe ich jetzt den ungünstigsten Stromsparmodus > (runtertakten+Sleepmode) des STM32 zugrundegelegt. Wenn man in der > Hardware die Vorzugslagen sauber definiert, dann könnte man auch den > Stop-Mode verwenden, der nochmal deutlich sparsamer ist - zu Lasten der > Aufwachzeit. Hallo, ich hab da gestern etwas mit gespielt. Mir reicht eigentlich "weniger Strom", trotz Batterien. Stop Mode ist ja etwas aufwendiger, da man zb die RTC braucht um den aufzuwecken, SystTick muss vorherabgeschaltet werden usw. Ein __WFI() dürfte doch auch einiges einsparen, oder? Und jeder Systick, bzw. ExtI oder Timer Interrupt reisst den wieder raus. Ich habe in meiner Hobbyanwendung Zeiten am Laufen, die nicth angehalten werden sollen aber die Main Loop kann schon mal geparkt werden, bis was passiert.
Christian J. schrieb: >> restlichen Zeit 950µA. >> Damit kannst du die mittlere Stromaufnahme berechnen: >> >> 0,950mA*(1-0,125/72) + 50mA*0,125/72 = 1,035mA. >> >> Dabei habe ich jetzt den ungünstigsten Stromsparmodus >> (runtertakten+Sleepmode) des STM32 zugrundegelegt. Wenn man in der >> Hardware die Vorzugslagen sauber definiert, dann könnte man auch den >> Stop-Mode verwenden, der nochmal deutlich sparsamer ist - zu Lasten der >> Aufwachzeit. > > Hallo, > > ich hab da gestern etwas mit gespielt. Mir reicht eigentlich "weniger > Strom", trotz Batterien. Stop Mode ist ja etwas aufwendiger, da man zb > die RTC braucht um den aufzuwecken, SystTick muss vorherabgeschaltet > werden usw. Das größere Problem beim STM32Fxxx ist, dass der Stop Mode keine pin level retention hat, d.h. im Stop-Mode werden alle Pins hochohmig. Das wird in der Regel dazu führen, dass die Peripherie Amok läuft. Wenn man den Stop Mode verwenden will, dann muss man schon in der Designphase darüber nachdenken. Daher mein Hinweis bzgl. anderer Controller, die auch in sehr tiefen Energiesparmodi noch die Pins festhalten. > Ein __WFI() dürfte doch auch einiges einsparen, oder? Und jeder Systick, > bzw. ExtI oder Timer Interrupt reisst den wieder raus. Ich habe in > meiner Hobbyanwendung Zeiten am Laufen, die nicth angehalten werden > sollen aber die Main Loop kann schon mal geparkt werden, bis was > passiert. WFI versetzt den µC in Sleepmode, aufwecken erfolgt über Interrupt. Das ist also der Zielmodus. Die Frage ist, was der Controller dann genau verbraucht. Das Aufwecken über EXTI oder Timer ist völlig korrekt. Wichtig ist, dass du den Kern nach der Verarbeitung der aktuellen Interrupts wieder schlafen legst. SysTick ist hier etwas deplatziert, daher sollte man in sehr sparsamen Anwendungen entweder auf SysTick verzichten oder das Intervall sehr groß (~1s) machen.
Dr. Pinguin schrieb: > https://vjordan.info/log/fpga/stm32-bare-metal-start-up-and-real-bit-banging-speed.html Das Papier ist nicht uninteressant, aber beim DMA-UART kann man einen Schritt weiter gehen: - DMA/CPU laufen mit hohem Takt - ein Timer ist auf die Baudrate programmiert und löst DMA-Transfers aus. - mit zwei Timern ist sogar ganz asynchron full-duplex möglich.
Frank B. schrieb: > SysTick ist hier etwas deplatziert, > daher sollte man in sehr sparsamen Anwendungen entweder auf SysTick > verzichten oder das Intervall sehr groß (~1s) machen. Das geht doch nicht. Genau darüber habe ich gestern nachgedacht. Über SysTick steht nichts drin im Reference Sheet, 3 Zeilen, das ist alles. Wie gross ist denn der größte Wert für den Reload? Ich nutze HCLK_Div_8, also 9 Mhz. Mit 9000 tackert er jede 1ms. Mit 9 Mio würde es eben 1s sein was mir ausreicht. Nur passen 9 Mio nicht rein in den Befehl, den ich jetzt nicht im Kopf habe. Irgendwo bei 200ms war Schluss. Das mit den Pin Leveln habe ich auch gemerkt, dass ist beim F4xxx besser.
Frank B. schrieb: > Das größere Problem beim STM32Fxxx ist, dass der Stop Mode keine pin > level retention hat, d.h. im Stop-Mode werden alle Pins hochohmig. Daher mein Hinweis auf den L4
Und wir löst ihr das mit dem Debuggen? Jeder Sleep oder Stop sperrt den swd Debugger aus. Zigmal gestern ausgesperrt und Jumper umstecken müssen auf Boot Mode, Chip erasen, Jumper zurück usw. Nur RAM Debug läuft, da flüchtiger Speicher.
Frank B. schrieb: > Das größere Problem beim STM32Fxxx ist, dass der Stop Mode keine pin > level retention hat, d.h. im Stop-Mode werden alle Pins hochohmig. Das > wird in der Regel dazu führen, dass die Peripherie Amok läuft. Wenn man > den Stop Mode verwenden will, dann muss man schon in der Designphase > darüber nachdenken. Daher mein Hinweis bzgl. anderer Controller, die > auch in sehr tiefen Energiesparmodi noch die Pins festhalten. Hi Frank, wo ist denn die Info zum Stop-Mode her? Laut AN4365 "STM32F4 power consumption": Stop mode: – Lowest power consumption while all the SRAM and registers are kept. – PLL, HSI, HSE are disabled. – All clocks in 1.2 V domain are switched-off. – Voltage regulator is working in Normal mode or Low-power mode. – Flash memory is working in Stop mode or Deep-power down mode. The Cortex-M4 core is stopped and the clocks are switched off (the PLL, the HSI and the HSE are disabled). SRAM and register content are kept. All I/O pins keep the same state as the Run mode. The voltage regulator is working in Normal or Low-power mode and the Flash memory can be configured in Stop mode or Deep-power down mode to save more static power. oder liegt eine Verwechslung mit Standby/Vbat-Mode vor? Grüße, marcus
> Ich nutze HCLK_Div_8, also 9 Mhz. Mit 9000 tackert er jede 1ms. Mit 9 > Mio würde es eben 1s sein was mir ausreicht. Nur passen 9 Mio nicht rein > in den Befehl, den ich jetzt nicht im Kopf habe. Irgendwo bei 200ms war > Schluss. Sollte es aber nicht sein, da sowohl Count- als auch Reload-Register 24 Bit breit sind (also ca. 16 Mio).
Uwe B. schrieb: > Frank B. schrieb: >> Alles, was du da anführst, ist unsinnig. Stromverbrauch reduziert man >> über Ruhephasen, nicht über geringeren Takt. > > Es ging auch um die Device Clocks. Da ist so langsam wie möglich > richtig! Und beim Prozessortakt kommen noch die Voltage regulator > setting dazu. Zwar nicht bein F103, aber bei den meisten anderen > Familien. Ganz im Gegenteil: Es ist in den meisten Fällen völlig falsch. Beispiel I2C: Ein Low-Pegel auf dem Bus führt dazu, dass Strom über den Pullup fliesst. der Pullup kann aber nicht beliebig groß sein. Eine schnelle Datenübertragung sorgt dafür, dass der Bus schnell wieder frei wird und kein Strom mehr fliesst. Daher sollte bspw. der I2C-Clock für stromsparende Anwendungen so hoch wie möglich sein. Das selbe gilt für SPI: Das Chip Select wird sinnvollerweise durch einen Pullup in die Vorzugslage High gezogen. Bei der Datenübertragung fliesst über diesen Pullup Strom. Schnellere Übertragung heisst weniger Strom. Diese Logik lässt sich auf nahezu jede Kommunikationsschnittstelle anwenden. Wenn man keine LowPower-Schnittstelle hat, deaktiviert man einen Kommunikationsslave komplett und reagiert auf neue eingehende Daten über einem EXTI-Interrupt, der die Schnittstelle wieder aktiviert. Das funktioniert mit USART und SPI problemlos, auf I2C-Slaves oder CAN sollte man besser verzichten. USB wird sowieso nur aktiviert, wenn VBUS als Versorgung anliegt. Was haben wir noch? ADC - wenn keine permanente Wandlung erforderlich ist, ausschalten des ADC (inkl. Taktabschaltung) mehr Strom als langsame Wandlung. Timer - Die Timertaktung ist in der Regel abhängig von der Applikation, so dass hier wenig Spielraum besteht. Wenn ein Timer nicht benötigt wird, schaltet man ihn aus. DMA - wenn die Peripherie, die den DMA nutzt, nicht aktiv ist, brauche ich den DMA-Controller auch nicht. Strom spart man, indem man alle zur Zeit nicht benötigte Peripherie abschaltet. Niedrige Taktung ist eher hinderlich.
Frank B. schrieb: > Strom spart man, indem man alle zur Zeit nicht benötigte Peripherie > abschaltet. Niedrige Taktung ist eher hinderlich. Macht es auch Sinn nach jedem kurzen SPI Burst die RCC Clocks wieder abzuschalten? Bzw die für I2C, ADC usw. Ich lasse bisher alles an, da ich nicht weiss wie lange der Kram zum starten braucht. Oder reicht SPI_Cmd(Disable) aus? >>Laut AN4365 "STM32F4 power consumption": Hier im Thread ist der STM32F1xxx gemeint, er hat das nicht.
Christian J. schrieb: > Und wir löst ihr das mit dem Debuggen? Jeder Sleep oder Stop sperrt den > swd Debugger aus. Zigmal gestern ausgesperrt und Jumper umstecken müssen > auf Boot Mode, Chip erasen, Jumper zurück usw. Nur RAM Debug läuft, da > flüchtiger Speicher. Dafür gibt es die passenden Bits. Im RM ab Seite 1090 ist das beschrieben. Christian J. schrieb: > Frank B. schrieb: >> SysTick ist hier etwas deplatziert, >> daher sollte man in sehr sparsamen Anwendungen entweder auf SysTick >> verzichten oder das Intervall sehr groß (~1s) machen. > > Das geht doch nicht. Genau darüber habe ich gestern nachgedacht. Über > SysTick steht nichts drin im Reference Sheet, 3 Zeilen, das ist alles. > Wie gross ist denn der größte Wert für den Reload? Habe ich gerade nicht im Kopf, aber der SysTick lässt sich auf jeden Fall deaktivieren. Das findest du im CM3-Manual, nicht im RM für den STM32, da der SysTick zum Core gehört. Marcus H. schrieb: > Hi Frank, wo ist denn die Info zum Stop-Mode her? >[...] > > oder liegt eine Verwechslung mit Standby/Vbat-Mode vor? > > Grüße, > marcus Ich bezog mich auf den STM32F1xx, den der TO auch benutzt.
Christian J. schrieb: > Frank B. schrieb: >> Strom spart man, indem man alle zur Zeit nicht benötigte Peripherie >> abschaltet. Niedrige Taktung ist eher hinderlich. > > Macht es auch Sinn nach jedem kurzen SPI Burst die RCC Clocks wieder > abzuschalten? Bzw die für I2C, ADC usw. Ich lasse bisher alles an, da > ich nicht weiss wie lange der Kram zum starten braucht. Das ist eine schwierige Frage. Gerade beim ADC hast du das Problem, dass du neu kalibrieren musst/solltest. Hier kommt es also schwer auf die Applikation an. Wenn du nur ab und zu mal die Betriebsspannung misst, dann schalte die Clock ab. > Oder reicht SPI_Cmd(Disable) aus? Wenn ich mir das an meinen Boards so ansehe, dann steigt die Stromaufnahme bereits beim Zuschalten des Taktes. Wenn du also Zeit für die Reinitialisierung der Peripherie hast (bspw. im Masterbetrieb), dann würde ich komplett abschalten.
Frank B. schrieb: > Habe ich gerade nicht im Kopf, aber der SysTick lässt sich auf jeden > Fall deaktivieren. Das findest du im CM3-Manual, nicht im RM für den > STM32, da der SysTick zum Core gehört. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html
Frank B. schrieb: > Ich bezog mich auf den STM32F1xx, den der TO auch benutzt. RM0008 rev14 - 5.3.4 Stop Mode: The Stop mode is based on the Cortex-M3 deepsleep mode combined with peripheral clock gating. The voltage regulator can be configured either in normal or low-power mode. In Stop mode, all clocks in the 1.8 V domain are stopped, the PLL, the HSI and the HSE RC oscillators are disabled. SRAM and register contents are preserved. In the Stop mode, all I/O pins keep the same state as in the Run mode.
Marcus H. schrieb: > Frank B. schrieb: >> Ich bezog mich auf den STM32F1xx, den der TO auch benutzt. > RM0008 rev14 - 5.3.4 Stop Mode: > The Stop mode is based on the Cortex-M3 deepsleep mode combined with > peripheral clock gating. The voltage regulator can be configured either > in normal or low-power mode. In Stop mode, all clocks in the 1.8 V > domain are stopped, the PLL, the HSI and the HSE RC oscillators are > disabled. SRAM and register contents are preserved. In the Stop mode, > all I/O pins keep the same state as in the Run mode. Siehst du, so kann man sich irren ;-) Da habe ich mich von den im Datenblatt angegebenen Messbedingungen aufs Glatteis führen lassen... Bei den ARM7 (LPC23xx) war es noch so, dass im Stop-Mode die pin level verloren gingen, das hab ich dann wohl durcheinander geworfen.
:
Bearbeitet durch User
Angehängte Dateien:
-
F103-ClockCfg.png
160 KB -
F103-PowerCfg.png
150 KB
Für die Clock+Power Einstellungen hilft das CubeMX auch. Es kennt vielleicht nicht alles aus dem Datenblatt, aber gerade beim Takt einstellen kann man ja einige Fehler machen und die werden hier schön angezeigt. Bei der Power Einstellung sieht man das der Strom im Run Mode hauptsächlich am CPU Takt hängt.
Puh... viel zu lesen. Ich werde mich mit dem Sleep Mode begnügen, da mir das ausreicht. Es gibt andere Dinge wie LED und Funkmodul was immer auf RX steht, die mehr verbrauchen. Mit den Clock wird man ja malle im Kopf :-( Klar kann man alles wieder abschalten nachdem es benutzt wurde. Ich habe 1s Pause zwischen jedem Arbeitsschritt der Statemachine. Aber wie sich das auswirkt alle RCC abzuschalten und anschließen wieder neu zu initialiseren weiss ich nicht. Alles ON ist der bequeme Weg, die Weichware bleibt verständlich, in jedem Modul gibt es 1 x Init Modul, was alles einstellt und dieses wird jeder anderen Routine vorangestellt, d.h. der "User" braucht sich nicht zu kümmern, die High Level Routinen rufen alle Low Level (Ports justieren, INTs umbiegen usw) auf, die sie brauchen und setzen danach flag_init_spi..... auf true. Alles wieder ausschalten würde das Verfahren jedesmal neu anwerfen. Mit PIC war die Welt doch einfacher :-) Leider habe ich sie alle verkauft, weil 10 Jahre damit reichten. @Jojo: Mir müssen uns mal über dieses CubeMX unterhalten, ich melde mich mal dazu. Ggf. auch mal telefonieren. Habe auch Teamspeak und einen WOT Server.
Bei den Cortexen bin ich auch auf Anfänger Level was solche Feinheiten angeht. Aber bei dem Cube Tools ist ja das schöne das man in den Dialogen spielen kann und sofort die Auswirkungen sieht. In den Manuals blättert man sich dafür die Finger wund. Exzessives Stromsparen habe ich auch noch nicht gemacht, da muss man sicher viel testen und kann einige Überraschungen erleben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.