Hallo zusammen, man list immer öfter "Restposten" bei der Beschaffung von MSP430. Weiß jemand wann welcher MSP430 auf- oder abgeküngigt wurde? Ee gibt immer noch gewisse Vorteile beim Verwenden des MSP430. Kennt jemand die künftige Stategie von TI bezüglich MSP430? Auf oder Ab ist mir relativ egal! Wichtig ist dass ich das Ding bekomme. Und ja! 32 Bit und ARM Cortex ist die Lösung für alles!!!
:
Bearbeitet durch User
Andreas V. schrieb: > Ich kann mir einfach nicht vorstellen dass die MSP430-Serie so schnell > komplett eingestellt werden So schnell??? Ist seit 1993 am Markt... Andreas V. schrieb: > weil die MSPs für bestimmte Aufgaben immer > noch gewisse Vorteile bieten! Kläre mich bitte auf, welche Vorteile denn? Ich werfe mal als Gegenkandidat den STM32F030 in den Raum...
Andreas V. schrieb: > Ja! 32 Bit und ARM Cortex ist die Lösung für alles!!! Wir warten noch auf die Liste mit den Vorteilen. Lahme Parolen raushauen kann jeder.
Was die selbst ernannten "Trolljäger" und "Neuer Schneller Weiter" vergötternden Herrschaften wieder für einen substanzlosen Nonsens schreiben. Warum soll man alles mit einem ARM erschlagen? Warum soll man auf eine andere Familie bzw. auf einen anderen Hersteller ausweichen? Der MSP430 reicht für eine Unmenge an Anwendungen und stellt eine optimale Lösung dar. Es ist eben nicht die Lösung mit Kanonen auf Spatzen zu schießen. Auch das Argument, man hätte für "spätere Erweiterungen" dann noch "luft nach oben" zieht hier nicht. Denn oftmals werden abgeschlossene Designs erarbeitet, so dass die "Luft nach oben" oft ein komplettes Redesign erfordert. Zudem muss man sich bei einem Umstieg erst in eine neue Entwicklungsumgebung einarbeiten. Dafür ist gerade in der anwendungsorientierten Praxis kaum Zeit.
Vorteile MSP430: - Standalone betreibbar. Man braucht nur 3,3V, GND, einen SMD-Widerstand. - Passt in eine DIP Fassung und ist im Notfall auswechselbar. - Kann (wenn man es braucht) 64 Bit Operationen. - Kostenlos im IAR verwendbar. - Schlanke SBW Schnittstelle. - robust ohne Ende. - braucht extrem wenig Strom auch ohne Low Energy Mode. - hat alles was man braucht. - Ist ohne großen Aufwand in alle Schaltungen zu integrieren.
:
Bearbeitet durch User
Andreas V. schrieb: > Vorteile MSP430: > > - Standalone betreibbar. Man braucht nur 3,3V, GND, einen > SMD-Widerstand. Genauso bei den STM32. Nur brauchste da den Widerstand nicht. > - Passt in eine DIP Fassung und ist im Notfall auswechselbar. DIP ist tot. > - Kostenlos im IAR verwendbar. Für STM32 gibts tonnenweise kostenlose Tools, vom Compiler über die IDE. > - Schlanke SBW Schnittstelle. STM32 = JTAG oder schlanke 2 draht Schnittstelle. > - robust ohne Ende. Unspezifischer Allgemeinplatz. > - braucht extrem wenig Strom auch ohne Low Energy Mode. Unspezifierter Allgemeinplatz. STM32 gibts ebenfalls in Ultra Low Power Varianten. > > - hat alles was man braucht. Unsinn. > > - Ist ohne großen Aufwand in alle Schaltungen zu integrieren. STM32 Ebenso Dir ist schon klar dass nicht nach allgemeinen Vorteilen sondern spezifisch nach Vorteilen GEGENÜBER STM32, oder Cortex-M allgemein von mir aus, gefragt wurde?
:
Bearbeitet durch User
Andreas V. schrieb: > Cyblord -. schrieb: >> DIP ist tot. > > .. aber praktisch! Unsinn. Aber wer es braucht kann genügend DIP Breakout Boards für nahezu jedes SMD Gehäuse nutzen.
Cyblord -. schrieb: > Für STM32 gibts tonnenweise kostenlose Tools, vom Compiler über die IDE. Cyblord -. schrieb: > Unsinn. Aber wer es braucht kann genügend DIP Breakout Boards für nahezu > jedes SMD Gehäuse nutzen. Schon mal einen STM32 gelötet? Ich kann nur STM Boards finden. Das macht ja auch Sinn; brauche ich aber nicht!
Andreas V. schrieb: > Cyblord -. schrieb: >> Für STM32 gibts tonnenweise kostenlose Tools, vom Compiler über die IDE. > > Cyblord -. schrieb: >> Unsinn. Aber wer es braucht kann genügend DIP Breakout Boards für nahezu >> jedes SMD Gehäuse nutzen. > > Schon mal einen STM32 gelötet? Schon oft. z.B. im LQFP32/48 Gehäuse. Nichts leichter als das. > Ich kann nur STM Boards finden. Das macht ja auch Sinn; brauche ich aber > nicht! Aha du kannst nur Boards finden. Wo hast du gesucht? Jede Distri verkauft hunderte verschiedene STM32 als nackter Chip. Du bist halt auch so ein Typ der nur kann was er kennt und nur kennt was auf sein Breadboard passt. Typisch von vorgestern. Nur solche Leute hängen sich an den MSP. Andere Gründe als die eigene Unfähigkeit zur Anpassung gibt es nämlich nicht.
:
Bearbeitet durch User
Cyblord -. schrieb: >> - hat alles was man braucht. > > Unsinn. Warum ist das Unsinn? Ich brauche nicht mehr als I2C! Das Teil soll kontinuierlich arbeiten und wenig Strom brauchen. Wenn ich mehr brauche kann ich auch den STM32 oder gleich einen Raspi Zero nehmen. Das brauche ich aber nicht!
Andreas V. schrieb: > Warum ist das Unsinn? Ich brauche nicht mehr als I2C! Das Teil soll > kontinuierlich arbeiten und wenig Strom brauchen. > > Wenn ich mehr brauche kann ich auch den STM32 oder gleich einen Raspi > Zero nehmen. Das brauche ich aber nicht! Von mir aus geht das in Ordnung wenn dir der MSP reicht. Darum gings aber nicht. Du hast dich zu der Aussage verstiegen deine MSP Krücke wäre irgendwie aktuellen modernen Controllern überlegen. Was nicht stimmt. Es gibt keine objektiven Vorteile. Du magst subjektive Vorteile haben, schön. Dann sag das gleich und versteige dich nicht zu wirren Aussagen.
@Andeas Dir ist aber schon klar, dass es nicht unsere Aufgabe hier ist dich vom stm32 zu überzeugen, oder? Benutze doch weiterhin den MSP430 wenn es dir danach ist und schlage dich mit Abkündigungen, hohen Preisen, merkwürdigen Hardwarebeschränkungen und langen Entwicklungszeiten rum. Deine Sache. Die meisten sind auf den 32-bit Zug mittlerweile aufgesprungen, da es neben den offensichtlichen Vorteilen (Preis, Beschaffbarkeit, Auswahl, second source, etc) jede Menge andere Vorteile in der Anwendbarkeit bietet. Diese erkennt man aber nur dann, wenn man sich mit der "neueren" Technik befasst. Dies hast du augenscheinlich noch nicht gemacht. Nicht mein Problem. Es gibt gerade bei uns in Deutschland etliche Firmen, die eine ähnliche Einstellung habe wie du. Schön bei DIP bleiben, bloß keine SMD-Technik, und erst recht keinen Fortschritt bitte, da müsste man ja was dazulernen. Genau diese Firmen heulen aber auch auffallend oft rum, weil sich der Markt nun mal verändert hat. Ob da irgendein Zusammenhang besteht???
Cyblord -. schrieb: > Aha du kannst nur Boards finden. Wo hast du gesucht? Jede Distri > verkauft hunderte verschiedene STM32 als nackter Chip. > > Du bist halt auch so ein Typ der nur kann was er kennt und nur kennt was > auf sein Breadboard passt. Typisch von vorgestern. Nur solche Leute > hängen sich an den MSP. Andere Gründe als die eigene Unfähigkeit zur > Anpassung gibt es nämlich nicht. Ich habe nur keine Lust auf Beschäftigungstherapie. Dazu habe ich keine Zeit bzw. man kann seine Zeit sinvoller verbringen. Ich brauche keinen Chip mit 64 oder 100 Pins. Vor Allem löte ich keine 100 PIN's wenn ich nur 5 brauche. Wenn ich das brauche dann hole ich mir ein Microprozessor mit Board. Das alles entspricht nicht den Anforderungen.
Andreas V. schrieb: > Ich brauche keinen Chip mit 64 oder 100 Pins. Vor Allem löte ich keine > 100 PIN's wenn ich nur 5 brauche. Wenn ich das brauche dann hole ich mir > ein Microprozessor mit Board. Nochmal, STM32 gibts im LQFP32 Gehäuse. D.h. 32 Pins. Nicht 64. Nicht 100. Wenn man ein fertiges Breakout Boards kauft muss man gar nichts löten und hat wieder DIP Maße. > Das alles entspricht nicht den Anforderungen. Manche merken halt nicht wenn der Zug abfährt. 8 und 16 Bitter in DIP fahren halt nun mal langsam ab. Merkste doch eigentlich an der ABkündigung selber, nech? Und wie gesagt, bleib bei deinem alten Kram, hat hier niemand ein Problem mit. Aber erzähle keinen Unsinn bezüglich Vorteilen. Nur weil DU wirre Anforderung hast und irgendwas als persönlichen Vorteil ansiehst. Das ist deine Sache. Und es gibt sogar einige Cortex-M Exoten im DIP Gehäuse wenn ich mich recht erinnere. Aber nicht von ST.
TrollJäger schrieb: > @Andeas > > Dir ist aber schon klar, dass es nicht unsere Aufgabe hier ist dich vom > stm32 zu überzeugen, oder? Lag jetzt wegen der Anforderungen nicht unbedingt im Fokus. > Benutze doch weiterhin den MSP430 wenn es dir danach ist und schlage > dich mit Abkündigungen, hohen Preisen, merkwürdigen > Hardwarebeschränkungen und langen Entwicklungszeiten rum. Deine Sache. > Die meisten sind auf den 32-bit Zug mittlerweile aufgesprungen, da es > neben den offensichtlichen Vorteilen (Preis, Beschaffbarkeit, Auswahl, > second source, etc) jede Menge andere Vorteile in der Anwendbarkeit > bietet. Diese erkennt man aber nur dann, wenn man sich mit der "neueren" > Technik befasst. Dies hast du augenscheinlich noch nicht gemacht. Nicht > mein Problem. Der MSP430 ist seit Jahren der günstigste Prozessor der auch 64 Bit kann. Beschaffungsprobleme hatte ich bislang noch keine. Ob das so bleibt war die Frage. > > Es gibt gerade bei uns in Deutschland etliche Firmen, die eine ähnliche > Einstellung habe wie du. Schön bei DIP bleiben, bloß keine SMD-Technik, > und erst recht keinen Fortschritt bitte, da müsste man ja was > dazulernen. Genau diese Firmen heulen aber auch auffallend oft rum, weil > sich der Markt nun mal verändert hat. Ob da irgendein Zusammenhang > besteht??? Manchnal soll es einfach nur robust sein. Wer schon öfter mal SMD Bauteile reparierte weiss wovon ich spreche. Viele (SMD)-Bauteile haben inzwischen eine Lebensdauer von 20000 Stunden... Oder schmeissen wir gleich alles weg!
Cyblord -. schrieb: > DIP ist tot. Faszinierend, dass es viele PICs, viele AVRs, viele MSP430, viele CMOS- und TTL-Gatter, Schieberegister, RTCs, Operationsverstärker,... alle noch im DIP gibt und immer noch produziert werden. Das würde ich nicht erwarten, wenn DIP wirklich tot wäre.
Sebastian R. schrieb: > Cyblord -. schrieb: >> DIP ist tot. > > Faszinierend, dass es viele PICs, viele AVRs, viele MSP430, viele CMOS- > und TTL-Gatter, Schieberegister, RTCs, Operationsverstärker,... alle > noch im DIP gibt und immer noch produziert werden. Ja immer NOCH. Natürlich bekommt man das alte Zeug noch in DIP. > Das würde ich nicht erwarten, wenn DIP wirklich tot wäre. Dann schau dir neuere Controller, Sensoren usw. mal an, in welchen Gehäusen die so angeboten werden.
Mein Opa ist auch tot. Also er atmet, er spricht und isst NOCH. Wenn man ihn mit jungen Menschen vergleicht, ist er tot.
Sebastian R. schrieb: > Mein Opa ist auch tot. > > Also er atmet, er spricht und isst NOCH. Wenn man ihn mit jungen > Menschen vergleicht, ist er tot. Wenn alles was neu rauskommt seit Jahren praktisch nur noch in SMD erscheint, wohin geht dann die Reise deiner Meinung nach? Aber es ist erstaunlich wie die Altchen hier immer wieder durch das DIP Thema getriggert werden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Du hast dich zu der Aussage verstiegen deine MSP Krücke wäre irgendwie > aktuellen modernen Controllern überlegen. Was nicht stimmt. Es gibt > keine objektiven Vorteile. > Du magst subjektive Vorteile haben, schön. Dann sag das gleich und > versteige dich nicht zu wirren Aussagen. Der MSP430 ist nicht überlegen! Er macht nur genau das was er soll! Ich brauche keinen Prozessor mit der Leistungsfähigkeit eines Intel i7 Prozessors. Den brauche ich noch nicht mal für mein KiCAD oder FreeCAD. Wenn ich den Garten umgrabe mache ich das ja auch nicht mit einem modernen 20t Hochleistungstraktor mit 20 Pflügen und 800PS. Bestenfalls nehme ich dann die alte Gartenfräse mit 1 PS.
Cyblord -. schrieb: > Wenn alles was neu rauskommt seit Jahren praktisch nur noch in SMD > erscheint, wohin geht dann die Reise deiner Meinung nach? Der PIC16F15386 ist Anfang letzten Jahres erschienen, fällt damit also in deine Kategorie "seit Jahren". Allerdings ist er auch im PDIP erhältlich, womit deine Aussage "nur noch in SMD" widerlegt wäre. Natürlich geht der Trend Richtung Miniaturisation, aber nur weil du ganz toll SMD löten kannst und du DIP doof findest, kann man daraus keine allgemeingültigen Aussagen treffen. Deine Aussagen "DIP ist tot" und "seit Jahren erscheint alles nur noch in SMD" sind schlichtweg falsch und sehr leicht widerlegbar. Deine Behauptungen stimmen für den aktuellen Trend und vermutlich für einen Großteil der Industrie (wir verarbeiten z.B. zu 80% nur noch Dies) funktionieren, aber deine Meinung repräsentiert nicht die aktuelle Wahrheit, sondern ist eben nur deine eigene Meinung.
Andreas V. schrieb: > Der MSP430 ist nicht überlegen! Er macht nur genau das was er soll! Ich > brauche keinen Prozessor mit der Leistungsfähigkeit eines Intel i7 > Prozessors. Den brauche ich noch nicht mal für mein KiCAD oder FreeCAD. Was für ein Unsinn brabbelst du da eigentlich? Grundsätzlich ist ein STM32 und ein MSP in der gleichen Liga. Was soll der i7 Vergleich? Für jede MPS430 Anwendung wirst du einen STM32 finden der nicht überdimensioniert ist. Trotzdem stellt er eben die zeitgemäße Alternative dar. In praktisch jeder hinsicht. Andreas V. schrieb: > Wenn ich den Garten umgrabe mache ich das ja auch nicht mit einem > modernen 20t Hochleistungstraktor mit 20 Pflügen und 800PS. Bestenfalls > nehme ich dann die alte Gartenfräse mit 1 PS. Woher diese unsäglich unpassenden Beispiele? Das passt doch hinten und vorne nicht.
Cyblord -. schrieb: > Sebastian R. schrieb: >> Mein Opa ist auch tot. >> >> Also er atmet, er spricht und isst NOCH. Wenn man ihn mit jungen >> Menschen vergleicht, ist er tot. > > Wenn alles was neu rauskommt seit Jahren praktisch nur noch in SMD > erscheint, wohin geht dann die Reise deiner Meinung nach? > > Aber es ist erstaunlich wie die Altchen hier immer wieder durch das DIP > Thema getriggert werden. Das stimmt nicht! SMD hat nicht nur Vorteile! Nur weil etwas alt ist muss es nicht schlecht sein! Ich hasse solche Totschlagargumente. Egal was ich mache: ARM Cortex und 32 Bit. Dass der ARM in vielen Fällen nur zu 1% ausgenuzt wird interessiert anscheinend niemand...
Andreas V. schrieb: > SMD hat nicht nur Vorteile! Nur weil etwas alt ist muss es nicht > schlecht sein! Ich hasse solche Totschlagargumente. Es geht nicht darum was man besser oder schlechter findet. Es ist nun mal eine Tatsache das SMD auf dem Vormarsch ist. Daran ändert auch ein "neuer" PIC im DIP Gehäuse nichts. AVR und PIC sind traditionell sehr mit DIP verbandelt und halten DIP noch die Stange. Aber sogar hier wirds es dünner. > Dass der ARM in vielen Fällen nur zu 1% ausgenuzt wird interessiert > anscheinend niemand... Ist das genaus so eine Mär wie die dass man sein Gehirn nur zu 10% nutzt? Woher kommt diese Erkentniss? Quellen? Studien? Wie misst man das? Speicher, Geschwindigkeit, Pin-Nutzung? Bitte erläutere uns das mal genauer. Das interessiert mich.
:
Bearbeitet durch User
Cyblord -. schrieb: > Was für ein Unsinn brabbelst du da eigentlich? Grundsätzlich ist ein > STM32 und ein MSP in der gleichen Liga. Was soll der i7 Vergleich? Schon mal eine Abschätzung bezüglich Aufwand / Nutzen gemacht? Glaube nicht!
Andreas V. schrieb: > Cyblord -. schrieb: >> Was für ein Unsinn brabbelst du da eigentlich? Grundsätzlich ist ein >> STM32 und ein MSP in der gleichen Liga. Was soll der i7 Vergleich? > > Schon mal eine Abschätzung bezüglich Aufwand / Nutzen gemacht? > > Glaube nicht! Weil du es intellektuell nicht gebacken bekommst auf eine moderne Plattform umzusteigen, können alle anderen Aufwand und Nutzen nicht korrekt abschätzen? Weil dein MSP ist am auslaufen und die ganze Welt ist schon auf ARM umgestiegen. Also wer ist denn nun hier der Geisterfahrer?
:
Bearbeitet durch User
Cyblord -. schrieb: > Wenn alles was neu rauskommt seit Jahren praktisch nur noch in SMD > erscheint, wohin geht dann die Reise deiner Meinung nach? Die Bauform hat etwas mit der Bestückung und damit mit der Grösse der Serien zu tun. THT ist für Handbestückung besser geeignet, SMD für Automatenbestückung besser geeignet. THT ist damit für Reparaturen geeignet die ja manuell erfolgen, bei SMD wird eher die ganze Platine ersetzt, was nicht das Problem wäre, wenn sie genau so mit Bestellnummer zu ordern wäre wie einzelne Bauteile, leider ist das nicht so, bei Reichelt gibt es keine Miele Waschmaschinenplatine etc. und bei Miele gibt es die nicht billiger als eine ganze Waschmaschine. Das heisst für Bauteile die es nur noch in SMD gibt: Keine Handbestückung mehr, keine kleinen Serien, nur noch Grosserien mit Bestückungsautomaten auf denen nichts repariert wird, sondern nur noch weggeschmissen wird. Macht man aber aktuell irgendwelche Geräte auf (LED Lampen, Netzteile, HiFi), findet man noch überraschend viel in THT. Wenn sich manche Hersteller ohne Not aus diesem Marktanteil verabschieden wollen weil sie nur noch Millionenstückzahlen im Automobilbereich in ihren Dollaraugen leuchten haben, nur zu.
Cyblord -. schrieb: > Weil du es intellektuell nicht gebacken bekommst auf eine moderne > Plattform umzusteigen, können alle anderen Aufwand und Nutzen nicht > korrekt abschätzen? Weil dein MSP ist am auslaufen und die ganze Welt > ist schon auf ARM umgestiegen. Also wer ist denn nun hier der > Geisterfahrer? Wer sagt denn dass ich noch keinen CORTEX programmiert habe? Manchmal macht es aber keinen Sinn mit Kanonen auf Spatzen zu schiessen. Selbst 48 Pins sind mindestens 34 Pins zu viel. 34mA im Betrieb sind mir einfach zu viel. Selbst bei internem Oszillator braucht der Cortex das mindestens Doppelte an Strom. Was nutzt mir ein Prozessor den ich ständig schlafen legen muss wenn ich ihn ständig brauche. Und nur im Sleep Mode braucht der Cortex nicht viel Strom. Natürlich kann man das Teil ständig schlafen legen mit allen Vorteilen und Nachteilen. Die Standby-Ströme erhohen sich bei modernen Architekturen um ein Vielfaches wenn die Temperatur z.B. Oberhalb von 25°C sind. Warum kann man nicht sachlich bleiben?
Als ich das letzte mal einen STM32F103C8T6 (Cortex M3) bei 8MHz mit einem Atmega328P bei ebenfalls 8MHz verglichen hatte, kam ich auf fast die gleiche Stromaufnahme.
Was hängen sich die ganzen "Neuerer" eigentlich immer an der DIP-Bauform auf? Es klingt hier immer so, als gäbe es nur die 32-Bitter und STM's und Co. einzig in diversen SMD-Bauformen... -nun. vom MSP430 gibt es ebenso diverse SMD-Ausführungen. Zudem sind 8bit oder 16bit noch lange nicht tot. In einer Zeit der vielzitierten Ressourcenschonung ist es doch gerade wichtig und umso richtiger, zweckentsprechend Material einzusetzen. Es geht nicht darum das Mögliche zu realisieren, sondern das Nötige! Entwicklungsumgebungen für den MSP gibt es zudem ebenfalls kostenlos. Sicher ist ein Umstieg auf eine andere Entwicklungsumgebung nicht so schwierig und auch nicht intellektuell besonders anstrengend (weil einige hier gleich wieder den Intellekt für sich beanspruchen wollen), aber es fehlt oft an Zeit. Außerdem sind auch hier wieder anderweitige Investitionen nötig, welche sich erst rechnen müssen. Ich habe selber vor ca. 8 Jahren mit dem STM32 begonnnen -und ja, unbestritten er hat seine Vorteile. Aber trotzdem tut das der zweckorientierten Anwendung des MSP keinen Abruf.
Andreas V. schrieb: > Die Standby-Ströme erhohen sich bei modernen Architekturen um ein > Vielfaches wenn die Temperatur z.B. Oberhalb von 25°C sind. Um ein vielfaches? Also werden aus 34mA bei 25° plötzlich >68mA bei 30°?
Cyblord -. schrieb: > Ist das genaus so eine Mär wie die dass man sein Gehirn nur zu 10% > nutzt? > > Woher kommt diese Erkentniss? Quellen? Studien? Wie misst man das? > Speicher, Geschwindigkeit, Pin-Nutzung? Bitte erläutere uns das mal > genauer. Das interessiert mich. Wenn ich folgende Schnittstellen habe: 3 x ADC, 2 x DAC, 2 x DMA, 2 x I2C 5 x USART 3 x SPI, 2 x I2S, 3 x CAN 1 x USB Ich nutze nur i2C. Ich schicke den Prozessor 950ms pro 1000ms zum Schlafen. Wieviel % der Leistung des µC nutze ich dann? Die Leistung geht gegen null. Der Stromverbrauch aber nicht. Wenn ich das Teil aber nun alle 100ms oder öfter brauche stellt sich die Frage ob sich das Schlafenlegen lohnt...
Stefanus F. schrieb: > Als ich das letzte mal einen STM32F103C8T6 (Cortex M3) bei 8MHz mit > einem Atmega328P bei ebenfalls 8MHz verglichen hatte, kam ich auf fast > die gleiche Stromaufnahme. ... und die wäre ? In welchem Betriebsmodi?
Andreas V. schrieb: > Ich schicke den Prozessor 950ms pro 1000ms zum > Schlafen. > > Wieviel % der Leistung des µC nutze ich dann? > > Die Leistung geht gegen null. Der Stromverbrauch aber nicht. Die Stromaufnahme geht im Sleep bei fast allen ARMs in den µA Bereich. Geh mal nachmessen, anstatt solche Behauptungen aufzustellen. Das Gleiche Haltlose Gewäsch, wie mit dem Vielfachen.
EloGuy schrieb: > Andreas V. schrieb: >> Die Standby-Ströme erhohen sich bei modernen Architekturen um ein >> Vielfaches wenn die Temperatur z.B. Oberhalb von 25°C sind. > > Um ein vielfaches? Also werden aus 34mA bei 25° plötzlich >68mA bei 30°? Un wie hoch ist dann der Betriebsstrom? ;-) Ich meinte Standby-Ströme!
Andreas V. schrieb: > Wenn ich > das Teil aber nun alle 100ms oder öfter brauche stellt sich die Frage ob > sich das Schlafenlegen lohnt... Wenn Du ihn alle 100ms für jeweils 99,5ms lang brauchst, lohnt es sich nicht, wenn das, was er alle 100ms machen soll, jeweils in 1ms oder weniger erledigt ist, schon.
EloGuy schrieb: > Die Stromaufnahme geht im Sleep bei fast allen ARMs in den µA Bereich. > Geh mal nachmessen, anstatt solche Behauptungen aufzustellen. > Das Gleiche Haltlose Gewäsch, wie mit dem Vielfachen. Ist halt beim MSP430 im Betrieb immer noch viel weniger.
M.A. S. schrieb: > Wenn Du ihn alle 100ms für jeweils 99,5ms lang brauchst, lohnt es sich > nicht, wenn das, was er alle 100ms machen soll, jeweils in 1ms oder > weniger erledigt ist, schon. Die I2C Komponenten sind nicht so schnell.
Das mit Standby-Betriebsstrom habe ich falsch aufgenommen. Meine Antwort mit den >68mA also bitte nicht ernst nehmen ;)
Andreas V. schrieb: > In welchem Betriebsmodi? "In welcheN Betriebsmodi" oder: "In welcheM BedtriebsmodUS"
Cyblord -. schrieb: >> - braucht extrem wenig Strom auch ohne Low Energy Mode. > > Unspezifierter Allgemeinplatz. STM32 gibts ebenfalls in Ultra Low Power > Varianten. Degen einen MSP430FR5994 verlieren alle ARMs, wenn man die FFT Leistung pro J(Ws) vergleicht!
ARM-ab schrieb im Beitrag #5629676: > Cyblord -. schrieb: > >>> - braucht extrem wenig Strom auch ohne Low Energy Mode. >> >> Unspezifierter Allgemeinplatz. STM32 gibts ebenfalls in Ultra Low Power >> Varianten. > > Degen einen MSP430FR5994 verlieren alle ARMs, wenn man die FFT Leistung > pro J(Ws) vergleicht! Wie das? ARM ist nur ein Lizenzkern. Die Hardware und die Fertigungstechnologie haben damit gar nichts zu tun.
Ich habe es eben noch einmal nachgemessen. Im Betrieb zieht der MSP430 ohne LED 360µA. Kann das das STM-Board auch? Da habe ich gerade nix zur Hand. Der Raspi Zero braucht ca 140mA. Beim ESP32 müsste ich auch mal nachmessen. Der bewegt sich aber auch im mA Bereich.
Andreas V. schrieb: > Weiß jemand wann welcher MSP430 auf- oder abgeküngigt wurde? (Direkte) Kunden von TI wissen das: http://www.ti.com/support-quality/quality-policies-procedures/product-change-notification.html Grundsätzlich ist die Lebensdauer von TI-Produkten mindestens 10 Jahre. Und was sich gut verkauft, wird auch nicht eingestellt. Beim MSP430 ist dein Problem, das es immer wieder neue Modelle gibt (heuzutage größtenteils FRAM), und dass die meisten anderen auf diese umgestiegen sind. > Kennt jemand die künftige Stategie von TI bezüglich MSP430? Wer sie kennt, darf sie nicht veröffentlichen. TI hat keine Probleme damit, ARM-Kerne einzusetzen. Davon sind aber keine kleiner als M4. Es würde für TI nichts bringen, MSP430 und Cortex-M0 parallel anzubieten, oder MSP430 rauszuschmeißen und damit alle bisherigen Kunden zu verprellen.
Cyblord -. schrieb: > ARM-ab schrieb im Beitrag #5629676: >> Degen einen MSP430FR5994 verlieren alle ARMs, wenn man die FFT Leistung >> pro J(Ws) vergleicht! > > Wie das? "The MSP430FR599x microcontrollers (MCUs) take low power and performance to the next level with the unique Low-Energy Accelerator (LEA) for digital signal processing. This accelerator delivers 40x the performance of Arm® Cortex®-M0+ MCUs to help developers efficiently process data using complex functions such as FFT, FIR, and matrix multiplication." So etwas ginge natürlich auch mit ARM (aber dort sagt man dann lieber "nimm NEON").
Andreas V. schrieb: > Stefanus F. schrieb: >> Als ich das letzte mal einen STM32F103C8T6 (Cortex M3) bei 8MHz mit >> einem Atmega328P bei ebenfalls 8MHz verglichen hatte, kam ich auf fast >> die gleiche Stromaufnahme. > > ... und die wäre ? > > In welchem Betriebsmodi? Ein bisschen herum Rechnen in Endlosschleife, ohne externe I/O. Gleicher Quelltext für beide Mikrocontroller (abgesehen von der Initialisierung).
Andreas V. schrieb: > Kennt jemand die künftige Stategie von TI bezüglich MSP430? Der MSP432 ... soll scheinbar als Ersatz dienen. Besser, neuer, stromsparender. Irgend wann will man eben den ganzen alten Mist einstampfen und etwas neues machen. Die werden doch sicherlich einen Hinweis zur Portierung der Projekte auf den neuen Controller rausgegeben haben oder irgend einen Hinweis um die MSP430 Kunden nicht zu verlieren.
Ich wüßte nicht, wozu ich noch einen MSP430 einsetzten sollte. Das Hauptargument "Ultar Low Power" können anderen Hersteller ebenfalls. Als Beigabe gibt es ein Mehr an Rechenleistung und Speicher zum günstigen Preis hinzu. Wenn es um Ultra Low Power geht... EFM32
Andreas V. schrieb: > Ich habe es eben noch einmal nachgemessen. Im Betrieb zieht der MSP430 > ohne LED 360µA. > > Kann das das STM-Board auch? > > Da habe ich gerade nix zur Hand. Der Raspi Zero braucht ca 140mA. Beim > ESP32 müsste ich auch mal nachmessen. Der bewegt sich aber auch im mA > Bereich. Haha, vergleich den am besten gleich noch mit einem Pentium II. Ich sage Mal so, die FRAM MSP430 uC'S sind im Vorteil, wenn man oft den Speicher überschreiben muss. Ansonsten würde ich die niergend eindesignen, da gibt es bessere Alternativen von ST mit mehr Performance, weniger Kosten, guten Tools und einer größeren Community. (Entschuldigt mich für soviel Denglish)
Cyblord -. schrieb: >> Schon mal einen STM32 gelötet? > > Schon oft. z.B. im LQFP32/48 Gehäuse. Nichts leichter als das. Diese Aussage ist definitiv falsch. wendelsberg
A. F. schrieb: > Haha, vergleich den am besten gleich noch mit einem Pentium II. > Den will ich ja gerade nicht..... > Ich sage Mal so, die FRAM MSP430 uC'S sind im Vorteil, wenn man oft den > Speicher überschreiben muss. Ansonsten würde ich die niergend > eindesignen, da gibt es bessere Alternativen von ST mit mehr > Performance, weniger Kosten, guten Tools und einer größeren Community. > (Entschuldigt mich für soviel Denglish) Was soll das? Wenn man nicht will dann redet man alles schlecht. Da helfen keine Argumente mehr. Wenn die Batterie leer ist, dann ist es halt so! Anforderungen scheinen keine Rolle mehr zu spielen. Früher gingen Ingenieure so vor dass sie erst mal analysierten was sie brauchten. Was ich in letzter Zeit sehe sind Programme mit maximal Overhead. Und das versucht man dann durch Performanz wieder auszugleichen. Schneller und stabiler wird's dann meistens auch nicht...
:
Bearbeitet durch User
Angehängte Dateien:
Mike J. schrieb: > Der MSP432 ... soll scheinbar als Ersatz dienen. Nein, das ist eine völlig andere Größenordnung. > Besser, neuer, stromsparender. Der neueste MSP ist der MSP430FR2355, und bei den passenden Anwendungen ist er besser und stromsparender.
Clemens L. schrieb: > Der neueste MSP ist der MSP430FR2355, und bei den passenden Anwendungen > ist er besser und stromsparender. Gibt es Erfahrung aus der Praxis was der neue MSP an Strom braucht? Zu ARM's scheint es ja nichts aussagekräftiges zu geben außer über Ruheströme. 38mA bzw. 1 mA ist mir definitiv zu viel im Gegensatz zu 370µA beim MSP430. Wahrscheinlich tränen den Leuten sonst die Augen bzw. die Batterie wird heiß!
Mike J. schrieb: > Der MSP432 ... soll scheinbar als Ersatz dienen. > Besser, neuer, stromsparender. > Irgend wann will man eben den ganzen alten Mist einstampfen und etwas > neues machen. > > Die werden doch sicherlich einen Hinweis zur Portierung der Projekte auf > den neuen Controller rausgegeben haben oder irgend einen Hinweis um die > MSP430 Kunden nicht zu verlieren. Der MSP432P401 zieht laut Datenblatt im Active Mode um die 1000µA. Gibt's dazu Erfahrungen? Die 370µA beim MSP430 habe ich übrigems bei zwei aktiv wechslden GPIO's (und einigen Bitoperationen und Additionen) im Actice Mode gemessen was einem Zugriff mit I2C entspricht!
Andreas V. schrieb: > Was soll das? > > Wenn man nicht will dann redet man alles schlecht. Da helfen keine > Argumente mehr. Wenn die Batterie leer ist, dann ist es halt so! > Anforderungen scheinen keine Rolle mehr zu spielen. Früher gingen > Ingenieure so vor dass sie erst mal analysierten was sie brauchten. Ich habe doch meine Argumente gelistet (zumindest einen Teil davon). Habe Erfahrung mit STM, MSP, AVR, EMF32, LPC gemacht. Die STM uC möchte ich nicht missen. MSP hat gewöhnlich auch höhere VDDmin Spannung, STM32L0 hat eine ALU, 32 bit BUS usw.
A. F. schrieb: >> >> Wenn man nicht will dann redet man alles schlecht. Da helfen keine >> Argumente mehr. Wenn die Batterie leer ist, dann ist es halt so! >> Anforderungen scheinen keine Rolle mehr zu spielen. Früher gingen >> Ingenieure so vor dass sie erst mal analysierten was sie brauchten. > > Ich habe doch meine Argumente gelistet (zumindest einen Teil davon). > Habe Erfahrung mit STM, MSP, AVR, EMF32, LPC gemacht. Die STM uC möchte > ich nicht missen. MSP hat gewöhnlich auch höhere VDDmin Spannung, > STM32L0 hat eine ALU, 32 bit BUS usw. Der MSP430 kommt locker mit 2V zurecht, aber dann ist die Batterie auch leer. Ich sehe halt keine konkreten Werte für die anderen Prozessoren! Das was ich sehe sind hohe Ströme über 1mA im Active Mode die man durch schlafen legen versucht auszugleichen!
Angehängte Dateien:
-
MSP430FR2355.png
50 KB
Andreas V. schrieb: > Clemens L. schrieb: >> Der neueste MSP ist der MSP430FR2355, und bei den passenden Anwendungen >> ist er besser und stromsparender. > > Gibt es Erfahrung aus der Praxis was der neue MSP an Strom braucht? Ca. 335 µA bei 1 MHz, aber das ist abhängig vom Cache. Wenn es dich interessiert: das Ding ist TI ein LaunchPad wert: http://www.ti.com/tool/MSP-EXP430FR2355
Clemens L. schrieb: > Andreas V. schrieb: >> Clemens L. schrieb: >>> Der neueste MSP ist der MSP430FR2355, und bei den passenden Anwendungen >>> ist er besser und stromsparender. >> >> Gibt es Erfahrung aus der Praxis was der neue MSP an Strom braucht? > > Ca. 335 µA bei 1 MHz, aber das ist abhängig vom Cache. > > Wenn es dich interessiert: das Ding ist TI ein LaunchPad wert: > http://www.ti.com/tool/MSP-EXP430FR2355 Cool! Das bestäigt meine Erfahrungswerte mit dem MSP430G25X3 und MSP430FXXXX! Ich glaube da haben sie nicht mehr viel herausgeholt. Die MSP430 FR-Reihe habe ich bislang nur auf einem fertigen Breadboard erlebt, aber da hielt eine 2032 Batterie nur ca. 3 Wochen; was aber an der Applikation und an den BLE Komponenten lag.
Andreas V. schrieb: > man list immer öfter "Restposten" bei der Beschaffung von MSP430. Ach, tut "man" das? Ist denn überhaupt schon irgendeine MSP430-Variante abgekündigt worden, von den ultrasteinalten aus der Vor-Flash-Zeit mal abgesehen?
Andreas V. schrieb: > Cyblord -. schrieb: >> DIP ist tot. > > .. aber praktisch! DIP ist so ziemlich das unpraktischste was man sich überhaupt vorstellen kann, es ist unbrauchbar groß, es ist schlecht zu bestücken und es ist bei Reparaturen schlecht auszutauschen.
Beitrag #5630067 wurde von einem Moderator gelöscht.
Rufus Τ. F. schrieb: > Ist denn überhaupt schon irgendeine MSP430-Variante abgekündigt > worden, von den ultrasteinalten aus der Vor-Flash-Zeit mal abgesehen? https://www.digikey.de/products/de/integrated-circuits-ics/embedded-microcontrollers/685?FV=ffec5831%2Cffec5bda%2Cffec7c00%2Cffec7c01%2Cffec7c02%2Cffec7c03%2Cffec7c04%2Cffec7c05%2Cffec7c06%2Cffec9218%2Cffec92ce%2Cffecb275%2C1c0011%2C1c0002%2C1c0003%2C1c0006%2C1f140001%2C1f140007%2Cffe002ad&ColumnSort=1000002&pageSize=100
Ich möchte hier mal den STM32F030 als Vergleich einbringen. Laut Datenblatt "6.3.5 Supply current characteristics" braucht der bei 8MHz vom Internen Oszillator ohne PLL: 4,5mA mit allen Peripherals enabled 3mA mit allen Peripherals disabled Habe das auch mal kurz getestet und es kommt ziemlich genau hin. Clemens L. schrieb: > Ca. 335 µA bei 1 MHz, aber das ist abhängig vom Cache. Ich habe den STM auch mal bei einer AHB von 1MHz getestet, die Sysclock ist weiterhin bei 8MHz, da man diese beim STM32F030 nicht runter teilen kann. Damit kam ich auf 1,5mA mit Systick, einem Timer und GPIOA eingeschaltet. Braucht also deutlich mehr. Für Stromsparanwendungen sind also natürlich MSP430 oder PIC besser, aber als Generallösung für Bastler sind die STM32 recht gut zu gebrauchen. Andreas V. schrieb: > Zu ARM's scheint es ja nichts aussagekräftiges zu geben außer über > Ruheströme. 38mA bzw. 1 mA ist mir definitiv zu viel im Gegensatz zu > 370µA beim MSP430. Bei ST ist in jedem Datasheet eine Tabelle mit Stromverbrauch, manchmal sogar noch Stromverbrauch der einzelnen Peripherals enthalten.
Für andere Controller habe ich jetzt keine wirklichen Erfahrungen, aber mit den MSP430 ist es mit überschaubarem Aufwand mit RTC und LCD aktiv mit gelegentlichem Aufwachen Batterielaufzeiten von >1 Jahr aus einer CR2016 Knopfzelle zu erreichen: https://github.com/carrotIndustries/pluto Andere Uhrprojekte, wie die goodwatch benutzen auch einen MSP430. Für Anwendungen, bei denen es primär darauf ankommt, wenig Strom zu verbrauchen sind MSP430 für mich nach wie vor die erste Wahl.
Nun... wir waren vor einigen Jahren... noch vor dem großen ARM-Run auf der Suche nach einem extrem sparsamen uC. Die MSP430-Familie kannte ich noch aus den spätern 90ern und... bis auf ein paar spezielle 4bit-Prozessoren, die nur in 100k+/Jahr erhältlich waren (Uhrenchips oder sowas) gab es nix vergleichbares zum MSP430. Atmel sowieso nicht, PIC - nur über meine Leiche und sonst? Energy Micro hat gerade angefangen LP-ARMs zu Promoten. Ergebnis der Recherche und dann der nachfolgenden Entwicklung: 1 aktiver Sensor, 1 aktiver Prozessor und ein Linearregler von 6 auf 3V3 - alle zusammen mit je nach Tagesverfasung 800nA-1uA (Nanoampere und Mikroampere, damit es keine Lesefehler verursacht) Das andere System mit einem etwas größeren MSP braucht heiße 1,8uA, da ist die RTC und einige Interrupts aktiv. Und das Kistl läuft bis zu einer Batteriespannung von 1,9-2V. Ich habe bis heute keinen ARM (und sei er auch noch so ULP angepriesen) gefunden, der bei 32kHz RTC-Clk, damit laufenden Timern und Interrups im Sleepmode 3 bzw 4 aktiv unter 600nA Eigenbedarf hat. Daher - eine Empfehlung für einen handelüblichen ARM wäre nett - wenn es ihn den gibt.
Ich glaube für Ultra Low Power Anwendungen ist ein ARM Cortex uC einfach nicht der richtige. Kerne wie der MSP430 sind extra auf Low Power optimiert, die Peripherals ebenfalls. Hersteller von ARM Cortex uC können da nur bei den Peripherals etwas ändern, der Cortex mit dem Bux Matrix System ist zugekauft. Dazu kommt noch, dass der Kern einfach größer ist, und typischerweise macht mehr Fläche und Komplexität auch mehr Strom.
Bernd K. schrieb: > DIP ist so ziemlich das unpraktischste was man sich überhaupt vorstellen > kann, es ist unbrauchbar groß, es ist schlecht zu bestücken und es ist > bei Reparaturen schlecht auszutauschen. Schon mal einen TSSOP, SOP, VQFN, QFN, LQFP, NFBGA oder ähnliches Bauteil mit dem Schraubendreher im Feld ausgewechselt?
Beitrag #5630219 wurde von einem Moderator gelöscht.
Andreas V. schrieb: > Bernd K. schrieb: >> DIP ist so ziemlich das unpraktischste was man sich überhaupt vorstellen >> kann, es ist unbrauchbar groß, es ist schlecht zu bestücken und es ist >> bei Reparaturen schlecht auszutauschen. > > Schon mal einen TSSOP, SOP, VQFN, QFN, LQFP, NFBGA oder ähnliches > Bauteil mit dem Schraubendreher im Feld ausgewechselt? Wenn jemand Designs verkauf die ISP-fähige uCs im Feld tauschen müssen hat das Design wahrlich andere Probleme, die Bauform ist da nur das sichtbare Symptom des Entwicklerversagens.... Abgesehen davon: Ja, das geht. Wenn der entsprechende Bauteil auf einem Subprint montiert ist, dazu braucht es kein DIP-Gehäuse. PS - zu DIP-Zeiten waren verbogene IC-Pins, die bei der Inbetriebnahme funktioniert haben und dann im Feld nach einer überschaubar kurzen Zeit ausgefallen sind eine der üblicheren Fehlerursachen. Und ja, wir hatten Genrad-ICT, Pattern-"Recognizer" von HP und einigen anderen damals neumodischen Kram zur Verfügung. MiWi
MiWi schrieb: > Wenn jemand Designs verkauf die ISP-fähige uCs im Feld tauschen müssen > hat das Design wahrlich andere Probleme, die Bauform ist da nur das > sichtbare Symptom des Entwicklerversagens.... Es kann immer mal passieren dass ein Bauteil sich verabschiedet! > > Abgesehen davon: Ja, das geht. Wenn der entsprechende Bauteil auf einem > Subprint montiert ist, dazu braucht es kein DIP-Gehäuse. Das Subprint ist dann aber auch fehlerträchtig und aufwendig. Nicht wahr? > > PS - zu DIP-Zeiten waren verbogene IC-Pins, die bei der Inbetriebnahme > funktioniert haben und dann im Feld nach einer überschaubar kurzen Zeit > ausgefallen sind eine der üblicheren Fehlerursachen. Und ja, wir hatten > Genrad-ICT, Pattern-"Recognizer" von HP und einigen anderen damals > neumodischen Kram zur Verfügung. Gibt's dazu nicht die QS? Prüft ihr euere Geräte nicht? Sichtprüfung? Automatisiert bei Großserien? Objekterkennung? > > MiWi
Alex D. schrieb: > Ich möchte hier mal den STM32F030 als Vergleich einbringen. Das Problem beim F0 ist, dass der Flash relativ stromhungrig ist. Das ist bei den L0 und L4 komplett anders, da die in einem anderen Prozess gefertigt werden. Alex D. schrieb: > Ich habe den STM auch mal bei einer AHB von 1MHz getestet, die Sysclock > ist weiterhin bei 8MHz, da man diese beim STM32F030 nicht runter teilen > kann. Damit kam ich auf 1,5mA mit Systick, einem Timer und GPIOA > eingeschaltet. Versorge den F0 mal mit einem externen 1MHz Takt und führe den Code aus dem RAM aus, dann sieht die Welt ganz anders aus. MiWi schrieb: > Daher - eine Empfehlung für einen handelüblichen ARM wäre nett - wenn es > ihn den gibt. STM32L4 haben solche "low power timer" (und sogar LPUART) und liegen auch in der Region was den Standbyverbrauch mit RTC angeht. Man muss natürlich auch bedenken, dass typischerweise ein erheblicher Teil des Gesamtverbrauchs in den Phasen anfällt, in denen der Controller aktiv ist und da gilt natürlich "je kürzer desto besser". D.h. wiederum ich kann nicht einfach den Stromverbrauch von einem ATMega oder PIC bei 8 MHz mit dem Verbrauch eines L4 bei 8 MHz vergleichen, weil der CM4F einfach ein vielfaches der Rechenleistung bei gleichem Takt bringt, damit ein vielfaches schneller mit der eigentlichen Berechnung fertig ist und somit früher wieder schlafen kann. Der reine Standbyverbrauch ist da gar nicht so kriegsentscheidend und es ist fast egal ob das Ding jetzt 600nA oder 800nA zieht.
EloGuy schrieb: > Andreas V. schrieb: >> Ich schicke den Prozessor 950ms pro 1000ms zum >> Schlafen. >> >> Wieviel % der Leistung des µC nutze ich dann? >> >> Die Leistung geht gegen null. Der Stromverbrauch aber nicht. > > Die Stromaufnahme geht im Sleep bei fast allen ARMs in den µA Bereich. >... Die Sleep-Modi des MSP werden wimre in nA angegeben (100nA beim F149). Die µA Angaben in dem Datenblatt gelten für den Betrieb mit voller Kanne. Auch wenn die ARM-Fanboys hier noch so engagiert sind: Im Stromsparen sind ARMs kagge. Die Interrupt-Latenz von einem 144MHz M3 ist auch nicht wirklich prickelnd. Der ARM verheizt halt rund 30 Takte, während der MSP nur 3 bis 4 braucht. Der Fairness halber muss man sagen: Ein 16Bit ARM wäre wohl genauso sparsam, und ein 32Bit MSP würde bei 100MHz wohl auch an der mA-Grenze kratzen. Für jeden MuC gib es ein sinnvolles Einsatzfeld. Auch für die (noch immer wachsende Familie) der MSP430s wird sich das nicht ändern.
@juut Ich schweiß was! Kann es sein dass der MSP432 ein 32 Bit ARM Cortex M4 ist? - 32 Bit Float Point Unit IEEE (die ich nicht brauche) - 32 Bit Adressraum (den ich nicht brauche) - entsprenchend viele Schnittstellen (die ich nicht brauche) - Datenstrukturen auf 32 Bit optimiert - 5 x mehr Rechenleistung (urgrg) ... und dennoch stromsparend ist. Logischerweise braucht er mehr Strom als der MSP430...
R2D2 schrieb: > Welcher MSP430 kann 64 Bit? Der MSP430 ist ein 16 Bit µProcessor! Eine Float Point Unit hat er auch nicht. Ich kann nur ohne Weiteres 64 Bit Operationen verarbeiten wenn ich es im Compiler einstelle... Z.B. double kann je nach Einstellung 32 Bit haben oder 64 Bit haben. Es geht allerdings nicht immer nur um Rechenleistung!
Roland E. schrieb: > Der ARM verheizt halt rund 30 Takte, während der MSP > nur 3 bis 4 braucht. Quatsch und damit zeigst du auch, dass du dich nicht auskennst. Es sind zwischen 12-16 Takte bei Cortex Mx. Damit braucht ein MSP430 250ns bei 16Mhz. Ein ARM schafft das bei 48-64MHz auch. Mit einem STM32L0 kommt man locker unter 1uA inklusive RTC. Bei anderen Herstellern sieht es ähnlich aus. MiWi schrieb: > Ich habe bis heute keinen ARM (und sei er auch noch so ULP angepriesen) > gefunden, der bei 32kHz RTC-Clk, damit laufenden Timern und Interrups im > Sleepmode 3 bzw 4 aktiv unter 600nA Eigenbedarf hat. STM32L011 -> 540nA
Andreas V. schrieb: > @juut > Ich schweiß was! Du bist ja eine Superschlaunase. :-( Ist der 432 der Ablöser vom 430??? Das ist die Frage!!!
Alex D. schrieb: > Ich glaube für Ultra Low Power Anwendungen ist ein ARM Cortex uC einfach > nicht der richtige. Kerne wie der MSP430 sind extra auf Low Power > optimiert, die Peripherals ebenfalls. Glauben tut man da, wo die Fenster bunt sind.... Das die MSPs stromsparend sind bezweifelt keiner, aber das können andere Hersteller auch. Manchmal hilft auch der Blick in die Erratas und letztlich der Preis. Bei uns wird der MSP nicht mehr eingesetzt. MiWi schrieb: > Ich habe bis heute keinen ARM (und sei er auch noch so ULP angepriesen) > gefunden, der bei 32kHz RTC-Clk, damit laufenden Timern und Interrups im > Sleepmode 3 bzw 4 aktiv unter 600nA Eigenbedarf hat. Der EFM32 liegt im EM2 bei 900uA.
Stefan schrieb: > Was die selbst ernannten "Trolljäger" und "Neuer Schneller Weiter" > vergötternden Herrschaften wieder für einen substanzlosen Nonsens > schreiben. > Warum soll man alles mit einem ARM erschlagen? Warum soll man auf eine > andere Familie bzw. auf einen anderen Hersteller ausweichen? > Der MSP430 reicht für eine Unmenge an Anwendungen und stellt eine > optimale Lösung dar. Es ist eben nicht die Lösung mit Kanonen auf > Spatzen zu schießen. > Auch das Argument, man hätte für "spätere Erweiterungen" dann noch "luft > nach oben" zieht hier nicht. Denn oftmals werden abgeschlossene Designs > erarbeitet, so dass die "Luft nach oben" oft ein komplettes Redesign > erfordert. > Zudem muss man sich bei einem Umstieg erst in eine neue > Entwicklungsumgebung einarbeiten. Dafür ist gerade in der > anwendungsorientierten Praxis kaum Zeit. Glückwunsch! Der erste mir bekannte Text, in dem die Formulierung "selbst ernannt" vorkommt, der aber dennoch nicht nur Unsinn enthält. Sonst ist das ein recht zuverlässiges Kriterium ...
MSP ist juuut schrieb: > Wofür ist denn wohl der MSP432? "MSP432P4 high-precision ADC MCUs": http://www.ti.com/microcontrollers/simplelink-mcus/wired-mcus/overview/msp432p4.html "MSP432E4 Ethernet MCUs": http://www.ti.com/microcontrollers/simplelink-mcus/wired-mcus/overview/msp432e4.html ist juuut schrieb: > Ist der 432 der Ablöser vom 430??? Das ist die Frage!!! Der kleinste 432 fängt dort an, wo die größten 430 aufhören. Also nein!!!
R2D2 schrieb: > Welcher MSP430 kann 64 Bit? Jeder, wenn der Compiler für eine Addition 4x ADC benutzt. :o) So etwas geht beim ARM natürlich auch ...
ist juuut schrieb: > Du bist ja eine Superschlaunase. :-( > > Ist der 432 der Ablöser vom 430??? Das ist die Frage!!! Die Frage war eigentlich: Wie lange kann ich den MSP430 noch verwenden bzw. beziehen?
Andreas V. schrieb: > Zu ARM's scheint es ja nichts aussagekräftiges zu geben außer über > Ruheströme. 38mA bzw. 1 mA ist mir definitiv zu viel im Gegensatz zu > 370µA beim MSP430. Du hast dich definitiv nicht informiert, oder sind die Herrstellerangaben für dich grundsätzlich nicht aussagekräftig? STM32L011x3/4 comprehensive set of power-saving modes allows the design of low-power applications. Features - Down to 76 μA/MHz in Run mode - 41 μA 12-bit ADC conversion at 10 ksps - 0.23 μA Standby mode (2 wakeup pins) - 0.29 μA Stop mode (16 wakeup lines) - 0.54 μA Stop mode + RTC + 2 KB RAM retention
Clemens L. schrieb: > MSP ist juuut schrieb: >> Wofür ist denn wohl der MSP432? > > "MSP432P4 high-precision ADC MCUs": > http://www.ti.com/microcontrollers/simplelink-mcus/wired-mcus/overview/msp432p4.html > "MSP432E4 Ethernet MCUs": > http://www.ti.com/microcontrollers/simplelink-mcus/wired-mcus/overview/msp432e4.html > > ist juuut schrieb: >> Ist der 432 der Ablöser vom 430??? Das ist die Frage!!! > > Der kleinste 432 fängt dort an, wo die größten 430 aufhören. Also > nein!!! Liegt die Wahrheit wie so oft nicht in der Mitte?
Andreas V. schrieb: > Liegt die Wahrheit wie so oft nicht in der Mitte? "In Gefahr und höchster Not, ist der Mittelweg der Tod."
A. F. schrieb: > Andreas V. schrieb: >> Zu ARM's scheint es ja nichts aussagekräftiges zu geben außer über >> Ruheströme. 38mA bzw. 1 mA ist mir definitiv zu viel im Gegensatz zu >> 370µA beim MSP430. > > Du hast dich definitiv nicht informiert, oder sind die > Herrstellerangaben für dich grundsätzlich nicht aussagekräftig? > > STM32L011x3/4 comprehensive set of power-saving modes allows the design > of low-power applications. > Features > - Down to 76 μA/MHz in Run mode > - 41 μA 12-bit ADC conversion at 10 ksps > - 0.23 μA Standby mode (2 wakeup pins) > - 0.29 μA Stop mode (16 wakeup lines) > - 0.54 μA Stop mode + RTC + 2 KB RAM retention Entschuldigung, aber ich kenne nicht alle der 100000 erhältlichen µProzessoren! Herstellerangaben genieße ich immer mit Vorsicht! Das heißt nicht dass das etwas mit Realbetrieb zu tun hat. Ich sehe das immer als ungefähre Hausnummer. Jeden Prozessor mit den entsprechenden Ausprägungen kann ich nicht durchtesten. Das dürfte relativ teuer und zeitaufwändig werden!
Ich habe mich mal umgesehen. Der STM32F103C8T6 ist der Einzige STM32 der preislich und von der Größe her passt. Der scheint mit 5V über µUUSB betrieben zu werden und dann mit einem Low Drop heruntergeregelt zu werden. Mit 3.3V scheint er auch betrieben werden zu können. Den 72Mhz Quarz werde ich mal versuchen durch einen 8MHz bzw. kleiner auszutauschen. Rein Interesse halber werde ich mir das Ding mal betellen und untersuchen! Tear down the STM32's! Ich bin mal auf die Ergebnisse gespannt!
Andreas V. schrieb: > Der scheint mit 5V über µUUSB betrieben zu werden und dann mit einem Low > Drop heruntergeregelt zu werden. Von was redest du da? Von irgendeinem Board wo der drauf ist? Vom Controller selber sicher nicht. Du verwendest irgendwie Controller und Board recht synonym. Ich würde dir raten das besser zu unterscheiden.
Cyblord -. schrieb: > Von was redest du da? Von irgendeinem Board wo der drauf ist? Vom > Controller selber sicher nicht. > > Du verwendest irgendwie Controller und Board recht synonym. Ich würde > dir raten das besser zu unterscheiden. Und schon reletiviert sich alles wieder!!! :-) Das ist ein : STM32F103C8T6 Minimalsystem Modul Da gibts nicht viel mehr als der Prozessor mit Herausführung der PIN's, einem Reset Schalter, Pulldowns und dem Quarz. Den Linearregler kill ich im Notfall mit dem Lötkolben! Wer natürlich Lust auf Beschäftigungstherapie hat kann sich selbst was zusammenbasteln!
Andreas V. schrieb: > Cyblord -. schrieb: >> Von was redest du da? Von irgendeinem Board wo der drauf ist? Vom >> Controller selber sicher nicht. >> >> Du verwendest irgendwie Controller und Board recht synonym. Ich würde >> dir raten das besser zu unterscheiden. > > Und schon reletiviert sich alles wieder!!! :-) Inwiefern? > > Das ist ein : STM32F103C8T6 Minimalsystem Modul > > Da gibts nicht viel mehr als der Prozessor mit Herausführung der PIN's, > einem Reset Schalter, Pulldowns und dem Quarz. Den Linearregler kill ich > im Notfall mit dem Lötkolben! Wer natürlich Lust auf > Beschäftigungstherapie hat kann sich selbst was zusammenbasteln! Das spielt doch keine Rolle wie viel da drauf ist. Es ist kein reines Breakout sondern ein Gesamtsystem mit Spannungswandler. Das ist deutlich von einem nackten Controller zu unterscheiden. Aber das sollte bei deinem MSP430 genau so sein. Es gibt nackte Controller und Boards. Oder nicht? Ich verstehe hier dein rumgeier nicht ganz, wenn ich ehrlich bin. Ich möchte nur eine korrekte Terminologie hinweisen. Denn eine Aussage wie > Der STM32F103C8T6 [...] Der scheint mit 5V über µUUSB betrieben zu > werden und dann mit einem Low > Drop heruntergeregelt zu werden. ist grundfalsch und führt in die Irre. > Wer natürlich Lust auf > Beschäftigungstherapie hat kann sich selbst was zusammenbasteln! Du solltest mal ein wenig bedenken dass es verschiedene Welten gibt. Ich hebr für meine Schaltungen immer prof. gefertige Platinen erstellt und da kommt natürlich ein nackter Controller drauf. Irgendwelche fertigen Boards habe ich noch nie benutzt. Das hat aber nichts mit "Beschäftigungstherapie" zu tun, sondern weil ich aufgeräumte, saubere und kompakte Baugruppen benötige. Deine Breadboard-Welt ist nicht der Nabel der Welt und zu könntest ein wenig Demut walten lassen bei deinen Aussagen. Die haben dich oben schon in Schwierigkeiten gebracht.
:
Bearbeitet durch User
Cyblord -. schrieb: > ist grundfalsch und führt in die Irre. Angst vor der Wahrheit? Da sind nur die zum Betrieb nötigen Komponenten vorhanden! Irgendwie muss man das Ding ja betreiben! Wie gesagt der Linearregler kann entfernt werden! Sonst ist da nix drauf!
Andreas V. schrieb: > Cyblord -. schrieb: >> ist grundfalsch und führt in die Irre. > > Angst vor der Wahrheit? Da sind nur die zum Betrieb nötigen Komponenten > vorhanden! Irgendwie muss man das Ding ja betreiben! Oh je.... Welche Wahrheit? Ein STM32 läuft an 3,3V ohne externe Komponenten. Ein paar Kerkos sollte man im Zweifel vorsehen. Nochmal: Ist das beim MSP430 irgendwie anders? Worum geht es dir hier? > Wie gesagt der Linearregler kann entfernt werden! Sonst ist da nix > drauf! Darum gehts doch nicht.
:
Bearbeitet durch User
Cyblord -. schrieb: > Welche Wahrheit? Ein STM32 läuft an 3,3V ohne externe Komponenten. Ein > paar Kerkos sollte man im Zweifel vorsehen. > Nochmal: Ist das beim MSP430 irgendwie anders? Worum geht es dir hier? - Der µP muss möglichst wenig Leistung verbraten. - Der µP muss bezahlbar sein. - Der µP muss lange beziehbar sein. - Der µP muss I2C haben. - Der µP muss SBW (oder JTAG) haben. - Rechenleistung ist relativ egal! Der MSP430 braucht grundsätzlich nur VDD, GND und selbst den Reset-Pulldown kann man sich im Notfall sparen; ein absoluter Minimalist! SBW ist schlanker als JTAG, => vorzugsweise SBW. Angaben wie µA/Mhz finde ich nicht hilfreich (Habe ich in einem STM Dokument gelesen). Herstellerangaben sehen immer positiv aus. Aus diesem Grund lese ich die Dokumente mit Vorsicht. Das probiere ich dann lieber aus. Ich bin ja grundsätzlich immer offen für alles! Aber es muss auch für den Einsatzzweck passen und praktikabel sein!
Andreas V. schrieb: > Der MSP430 braucht grundsätzlich nur VDD, GND und selbst den > Reset-Pulldown kann man sich im Notfall sparen; ein absoluter > Minimalist! Nochmal. Was ist der Unterschied zum STM32? Das ist dort doch genau so. Allerdings sollte man bei beiden Controllern die Kerkos trotzdem vorsehen. Aber ich denke das dreht sich hier im Kreis. Deine Spitzen gegenüber STM32 sind unbegründet und wie gesagt kann ich grade nicht nachvollziehen worum es dir in der Diskussion um das Board eigentlich geht. Jetzt nochmal alle DEINE persönlichen Anforderungen aufzuschreiben ist sicher nicht zielführend.
:
Bearbeitet durch User
Angehängte Dateien:
-
slaa668-figure1.png
96 KB
Cyblord -. schrieb: > Ein STM32 läuft an 3,3V ohne externe Komponenten. Ein paar Kerkos sollte > man im Zweifel vorsehen. > Nochmal: Ist das beim MSP430 irgendwie anders? Nein. Aber um zum ursprünglichen Thema zurückzukommen: Den MSP432P4 kann man einen Induktor spendieren, um den internen LDO durch einen Step-Down-Wandler zu ersetzen. (Bei den MSP430 würde sich das nicht lohnen.)
Clemens L. schrieb: > Aber um zum ursprünglichen Thema zurückzukommen: Den MSP432P4 kann man > einen Induktor spendieren, um den internen LDO durch einen > Step-Down-Wandler zu ersetzen. (Bei den MSP430 würde sich das nicht > lohnen.) Das ursprüngliche Thema war: Wie lange krieg ich den MSP430 noch? Der MSP braucht keinen LDO, weil sich die Frage nicht stellt. 3,3V Betriebsspannung und beim MSP432 auch soweit ich das sehe. Step-Downs sind nicht immer nur vorteilhaft.
Andreas V. schrieb: > Der MSP braucht keinen LDO, weil sich die Frage nicht stellt. 3,3V > Betriebsspannung und beim MSP432 auch soweit ich das sehe. > Step-Downs sind nicht immer nur vorteilhaft. Ah daher weht der Wind. Da haben wir schon das zweite Thema welches die Altchen hier so richtig zum kochen bringt: 5V ist auch tot. Seite an Seite mit DIP begraben und vergessen. Warum? Aus ähnlichen Gründen. Man findet kaum noch moderne Bauteile die nativ mit 5V arbeiten. Praktisch alles neue arbeitet mit 3,3V. Seien es Controller, Sensoren oder sonstige Halbleiter. Natürlich gibt manchmal welche mit 5V Toleranz. D.h. in den meisten Schaltungen die man heute auf 5V Logik/Controllerspannung auslegt bekommt man zwangsläufig eine Ansammlung von Spannungs- und Pegelwandlern um halbwegs moderne Peripherie anschließen zu können. Das Problem kennen die Freunde des Arduino wenn mal Peripherie ohne ein fertiges Schield betrieben werden soll. Da brauchts dann meist auch wieder Pegelwandler. Was immer noch oft verwendet wird, und 5V benötigt sind die guten alten LC Displays. Die machen in reinen 3,3V Schaltungen praktisch als einzige noch ein bisschen Probleme. Aber die werden zunehmend durch billige SPI OLEDs abgelöst die natürlich alle nur noch mit 3,3V arbeiten. Deshalb würde ich dir raten, nicht nur auf SMD sondern auch gleich auf 3,3V umzusteigen.
:
Bearbeitet durch User
Andreas V. schrieb: > Bernd K. schrieb: >> DIP ist so ziemlich das unpraktischste was man sich überhaupt vorstellen >> kann, es ist unbrauchbar groß, es ist schlecht zu bestücken und es ist >> bei Reparaturen schlecht auszutauschen. > > Schon mal einen TSSOP, SOP, VQFN, QFN, LQFP, NFBGA oder ähnliches > Bauteil mit dem Schraubendreher im Feld ausgewechselt? Schonmal ein DIP mit dem Schraubendreher ausgelötet? Im Feld?
Cyblord -. schrieb: > Nochmal. Was ist der Unterschied zum STM32? Das ist dort doch genau so. > Allerdings sollte man bei beiden Controllern die Kerkos trotzdem > vorsehen. > > Aber ich denke das dreht sich hier im Kreis. Deine Spitzen gegenüber > STM32 sind unbegründet und wie gesagt kann ich grade nicht > nachvollziehen worum es dir in der Diskussion um das Board eigentlich > geht. Ich habe nichts gegen den STM! Es interessiert mich halt nur welcher µP die Batterie schneller leer zieht. Was ich in letzter Zeit sah war: Wir nehmen einen ARM und leben mit der leeren Batterie oder wir nehmen eine Lithium Batterie in der Größe einer Monozelle für 50€.
Andreas V. schrieb: > Ich habe nichts gegen den STM! Es interessiert mich halt nur welcher µP > die Batterie schneller leer zieht. Wie passt das zu deiner Aussage: > Angaben wie µA/Mhz finde ich nicht hilfreich Entweder du interessierst dich für den Stromverbrauch oder nicht. Und der Verbrauch hängt leider enorm vom Takt ab, da beißt die Maus keinen Faden ab. > Was ich in letzter Zeit sah war: > Wir nehmen einen ARM und leben mit der leeren Batterie oder wir nehmen > eine Lithium Batterie in der Größe einer Monozelle für 50€. Das Stromverbrauchsthema wurde doch weiter oben schon gut besprochen. Strom sparen geht mit anderen Controllern auch. Auch mit STM32. >> Schon mal einen TSSOP, SOP, VQFN, QFN, LQFP, NFBGA oder ähnliches >> Bauteil mit dem Schraubendreher im Feld ausgewechselt? > Schonmal ein DIP mit dem Schraubendreher ausgelötet? Im Feld? Korrekt. SMD lötet man mit Heißluft in kurzer Zeit aus und ein neues Bauteil wieder ein.
:
Bearbeitet durch User
Man könnte meinen STM wären die einzigen die ARM-Controller herstellen wenn man hier liest. Ziemlich einseitig.
Cyblord -. schrieb: > Wie passt das zu deiner Aussage: >> Angaben wie µA/Mhz finde ich nicht hilfreich > > Entweder du interessierst dich für den Stromverbrauch oder nicht. > Und der Verbrauch hängt leider enorm vom Takt ab, da beißt die Maus > keinen Faden ab. Der Stromverbrauch ist nur innerhalb bestimmter Grenzen annähernd Linear. Man muss halt die Grenzen kennen, sonst läuft die Rechnung ganz schnell aus dem Ruder!
Bernd K. schrieb: > Man könnte meinen STM wären die einzigen die ARM-Controller herstellen > wenn man hier liest. Ziemlich einseitig. Ja der STM32 fungiert hier ein wenig als Platzhalter.
Andreas V. schrieb: > Der Stromverbrauch ist nur innerhalb bestimmter Grenzen annähernd > Linear. Man muss halt die Grenzen kennen, sonst läuft die Rechnung ganz > schnell aus dem Ruder! Kannst du das mal näher erläutern?
Cyblord -. schrieb: > Kannst du das mal näher erläutern? Sorry, ich meinte die Kurve Taktfrequenz zu Stropmverbrauch ist dann nicht mehr linear wenn ich z.B. unter 1 MHz gehe oder über 75 MHz oder wie auch immer sich der STM verhält.
Cyblord -. schrieb: > Bernd K. schrieb: >> Man könnte meinen STM wären die einzigen die ARM-Controller herstellen >> wenn man hier liest. Ziemlich einseitig. > > Ja der STM32 fungiert hier ein wenig als Platzhalter. Nicht gerade repräsentativ. Zum Beispiel werden immerzu dessen Nachteile (überbordend komplexe Peripherie, Clock-Tree, etc) genannt um unzutreffende Aussagen über die ganze Cortex-M-Welt zu tätigen.
Bernd K. schrieb: >> Ja der STM32 fungiert hier ein wenig als Platzhalter. > > Nicht gerade repräsentativ. Zum Beispiel werden immerzu dessen Nachteile > (überbordend komplexe Peripherie, Clock-Tree, etc) genannt um > unzutreffende Aussagen über die ganze Cortex-M-Welt zu tätigen. Deshalb: Glaube nur dem was Du selbst ausprobiert hast! Ich weiß ehrlich nicht genau ob es "extrem" stromsparende ARM's gibt. Das war glaube ich nie wirklich der Fokus in dieser "extremen" Liga zu spielen.
Die ganze Diskussion ist doch Käse, deswegen habe ich auch oben die aussterbenden weißen Männer ins Gespräch gebracht. _MSP430 wird es genau so lange geben wie TI die gewinnbringend unter die Leute bringen kann, wenn das mal nicht mehr der Fall ist, sind die Dinger von ehute auf morgen abgekündigt und fertig. Den Luxus von 2nd Sources wie beim 8080, 8085 oder Z80 noch üblich, gibt es nicht mehr. Selbst wenn man nicht SMT32 sondern Cortex-M3 sagt, findet sich Nichts direkt kompatibles, der Kern ist zwar bei anderen Herstellern auch verfügbar, die Peripherie, die den größten Teil des Portierungsaufwandes verursacht, ist aber bei jedem Hersteller anders. Natürlich sind 32Bit ne feine Sache, man hat Platz und das Ding ist relativ schnell, aber auch in der Gegend haben andere Mütter schöne Töchter, ob nun in China die neuen Eigenentwicklungen, die kommenden RiscV oder die Mips kompatibeln wie beispielsweise von Infineon (in jeder Menge Routern zu finden). Es wäre doch echt Mist wenn es nur noch Blondinen gäbe, oder? Gruß, Holm
Andreas V. schrieb: > A. F. schrieb: >> - 41 μA 12-bit ADC conversion at 10 ksps Das ist doch nur der ADC Strom (IDDA (ADC)). Der gesamte Strom müsste doch deutlich höher liegen, oder? > Herstellerangaben genieße ich immer mit Vorsicht! Genau - Seit #1 vom Datenblatt ist die 'Werbung', der Rest des Datenblattes das 'Kleingedruckte', *, **, ***,..
33Bit schrieb: > Genau - Seit #1 vom Datenblatt ist die 'Werbung', der Rest des > Datenblattes das 'Kleingedruckte', *, **, ***,.. Das heißt nicht, dass die erste Seite falsch ist. Man muss nur mit typischen Angaben unter Randbedingungen rechnen. Mit Glauben hat das allgemein nichts zu tun.
Angehängte Dateien:
Andreas V. schrieb: > die Kurve Taktfrequenz zu Stropmverbrauch ist dann nicht mehr linear wenn > ich z.B. unter 1 MHz gehe oder über 75 MHz oder wie auch immer sich der > STM verhält. Hast du so eine Kurve? Bei einem anderen ARM sieht es ziemlich linear aus. (Aber unter 1 MHz gibt es dort auch nicht; dann sind eher die Leckströme im Schlafmodus interessant.)
Wenn euch jedes einzelne uA so weh tut, schaut doch zu den schweizer Uhrenherstellern. Die haben 4 Bit uC, die wirklich sparsam sind...
Andreas V. schrieb: > Ich weiß ehrlich nicht genau ob es "extrem" stromsparende ARM's gibt. Heutzutage so etwas wie "EFM32 Zero Gecko": https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko Soweit ich sehe, ganz grob 15 % weniger Strom als MSP430 bei gleicher Taktfrequenz.
Clemens L. schrieb: > Andreas V. schrieb: >> Ich weiß ehrlich nicht genau ob es "extrem" stromsparende ARM's gibt. > > Heutzutage so etwas wie "EFM32 Zero Gecko": > https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko > Soweit ich sehe, ganz grob 15 % weniger Strom als MSP430 bei gleicher > Taktfrequenz. Die Sau ist teuer! Selbst das blanke Bauteil (EFM32 Zero Gecko) kostet ein Vielfaches des MSP430 und ist garantiert nicht so weit verbreitet. Der Bezug ist auch nicht garantiert. Den EFM32 krieg ich auch nicht bei meinem Händler meines Vertrauens. Ich finde keine Alternative zum MSP die im Rahmen bleibt! Da bleibt einfach nur noch dass man extrem hohe Stückzahlen ordert.
Andreas V. schrieb: > Der (STM32F103C8T6) scheint mit 5V über µUUSB betrieben zu werden > und dann mit einem Low Drop heruntergeregelt zu werden. Nein, er wird mit maximal 3,6V betrieben. > Mit 3.3V scheint er auch betrieben werden zu können. Kannst auch auf 2V runter gehen, wenn du willst. > Den 72Mhz Quarz werde ich mal versuchen durch > einen 8MHz bzw. kleiner auszutauschen. Dieser µC kann gar nicht mit einem 72MHz Quarz betrieben werden. Normal sind 8MHz, intern kann man die Frequenz per PLL erhöhen, wenn man möchte. Da du ihn mal ausprobieren willst, werden Dich meine Infos zum Einstieg womöglich interessieren: http://stefanfrings.de/stm32/index.html
Andreas V. schrieb: > Angst vor der Wahrheit? Da sind nur die zum Betrieb nötigen Komponenten > vorhanden! Irgendwie muss man das Ding ja betreiben! Stimmt nicht. Du kannst auch beide Quarze, die LED's, und den USB-Anschluss entfernen. Minimal braucht man beim STM32F103C8T6 nur eine Stromversorgung. Sonst nichts.
Andreas V. schrieb: > Angaben wie µA/Mhz finde ich nicht hilfreich. > Herstellerangaben sehen immer positiv aus. Aus diesem Grund > lese ich die Dokumente mit Vorsicht. Bei STM32 kannst du dich auf die Angaben verlassen. Dafür lege ich meine Hand ins Wasser. Spass beiseite, die Angaben sind wirklich korrekt - kein Vergleich zu (z.B.) Espressif.
Stefanus F. schrieb: > Dieser µC kann gar nicht mit einem 72MHz Quarz betrieben werden. Normal > sind 8MHz, intern kann man die Frequenz per PLL erhöhen, wenn man > möchte. Du beschreibst das STM32F103VET6 Minimum System Board bestellt habe ich mir das STM32F103C8T6 Minimalsystem Modul Ich hoffe die sind kompatibel zueinander. Deine Seite ist übrigens Information pur! Cool!
Cyblord -. schrieb: > D.h. in den meisten Schaltungen die man heute auf 5V > Logik/Controllerspannung auslegt bekommt man zwangsläufig eine > Ansammlung von Spannungs- und Pegelwandlern um halbwegs moderne > Peripherie anschließen zu können. Das ist doch Quatsch. Die STM32 µC haben viele 5V tolerante I/O Pins. Die können mit Hilfe eines Pulls-Up Widerstandes sogar 5V ausgeben. Aber das ist nur selten nötig weil nahezu alle 5V IC's auch 3,3V oder wenigstens 3,6V tolerant sind. > Das Problem kennen die Freunde des Arduino Spielzeug... > Was immer noch oft verwendet wird, und 5V benötigt sind die guten alten > LC Displays. Die machen in reinen 3,3V Schaltungen praktisch als einzige > noch ein bisschen Probleme. Huch! Ich habe noch ein par alte Displays aus Anfang der 90er Jahre. Zu der Zeit gab es abgesehen von PC Prozessoren noch fast nichts mit 3,3V. Trotzdem laufen die Displays tadellos mit 3,3V. Man muss nur eine negative Kontrastspannung anlegen, die man mit einem simplen Timerausgang sehr bequem erzeugen kann. > Deshalb würde ich dir raten, nicht nur auf SMD sondern auch gleich auf > 3,3V umzusteigen. Na wenigstens sind wir uns hier einig.
Andreas V. schrieb: > Ich finde keine Alternative zum MSP die im Rahmen bleibt! > Da bleibt einfach nur noch dass man extrem hohe Stückzahlen ordert. Dann bleib doch beim MSP430. Digikey hat davon mehr als 100k lagernd... und ich habe nirgends gelesen, dass die abgekündigt werden - das ist eine Ente! Die kleinen Dinger bekommst du in Stückzahlen ab einem Dollar, die sind einfach zu programmieren, und wenn sie den Zweck erfüllen, dann passt es doch?
Holm T. schrieb: > _MSP430 wird es genau so lange geben wie TI die gewinnbringend unter die > Leute bringen kann, wenn das mal nicht mehr der Fall ist, sind die > Dinger von ehute auf morgen abgekündigt und fertig. Jo, deckt sich fast mit der offiziellen Politik von TI. Nur das von Heute auf Morgen stimmt nicht, das Bauteil wird erstmal auf NRND gesetzt und dann gibts nach einer Karenzzeit einen Termin für den LTB.
Andreas V. schrieb: > Stefanus F. schrieb: >> Dieser µC kann gar nicht mit einem 72MHz Quarz betrieben werden. Normal >> sind 8MHz, intern kann man die Frequenz per PLL erhöhen, wenn man >> möchte. Nein, ich beschreibe die STM32F103 Mikrocontroller Serie. Dies bezüglich sind sie alle gleich. > Deine Seite ist übrigens Information pur! Cool! Vielen Dank Ich finde es immer hilfreich, wenn Anfänger ihre ersten Erkenntnisse für andere Anfänger aufschreiben. Sonst kann es bis zum ersten Hello World schon mal mehrere Tage dauern und das macht (zumindest mir) dann keinen Spaß.
Andreas V. schrieb: > Stefanus F. schrieb: >> Dieser µC kann gar nicht mit einem 72MHz Quarz betrieben werden. Normal >> sind 8MHz, intern kann man die Frequenz per PLL erhöhen, wenn man >> möchte. > > Du beschreibst das > STM32F103VET6 Minimum System Board > > bestellt habe ich mir das > STM32F103C8T6 Minimalsystem Modul > > Ich hoffe die sind kompatibel zueinander. > > Deine Seite ist übrigens Information pur! Cool! Ich wollte schon lange etwas mit einem STM32 Cortex M3 oder M4 programmieren und habe mir gleich noch einen ST-Link Adapter besorgt. Das scheint einfacher und schneller und kompatibler zu sein. Bin mal gespannt auf den Stromverbrauch. Der Witz ist das SMD-Board ist 53mm x 22 mm groß (25 mm x 10 mm bzw. 18 mm x 10 mm hat MSP430). Ist halt eine andere Liga!
Udo K. schrieb: > und ich habe nirgends gelesen, > dass die abgekündigt werden - das ist eine Ente! Der MSP430 als komplette Controllerfamilie wohl nicht, aber einige Familienmitglieder scheinen abgekündigt zu werden, wie "Clemens" mit seinem Digikey-Link darstellte: Beitrag "Re: MSP430 Aufkündigung?" Einiges davon ist von TI durch funktional äquivalente Bausteine ersetzt worden, wie z.B. der MSP430F1101 durch den MSP430F1101A, bei anderen scheint sich das "Problem" nur auf die Bauform zu beziehen, wie z.B. der MSP430F2618 ... Man muss diese Digikey-Liste also wohl mit gewisser Vorsicht betrachten.
Udo K. schrieb: > Andreas V. schrieb: >> Ich finde keine Alternative zum MSP die im Rahmen bleibt! >> Da bleibt einfach nur noch dass man extrem hohe Stückzahlen ordert. > > Dann bleib doch beim MSP430. Digikey hat davon mehr als > 100k lagernd... und ich habe nirgends gelesen, > dass die abgekündigt werden - das ist eine Ente! > > Die kleinen Dinger bekommst du in Stückzahlen ab einem Dollar, > die sind einfach zu programmieren, > und wenn sie den Zweck erfüllen, dann passt es doch? Danke, bei dem Projekt werde ich das auch tun!
Rufus Τ. F. schrieb: > Einiges davon ist von TI durch funktional äquivalente Bausteine ersetzt > worden, wie z.B. der MSP430F1101 durch den MSP430F1101A, bei anderen > scheint sich das "Problem" nur auf die Bauform zu beziehen, wie z.B. der > MSP430F2618 ... > > Man muss diese Digikey-Liste also wohl mit gewisser Vorsicht betrachten. Die Datenblätter und Suchfunktionen von Digikey sind oft hilfreich. Merkwürdigerweise unterscheidet Digikey zwischen "Obsolet" und "Nicht für Neukonstruktionen". Ich interpretiere das so: "Nicht mehr verfügbar" und "solange Vorrat reicht". Bei dem oben genannten Filter auf "Obsolet" und "Nicht für Neukonstruktionen" befindet sich keine PDIP-Version. Es sind komischerweise P, E und F-Typen die auslaufen und noch nicht einmal ein G-Typ. Das hätte ich jetzt nicht gedacht.
Andreas V. schrieb: > Die Datenblätter und Suchfunktionen von Digikey sind oft hilfreich. Mag sein, aber Datenblätter für MSP430 würde ich primär bei TI suchen. Zumal die Digikey-Liste durch die Auflistung aller möglichen Bauformen auch noch unnötig aufgebläht wird.
Michael X. schrieb: > Holm T. schrieb: > >> _MSP430 wird es genau so lange geben wie TI die gewinnbringend unter die >> Leute bringen kann, wenn das mal nicht mehr der Fall ist, sind die >> Dinger von ehute auf morgen abgekündigt und fertig. > > Jo, deckt sich fast mit der offiziellen Politik von TI. Nur das von > Heute auf Morgen stimmt nicht, das Bauteil wird erstmal auf NRND gesetzt > und dann gibts nach einer Karenzzeit einen Termin für den LTB. Ja, NRND ist doch im Endeffekt nichts Anderes als "abgekündigt" mit letzter Bestellmöglichkeit usw.. Ich habe alles Mögliche schon in den Fingern gehabt und der MSP430 ist nicht das Schlechteste Teil, auch wenn mich die recht vielen nie beseitigten Fehler etwas nerven. Ansonsten find ich den durchaus gut gemacht, er hat ja auch deutsche Väter. Am ekligsten fand ich bisher PICs, ist ja auch ein hornaltes GI Design, aber die Anschauungen gehen da auseinander, auch kenne ich weder PIC18 noch PIC32. Gruß, Holm
Cyblord -. schrieb: > Dir ist schon klar dass nicht nach allgemeinen Vorteilen sondern > spezifisch nach Vorteilen GEGENÜBER STM32, oder Cortex-M allgemein von > mir aus, gefragt wurde? Wenn du hier nicht so raunzen würdest, wäre das Klima angenehmer. Aber zum Thema: Suche bei all den üblichen Cortexen mal nach einem, der 1..4 SigmaDelta-ADC's mit bis zu 24 Bit drin hat. Oder suche mal nach welchen, die bereits ab 1.8 V betriebsbereit sind. Nee, auch wenn ich selber keine MSP430 verwende, so weiß ich doch, daß man diese µC-Reihe nicht so abtun sollte, wie du das hier grad veranstaltest. Allerdings sehe ich auch, daß die Preise für die MSP430 durchaus ein Stückchen höher liegen als so mancher annähernd vergleichbarer Cortex. W.S.
W.S. schrieb: > Wenn du hier nicht so raunzen würdest, wäre das Klima angenehmer. Darfst gerne wieder gehen wenns dir nicht gefällt.
Cyblord -. schrieb: > W.S. schrieb: >> Wenn du hier nicht so raunzen würdest, wäre das Klima angenehmer. > > Darfst gerne wieder gehen wenns dir nicht gefällt. Das steht Dir natürlich auch frei. Ich suche immer noch nach einem Cortex unter 2€ der weniger als 370µA im Betrieb macht!
Angehängte Dateien:
Andreas V. schrieb: > Das steht Dir natürlich auch frei. Ich suche immer noch nach einem > Cortex unter 2€ der weniger als 370µA im Betrieb macht! STM32L011 https://www.mouser.de/ProductDetail/STMicroelectronics/STM32L011D3P6TR?qs=sGAEpiMZZMuKfYsiLTIqmO%2fWjgiA4i60SEbJeBC76HI%3d Bei den anderen Distris hatte ich jetzt keine Lust zu suchen.
Rufus Τ. F. schrieb: > Welchen Teil von "Cortex" hast Du jetzt nicht verstanden? Dachte ich mir auch gerade :-)
Jap, verwendbar ab 9,61 € https://www.digikey.de/products/de/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=STM32L011
TrollJäger schrieb: > Andreas V. schrieb: >> Das steht Dir natürlich auch frei. Ich suche immer noch nach einem >> Cortex unter 2€ der weniger als 370µA im Betrieb macht! > > STM32L011 Abgesehen davon ist der Stromverbrauch im Betrieb völlig nebensächlich. Deine verteufelten uA/MHz sind interessant, sowie der Stromverbrauch im Sleep. Je schneller der uC ist, desto länger kann er schlafen.
Andreas V. schrieb: > Ja! 32 Bit und ARM Cortex ist die Lösung für alles!!! Auch für prellende Tasten?
Ich dachte gerade: Am besten ich hole mir ein AK47 und lege das Teil komplett schlafen!... Maximale Stromersparnis! Sorry, aber das konnte ich mir jetzt nicht verkneifen! ;-) Stromverbrauch ist abhängig von der Anwendung! Die Argumente hörte ich schon oft. Aber dann schafften die Herrn Doktoren es nicht einen Betrieb von mehr als drei Wochen zu gewährleisten...
Krakau schrieb: > Andreas V. schrieb: >> Ja! 32 Bit und ARM Cortex ist die Lösung für alles!!! > > Auch für prellende Tasten? Für Alles; ansonsten 42! ;-)
Andreas V. schrieb: > Stromverbrauch ist abhängig von der Anwendung! Was ist daran denn so schwer zu vertstehen? Dein MSP430 braucht 100us/s für die Anwendung und der Cortex für die gleiche Aufgabe 20us/s. Bei gleichem Strombedarf im Sleepmode, darf der Cortex den fünffachen Strom im Betrieb verbrauchen. In der Realität ist der Vergleich etwas komplexer. Aber wenn es nicht auf einzelne nA ankommt kann ich jede MSP430 Anwendung auf einem Low Power Cortex laufen lassen. Schneller und billiger ist er auch noch bei gleichem Speicherausbau.
avr schrieb: > Was ist daran denn so schwer zu vertstehen? Dein MSP430 braucht 100us/s > für die Anwendung und der Cortex für die gleiche Aufgabe 20us/s. Bei > gleichem Strombedarf im Sleepmode, darf der Cortex den fünffachen Strom > im Betrieb verbrauchen. In der Realität ist der Vergleich etwas > komplexer. Aber wenn es nicht auf einzelne nA ankommt kann ich jede > MSP430 Anwendung auf einem Low Power Cortex laufen lassen. Schneller und > billiger ist er auch noch bei gleichem Speicherausbau. Es ist eben komplexer und andere Komponenten spielen halt auch noch eine Rolle. I2C Komponenten brauchen auch ihre Zeit und wenn man mehrere I2C Komponenten hat wird es nicht einfacher bzw. schneller. Bei einer Blinklichtausgabe gebe ich Dir Recht. Auch bei Rechenoperationen geht das in Ordnung. Natürlich kann man mit Interrupts arbeiten. Letzten Endes kann man das Gerät nicht so oft schlafen legen wie man das in der Theorie gerne möchte...
Rufus Τ. F. schrieb: > Welchen Teil von "Cortex" hast Du jetzt nicht verstanden? Ging es nicht um eine Low-Power Alternative zum MSP430? STM32L011 54uA ab 1,30 EUR EFM8SB2 90uA ab 0,50 EUR EFM8BB1 290uA ab 0,30 EUR Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch mehr verbrauchen.
Lothar schrieb: > Ging es nicht um eine Low-Power Alternative zum MSP430? Ich betrachtete Deinen Beitrag als Antwort hierauf: > Ich suche immer noch nach einem > Cortex unter 2€ der weniger als 370µA im Betrieb macht!
Lothar schrieb: > Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch > mehr verbrauchen. Wer sich den STM32l011 wegen den 54µA holt, muss dann eben direkt oder mit alternativen std-libs arbeiten. Das ist kein Argument. Die HAL ist eine von vielen Möglichkeiten. Man macht doch auch keine quälende Diät nur um Sonntags Fleisch essen zu können ;)
Lothar schrieb: > Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch > mehr verbrauchen. [ ] Die Hal muss benutzt werden [ ] Du kennst die um Welten schlankere LL-Variante Der efm8 braucht übrigens Dank unfähigen Compiler deutlich länger. Die Codeoptimierung ist einfach nur traurig. Das Speichermodell, bei dem der Programmierer auch noch die Segmente festlegen muss auch.
avr schrieb: > Lothar schrieb: >> Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch >> mehr verbrauchen. > > [ ] Die Hal muss benutzt werden > [ ] Du kennst die um Welten schlankere LL-Variante > > Der efm8 braucht übrigens Dank unfähigen Compiler deutlich länger. Die > Codeoptimierung ist einfach nur traurig. Das Speichermodell, bei dem der > Programmierer auch noch die Segmente festlegen muss auch. Kann man das beim IAR im Compiler einstellen? HAL = Hardware Abstraction Layer LL = Lower Level? Ich kann nichts finden. Evtl. heißt die Option anders!
:
Bearbeitet durch User
LL LowLevel? CMSIS für den ARM-Kern und für die STM32 spezifischen Dinge direkt in C an den Registern fummeln. Da kommt man nicht drum herum, wenn man aus so einem kleinen Controller das letzte rausholen will. Sind denn die AVRs schon so in Vergessenheit geraten, dass alle nur noch mit "libs" hantieren können? - Wie ich dieses Wort hasse. In der Bibliothek leihe ich mir Bücher aus, ihr Super-Hacker.
OK, dann habe ich das falsch aufgefasst gehabt. Ich schick meine Nachrichten auch meistens byteweise. Das läuft schneller und fehlerfreier. Die Libs haben oft Fehler bzw. viel Overhead. Jetzt weiss ich auch warum mir Embedded Programmierung so gut gefällt...
EloGuy schrieb: > LL LowLevel? Das ist eine alternative HAL von ST, die eher auf Registerebene arbeitet, das ganze aber dennoch etwas abstrahiert und praktisch keinen Overhead aufweist. EloGuy schrieb: > Sind denn die AVRs schon so in Vergessenheit geraten, dass alle nur noch > mit "libs" hantieren können? Was hat den der Einsatz von Libraries mit avrs zu tun? Bei fertigen HALs geht oftmals ums Sparen von Entwicklungszeit. Und Middleware möchte man zum Teil gar nicht selbst programmieren. Hast du deinen Ethernet- und USB-Stack selbst programmiert? MP3 oder JPEG Decoder? Sowas programmiert man heute kaum noch selbst und das aus guten Grund.
Es geht bei Hardware Abstraktion auch nicht um einen kompletten Ethernet-Stack, sondern um die ST-HAL zum Pin-Wackeln. Total oversized und die Arbeit, zu verstehen was da passiert, da kann man gleich ins Datenblatt schauen. Und ja, USB-Treiber für NetBSD, jpeg, mp3 und Video encodierung habe ich schon zu Fuß gemacht. Mit AVRs hat das insofern was zu tun, als dass kaum noch einer an Datenrichtungsregister denkt, einen Timer versteht und für alles braucht man eine lib. Zu Zeiten von AVR Studio 4 auf Win2000 hatte man die ausgedruckten Referenzen, Datenblätter usw auf dem Tisch und kam damit zurecht. Jeder ist ein Hacker und ein Maker. Das kam erst nachdem Mikrocontroller zur Consumerware für Blogger wurden. Meine ADC lieb geht nicht, was mach ich falsch?
avr schrieb: > Andreas V. schrieb: >> Stromverbrauch ist abhängig von der Anwendung! > > Was ist daran denn so schwer zu vertstehen? Dein MSP430 braucht 100us/s > für die Anwendung und der Cortex für die gleiche Aufgabe 20us/s. Bei > gleichem Strombedarf im Sleepmode, darf der Cortex den fünffachen Strom > im Betrieb verbrauchen. In der Realität ist der Vergleich etwas > komplexer. Aber wenn es nicht auf einzelne nA ankommt kann ich jede > MSP430 Anwendung auf einem Low Power Cortex laufen lassen. Schneller und > billiger ist er auch noch bei gleichem Speicherausbau. 10 Chinesen brauchen 14 Tage um ein Haus zu bauen, wie lange dauert es das Haus zu bauen wenn 10 000 Chinesen gleichzeitig arbeiten? Gruß, Holm
Holm T. schrieb: > 10 Chinesen brauchen 14 Tage um ein Haus zu bauen, wie lange dauert es > das Haus zu bauen wenn 10 000 Chinesen gleichzeitig arbeiten? > Wenn Du dieses Wochenende neun Frauen schwängerst, wann wirst Du dann Vater?
Lothar schrieb: > Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch > mehr verbrauchen. Erstens musst du keinen HAL nutzen, zweitens kann man in C++ dank zero cost abstraction heute wesentlich stärker abstrahierten Code schreiben, ohne dass er deswegen ineffizient wird.
Andreas V. schrieb: > Es ist eben komplexer und andere Komponenten spielen halt auch noch eine > Rolle. I2C Komponenten brauchen auch ihre Zeit Sorry, jetzt wird es aber ziemlich absurd. Ein I²C Bus nimmt typischerweise 2mA alleine schon wegen der Pull-Up Widerstände auf. Und du feilscht hier um µA ?
Lothar schrieb: > Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch > mehr verbrauchen. Die HAL muss man nicht benutzen.
Percy N. schrieb: > Holm T. schrieb: > >> 10 Chinesen brauchen 14 Tage um ein Haus zu bauen, wie lange dauert es >> das Haus zu bauen wenn 10 000 Chinesen gleichzeitig arbeiten? >> > > Wenn Du dieses Wochenende neun Frauen schwängerst, wann wirst Du dann > Vater? Du hasts wohl verstanden. Gruß, Holm
Stefanus F. schrieb: > Andreas V. schrieb: >> Es ist eben komplexer und andere Komponenten spielen halt auch noch eine >> Rolle. I2C Komponenten brauchen auch ihre Zeit > > Sorry, jetzt wird es aber ziemlich absurd. > > Ein I²C Bus nimmt typischerweise 2mA alleine schon wegen der Pull-Up > Widerstände auf. Und du feilscht hier um µA ? Guter Einwand! Wenn Du langsamer taktest und entsprechend anpasst kannst Du in den unteren µA-Bereich kommen. Typischerweise macht man das beim SMBus oft so. Es muss nur zusammenpassen und es dürfen keine Fehler entstehen. EMV ist da natürlich ein Thema. Und ja! Ich habe keine µA zu verschenken! Die µA addieren sich schnell zu mA zusammen. Eine Energiequelle mit der Kapazität einer Motorrad-Batterie(14 Ah) am besten mit Step-Down-Converter auf 3,3V geht natürlich auch. Die gibts aber auch als Lithium für 3V mit step-Up-Converter. ;-)
Holm T. schrieb: >> Wenn Du dieses Wochenende neun Frauen schwängerst, wann wirst Du dann >> Vater? Gar nicht mehr! :-)
:
Bearbeitet durch User
Andreas V. schrieb: > Holm T. schrieb: >>> Wenn Du dieses Wochenende neun Frauen schwängerst, wann wirst Du dann >>> Vater? > > Gar nicht mehr! :-) ...nee Du, das schrieb Holm ganz und gar nicht. Gruß, Holm
Stefanus F. schrieb: > Lothar schrieb: >> Zudem dürfte der STM32 dank HAL deutlich länger brauchen und damit auch >> mehr verbrauchen. > > Die HAL muss man nicht benutzen. Jetzt habe ich auch verstanden was Du unter HAL verstehst! Das kenne ich bei komplexen High Level Systemen mit Geschäftsprozessen, bei Betriebssystemen und dem ganzen anderen Kram etwas anders. Aber das gehört nicht hier her! Es wächst halt alles immer mehr zusammen...
Holm T. schrieb: > Andreas V. schrieb: >> Holm T. schrieb: >>>> Wenn Du dieses Wochenende neun Frauen schwängerst, wann wirst Du dann >>>> Vater? >> >> Gar nicht mehr! :-) > > ...nee Du, das schrieb Holm ganz und gar nicht. > > Gruß, > > Holm Da ist etwas durcheinander gekommen! Gruß
:
Bearbeitet durch User
Andreas V. schrieb: > Stefanus F. schrieb: >> Ein I²C Bus nimmt typischerweise 2mA alleine schon wegen der Pull-Up >> Widerstände auf. Und du feilscht hier um µA ? > > Guter Einwand! > Wenn Du langsamer taktest und entsprechend anpasst kannst Du in den > unteren µA-Bereich kommen. Ein langsamerer Takt erhöht auch die Dauer der I²C-Transaktionen. Insgesamt Energie sparen geht besser (und teurer) nur mit Konstantstromquellen (LTC1694/LTC4311) oder Chips mit Beschleunigern (z.B. MAX20326, TCA9406).
(Es geht um I²C mit ungewöhnlich großen Pull-Up Widerständen, um Strom zu sparen) Andreas V. schrieb: > Wenn Du langsamer taktest und entsprechend anpasst kannst Du in den > unteren µA-Bereich kommen. Und bist voll außerhalb der Spezifikationen, denn die fordert eine gewisse Flankensteilheit. Wir hatten neulich erst jemanden, bei dem es genau deswegen nicht funktionierte.
vn nn schrieb: > Erstens musst du keinen HAL nutzen, zweitens kann man in C++ dank zero > cost abstraction heute wesentlich stärker abstrahierten Code schreiben, > ohne dass er deswegen ineffizient wird. ..und drittens hast du rein GARNICHTS verstanden. Hier geht es um sinnvolle Lowlevel-Treiber, also solche Programmteile, die die zugrundeliegende Hardware tatsächlich abstrahieren. Das sieht dann so aus, daß man aus höheren Programmschichten keinen Port mehr sieht, wo man a la ST ne Funktion SetPort(Port,Bit,HiOderLo) hat, sondern wo man eine Funktion a la SchalteLampe(EinOdeAus) hat. In letzterem Falle abstrahiert der Treiber nämlich wirklich die zugrundeliegende Hardware, die in einem Fall ein Portpin sein kann, in einem anderen Fall aber auch ein über WLAN zu erreichendes Gerät. Die höheren Programmschichten wollen die Funktion, also Lampe ein oder aus - aber es soll ihnen schnurz sein, ob das per Pin oder grünem Marsmännchen erfolgt. Der ganze Schmonzes von ST hingegen abstrahiert rein GARNICHTS. Er bläht bloß alles auf. Insofern sind alle derartigen "HAL"-Machwerke eben keine Hardware-Abstraktionsschicht. Und noch ein Wort zum Stromsparen: Man kann Holms Chinesen eben nicht so handhaben, wie es avr hier meint: avr schrieb: > Dein MSP430 braucht 100us/s > für die Anwendung und der Cortex für die gleiche Aufgabe 20us/s. Und warum ist diese Rechnung falsch? Weil manche Dinge eben ihre Zeit brauchen, egal wie schnell ein µC trampeln kann. Beim I2C zum Beispiel kannst du eben nicht den Takt nach Belieben schneller machen, da gibt es Vorgaben, die das verbieten. Ebenso brauchst du dafür Hochzieher an SCL und SDA, die du nicht beliebig hochohmig machen kannst. Aber das nur am Rande.. Und nochwas ganz Generelles: Monokulturen hatten schon immer kurzzeitige Vorteile, aber auf lange Sicht waren sie auch schon immer etwas sehr Schlechtes. Man braucht auf lange Sicht die Vielfalt. Gilt überall, in der Gesellschaft, in der Technik, in Hard- und in Software. W.S.
W.S. schrieb: > Man braucht auf lange Sicht die Vielfalt. Gilt überall, in der > Gesellschaft, in der Technik, in Hard- und in Software. Gilt auch bei Meinungen. Solche Diskussionen sind gut und wir müssen uns nicht krampfhaft auf einen gemeinsamen Stand einigen.
W.S. schrieb: > Und warum ist diese Rechnung falsch? Weil manche Dinge eben ihre Zeit > brauchen, egal wie schnell ein µC trampeln kann. Beim I2C zum Beispiel > kannst du eben nicht den Takt nach Belieben schneller machen, da gibt es > Vorgaben, die das verbieten. Ebenso brauchst du dafür Hochzieher an SCL > und SDA, die du nicht beliebig hochohmig machen kannst. Aber das nur am > Rande.. Sehe ich genauso! Funktionieren tut alles immer mit dem kleinsten gemeinsamen Nenner. Bei 100kbps und mehreren Sensoren und insgesamt 100 Datenbytes und 500% Übertragungsoverhead und Toleranz und Sicherheit sind das ca. 50ms / 1000ms. Allerdings verteilt in mehrere Abschnitte pro 1000ms zu verschiedenen Zeiten. Schlafen legen lohnt sich dann nur bedingt. Übrigens gilt dann nur für die 50ms: 3,3V / 1,8K = 1,80mA 3,3V / 10K = 0,33mA 3,0V / 10K = 0,30mA 2,8V / 10K = 0,28mA Das Integral kann sich dann jeder selbst ausrechnen. Und das ist extrem grob geschätzt! Viel tiefer geht dann auch nicht.
Stefanus F. schrieb: > W.S. schrieb: >> Man braucht auf lange Sicht die Vielfalt. Gilt überall, in der >> Gesellschaft, in der Technik, in Hard- und in Software. > > Gilt auch bei Meinungen. Solche Diskussionen sind gut und wir müssen uns > nicht krampfhaft auf einen gemeinsamen Stand einigen. Daumen rauf! Obwohl man das eigentlich nicht sagen sollen müsste!!!
Stefanus F. schrieb: > W.S. schrieb: >> Man braucht auf lange Sicht die Vielfalt. Gilt überall, in der >> Gesellschaft, in der Technik, in Hard- und in Software. > > Gilt auch bei Meinungen. Solche Diskussionen sind gut und wir müssen uns > nicht krampfhaft auf einen gemeinsamen Stand einigen. ..unterschreib. Deswegen hatte ich aber angedeutet das "mein STM ist aber länger als Deiner" ziemlicher Unfug ist. Gruß, Homl
Holm T. schrieb: > Deswegen hatte ich aber angedeutet das "mein STM ist aber länger als > Deiner" ziemlicher Unfug ist. Herrrrrrrrrgottt, wie kann man das nicht wissen!!!
W.S. schrieb: > ..und drittens hast du rein GARNICHTS verstanden. Leider hat dein Erguss,keinen, aber auch gar keinen Bezug zu meinen Posting. Aber hauptsache du kannst andere beleidigen, dann ist der Tag gerettet. W.S. schrieb: > Das sieht > dann so aus, daß man aus höheren Programmschichten keinen Port mehr > sieht, wo man a la ST ne Funktion SetPort(Port,Bit,HiOderLo) hat, > sondern wo man eine Funktion a la SchalteLampe(EinOdeAus) hat. Idealerweise hat man beides, denn auch SchalteLampe() greift hoffentlich nicht direkt auf die Register zu, sondern auf SetPort(). Dann ist es nämlich egal, ob SchalteLampe() auf einem ST oder einem MSP oder einem AVR läuft. W.S. schrieb: > In letzterem Falle abstrahiert der Treiber nämlich wirklich die > zugrundeliegende Hardware, die in einem Fall ein Portpin sein kann, in > einem anderen Fall aber auch ein über WLAN zu erreichendes Gerät. Richtig. Nur möchte ich auf dem WLAN-Gerät doch bitte auch nicht direkt auf die Register schreiben, und damit kommt der Lowlevel HAL ins Spiel. W.S. schrieb: > Die > höheren Programmschichten wollen die Funktion, also Lampe ein oder aus - > aber es soll ihnen schnurz sein, ob das per Pin oder grünem Marsmännchen > erfolgt. Ebenfalls richtig, allerdings wuch hier nix, was meinem Posting widerspricht. W.S. schrieb: > Der ganze Schmonzes von ST hingegen abstrahiert rein GARNICHTS. Er bläht > bloß alles auf. Insofern sind alle derartigen "HAL"-Machwerke eben keine > Hardware-Abstraktionsschicht. Natürlich tun sie das, denn damit ist es der darüberliegenden Schicht egal, welcher ST das nun ist, und wie die Register nun heißen. Verwendet man öfter auch andere Controller, implementiert man diese Schnittstelle im idealfall natürlich selbst, denn dann hat man eine gemeinsame Schnittstelle, unabhängig davon, welcher Controller nun darunter läuft. Mit modernern Compilern und vernünftig geschriebenen Code kostet diese Abstraktionsschicht btw keinen einzigen Zyklus. Um dein Posting zusammenfassen, du steigst gleich mal mit einer derben Beleidigung ein, gibt mir dann in weiten Teilen recht, um dann in Unfug sondersgleichen zu gipfeln. Wunderbar.
vn nn schrieb: > Um dein Posting zusammenfassen, du steigst gleich mal mit einer derben > Beleidigung ein, gibt mir dann in weiten Teilen recht, um dann in Unfug > sondersgleichen zu gipfeln. Wunderbar. Das sind übrigens Fakten die mich auch stören. Das scheint allerdings im deutschen Sprachraum so üblich geworden zu sein und auch im allgemeinen Umgang ist das so. Anstatt sich auseinanderzudividieren sollte man sich gemeinsam darauf konzentrieren eine Lösung zu finden. Wir haben doch gute Ansätze gefunden! Ich bin dankbar für jedes Argument!
Andreas V. schrieb: > Das scheint allerdings im deutschen Sprachraum so üblich geworden zu > sein Nein, das ist einfach nur „W.S.“, wie wir ihn kennen, leider. (Was nicht heißen soll, dass er gar keine sachlichen Beiträge hervorbringen würde, aber eben leider viele in obiger Art.) Wofür sollte deine Verallgemeinerung gut sein?
Jörg W. schrieb: > Wofür sollte deine Verallgemeinerung gut sein? Das mag jetzt naiv sein (und vor Allem nicht Karriere fördernd): Bleiben wir sachlich und konzentrieren wir uns auf das Ziel!
vn nn schrieb: > Idealerweise hat man beides, denn auch SchalteLampe() greift hoffentlich > nicht direkt auf die Register zu, sondern auf SetPort(). Eben nicht. Es ist und soll auch für die höheren Schichten EGAL sein, was sich für eine Technik hinter dem Lowlevel-treiber SchalteLampe() verbirgt. Ob dazu überhaupt ein Portpin oder irgend etwas anderes vorhanden ist, um besagte Funktionalität zu gewährleisten, ist ein Internum des LL-Treibers und geht den Rest der Firmware nichts an. Das ist HAL. Aber wie du das siehst, scheint ja so zu sein, daß du unter HAL verstehst, daß man einen Portpin nur mittels einer von ST gelieferten Bibliothek setzen darf und nicht etwa direkt. Und was macht dein so geschriebenes Programm, wenn es mal auf einen LPC oder gar auf einen PIC32 portiert werden soll? Wie kriegst du da dein SetPort() hinein, zumal du davon ausgehen kannst, daß auf anderen Chips nicht einmal die Ports und deren Pins zu deiner von den STM32 geprägten Vorstellung davon passen? Nein, sowas wie SetPort() ist keine Abstraktion der Hardware, sondern nur ein Versuch, die die Hardware nicht so zu sehen, wie sie konkret ist. Und daß dabei wesentliche Qualitätsmerkmale der konkreten Hardware gnadenlos ignoriert werden, ist ein weiteres Thema. Das reicht vom BSRR bei den STM32 bis zu den bool GPPB[] bei den LPC11's und anderen Dingen, die den fachgerechten Umgang mit den GPIO's erleichtern. W.S.
SetPort() ist jetzt aber auch das schlechteste Extrembeispiel, dass man sich heraus picken kann. Bei I²C, UART und USB Kommunikation sieht es schon ganz anders aus.
Andreas V. schrieb: > Bei 100kbps und mehreren Sensoren und insgesamt 100 Datenbytes und 500% > Übertragungsoverhead und Toleranz und Sicherheit sind das ca. 50ms / > 1000ms. Allerdings verteilt in mehrere Abschnitte pro 1000ms zu > verschiedenen Zeiten. Schlafen legen lohnt sich dann nur bedingt. Du hast Dich zwar schon auf I2C festgelegt, aber vielleicht noch drei Denkansätze: 1. Ich weiß nicht, ob es funktioniert und ob es überhaupt meßbaren Einfluß auf die Stromaufnahme hat, wenn man die I2C-Pullups in den Ruhepausen wegschaltet. Außerdem kann man manche Sensoren in den Ruhepausen auch abschalten. Der Mikrocontroller ist ja nur für einen Teil der Stromaufnahme verantwortlich. 2. Man kann I2C auch mit normalen GPIO machen. Dazu braucht man nicht zwingend eine I2C-Hardware im Controller. Du könntest somit den Controllerkreis erweitern. Wobei mir jetzt auf die Schnelle kein aktueller Chip einfällt, der keine I2C-Unit hat. 3. Möglicherweise kannst Du auch Sensoren ohne I2C-Schnittstelle verwenden. Mit SPI (MHz statt kHz) kann man sich i.d.R. schneller wieder schlafen legen.
Stefanus F. schrieb: > Bei I²C, UART und USB Kommunikation sieht es schon ganz anders aus. Und wie stellst Du Dir das vor? Bei mir könnte das so aussehen: TransmitInit(0x48,0x3f); I2C7BitWrite(byteArray, anzahlDerBytes); I2C7BitRead(byteArray, anzahlDerBytes); Das habe ich bei puren embedded Programmierern noch nie gesehen. Da heisst es dann eher so: ti(0x48, 0x3f); w(ba, n); r(ba, n); wenn überhaupt...
:
Bearbeitet durch User
Andreas V. schrieb: > Stefanus F. schrieb: >> Bei I²C, UART und USB Kommunikation sieht es schon ganz anders aus. > > Und wie stellst Du Dir das vor? > > Bei mir könnte das so aussehen: > > TransmitInit(0x48,0x3f); > I2C7BitWrite(byteArray, anzahlDerBytes); > I2C7BitRead(byteArray, anzahlDerBytes); Ja genau so. Das wäre doch eine sinnvolle Abstraktion der Hardware. Soweit ich weiß ist das in der HAL und in Arduino so realisiert worden. Und so macht es für mich Sinn.
Tom schrieb: > 1. Ich weiß nicht, ob es funktioniert und ob es überhaupt meßbaren > Einfluß auf die Stromaufnahme hat, wenn man die I2C-Pullups in den > Ruhepausen wegschaltet. Hat keinen Einfluss: im Ruhezustand sind alle Ausgangsstufen stromlos, die Pullups ziehen dann die Leitungen auf high. Strom wird über die Pullups ja nur aufgenommen, wenn einer der Ausgangstransistoren aktiv wird, d.h. auf dem Bus auch "etwas passiert".
Ich persönlich hasse dises künstliche Hochjubeln der STM32. So toll sind die nun wieder auch nicht. Sie sind nicht einmal besonders häfig. Selbst der gute alte SAM7 (jupp, auch das ist ein ARM...) dürfte selbst nach all den Jahren noch häufiger sein, als die meisten STM32-Derivate. Was mich an STM32 pesönlich stört? - Die penetrant-arrogant-lästigen Fanboys auf µC.net - Die Peripheral Lib - Cube-MX - Die Datenblätter Es gibt bessere Cortexe als die STM32. Schon die SAM3 wären mir lieber. Oder die Kinetis-Serie. Oder die LPCx. Hurra. Für STM32-Fanboys gilt: Horizont = Brett vorm Kopf :-( Und dann immer: Der STM32F4 ist "so schnell". Schnell ist für mich kein einziger µC. Selbst ein mieselsüchtiger i.MX6 steckt hunderte STM32F4 gleichzeitig in die Tasche...
Stefanus F. schrieb: > SetPort() ist jetzt aber auch das schlechteste Extrembeispiel, dass man > sich heraus picken kann. > > Bei I²C, UART und USB Kommunikation sieht es schon ganz anders aus. Ja natürlich ist gerade sowas wie SetPort() das Extrembeispiel. Aber daran sieht man deshalb am ehesten das Prinzip. Ich poste hier mal ein Zitat:
1 | uint_fast8_t
|
2 | button_pressed (void) |
3 | {
|
4 | if (GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == BUTTON_PRESSED) |
5 | {
|
6 | return 1; |
7 | }
|
8 | return 0; |
9 | }
|
Zuerst wird ein GPIO_Read..dingens aufgerufen und dann, damit's auch schön schnell wird, das Ganze in ein uint_fast8_t gestopft. Geht's noch? Verrate mir doch mal, wie ich das Lesen solchen Quelltextes ohne innere Seelenverletzung überstehen kann. Ansonsten sehe ich für UART und USB (wenn nur VCP) Lowlevel-Treiber, die nach außen hin zwar eine hardwareunabhängige Schnittstelle haben, innerlich aber selbstverständlich direkt auf die Hardware des Chips zugreifen, eben weil sie komplett chipspezifisch sind. So ein LL-treiber ist ja gerade das Stück Software, was die Abstraktion von chipspeziell zu hardwareunabhängig zu erledigen hat. So ein Treiber ist die HAL und da gibt es keinen Platz für eine HAL-HAL. Guck dir z.B. mal die USB-VCP-Treiber an, die ich hier mal gepostet habe. Klar, die Oberfläche ist überall gleich, die Funktionalität aus Sicht der höheren Programmschichten auch, selbst das Erscheinungsbild am PC ist gleich - egal ob das nun ein NUC120 oder STM32 oder LPC17xx oder LPC4088 ist. Aber die innere Realisierung ist jeweils derart unterschiedlich, daß man so einen Treiber UNBEDINGT direkt für die jeweilige HW schreiben muß - wer versucht, sowas mit irgendwelchen zwischengeschalteten Libs zu tun, der erstickt in #ifdef's und scheitert trotzdem. Ich hab das alles durch. Der wirklich einzige Treiber, den ich mal weiterverwenden konnte, war der SD-Karten-treiber für den LPC2478, der nach Ändern der Gruppennamen von SDIO_xxx nach MCIO_xxx (oder umgekehrt, ist schon zu lange her) direkt ohne Änderung in den Anweisungen auch für die größeren STM32F103 benutzbar war. Aber das ist die seltene Ausnahme. Und jetzt bedenke mal, was es mit den ST.Lib, HAL, Cube und so weiter tatsächlich auf sich hat. Der Hersteller ST hat ein Ziel, die Kunden mit so etwas an sich zu binden. Er ist logischermaßen gar nicht daran interessiert, Lowlevel-Treiber zu liefern, die seine HW bedienen und nach oben hin eine tatsächlich hardwareunabhängige Schnittstelle liefern. Denn da könnten die Kunden ja recht leicht auch auf andere Hersteller ausweichen. Seine Software muß also auch nach oben immer noch hardwarebezogen sein - und zwar STM32Fxx-hardwarebezogen. Das letztere ist für ST von Wichtigkeit. Deswegen ist die HAL auch keine HAL. Und? Nun ST hat da wirklich ganze Arbeit geleistet, das muß man ihnen anerkennen. Selbst die Leute hier sagen nicht, "ich kommen vom AVR und möchte jetzt mit den Cortexen anfangen", sondern sie sagen "ich kommen vom AVR und möchte jetzt mit den STM32Fxxx anfangen". Es hat geklappt auf ganzer Linie. Verstehe mich recht: ich finde das aus Sicht von ST vollkommen konsequent und firmenpolitisch zu akzeptieren. Dennoch sehe ich hier einen grundsätzlichen Interessenkonflikt: Hersteller versus Anwender. Man kann sich entweder dreinschicken und an einen Hersteller anbinden lassen oder man kann das eben nicht tun und sich auf seinen eigenen Weg machen. Aber man sollte das WISSEN und nicht etwas für eine HAL halten, was in Wirklichkeit gar keine ist. W.S.
kein STM32 Fan schrieb im Beitrag #5633025: > Was mich an STM32 pesönlich stört? > - Die penetrant-arrogant-lästigen Fanboys auf µC.net Fanboys nerven immer, ob nun C++, Arduino, AVR oder eben STM32. > - Die Peripheral Lib > - Cube-MX Muss man nicht nehmen. Das, was andere Hersteller da liefern, ist kaum besser. > - Die Datenblätter Die sind in der Tat eher mittelprächtig. > Es gibt bessere Cortexe als die STM32. Schon die SAM3 wären mir lieber. SAM3/SAM4 haben eine ziemlich dinosaurierhaft anmutende Peripherie. SPI, bei dem man die Select-Leitungen auch noch über einen Adressdecoder schicken kann, braucht man sowas wirklich? Das macht die Sache leider auch nicht wirklich übersichtlich. Auch andere Inkompatibilitäten innerhalb der Familien nerven: vom SAM4S auf SAM4E wurde die zweite PLL weggelassen. Wenn man USB haben will, braucht man aber ein Vielfaches von 48 MHz, damit kann man die maximale CPU-Frequenz von 120 MHz nicht mehr erreichen (nur 96). SAMx70 ist als Nachfolger von SAM4 konzipiert, aber die Timer sind nun plötzlich wieder nur 16 bit breit (und das steht nicht mal in der migration note …) Alles so Kleinkram, aber lästig. SAMD & Co. sind von der Peripherie her hübsch, allerdings eben Cortex-M0+.
W.S. schrieb: > vn nn schrieb: >> Idealerweise hat man beides, denn auch SchalteLampe() greift hoffentlich >> nicht direkt auf die Register zu, sondern auf SetPort(). > > Eben nicht. Es ist und soll auch für die höheren Schichten EGAL sein, > was sich für eine Technik hinter dem Lowlevel-treiber SchalteLampe() > verbirgt. DOCH! vn nn hat das schon richtig erkannt! Du hast entweder IHN oder DEN SACHVERHALT nicht verstanden (oder willst ihn nicht verstehen)! Denn "vn nn" schrieb ja explizit von "BEIDES"... Bei einem sinnvollen Aufbau sieht es doch so aus: (zumindest wenn es kein explizites "write and forget" Programm sein soll. Du hast das Hautprogramm das die gewünschte Funktion bereitstellt und das vielleicht irgendwann mal auf einer anderen Plattform laufen soll. In diesem Programm gibt es dann vielleicht eine Funktion "SetzeBeleuchtungsSzene()" um alle angeschlossenen Lichtquellen in einen vordefinierten Zustand zu bringen. In dieser Funktion wird eine einzelne Lampe mit dem Befehl "SchalteLampe()" angesprochen. Dann hast du die HAL. Diese stellt generische Funktionen für das Hauptprogramm zur Verfügung, greift aber ihrerseits auf Plattformspezifische Funktionen zu. In der HAL ist dann die Funktion SchalteLampe() vorhanden. Innerhalb dieser Funktion wird dann mit Plattformspezifischen Befehlen gearbeitet. Die Funktionen der HAL greifen dann entweder auf Funktionen der Lib zu oder aber direkt auf einzelne Register. Meist ist die Verwendung der Lib vorzuziehen da dadurch zumindest beim WEchsel innerhalb der µC Familie keine oder nur minimalste Änderungen gemacht werden müssen. Beim Direktzugriff auf ein Register kann es aber schon beim Wechsel auf den nächstgrößeren µC der Serie nötig sein alles anzupassen! In diesem Beispiel sagen wir mal das die Funktion SchalteLampe() dann den Befehl SetBits() aus der LIB aufruft. Und in der LIB ist dann definiert das die Funktion SetBits() dann das jeweils bei diesem µC richtige Portregister verändert. Oder anders gesagt: Die Lib (des Herstellers) sorgt für eine Codekompatibilität innerhalb der Controllerfamilie. Die HAL stellt eine universelle API zur Verfügung, jedoch benötigt jede Plattform seine eigene HAL. Und wenn ich nun das Programm von STM32 auf einen PIC16 übertragen will, dann kann ich bei einer gut durchdachten Programmierung den eigentlichen Programmablauf (Hautpprogramm) absolut unverändert lassen. Ich tausche einfach die HAL-STM die bei "Schalte Lampe(Lampennummer)" den Befehl GPIO_SetBits(GPIOB,Lampennummer) aufruft gegen die HAL-PIC aus bei der beim Befehl "Schalte Lampe(Lampennummer)" dann LATB = Lampennummer; ausgeführt wird. Jede HAL bindet dann die für sich spezifische Lib automatisch ein. Wobei noch zu sagen ist, das die tatsächliche HAL (wie sie bei Embedded verstanden wird) in der Regel teil der SELBST ERSTELLTEN Dateien ist. Während die darunterliegenden LIbs dann entweder vom HAlbleiterhersteller oder anderen kommerziellen Anbietern kommen. Gruß Carsten Dann
Andreas V. schrieb: > Bei mir könnte das so aussehen: > > TransmitInit(0x48,0x3f); > I2C7BitWrite(byteArray, anzahlDerBytes); > I2C7BitRead(byteArray, anzahlDerBytes); > > Das habe ich bei puren embedded Programmierern noch nie gesehen. Dann sollstes du einfach mal die Augen aufmachen! Das sind doch die absoluten Basics. Und selbst wer nicht von scih aus sprechende Namen verwenden will, das macht nahezu jede HErstellerlib seit Jahren (Jahrzehnten) so... Nur etwas Kompakter darf es natürlich schon sein, da die Angabe 7Bit hier überflüssig ist. Denn die Unterscheidung 7 oder 10 Bit bezieht sich ja nur auf die Adressen... > > Da heisst es dann eher so: > > ti(0x48, 0x3f); > w(ba, n); > r(ba, n); > > wenn überhaupt... Dann solltest du mal deinen Umgang checken. Das würde überall wo die Anzahl der (sachkundigen) Personen die den Code irgendwann mal zu gesicht bekommen >1.0 ist dem Ersteller hoffentlich zu recht um die Ohren geschlagen werden. Im Proffessionellen Umfeld habe ich das bisher nur bei sehr alten ASM Code hier und da für Makros mal gesehen. Aber auch da nicht bei Sachen die in diesem Jahrtausend erstellt wurden. Aber um mal "alte" Beispiele zu bringen: (Mein Ausdruck ist von 2004, gab es wohl auch schon früher) Beim "alten" Microchip Compiler für die Pic18 waren unter anderem die folgenden Befehle vorgesehen: OpenI2C(SLAVE_7, SLEW_ON); // I2C Port wird als Slave Initialisiert, 7Bit Adressen, 400Khz unsigned char ReceivedByte = ReadI2C(); // Das aktuelle Byte wird aus dem I2C Empfangsregister gelesen und in der Variable ReceivedByte abgelegt. WriteI2C(0x55); // Gibt 01010101 auf der I2C Leitung aus... Aktuelle Funktionen bei Verwendung des XC8 (Pic12...PIC18) und dynamischer Erzeugung der Funktionen durch MCC sind beispielsweise: I2C_MasterWrite(*pdata,length,address,*pflag) //Schreibt einen Bytestream I2C_MasterRead(*pdata,length,address,*pflag) // liest einen Bytestream Gruß Carsten
Beitrag #5633363 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > SAMD & Co. sind von der Peripherie her hübsch, allerdings eben > Cortex-M0+. Ganz neu aber gerade im Energiesparen ganz groß sind die SAM L10 und L11 mit dem Nachfolgerkern Cortex-M23. kein STM32 Fan schrieb im Beitrag #5633025: > Es gibt bessere Cortexe als die STM32. Niemand hat hier je behauptet, dass es keine Alternativen gäbe. Im Gegenteil, siehe oben. > Schon die SAM3 wären mir lieber. Oder die Kinetis-Serie. Oder die LPCx. Das ist jetzt aber kein konkreter Vorschlag für einen stromsparenden Controller. Klingt eher nach einem Sammelsurium à la "hab ich mal von gehört".
Hallo zusammen, es hat ein bissl gedauert! Ich habe den MSP430G2553 getestet und der funzt wunderbar. Das mit dem Schlafen legen des µP verhält sich genau so wie ich es vermutet habe. Der Stromverbrauch geht nicht gegen 0. Das stellte ich fest indem ich den µP mit LPM0; ohne irgeneinen anderen Code schlafen legte. Versuchsaufbau: - Test mit EEPROM von Atmel, weil mein 16 Bit-DAC momentan keinen Mucks mehr macht. - Ich passte die Lib von Uli Kretzschmar auf den G2553 an, weil die Ports nicht passten. - Ich baute den MSP430G2553 standalone auf einen Breadboard auf. - Ich verband die SBW-Leitungen des Launchpad MSP-EXP430G2 mit dem Breadboard. - Umstellung Compiler auf SBW und MSP430G2553. - Pullups erhöhte ich bis auf 120K (Härtetest). - Zur Kontrolle schloss ich einen Logic Analyzer an - Zur Kontrolle schloss ich mein selbstgebautes I2C Breakout Board mit dem MCP2221 an. Ergebnis mit Pullups (120K): ============================= Stromverbrauch bei LPM0; ca. 80µA bei 3,3V Stromverbrauch im Betrieb: ca. 370µA bei 3,3V Die Daten wurden lesend und schreibend korrekt übertragen. Der Strom es EEPROMS ist in die Messung nicht mit einbezogen. Anbei die Lib und das TestProgramm. Gruß Andreas
:
Bearbeitet durch User
Nachtrag ========= Im Datenblatt steht: Active Mode: 230μA at 1 MHz, bei 2.2V Standby Mode: 0.5μA Off Mode (RAM Retention): 0.1μA .. was Idealwerte sind! Die Zeilen in main.c waren ein Copy-Paste-Fehler: array[1] = array[0] + 0; // Offset für EPROM-Adresse HB array[1] = array[1] + 0; // Offset für EPROM-Adresse LB Beim ersten mal Schreiben kann es zu einem Fehler kommen. Notfalls zwei mal schreiben...
Andreas V. schrieb: > Standby Mode: 0.5μA Damit meint TI wahrscheinlich LPM3, der Wert jedenfalls passt zur Tabelle im Datenblatt auf Seite 23. Für LPM0 werden 56 µA angegeben (typ), Deine gemessenen 80 µA sind also ein ziemlich guter Wert, insbesondere, wenn man bedenkt, daß Du bei 50% höherer Versorgungsspannung gemessen hast (3.3V statt 2.2V). Auch Deine 370µA im AM entsprechen dem Datenblatt, auf Seite 22 wird für 3.0V ein Wert von typ 330 max 420 µA angegeben. Auf welche Weise hast Du die Ströme gemessen?
Rufus Τ. F. schrieb: > Auf welche Weise hast Du die Ströme gemessen? Das mit der Spannung ist so eine Sache. Wer hat schon eine 2,2V Spannungsquelle (ausser wer auf Nickel-Cadmium-Akkus mit 2,4V steht oder Stepup/down-Converter steht ...)? Ich habe ein Feld-Wald-Wiesen-Multimeter dazwischengeschaltet; Messbereich 2000µA. Das Billigteil ist allerdings im unteren Amperebereich relativ genau und kann locker mit meinem Wavetek Multimeter mithalten. Es sind also alles Effektivwerte. Eine Messung mit Oszi steht noch aus...
Andreas V. schrieb: > Hallo zusammen, > > es hat ein bissl gedauert! > > Ich habe den MSP430G2553 getestet und der funzt wunderbar. > Das mit dem Schlafen legen des µP verhält sich genau so wie ich es > vermutet habe. Der Stromverbrauch geht nicht gegen 0. Das stellte ich > fest indem ich den µP mit LPM0; ohne irgeneinen anderen Code schlafen > legte. > > Versuchsaufbau: > - Test mit EEPROM von Atmel, weil mein 16 Bit-DAC momentan keinen Mucks > mehr macht. > - Ich passte die Lib von Uli Kretzschmar auf den G2553 an, weil die > Ports nicht passten. > - Ich baute den MSP430G2553 standalone auf einen Breadboard auf. > - Ich verband die SBW-Leitungen des Launchpad MSP-EXP430G2 mit dem > Breadboard. > - Umstellung Compiler auf SBW und MSP430G2553. > - Pullups erhöhte ich bis auf 120K (Härtetest). > - Zur Kontrolle schloss ich einen Logic Analyzer an > - Zur Kontrolle schloss ich mein selbstgebautes I2C Breakout Board mit > dem MCP2221 an. > > Ergebnis mit Pullups (120K): > ============================= > Stromverbrauch bei LPM0; ca. 80µA bei 3,3V > Stromverbrauch im Betrieb: ca. 370µA bei 3,3V > Die Daten wurden lesend und schreibend korrekt übertragen. > > Der Strom es EEPROMS ist in die Messung nicht mit einbezogen. > > Anbei die Lib und das TestProgramm. > > > Gruß > > > Andreas Du machst irgendwas falsch (Pegel an Anschlüssen mit Pullup?). Beim G2553 hatte ich in LPM1 deutlich weniger als 1µA worauf hin ich beschlossen hatte den Einschalter für die Mimik weg zu lassen. Speisung erfolgte aus einer R6 großen Lithium Primärzelle. Gruß, Holm
Carsten S. schrieb: > In der HAL ist dann die Funktion SchalteLampe() vorhanden. Innerhalb > dieser Funktion wird dann mit Plattformspezifischen Befehlen gearbeitet. > Die Funktionen der HAL greifen dann entweder auf Funktionen der Lib zu > oder aber direkt auf einzelne Register. Meist ist die Verwendung der Lib > vorzuziehen da dadurch zumindest beim WEchsel innerhalb der µC Familie > keine oder nur minimalste Änderungen gemacht werden müssen. > Beim Direktzugriff auf ein Register kann es aber schon beim Wechsel auf > den nächstgrößeren µC der Serie nötig sein alles anzupassen! So langsam werd ich böse. Also: SchalteLampe() ist die HAL. Da gibt es keine weitere HAL, denn SchalteLampe() erledigt das sowohl plattformspezifisch, also auch projektspezifisch. Warum du dort mit Gewalt die Effizienz per Bibliotheksaufruf zu Boden ringen willst oder eine eigentlich unnütze Abhängigkeit von anderen Dateien einführen willst, ist mir unbegreiflich. Lowlevel-Treiber SOLLEN höchste Effizienz haben. Also ihren Job direkt mit der HW machen. Dafür sind sie ja hardwarespeziell. Dafür sind sie ja die HAL. Die Rechenleistung braucht man in den Algorithmen oder im Userinterface weitaus dringender. Und wenn Änderungen anstehen, z.B. µC Wechsel oder Schaltungsänderungen, dann mußt du das ohnehin in deiner Software auch ändern. Da kommst du niemals drumherum. Fragt sich bloß, wo überall in deine Firmware. Wenn all die Änderungen dann nur in SchalteLampe() zu machen sind, dann ist das übersichtlicher, als wenn man in mehreren anderen Dateien herumeiern muß, auf die in deinem Falle SchalteLampe() eine Abhängigkeit aufweist. Nein, die gute Regel lautet: Man soll sich auf Abhängigkeiten von externen Dateien, Libs und IDE-speziellen Dingen möglichst sparsam einlassen. Und man soll Abhängigkeiten, die nicht unbedingt sein müssen, besser bleiben lassen. W.S.
W.S. schrieb: > So langsam werd ich böse. > SchalteLampe() ist die HAL. Wenn wir in Zusammenhang mit STM32 von einer HAL sprechen, dann meinen damit die Cube HAL, ein Produkt von ST. Du kannst gerne deinen eigenen Sprachgebrauch entwickeln, aber dann sind Konflikte zu erwarten. Du reagierst hier auf ein Problem aggressiv, dass du selbst erzeugt hast. Das dein Programmierstil ein völlig anderer ist, als der von ST vermarktete, haben wir alle verstanden, denke ich. Viele Wege führen nach Rom, verlange nicht, dass alle den gleichen gehen.
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.