Hallo zusammen, ich suche einen neuen Standard-Controller für kleinere bis mittelgroße Projekte. Bin ne Weile raus.. Früher war mein Standardcontroller der ATMega328P, aber bei dem kam ich insbesondere wegen des kleinen Speichers bei Projekten mit GUI immer wieder an Grenzen. Daher würde ich jetzt gern mal einen Plattformwechsel machen. Zudem sind die 8bitter irgendwie auch einfach nicht mehr zeitgemäß. Gearbeitet hab ich ansonsten noch mit PICs und XC161, aber 32bit wären wohl heute eher angebracht? Könnt ihr mir einen Nachfolger empfehlen? Anforderungen - Möglichst kostenlose Toolchain für C oder C++ (oder gibts was besseres inzwischen?) - Preislich idealerweise vergleichbar mit den Atmels (1-2€), zumindest nicht viel teurer - Gut beziehbar, wenns geht auch für Privat - Deutlich mehr Flash, idealerweise eine skalierbare kompatible Controllerfamilie - wenns geht von Hand noch handlebar bzw. so das man sich Teile auf ne Adapterplatine fürs Breadbord schnallen kann, idealerweise nicht mehr als 32pins - CAN Controller onboard wär fein (idealerweise schon CAN-FD?) - falls möglich bis 5V bzw. zumindest tolerant, ist aber keine harte Anforderung wenn das zu viele Nachteile birgt. - Die üblichen verdächtigen möglichst on-chip UART(möglichst x2), SPI, I2C, PWM, ADC Hmm, hab ich noch was vergessen? Was nutzt ihr so? Viele Grüße Alec
STM32F0: Alec T. schrieb: > Anforderungen > - Möglichst kostenlose Toolchain für C oder C++ (oder gibts was besseres > inzwischen?) Ja,direkt von ST: Atollic Studio. > - Preislich idealerweise vergleichbar mit den Atmels (1-2€), zumindest > nicht viel teurer Auch das dürfte hinhauen. > - Gut beziehbar, wenns geht auch für Privat Auf jeden Fall kriegste was bei Mouser und Mouser liefert an privat. Check. > - Deutlich mehr Flash, idealerweise eine skalierbare kompatible > Controllerfamilie Da braucht manwohlnichts zu sagen :). Deutlich mehr.. > - wenns geht von Hand noch handlebar bzw. so das man sich Teile auf ne > Adapterplatine fürs Breadbord schnallen kann, idealerweise nicht mehr > als 32pins Hier ein jein. Gibt kleine und halt typische TQFP32-100. > - CAN Controller onboard wär fein (idealerweise schon CAN-FD?) Gibt soweit ich weiß auch STM32F1 oder F0 mit CAN. > - falls möglich bis 5V bzw. zumindest tolerant, ist aber keine harte > Anforderung wenn das zu viele Nachteile birgt. Leider wohl alles 3.3V. > - Die üblichen verdächtigen möglichst on-chip UART(möglichst x2), SPI, > I2C, PWM, ADC Das ist natürlich selbst auf dem kleinsten STM32 drauf. An alle Klugscheisse: Nicht überprüft.
STM32. Die klassische Blue Pill mit dem F103 und dazu nen China-STLink. Sind etwas unter 5€ für den Einstieg mit nem Breadboard-Kompatiblen Board und ISP-Programmer
Alec T. schrieb: > Bin ne Weile raus.. Früher war mein Standardcontroller der ATMega328P, > aber bei dem kam ich insbesondere wegen des kleinen Speichers bei > Projekten mit GUI immer wieder an Grenzen. Daher würde ich jetzt gern > mal einen Plattformwechsel machen. Warum? ATmega1284P existiert. 16k RAM, 128kFlash. > Zudem sind die 8bitter irgendwie auch > einfach nicht mehr zeitgemäß. Bullshit. Nur Vollidioten behaupten sowas. Ein 8Bitter ist solange zeitgemäß, solange man die Anforderungen einer Applikation damit umsetzen kann. > - Möglichst kostenlose Toolchain für C oder C++ (oder gibts was besseres > inzwischen?) Check. Außerdem: du kennst sie schon. Ist exakt die Gleiche wie beim Mega328P... > - Gut beziehbar, wenns geht auch für Privat Check. > - Deutlich mehr Flash, idealerweise eine skalierbare kompatible > Controllerfamilie Check. > - wenns geht von Hand noch handlebar bzw. so das man sich Teile auf ne > Adapterplatine fürs Breadbord schnallen kann, idealerweise nicht mehr > als 32pins Check. > - falls möglich bis 5V bzw. zumindest tolerant, ist aber keine harte Check. > - Die üblichen verdächtigen möglichst on-chip UART(möglichst x2), SPI, > I2C, PWM, ADC Check. > Was nutzt ihr so? Rate mal!
c-hater schrieb: >> Zudem sind die 8bitter irgendwie auch >> einfach nicht mehr zeitgemäß. > > Bullshit. Nur Vollidioten behaupten sowas. Seh ich auch so. Hab mal eine Aufgabe mit einen XMega128A1 realisiert, die ein Kollege mit einem 32-bit PIG nicht auf die Reihe bekommen hat. Welche Entwicklungsumgebung hast Du genutzt? Ich halte es nicht für sinnvoll, sich ständig an neue Programme und Programmer, ICE usw. gewöhnen zu müssen. Mit Atmel Studio und dem Atmel ICE kannst Du die ganze Bandbreite vom 8-poligen 8-bitter bist zum CORTEX M4F bearbeiten. Werden wieder einige Bastler jammern "oh, Atmel ICE, teuer", während sich in ihren Schachteln die nicht funktionierenden Billig-Teile ansammeln... mfg Achim
> Könnt ihr mir einen Nachfolger empfehlen?
Such mal auf eBay nach STM32F103 - dann weißt du, was der Nachfolger des
328 ist ...
Angehängte Dateien:
-
en.stm32_cl1734.jpg
280 KB
STM32 hat alles möglich, von Low-Power bis Leistungsfähigeren Cortex-M4, einfach mal schauen: https://www.st.com/en/microcontrollers/stm32-32-bit-arm-cortex-mcus.html Wenns nicht umbedingt 32Bit sein muss gibts da auch noch die MSP430 von TI (16Bit). Abgesehen vom sehr! niedrigen Stromverbrauch gibt es auch welche im DIP-Gehäuse, welche für den Hobby-Nutzer einfacher zu nutzen sind (obschon SMD-Gehäuse auf Adapterplatinen dasselbe bringen): http://www.ti.com/microcontrollers/msp430-ultra-low-power-mcus/overview.html#
Ich empfehle STM32F103, den gibt es in unterschiedlichen Grössen. Hier kannst du einen ersten Eindruck davon bekommen: http://stefanfrings.de/stm32/index.html
Ich glaube nicht, dass das eine ideologische Diskussion werden sollte, wie sinnvoll oder sinnlos der Umstieg von Atmel AVR 8bit auf etwas anderes ist. Sehr weit oben als Vorschlag ist definitiv STM32. Auch der MSP430 hat sehr viel Schönes. Beide haben sehr gute Tools und eine sehr große Community. Es gibt dann noch so ein paar Underdogs, wie den Silabs Gecko, den NXP LPC, Freescale (was auch immer auf den Freedom-Boards ist),... Aber wenn man sich einen neuen Controller ans Bein bindet, dann idealerweise einen, zu dem man sehr viele Informationen und Beispiele im Internet angucken kann. Ansonsten: Für den allerersten Schritt: Schau dir mal den ATMega328*PB* an. Der hat 2 UARTs, 2 SPIs, 5 (?) Timer,... Ist insgesamt ein aufgemöbelter 328P
:
Bearbeitet durch User
Sebastian R. schrieb: > Auch der MSP430 hat sehr viel Schönes. Leider nur sehr beschränktes und vor allem nicht erweiterbares RAM.
Wenn du jetzt wegen einer guten GUI und RAM wechseln willst, macht eigentlich nur mehr ein Cortex M4 oder M7 Sinn. (Oder gleich ein Rasberry) Man sieht den Trend ja schon an den günstigen China Messequipment. Siglent verwendet etwa TI A8 Sitarra oder Blackfin, beide noch mal deutlich leistungsfähiger. Heute haben alle mindestens 4.3 Zoll Displays mit hoher Auflösung und Touch. Da ist ein M0 oder M3 schon überfordert. Und wenn man ehrlich ist, bleibt es ja nicht beim guten Display, sondern man braucht auch FAT, USB 2.0 und Ethernet - und damit ein kleines Betriebssystem. Preislich ist da auch kein grosser Unterschied. ST ist sicher gut, aber ziemlich teuer... irgendwie müssen sie die viele Werbung wieder reinbekommen...
Udo K. schrieb: > ST ist sicher gut, aber ziemlich teuer Zumindest der STM32F103C8T6 kostet nur 1€ einzeln und 1,50€ als Modul mit zwei Quarze, USB Buchse und Spannungsregler. Der ATmega328 ist teurer. Ich finde die Aussicht nach oben gut. Momentan ist der STM32F103 für mich ein würdiger Nachfolger zum ATmega328. Er hat von allem mehr. Bei der Anzahl der Pins und Speichergrösse habe ich sogar viele Wahlmöglichkeiten. Und falls der doch mal zu klein/langsam sein sollte, nehme ich einen STM32F407. Der spielt in der nächst höheren Liga und wird weitgehend gleich programmiert. Und es geht noch weiter nach oben ... (für mich wohl nicht)
Stefanus F. schrieb: > Zumindest der STM32F103C8T6 kostet nur 1€ einzeln und 1,50€ als Modul > mit zwei Quarze, USB Buchse und Spannungsregler. Der ATmega328 ist > teurer. Ich weiss ja nicht wo du den kaufst... aber bei Digikey zahlst du 4.7 Euro netto bei Abnahme von 10 Stück... Bei Mouser liegt der auch bei 4.5 Euro. Wenn ich bei Digikey nach Cortex M0 - M7 im 32-64 Pin Gehäuse suche, dann ist Microchip ganz vorne mit dem M0+ ATSAMD21J16A um 0.64 Euro netto. Der günstigste M3 ist ebenfalls von Microchip, und liegt bei 1.05 netto. Aber wie schon gesagt, wenn man sich jetzt die Mühe macht, umzusteigen... dann sollte man sich bewusst sein, wohin der Markt geht... und für irgendwelche Steueraufgaben reicht ein Atmega meist auch aus.
Udo K. schrieb: > Ich weiss ja nicht wo du den kaufst... Für meine Hobbybasteleien bin ich relativ schmerzfrei: https://de.aliexpress.com/item/50-st-cke-STM32F103C8T6-LQFP48-32F103C8T6-QFP48-QFP-ARM-neue-und-original-IC/32875492687.html Das scheint wohl das Lockangebot zum Anfixen zu sein. Ich kann nur jedem raten, sich nicht allzu sehr an die HAL Libraris zu binden, sonst kommt man von STM32 wirklich nicht mehr so leicht weg.
Fürs Hobby ist das ja auch ok. Ich möchte wissen, wo die ihre Chips herhaben bei dem Preis.... Vielleicht günstig gekauften Restposten?
Sebastian R. schrieb: > Ansonsten: Für den allerersten Schritt: Schau dir mal den ATMega328*PB* > an. Der hat 2 UARTs, 2 SPIs, 5 (?) Timer,... Ist insgesamt ein > aufgemöbelter 328P Viel besser wäre hier gleich der aktuellste Mega4808/09.
udok schrieb: > Ich möchte wissen, wo die ihre Chips her haben bei dem Preis.... Vielleicht sind es gebrauchte aus dem Recycling. Vielleicht haben sie ihren GD32F103 auch weiter entwickelt so dass er jetzt als (gefälschter) STM32F103 taugt.
Vielen Dank für eure Anregungen. Der ATmega1284P ist im Prinzip aber nicht viel anders als der 328P oder? Dann fällt der für mich glaub ich auch eher raus. Nicht nur wegen des fehlenden CAN, auch weil bei 128k dann schon wieder Schluss ist. Zudem habe ich beim XC161 ich das das priorisierte Interruptsystem sehr zu schätzen gewusst. Die Cortex scheinen ja was ähnliches zu bieten. Ich hätte wohl noch dazu sagen sollen das es mir wichtig ist in der Software ordentlich abstrahieren zu können. Insbesondere wenn man (auch und wenn dann kleine und einfache) Grafikdisplays ansteuern will. Klar kann man auch auf Codegröße optimiert programmieren, aber das kostet mich zu viel Zeit, die habe ich leider nicht mehr. Möchte mir (wieder) meine Bibliothek aus konfigurierbaren Standard-Modulen aufbauen um neue Projekte schnell umsetzen zu können. Die STM32 machen dabei auf den ersten Blick schon n sehr guten Eindruck :) Werde mir wohl mal den STM32F103(TB) genauer ansehen, gibts ja schon ab knapp 2,50 und mit Board 4-5€ Oder den STM32F103(C8) Beide CAN on board was man sonst noch an Peripherie braucht. p.s. irgendwas größeres auf Linux basierend oder so scheidet definitiv aus. Dazu gibts genug fertiges wie den Raspberry, das Rad brauche ich nicht neu erfinden.
Wobei die STM32F103 entweder CAN oder USB können - nicht beides gleichzeitig.
Ah, Danke für die Info. Schade, aber für mich i.O. denke ich. Vielleicht findet sich ja ne gute Implementierung mit automatischer oder manueller Umschaltung.
Stefanus F. schrieb: > Wobei die STM32F103 entweder CAN oder USB können - nicht beides > gleichzeitig. ja, der ist schon etwas älter und da geht das noch nicht. Die aktuelleren Serien können das auch gleichzeitig. Z.B. beim STM32F072 ist das kein Problem.
c-hater schrieb: > Bullshit. Nur Vollidioten behaupten sowas. Tut immer wieder gut, wenn ich sehe, dass nicht nur hier in meinem Lande Türkei das Niveau einer Meinungsaeusserung nicht adäquat mit der Bildung einhergeht.
Gerd E. schrieb: > STM32F072 Kann ich so definitiv auch empfehlen, gibt es als Board zum Beispiel auf dem Nucleo (~10€), oder ohne Board für etwa 3€. https://www.st.com/en/evaluation-tools/nucleo-f072rb.html Allgemein ist ein Wechsel zu grösseren STM32 einfach zu erlernen, wenn man sich mit einem mal auskennt (gilt generell für Cortex M)
:
Bearbeitet durch User
ATSAMC21 wenn es 5V sein soll mit CAN-FD. Bis 256k Flash, 32/48/64/100 Pins, Cortex M0+ 48MHz. Oder in 3,3V dafür bis 1MB Flash, bis 128 Pins, Cortex M4F 120MHz: ATSAME51. Edit: die gerne gehypten STM32 gibt es erst ab H7 mit CAN-FD, die kleinste von den Kacheln ist mir aber deutlich zu fett. Edit: die Suche bei ST ist nicht so der Hit, es gibt auch STM32L55 mit 1x CAN-FD.
:
Bearbeitet durch User
Rudolph R. schrieb: > Edit: die Suche bei ST ist nicht so der Hit Da hast du recht, da man eine Zusatzsoftware braucht: https://www.st.com/en/development-tools/st-mcu-finder.html
Alec T. schrieb: > Der ATmega1284P ist im Prinzip aber nicht viel anders als der 328P oder? Naja, er hat mehr Pins, mehr RAM, mehr Flash, mehr UARTs, mehr Timer, aber weiterhin Bauformen, die ohne Adapterstress (und -kosten) sofort für's Protoyping verwendet werden können und er ist weiterhin 5V-fähig. Er liefert also fast alles, was du wolltest. Es fehlen eigentlich nur CAN und USB. Naja und der Preis ist auch ganz schön happig. Wobei: wenn du die Stückzahlen verbaust, bei denen der Hardwarepreis eine Rolle zu spielen beginnt, dann bekommst du sicher auch einen akzeptablen Preis... > Dann fällt der für mich glaub ich auch eher raus. > Nicht nur wegen des > fehlenden CAN, auch weil bei 128k dann schon wieder Schluss ist. Die musst du erstmal voll bekommen. Und wenn's tatsächlich da klemmt (was ich kaum glauben kann) dann wäre immer noch Atmega2560/2561 möglich. Das sind dann schon 256kFlash. > Zudem > habe ich beim XC161 ich das das priorisierte Interruptsystem sehr zu > schätzen gewusst. Kann man auch beim AVR8 haben. Muss man halt nur selber bauen. > Ich hätte wohl noch dazu sagen sollen das es mir wichtig ist in der > Software ordentlich abstrahieren zu können. Ach so, ein Theoretiker. Naja dann... Für maximales Abstraktionslevel würde ich mindestens zu einem XEON-Octacore-Board mit mindestens 256GByte RAM und 64 Terabyte Massenspeicher raten. Damit dürften dann auch die Hardcore-Abstraktoren noch ein "Hello world" gebacken bekommen, welches noch in diesem Jahrhundert die Ausgabe zur Anzeige bringt. Gerade so... LOL
Beitrag #5711370 wurde von einem Moderator gelöscht.
c-hater schrieb: >> Zudem >> habe ich beim XC161 ich das das priorisierte Interruptsystem sehr zu >> schätzen gewusst. > > Kann man auch beim AVR8 haben. Muss man halt nur selber bauen. Es gibt Dinge, die kann man nicht sinnvoll in Software erledigen. Den NVIC eines ARM bekommst Du auf einem AVR nur als Simulation programmiert. Praktischen Nutzen bezüglich Ausführungsgeschwindigkeit hat das nicht. Viele Sachen passen in einen AVR. Aber wenn man einen "Nachfolger" sucht ist STM32 keine falsche Entscheidung. Auch ohne Schinaschnäppchen sind die µCs bezahl- und verfügbar - egal ob einem der F1xx reicht oder man gleich einen F4xx benutzt, weil RAM, Flash und "Speed" die Anwendung nicht mehr ausbremsen.
Bevor du wechselst und alles neu lernen musst, schau dir erstmal folgende 8 Bitter an. ATXMEGA384C3 -> 384 KB Flash, 32 KB SRAM ATXMEGA128A1U -> 128 KB Flash, 8 KB SRAM, EBI (um das SRAM auf 16 MB zu erweitern.) Beide haben: AES, DMA, Event System, USB, mehrere USARTs mit IrDA support, SPI, CRC16, CRC32, RTC, 12 Bit ADC, DAC (nur der A), 32 MHz Takt. Damit kommt man auch heute noch sehr weit.
Der xmega hat auch einen priorisierbaren Interruptcontroller, der jedem Interrupt eine eigene Priorität zuweisen kann. Non-Maskable Interrupts und Round-Robin Modus inklusive.
Der xmega E hat eine 120nA RTC, die du sehr frei konfigurieren kannst. Z.B. so, dass er nur einmal pro Stunde aufwacht und ansonsten halt nur 120nA zieht. Oder mehrmals pro ms, wenn man will. Ja, ich geb zu, ich bin ein echter xmega Fanboy. Die Teile sind einfach nur geil.
ich setze im Hobby mittlerweile nur noch auf stm32. Ich habe mir beim China-Mann 10 Stück Bluepill für ein paar Euro gekauft (damit komme ich ne weile aus). Die nutze ich für alles. Auch wenn es nur eine blinkende LED ist. Spielt keine Rolle. Da die Platinchen so günstig sind (etwa 2 euro oder weniger) lohnt es sich nichtmal die Platinen auf einen Sockel zu stecken und werden direkt auf Lochraster gelötet. Atmega ist für mich gestorben (habe ich früher gerne genutzt, aber sind definitiv nutzlos für mich geworden). Ich nutze EMBitz als IDE.
schnippo schrieb: > ich setze im Hobby mittlerweile nur noch auf stm32. Ich habe mir beim > China-Mann 10 Stück Bluepill für ein paar Euro gekauft (damit komme ich > ne weile aus). Die nutze ich für alles. Auch wenn es nur eine blinkende > LED ist. Spielt keine Rolle. Ich setze im Strassenverkehr mittlerweile auch nur noch auf meinen fetten SUV. Damit komme ich ne Weile aus. Den nutze ich für alles. Auch wenn es nur eine Fahrt zum Bäcker umme Ecke ist. Spielt keine Rolle.
schnippo schrieb: > ich setze im Hobby mittlerweile nur noch auf stm32. > Atmega ist für mich gestorben (habe ich früher > gerne genutzt, aber sind definitiv nutzlos für mich geworden). Dann kann das ja nur mit anspruchsvolleren Anwendungen zusammenhängen. Oder eher mit ressourcenfressender Programmierung? Rödel schrieb: > Ich setze im Strassenverkehr mittlerweile auch nur noch auf meinen > fetten SUV. Naja, der Vergleich mit dem fetten SUV hinkt ein wenig. Der STM32 ist gehäuslich nicht größer und genauso billig. Hat schon was für sich, einer für alles. Man muß eben nur sein Handwerk beherrschen. Der "nicht mehr zeitgemäße" 8Bitter stellt jedenfalls nicht so hohe Anforderungen. Dessen Markt wächst nach wie vor genauso. Warum wohl?
Rödel schrieb: > Ich setze im Strassenverkehr mittlerweile auch nur noch auf meinen > fetten SUV. Damit komme ich ne Weile aus. Den nutze ich für alles. Auch > wenn es nur eine Fahrt zum Bäcker umme Ecke ist. Spielt keine Rolle. Bei diesem Fahrzeug sollte man auch den Energieverbrauch bei der Produktion und bei der Nutzung berücksichtigen. Bei AVR versus diesem kleinen STM kommst du auf sehr ähnliche Verbrauchswerte. Der AVR ist nur im Stillstand ohne laufende Timer bedeutend sparsamer.
Alec T. schrieb: > Vielen Dank für eure Anregungen. > > Der ATmega1284P ist im Prinzip aber nicht viel anders als der 328P oder? kann man so sehen aber: c-hater schrieb: > Naja, er hat mehr Pins, mehr RAM, mehr Flash, mehr UARTs, mehr Timer, > aber weiterhin Bauformen, die ohne Adapterstress (und -kosten) sofort > für's Protoyping verwendet werden können und er ist weiterhin 5V-fähig. > Die 128k musst du erstmal voll bekommen. Und wenn's tatsächlich da klemmt > (was ich kaum glauben kann) sehe ich absolut so, die 32K vom 328p habe ich öfter voll bekommen, die 2K SRAM noch öfter, da wechselte ich zum 1284p 16KB SRAM! mit dem Vorteil das ich mit nur wenigen Änderungen den Quellcode übernehhmen kann. Die 5V sind auch ein Vorteil für die meisten Module! Als Arduino migthy mini 1284p genauso steckbrettfreundlich wie ein nano328p https://github.com/JChristensen/mini1284 https://raw.githubusercontent.com/JChristensen/mini1284/master/mighty%20mini%201284p.jpg > dann wäre immer noch Atmega2560/2561 > möglich. Das sind dann schon 256kFlash. aber mit 8K nur halb so viel SRAM! wenn schon Nachfolger auch fürs Steckbrett eher den ESP32 leider mit nötiger Pegelanpassung für 5V Module.
:
Bearbeitet durch User
Joachim B. schrieb: > wenn schon Nachfolger auch fürs Steckbrett eher den ESP32 leider mit > nötiger Pegelanpassung für 5V Module. Den ESP32 würde ich nicht als Nachfolger nennen. Erstens wegen seiner Stromaufnahme (falls die relevant ist) und zweitens weil dein eigenes Programm nur ein Teil der gesamten Software nebst Betriebssystem ist. Das macht seine Programmierung erheblich schwieriger, ganz besonders wenn es um Timings <1ms geht.
Stefanus F. schrieb: > Joachim B. > ESP32 > Das macht seine Programmierung erheblich schwieriger, ganz besonders > wenn es um Timings <1ms geht. Vor allem lässt sich der AVR mit seinem deterministischen Programmablauf noch punktgenau auf alles hintrimmen. Der Support durch ein Betriebssystem ist bei den kleinen Teilen immer eine zweischneidige Sache.
Rödel schrieb: > Ja, ich geb zu, ich bin ein echter xmega Fanboy. Die Teile sind einfach > nur geil. Kann ich nur zustimmen. Die Hardwareeinheiten rund um die CPU sind einfach genial. 8fach PWM extension (256MHz PWM), Wave generation - direkte Ansteuerung von Halbbrücken mit dead-time-generation, ADC mit sequencer (zusammen mit DMA 16 kanäle analog lesen ohne dass die CPU was machen muss), bis zu 24 PWM-Kanäle, bis zu 8 USARTs (man braucht die sicher nicht alle, aber das PCB-Routen kann wesentlich entspannter erfolgen), Event machine mit 3 QDECs (auslesen von rotary encodern ohne das die CPU was machen muß) und, und, und ... und wenn's dann doch nicht reicht, kann man quasi nahtlos zum AVR32 (wird leider von MicroChip geschasst) oder zum ARM übergehen, da die Struktur der xmega denen schon recht angepasst ist. Mit Atmel Studio + ASF und Atmel ICE kann man so einen ziemlich breiten Controller-Leistungsbereich programmieren und debuggen, ohne ständig mit Installation/Konfiguration von Software und Ausprobieren von Hardware-Tools Zeit zu verschwenden. mfg Achim
Stefanus F. schrieb: > Den ESP32 würde ich nicht als Nachfolger nennen. keiner zwingt dich ich konnte mein Arduino Programm vom 328p wordclock mit wenigen Änderungen übernehmen, dank wlan habe ich sofort Zugang zum NTP. Stefanus F. schrieb: > Erstens wegen seiner > Stromaufnahme (falls die relevant ist) in einer RGB wordclock zweitrangig und der ESP kann auch sleep. Stefanus F. schrieb: > und zweitens weil dein eigenes > Programm nur ein Teil der gesamten Software nebst Betriebssystem ist. in der Arduino IDE eben nebensächlich weil es klappt.
Ich muss unbedingt hier noch meinen Liebling, den 1,8-5V, 20 MHz Tiny1614 hier unterbringen. In dem winzigen aber immer noch gut lötbaren SO-14, 60 Cent Gehäuse sind doch tatsächlich u. a. neben 16K Flash und 2K SRAM je 1x UART/I2C/SPI samt zwei ADCs mit fünf wählbaren internen Referenzen, drei Comperatoren, RTC, Custom Logic und das bekannte Eventsystem enthalten- alles programmier/debugbar über die neue 1Pin UPDI Schnittstelle.
Ralf schrieb: > Ich muss unbedingt hier noch meinen Liebling, den 1,8-5V, 20 MHz > Tiny1614 hier unterbringen 16K flash, 2K SRAM was hast du an Grenzen vom 328p nicht verstanden? Alec T. schrieb: > Früher war mein Standardcontroller der ATMega328P, > aber bei dem kam ich insbesondere wegen des kleinen Speichers bei > Projekten mit GUI immer wieder an Grenzen
Joachim B. schrieb: > was hast du an Grenzen vom 328p nicht verstanden? Was hast Du an der Frage Alec T. schrieb: > Was nutzt ihr so? nicht verstanden?
"Was nutzt ihr so?" war doch ganz eindeutig im Kontext "grösser als ATmega328" gemeint. Wer keine grösseren Mikrocontroller verwendet, war nicht angesprochen.
Anton M. schrieb: > Was hast Du an der Frage > > Alec T. schrieb: >> Was nutzt ihr so? > > nicht verstanden? ach das alte Spiel, aus dem Zusammenhang reissen? Ich habe zumindest den Eingangsbeitrag verstanden!
Rödel schrieb: > Bevor du wechselst und alles neu lernen musst, schau dir erstmal > folgende 8 Bitter an. > > ATXMEGA384C3 > ATXMEGA128A1U Die XMegas gibt es nicht mit CAN und das wurde vom TO explizit gewünscht. Und es sind von Atmel/Microchip auch schon lange keine neuen XMegas mehr angekündigt/freigegeben worden, so daß es nicht den Anschein macht, als ob die in der XMega-Serie eine große Zukunft sehen. Ich denke die sehen die Zukunft im 8 Bit-Bereich eher bei kleineren Controllern. Sie sind deshalb bei den Tinys fleißig dabei neue herauszubringen und übernehmen für die dann teilweise Funktionen und Peripherie aus den XMegas. Das sind 2 Punkte die hier meiner Meinung nach gegen die XMegas sprechen.
:
Bearbeitet durch User
Stefanus F. schrieb: > Wer keine grösseren Mikrocontroller verwendet, war nicht angesprochen. Na gut. Dann möchte ich noch den XMega128A4U erwähnen. Die umfangreiche XMega-Ausstattung wurde ja hier schon feilgeboten, wobei ich die immerhin 5 UARTs hervorheben möchte. Die 44 Pins lassen sich vom Bastler immer noch gut auf die Platine bringen und machen damit auch individuelle Designs ohne Adapterplatinengehampel möglich. Nur mit CAN schauts eben schlecht aus. Wofür braucht das der TO denn? Gerd E. schrieb: > so daß es nicht den Anschein macht, als > ob die in der XMega-Serie eine große Zukunft sehen. Ich denke die sehen > die Zukunft im 8 Bit-Bereich eher bei kleineren Controllern. Sie sind > deshalb bei den Tinys fleißig dabei neue herauszubringen und übernehmen > für die dann teilweise Funktionen und Peripherie aus den XMegas. Würde ich zwar ähnlich sehen, aber was ist schon die "große Zukunft"? Ist nicht viel entscheidender daß man einen Controller hat der die geplanten Anwendungen bewältigt? Was XMega vs. neue Megas/Tinys betrifft beginnen die Grenzen langsam aber stetig zu verschwimmen. Die neuen, viel günstigeren Controller nähern sich den alten XMegas immer weiter an.
Gerd E. schrieb: > Und es sind von Atmel/Microchip auch schon lange keine neuen XMegas mehr > angekündigt/freigegeben worden, so daß es nicht den Anschein macht, als > ob die in der XMega-Serie eine große Zukunft sehen Das ist ein Trugschluß. Die neuen Mega0 und die neuen Tinies sind de facto XMegas, sie heißen nur nicht so. Sogar die neue Programmier- schnittstelle UPDI ist näher am PDI der XMegas als an ISP. Tatsächlich ist es genau anders herum. Die Familien der Megas und Tinies haben keine neuen Mitglieder bekommen.
Axel S. schrieb: > Gerd E. schrieb: >> Und es sind von Atmel/Microchip auch schon lange keine neuen XMegas mehr >> angekündigt/freigegeben worden, so daß es nicht den Anschein macht, als >> ob die in der XMega-Serie eine große Zukunft sehen > > Das ist ein Trugschluß. Die neuen Mega0 und die neuen Tinies sind de > facto XMegas, sie heißen nur nicht so. Sogar die neue Programmier- > schnittstelle UPDI ist näher am PDI der XMegas als an ISP. Ich sagte ja daß sie Funktionen und Peripherie von den XMegas übernommen haben. Aber dennoch heißen sie Attiny und das nicht ohne Grund: Flash max. 32KB, SRAM max. 2KB, Gehäuse max. 24 Pins,... - die sind also ganz klar als kleine Controller konzipiert wie es der Name auch andeutet. Dazu passt auch daß es Peripherie wie USB-Device oder CAN nicht gibt. Von daher sind sie mit den echten XMegas nicht zu vergleichen, die waren ursprünglich durchaus als "größere" Controller gedacht und die gab es daher auch mit mehr Flash, RAM etc. Aber ich denke Atmel hat eingesehen, daß sie in dem Marktbereich mit 8 Bit Controllern heute nicht mehr punkten können und daß da eher ARM Cortex M angesagt ist.
Um das noch mal zu erwähnen: ATSAMC21 Ich nutze im Moment den ATSAMC21E18-AU mit 256k FLASH, 32k SRAM, CAN-FD. Das Teil hat das gleiche Gehäuse wie der ATMega16M1, ist dafür aber nur so vollgestopft mit Peripherie, lässt sich weiterhin mit dem AS7 und dem Atmel-ICE benutzen (und auch mal richtig debuggen), kostet dabei weniger. Da der ATSAMC21 5V Versorgung verträgt, benötige ich auf meinem kleinen CAN-Knoten nur einen Spannungsregler. Und wenn sich mal durch die Peripherie um den Controller herum ergibt das der besser mit 3,3V laufen sollte, dann kann der das auch bei vollem Takt. Zusätzlich habe ich jetzt einen Upgrade Pfad, wenn die Pins nicht reichen gibt es die ATSAMC21 auch mit 48, 64 und 100 Pins. Ab 48 Pins auch mit 2x CAN-FD. Dazu mit unterschiedlich viel Speicher, falls man doch mal knausern muss. Nicht so richtig wichtig, aber auch nicht ganz uninteressant, es gibt eine Automotive Version vom ATSAMC21, so im Gegensatz zum STM32. Das einzige Manko bisher ist die Dokumentation dazu. Da ich das ASF nicht verwenden will ist mir das Datenblatt an einigen Stellen einfach nicht ausführlich genug. Wenn es sowas als AVR geben würde, dann würde ich den benutzen. Wenn sowas noch als Tiny/AVR getarnter XMEGA kommen sollte, egal, zu spät.
Von mir ein +1 für die STM32er. Mit SW4STM32 gibt's eine fix&fertig IDE für Lau, auch für Linux. Einstieg ist dank der Klicki-Bunti STM32CubeMX Umgebung auch leicht.
Hallo zusammen, danke für den vielen Input. Zunächst einmal sollte das in der Tat keine Glaubensdiskussion werden. Irgend welche SUV-Vergleiche sind da nun wirklich deplaziert bzw. unsinnig. Natürlich kann man klein programmieren und vieles auf nen Tiny quetschen wenn man Spaß daran hat oder n paar Millionen davon produzieren will. Ich such aber nunmal (für mich) die nächste one-fits-(fast)-all Variante. Für die XMegas gabs n bischen was an Pro/Con, ich gucke mir die erwähnten Typen noch mal an. Tendenz für mich nach lesen dieses Threads geht aber schon eher in Richtung STM32. Am Ende erinner ich mich auch das ich mir in der Vergangenheit hin und wieder was breiteres als 8bit gewünscht hätte. Die neueren STM32F0x2 sehen schon gut aus. Vielleicht kann mir noch jemand seine Einschätzung bzgl. der Unterschiede bzw. Vor/Nachteile zwischen der STM32F0x2 vs. F103 serie geben? USB & CAN parallel wurde genannt. Der F0x2 hat noch nen DAC onboard - nicht das ich den oft brauchen würde, dennoch schick :) Bzgl. Rechenpower schätze ich reicht mir Cortex M0... Danke euch und schönen Sonntag zusammen :)
:
Bearbeitet durch User
Alec T. schrieb: > Die neueren STM32F0x2 sehen schon gut aus. Vielleicht kann mir noch > jemand seine Einschätzung bzgl. der Unterschiede bzw. Vor/Nachteile > zwischen der STM32F0x2 vs. F103 serie geben? USB & CAN parallel wurde > genannt. Der F0x2 hat noch nen DAC onboard - nicht das ich den oft > brauchen würde, dennoch schick :) Bzgl. Rechenpower schätze ich reicht > mir Cortex M0... Die F0 haben aktuellere und mehr Peripherie als die F1er. Das fängt bei der schieren Anzahl an Timern an, geht mit dem USB/CAN weiter und hört bei dem I2C auf. Das I2C beim F1er ist sehr empfindlich und fehlerbehaftet, man kann es zwar ordentlich zum Laufen bekommen, es ist aber eher ein Spießrutenlauf. Viele nehmen daher gleich Software-I2C. Bei den F0ern ist das wesentlich entspannter, da funktioniert das Hardware-I2C ordentlich. Nachteil der F0er ist, daß sie weniger SRAM, geringere Taktfrequenz und nur einen M0-Core haben. Der M0-Core ist bei Debugging, Interruptprioritäten, Befehlssatz,... ganz klar einfacher gestrickt als der M3-Core des F1ers. Wenn man vom Atmega kommt, wird man das aber erst mal gar nicht vermissen. Schön ist, daß bei ST die Footprints zwischen den Serien weitgehend kompatibel sind. Wenn ich also vorher beim Schaltplandesign mal ins Datenblatt (bzw. eine Migration-Appnote) der größeren Serien schaue, kann ich meine Platine so designen, daß ich da hinterher einen F0, F1, F3 oder F4 drauflöten kann.
Hat schon einmal jemand evaluiert, ein CAN Interface in Software zu implementieren? Auf den ersten Blick erscheint mit das nicht viel komplizierter, als eine UART. Also durchaus überschaubar. Oder kommt man dann in Konflikt mit irgendwelchen Lizenzen?
Für CAN-Interface nimmt man am besten MCP251x.. gibt es als normal can und als can-fd variante für SPI. Libraries findet man dank der Arduino community auch genug dafür. Portierung auf STM32 sollte sehr einfach sein.
Stefanus F. schrieb: > Hat schon einmal jemand evaluiert, ein CAN Interface in Software zu > implementieren? Auf den ersten Blick erscheint mit das nicht viel > komplizierter, als eine UART. Also durchaus überschaubar. Ich fürchte beim 2. Blick wird Dir auffallen daß das doch nicht ganz so einfach ist: Du musst eine mögliche Kollision auf dem Bus erkennen und dann aufhören zu senden. Dafür brauchst Du ein recht präzises Timing und eine schnelle Reaktion. Auch um das ACK zu senden musst Du auf dem Bus mithören, direkt Prüfsumme etc. berechnen und dann entscheiden ob ACK oder nicht. Die Zeit, um auf einem µC zwischen dem CRC und dem ACK-Slot zu berechnen was Du senden musst, ist ziemlich knapp. Du musst dabei immer auch die Sinallaufzeit auf einem Bus mit maximaler Leitungslänge mit beachten, das macht die Sache komplizierter. Wenn der µC kein eigenes CAN hat, würde ich daher auch zum MCP2515 raten.
:
Bearbeitet durch User
Den "Standard-Controller" für kleine bis mittelgroße Projekte gibt es meiner Ansicht nach nicht. Letztlich ist das entscheidende ja immer, was man genau realisieren möchte. Ich habe auch schon überlegt mich in Zukunft auf eine Plattform zu beschränken und evtl. auf ARM umzusteigen, da vermeintlich moderner. Bei näherer Betrachtung, was mir momentan so an Ideen vorschwebt, würde ein aktueller ATmega4808/09 in der Mehrzahl vermutlich völlig ausreichen, 8-bit hin oder her. Wenn es also ein Standard-Controller sein soll, braucht man meines Erachtens nach trotzdem mindestens zwei davon, die nicht unbedingt die selbe Architektur aufweisen müssen: Einen für die einfachen Sachen, den anderen fürs Komplexe. In Sachen ARM würde ich mir zunächst auch mal die SAM C/D/E von Microchip näher ansehen, da die STM32 bei vergleichbarer Leistung nach einer Kurzrecherche vor ein paar Monaten doch teilweise deutlich teurer sind (zumindest bei DigiKey in Mengen zu zehn Stück). Keine Ahnung, warum die in diesem Forum hier dem Anschein nach verpönt sind und bei ARM jeder nur an STM32 denkt. Gibt es dafür technische Gründe? Ich habe bisher noch mit keinem von beiden gearbeitet. Interessant für die Zukunft dürfte auch RISC-V sein. Leider sind z.B. die FE310 von SiFive derzeit vergriffen, gerade als ich mit dem Gedanken gespielt habe die mal auszuprobieren und schon angefangen hatte mir ein kleines Entwicklungsboard dafür zu erstellen. Mit etwa 5 Dollar pro Stück zwar etwas teuer, vor allem da die Peripherie doch etwas dürftig ist, dafür aber im Gegensatz zu ARM eine offene, lizenzfreie Architektur.
:
Bearbeitet durch User
Gerd E. schrieb: > Ich fürchte beim 2. Blick wird Dir auffallen daß das doch nicht ganz so > einfach ist Danke für deine Erklärung.
Florian S. schrieb: > Keine Ahnung, warum die in diesem Forum hier dem Anschein > nach verpönt sind und bei > ARM jeder nur an STM32 denkt. Gibt es dafür technische Gründe? Verpönt sind sie (bei mir) nicht, ich habe aber ganz banale Gründe, warum ich mich für den STM32F103 entschieden habe: a) Bekommt man als Steckbrett/Lochraster kompatibles Modul b) Die Module sind sehr billig c) Ich kann diesen Chip als Endverbraucher problemlos in kleinen Stückzahlen kaufen. d) Das Evaluationsboard samt Programmieradapter/Debugger (Nucleo-64) ist billig und auch wieder für mich problemlos zu beschaffen. e) Die Entwicklungsumgebung ist kostenlos und basiert auf mir bereits vertrauten Tools (Eclipse, gcc, Make). f) Weil er mich zufrieden gestellt hat, habe ich andere gar nicht ausprobiert. ATtiny, ATmega und Xmega kenne ich alle, sind auch nicht schlecht. Xmega sind aber für mich letztendlich sehr viel teurer. Ich müsste mir dazu erst eine passenden Debugger kaufen und bräuchte jedes mal eine Adapterplatine weil ich die Chips sonst nicht auf meine Lochrasterkarten drauf bekomme. Das gleiche Problem habe ich auch mit fast allen 32bit Mikrocontrollern.
Alec T. schrieb: > Für die XMegas gabs n bischen was an Pro/Con, ich gucke mir die > erwähnten Typen noch mal an. Tendenz für mich nach lesen dieses Threads > geht aber schon eher in Richtung STM32. Am Ende erinner ich mich auch > das ich mir in der Vergangenheit hin und wieder was breiteres als 8bit > gewünscht hätte. Ich vermisse die 8 Bit Zeiten definitiv nicht. Ein wichtiger Vorteil der 32 Bit Arm M0-M7 ist die C compilerfreundliche Architektur: Genug 32 Bit Register, Parameterübergabe über Register, Effiziente Interruptroutinen (mit optional eigenem Stack). Bei Bedarf auch Mult/Div in Hardware und bei M4F auch Floating Point. > > Die neueren STM32F0x2 sehen schon gut aus. Vielleicht kann mir noch > jemand seine Einschätzung bzgl. der Unterschiede bzw. Vor/Nachteile > zwischen der STM32F0x2 vs. F103 serie geben? USB & CAN parallel wurde > genannt. Der F0x2 hat noch nen DAC onboard - nicht das ich den oft > brauchen würde, dennoch schick :) Bzgl. Rechenpower schätze ich reicht > mir Cortex M0... Mit was anderem als einem M4 oder M7 mit mindestens 256kB RAM würde ich heute nicht mehr anfangen... ansonsten kannst du ja gleich beim ATMega bleiben. Die Einarbeitungszeit ist praktisch genauso hoch, und für halbwegs moderne Gui's brauchst du Speicher... ein 480x320 Hintergrundbild in 8 Bit braucht 150kByte. Schau drauf, dass der uC ein LCD Interface integriert hat, dann ist die LCD Ansteuerung effizient über DMA. SPI ist bei kleinen LCD's eine gute Lösung. Es muss nicht immer ST sein... NXP ist auch gut, mit besser dokumentierter Peripherie, teilweise mit USB 2.0 High Speed Phy (gibts bei ST gar nicht), von Freescale gibt es auch eine 5 Volt kompatible Schiene. Beide deutlich günstiger über offizielle Distributoren erhältlich. Von TI gibt es einen M4F mit Ethernet Phy integriert, das ist sehr praktisch wenn man einen Webserver braucht. Die Microsemi Arm Peripherie dürte weitgehend zu der XMega Serie kompatibel sein. Von ST gibt es das STM32F746G-Disco Kit um ca. 60 Euro, da sieht man was möglich ist: https://www.youtube.com/watch?v=JPXR5su4PKs
Ich stand privat auch vor der entscheidung meines derzeitigen Projekts: STM32F0 oder AVR. Bin dann zum STM gegangen. Man erkauft sich das Performanceplus sowie die gute Debugmöglichkeit zum Preis von etwas aufwändigerer Hardware. Habe heute zwei Stunden damit verbracht den Controller mit HSI und PLL auf den richtigen Takt zu bekommen. Das wäre beim AVR schneller gegangen bzw. hat der keine PLL. Dafür war die Inbetriebnahme eines Sensors deutlich einfacher wegen dem debugger. Kein Vorteil ohne Nachteil
Ingo Less schrieb: > Habe heute zwei Stunden damit verbracht den Controller mit > HSI und PLL auf den richtigen Takt zu bekommen. > Das wäre beim AVR schneller gegangen bzw. hat der keine PLL. Dann halte dich vom Xmega fern, der ist in dieser Hinsicht nicht einfacher als STM32.
Die Arm Peripherie ist deutlich komplexer, aber dafür auch sehr leistungsfähig. Von dem Gedanken, jedes Bit auf dem Prozessor zu kennen, muss man sich ganz schnell verabschieden... Features die man nicht braucht, muss man einfach ignorieren, sonst kommt man an kein Ziel. Ähnlich wei bei moderner Bloatware (Qt, .Net) PC Programmierung, da darf man auch nicht anfangen in den Lib Sourcen reinzuschauen...
Ingo Less schrieb: > Das wäre beim AVR schneller gegangen > bzw. hat der keine PLL. Es gibt durchaus auch AVR8 mit PLL-Takt. Tiny25/45/85 z.B. Nur beschränkt sich der Sackstand zur Konfiguration des Taktsystems dort halt auf auf das korrekte Setzen der Fuses. Naja, wenn man ganz ehrlich ist, muss man natürlich auch noch die Konfiguration des Timer1 hinzurechnen, die auch etwas aufwendiger ist als im synchronen Modus.
Stefanus F. schrieb: > Ingo Less schrieb: > Habe heute zwei Stunden damit verbracht den Controller mit HSI und PLL > auf den richtigen Takt zu bekommen. > Das wäre beim AVR schneller gegangen bzw. hat der keine PLL. > > Dann halte dich vom Xmega fern, der ist in dieser Hinsicht nicht > einfacher als STM32. Ich habe deinen Code auf nem F0 versucht. Du solltest ein RCC_DeInit(); und ein „PLL-Deaktivieren“ vor deinem Code auf deiner HP zu Thema Takt setzen, sonst wirken sich die Änderungen erst nach einem Power-Off aus, jedenfalls beim STM32F0
ARM frisst den AVR locker weg. Nicht mehr lange und die AVRs sind weg vom Markt. Schaut euch das Forum an. Gar nicht lange her und es dominierte AVR. Cortex wurde als überzogen und kompliziert gesehen. Man wollte nicht wechseln und schön beim AVR bleiben. Und jetzt? Das Forum hat sich um 180° gedreht und ist ARM-lastig geworden. Die großen Verfechter des AVR sind umgezogen und propagieren jetzt ARM. Also nimm einen Cortex M. Dafür bekommst du hier Unterstützung und es gibt viele Chips für alle möglichen Fälle.
Generverter schrieb: > ARM frisst den AVR locker weg. Nicht mehr lange und die AVRs sind weg > vom Markt. Guter Witz. Das haben wir hier schon oft gehört. Du solltest Dich eher fragen warum dies gerade nicht passiert. Bei weitem nicht jedes System braucht ein GUI oder verarbeitet Mutimediales (was man eigentlich getrost Raspi & Co überlassen kann). Das wird auch für die Zukunft gelten. Ingo Less schrieb: > Habe heute zwei Stunden damit verbracht den Controller mit HSI und PLL > auf den richtigen Takt zu bekommen. Das wäre beim AVR schneller gegangen PLL haben übrigens die XMega auch. Hier liegt die "Herausforderung" nur darin, vor der Umschaltung jeweils die hergestellte Stabilität der Taktquelle abzuwarten. Für die neuen Tinys und Megas langt in Asm nach Fuse-Voreinstellung ein Vierzeiler.
:
Bearbeitet durch User
Rödel schrieb: > schnippo schrieb: >> ich setze im Hobby mittlerweile nur noch auf stm32. Ich habe mir beim >> China-Mann 10 Stück Bluepill für ein paar Euro gekauft (damit komme ich >> ne weile aus). Die nutze ich für alles. Auch wenn es nur eine blinkende >> LED ist. Spielt keine Rolle. > > Ich setze im Strassenverkehr mittlerweile auch nur noch auf meinen > fetten SUV. Damit komme ich ne Weile aus. Den nutze ich für alles. Auch > wenn es nur eine Fahrt zum Bäcker umme Ecke ist. Spielt keine Rolle. Wenn der SUV günstiger ist als der Trabbi? Die STM32-Module sind so billig, dass selbst ein Glas Bier teurer ist. Wozu sollte ich in irgendeiner Weise sparsam sein? Es ist völlig irrelevant ob der uC sich langweilt. Dem Chip ist es egal - er hat ja keine Gefühle. :-) Und da ich alles in c schreibe ist es auch egal ob ich für ein Lauflicht einen 32bitter nutze oder einen 8bitter. Das Programm ist gleich schnell fertig. Anton M. schrieb: > schnippo schrieb: >> ich setze im Hobby mittlerweile nur noch auf stm32. >> Atmega ist für mich gestorben (habe ich früher >> gerne genutzt, aber sind definitiv nutzlos für mich geworden). > > Dann kann das ja nur mit anspruchsvolleren Anwendungen zusammenhängen. > Oder eher mit ressourcenfressender Programmierung? Spielt auch keine Rolle. Ob das Lauflicht nun 100KB Code braucht oder 1KB. Ich bekomme für sparsamen Code keinen Orden und im Hobby ist es gehopst wie gesprungen.
schnippo schrieb: > Spielt auch keine Rolle. Ob das Lauflicht nun 100KB Code braucht oder > 1KB. Ich bekomme für sparsamen Code keinen Orden und im Hobby ist es > gehopst wie gesprungen. Ja, nach diesem Prinzip funktioniert es. Jedes Jahr muß leistungsfähigere Hardware her. Wo doch das Vorhandene locker ausreichen würde.
Ingo Less schrieb: > Ich habe deinen Code auf nem F0 versucht. Du solltest ein RCC_DeInit(); > und ein „PLL-Deaktivieren“ vor deinem Code auf deiner HP zu Thema Takt > setzen, sonst wirken sich die Änderungen erst nach einem Power-Off aus, > jedenfalls beim STM32F0 Mein Code (die ganze Seite) ist ausdrücklich für den STM32F103 und da tut er was er soll. Du solltest nicht einfach davon ausgehen, Code von einer Serie auf die andere ohne Änderung übernehmen zu können. Ich werde da auch keine Eierlegenden Wollmilchsäue veröffentlichen, denn dann kann man auch gleich die Cube HAL verwenden.
Anton M. schrieb: > schnippo schrieb: >> Spielt auch keine Rolle. Ob das Lauflicht nun 100KB Code braucht oder >> 1KB. Ich bekomme für sparsamen Code keinen Orden und im Hobby ist es >> gehopst wie gesprungen. > > Ja, nach diesem Prinzip funktioniert es. > Jedes Jahr muß leistungsfähigere Hardware her. > Wo doch das Vorhandene locker ausreichen würde. Die Hardware wird doch nicht wegen den Bedürfnissen der Bastler leistungsfähiger und günstiger. Ich greife doch nur das Vorhandene ab und gehe den bequemsten Weg. Ein Controller mit dem man im Hobby so ziemlich alles abdecken kann (vom Quadrokopter bis zum Blinklicht habe ich schon alles mit den STM32 gemacht) ist eben sehr praktisch. Es gibt Bereiche in denen ich dir aber 100% zustimmen würde. Ich kann der geplanten Obsoleszenz bei Unterhaltungselektronik z.B. nichts abgewinnen. Smartphones werden immer leistungsfähiger, aber laufen bereits nach kurzer Zeit nicht mehr flüssig (trotz 4 Kernen und gigantischer Leistungsfähigkeit).
Man gut das nichtm alle so denken wie du Anton, dann wären wir nämlich noch mit nem Feuer in ner Höhle, dass reicht ja auch, statt vorm Kamin in nem Häus‘chen
Anton M. schrieb: > Ja, nach diesem Prinzip funktioniert es. > Jedes Jahr muß leistungsfähigere Hardware her. > Wo doch das Vorhandene locker ausreichen würde. Du kannst ja deinen PC durch einen IBM XT ersetzen und das Smartphone ganz weglegen. Denn das ist ja alles sinnlos übertriebene Technik. Ich sage Dir wo der Sinn ist: Das Programmieren ist einfacher und dadurch billiger geworden. Mein Vater musste für seinen ersten Office PC ein Monatsgehalt hinlegen und für das Textverarbeitungs-Programm nochmal so viel. Heute kostet ein PC mit MS-Office nur ein viertel Monatsgehalt und das Office kann man auch kostenlos haben, wenn man will. DAS ist der Fortschritt, dem Du dich verweigerst.
schnippo schrieb: > Smartphones werden immer leistungsfähiger, aber laufen > bereits nach kurzer Zeit nicht mehr flüssig Da kann man doch nur drauf tippen daß die Software dermaßen ineffizient und komplex geworden ist und die Entwickler manchen Überblick verloren haben, oder? schnippo schrieb: > Ich greife doch nur das Vorhandene ab > und gehe den bequemsten Weg. Wer den gefunden hat kann sich immer glücklich schätzen. Oder nicht? Also ich finde eher den Weg zum Ziel inspirierend, ein tieferes Verständis zu erlangen, als nur mit dem 'Zusammenklicken' von fertigen Codes ein Ziel schnellstmöglich zu erreichen. Als Bastler meine ich. Ingo Less schrieb: > Man gut das nichtm alle so denken wie du Anton, dann wären wir > nämlich > noch mit nem Feuer in ner Höhle, dass reicht ja auch, statt vorm Kamin > in nem Häus‘chen Oh nein Ingo, so möchte ich das nicht verstanden wissen. Aber ist es nicht legitim zu fragen ob die Richtung immer stimmt? Ich möchte für's Lauflicht doch nicht irgendwann bei Smartphone- Komplexität landen.
:
Bearbeitet durch User
Anton M. schrieb: > Da kann man doch nur drauf tippen daß die Software dermaßen ineffizient > und komplex geworden ist und die Entwickler manchen Überblick verloren > haben, oder? Das trifft sicher oft zu. Wenn die Software allerdings mit den Mitteln der 80er Jahre entwickel wäre, könnte sie kein normaler Mensch bezahlen. > Ich möchte für's Lauflicht doch nicht irgendwann bei > Smartphone- Komplexität landen. Für Dich ist es offensichtlich Hobby, da ist das so Ok. Auch für mich bieten Mikrocontroller die Möglichkeit, mich mit kleinen Details zu beschäftigen, die in meinem Beruf unter der Haube von Betriebssystemen, Frameworks und Applikationsservern verborgen bleiben. Durch die Mikrocontroller habe ich einiges gelernt, was auch bei den grossen Maschinen hilft. Immer wenn irgendwo die Performance Kacke ist, ruft man nach mir. Dennoch akzeptiere ich, dass die Entwicklung weiter geht. Mehr Speicher, mehr Rechenleistung, komplexere Software und ja: auch komplexere Probleme. Das ist halt so, als Softwareentwickler kannst du daran nichts ändern. Entweder machst du mit so gut du kannst, oder du bist raus. Ich habe zuhause meine kleine heile Mikrocontroller Welt, während auf der Arbeit mit Gigabytes und zig CPU Cores nur so herum gesaut wird. Dafür haue ich mit meinem Team aber auch Sachen in wenigen Wochen betriebsfertig und gewinnbringend raus, für die ich mit meinen Hobby-Methoden viele Jahre brauchen würde.
Nachdem ich zum ersten Mal in Eclipse durch ein Programm auf einer BluePill durchgesteppt bin und Fragen zur Hardware durch direktes Setzen von Periepherie-Registern vom Debugger aus klären konnte, war die Zeit des Nano vorbei. Es galt eben gegen eine komfortable Entwicklungsumgebung mit "ICE" für rund 10€ anzukommen. Atmel hat das nie auch nur versucht. Und man dafür atomare 32Bit Operationen, Unmengen richtige Pointer-Register, Interruptroutinen, die Dank entsprechend designter HW die Aufrufkonvetionen von C/C++ einhalten, usw. bekommt, warum sollte man dann für mehr Geld mit weniger zufrieden geben. Vielleicht weil ein M3 keine AVR8-Befehle versteht und man seine Programme leider genau so formuliert hat.
Die Diskussion führt ja wahrscheinlich zu nix... aber ich kann auch auf dem Cortex uC ganz bequem sehr effizient und ohne Overhead programmieren. Ich brauche dabei nicht mal auf Assembler auszuweichen. Der Compiler ist in fast allen Fällen besser. Ich muss aber den Startup Code selber schreiben (vielleicht 100 Zeilen für die Interrupt Tabelle), und auf die mitgelieferten Bibliotheken verzichten. Aber das ist kein Problem und es macht richtig viel Spass :-)
Mein Allround Controller ist der STM32. Die F0xx für kleinere Aufgaben bis hin zu F7xx für die etwas anspruchsvolleren. (Embeded Linux usw. mache ich nicht) Die breite Palette von über 700 Variationen machen den µC zu einem idealen Partner. Wem die kleinen STM32F0xx reichen, der kann sogar kostenlos den Keil µVision nutzen und der CubeMX von ST erzeugt dafür einen fertigen Start-Up Code und initialisiert schon mal die ganze Peripherie (Incl. PLL/Clock usw.). Wenn man sich daran hält wo man Usercode einfügen darf, kann man sogar die CubeMx Konfiguration im Nachhinein nochmal ändern und neu erstellen, der Usercode Bereich wird dann automatisch übernommen. Danach nur noch die eigene Sachen rein programmieren und schon läuft das ganze. Vor über 10 Jahren hatte ich diese immer wieder empfohlen, wurde damals oft verspottet auch von Leuten die sogar heute den STM32 nicht mehr missen wollen und weiter empfehlen. Das gute am STM32 ist der ARM Kern, da andere Hersteller von µC ebenfalls ARM Kerne einsetzen kann man daher die ganzen Anschaffungen wie z.B. Debugger und Software garantiert weiter verwenden, auch wenn es ST mal nicht mehr geben sollte. Für Privat/Hobby empfehle ich den "Segger J-LINK EDU", kostet ca. 50-60€ und ist in jedem Fall sein Geld wert da Segger sehr gute Tools mit liefert.
:
Bearbeitet durch User
Stefanus F. schrieb: > Anton M. schrieb: >> Ja, nach diesem Prinzip funktioniert es. >> Jedes Jahr muß leistungsfähigere Hardware her. >> Wo doch das Vorhandene locker ausreichen würde. > > Du kannst ja deinen PC durch einen IBM XT ersetzen und das Smartphone > ganz weglegen. Denn das ist ja alles sinnlos übertriebene Technik. Der XT wurde bis 1987 gebaut, nicht bis 2018. Stefanus F. schrieb: > Ich sage Dir wo der Sinn ist: Das Programmieren ist einfacher und > dadurch billiger geworden. Und in weiten Bereichen unvorstellbar ineffizient geworden. Extrem-Vorschlag: Java-Programmierer sollten bespielsweise verpflichtet werden einen Assembler-Dialekt zu lernen, um zu verstehen was wirklich auf der Box vor sich geht.
Markus M. schrieb: > Für Privat/Hobby empfehle ich den > "Segger J-LINK EDU", kostet ca. 50-60€ und ist in jedem Fall sein Geld > wert da Segger sehr gute Tools mit liefert. Dieser Preis würde mich abschrecken. Die ST-Link kompatiblen USB Sticks aus Asien für 2€ erfüllen ihren Zweck ebenfalls. Ich empfehle allerdings die Nucleo-64 Board für erste Versuche, da bekommt man einen abtrennbaren ST-Link mit USB-UART mit geliefert.
Naja, wenn man nicht weiss, wie man gut programmiert, ist ein STM schon die richtige Wahl. Da wird auch die grösste Inkompetenz durch mehr Takt und Speicher erschlagen. Ich persönlich kenne auch wirklich nur sehr sehr wenige wirklich gute Programmierer und die bekommen ihre Probleme immer verdammt schnell in den Griff. Aber die meisten sind halt so typische Pseudoprogrammierer. Meistens Quereinsteiger, wenig Erfahrung, schlagen sich vor allem mit dem durchtrainiertem Mundwerk durch. Ich weiss nicht warum, aber die dümmsten Programmierer haben immer die grösste Fresse.
Wobei gut programmieren auch heissen kann: schnell fertig werden. Mit STM hat das aber gar nichts zu tun. Und dann nimmt man halt ein 100 MByte Framework, das halbwegs geeignet erscheint, und wo man schon was gemacht hat damit. Ob das dann schön, effizient oder Bug frei ist, ist erst mal nicht wichtig. Und Silizium ist unglaublich billig geworden. An die Tatsache muss ich mich auch immer noch gewöhnen. Eine 240 GByte SSD gibts schon um 30 Euro... Schaut euch doch heutige Software an: Da geht es schon deutlich in Richtung 100 MByte, auch wenn es nur ein einfaches Handy Spiel oder ein Vokabel Lernprogramm ist... Und Mikrocontroller Programmierung geht in dieselbe Richtung.
Der Reigen der penetranten STM32 Fanboys. Jeder MUSS den Standart (sic) verwenden, sonst wird er verbal niedergeknüppelt. Weil STM32 = ARM, und alles andere kennt man ja nicht ;-) Das bei einem µC Peripherie, Programmierumgebung und Codebasis relevanter sind als hirnloses STM32-Gejubel werden sie nie kapieren. Mein Rat wäre: Erst einmal ausprobieren, ob du eine IDE zum STM32 findest, die dir zusagt, und ob du mit den kruden Konzepten in der HAL und den Datenblättern der STs etwas anfangen kannst. Dazu kann man sich ja mal ein Discovery-Board gönnen. Die Hardware der STM32 ist ja durchaus brauchbar. Wenn man sein Hirn allerdings nicht in die verwundenen Bahnen der STM32 Sofwareumgebungen zwingen kann, macht die Programmierung keinen Spass. Und das wäre für ein Hobby schon relevant. Wie immer gilt sowieso: Der richtige Controller ist derjenige, mit dem man die Aufgabe am besten gelöst bekommt. Es gibt auch andere Controller, die in Teilen durchaus besser als STM32 sind, wie PIC32, LPCx (NXP), Cypress PSOCs, MSP430. Man sollte sich von penetranten Fanboys nicht in eine Ecke zwingen lassen.
ohje schrieb: > Jeder MUSS den Standart (sic) verwenden, Er sollte lieber diesen Standard verwenden (sic und gell)
Udo K. schrieb: > Und Mikrocontroller Programmierung geht in dieselbe Richtung. Das ist wohl leider wahr, aber auch ein Trend, den man persönlich nicht unterstützen und vorantreiben muss. Klar muss und sollte man heute nicht jedes Bit und Byte auf die Goldwaage legen und extremst sparsam haushalten, das ist weder technisch noch ökonomisch nötig und sinnvoll. Aber ein bisschen Mitdenken und vernünftige Entscheidungen ohne Overkill haben noch nie geschadet. Ein RasPi für nen LED-Blinker ist Irrsinn, ein 32 Bit Controller auch! Ich kann auch mit dem 40-Tonner zum Bäcker Brötchen holen fahren, ist auch Irrsinn.
konrad duden schrieb: > Er sollte lieber diesen Standard verwenden (sic und gell) also Renesas. Nachdem das der größte µC-Hersteller ist :-)
Falk B. schrieb: > Udo K. schrieb: >> Und Mikrocontroller Programmierung geht in dieselbe Richtung. > > Das ist wohl leider wahr, aber auch ein Trend, den man persönlich nicht > unterstützen und vorantreiben muss. Klar muss und sollte man heute nicht > jedes Bit und Byte auf die Goldwaage legen und extremst sparsam > haushalten, das ist weder technisch noch ökonomisch nötig und sinnvoll. Ja, insbesondere bei den Preisen selbst für 32-Bit-Mikrocontroller. Bei einer BluePill für €1,50 überlegt man nicht mehr, ob man überhaupt noch in der AVR-Liste gucken soll. > Aber ein bisschen Mitdenken und vernünftige Entscheidungen ohne Overkill > haben noch nie geschadet. Ein RasPi für nen LED-Blinker ist Irrsinn, ein > 32 Bit Controller auch! Ich kann auch mit dem 40-Tonner zum Bäcker > Brötchen holen fahren, ist auch Irrsinn. Nicht unbedingt. Wenn der 40-Tonner praktisch dasselbe kostet, er die LED blinken lässt und ich mich mit 40-Tonnern sehr gut auskenne, dann gibt es keinen Grund, mich noch mit PKW und ihren Eigenheiten zu befassen. Auch wenn 95% des 40-Tonners brach liegen. Nicht zu vergessen ist dabei immer auch die Featuritis: man startet ein (Hobby-)Projekt und viel später hätte man (bzw. der Kunde) rein softwaremäßig gerne noch dies oder jenes usw. - da ist bei den 32-Bittern einfach mehr Luft nach oben. Sprich: bei den 32-Bittern habe ich mittlerweile eine enorme Bandbreite von "wenig Leistung" für wenige Cent bis zum Schlachtschiff - da ist es oft Zeitverschwendung, neben der 32-Bit-Reihe und deren Eigenheiten noch mit einer 8-Bit-Reihe (und deren Problemen) zu kämpfen. Einzig wenn man extrem Leistung sparen muss oder 5V-Ausgänge gefordert sind haben die älteren AVRs noch eine Chance. Wobei es kaum noch neue Chips gibt, die 5V vertragen.
Chris D. schrieb: > Bei einer BluePill für €1,50 überlegt man nicht mehr, ob man überhaupt > noch in der AVR-Liste gucken soll. Das stimmt, geht aber am Gesamtproblem vorbei. Nicht nur die Profis, auch die Amateure und Laien gehen jeden Tag massenhaft hirnlos mit Speicher und IT-Ressourcen um. Das leidige Problem der Bildformate ist nur eines davon. Ich bin ja nun weiß Gott kein Kind der sparsamen (Nach)kriegsgeneration, aber das hirn- und sinnlose Verschleudern von Ressourcen, auch wenn die teilweise heute nur noch wenig kosten, geht mir auf den Keks. >> Aber ein bisschen Mitdenken und vernünftige Entscheidungen ohne Overkill >> haben noch nie geschadet. Ein RasPi für nen LED-Blinker ist Irrsinn, ein >> 32 Bit Controller auch! Ich kann auch mit dem 40-Tonner zum Bäcker >> Brötchen holen fahren, ist auch Irrsinn. > > Nicht unbedingt. > > Wenn der 40-Tonner praktisch dasselbe kostet, er die LED blinken lässt > und ich mich mit 40-Tonnern sehr gut auskenne, dann gibt es keinen > Grund, mich noch mit PKW und ihren Eigenheiten zu befassen. Auch wenn > 95% des 40-Tonners brach liegen. Nicht alles was hinkt, ist ein Vergleich. Ja, beim STM32 und seinen ultrabilligen Boards mag das so sein und das ist OK, auch wenn es historisch gesehen schon gewöhnungsbedürftig ist. Allgemein gilt das aber NICHT, denn aufgeblähte technische Lösungen, nicht nur bei uCs, "beglücken" uns immer mehr. Der Toaster mit WLAN ist da nur die Spitze des Eisbergs. KISS! Spätestens wenn dir ein Hersteller ein ultrafettes, träges Framework auf Auge drücken will, siehst du das mal ganz fix anders. Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig Rechenleistung die Amis zum Mond geflogen sind. Oder mit wie wenig Rechenleistung in den 80er und 90er Jahren gerade zu aberwitzige Effekte auf den Heimcomputers gezaubert wurden. Auch wenn der normale Entwickleralltag nicht die Zeit und Möglichkeiten zur Entwicklung eines Superalgorithmuses bietet, sollte man das nicht ganz aus den Augen verlieren. Und last but not least habe ich auch einen gewissen sportlichen wie auch fachlichen Anspruch an mich und meine Kreationen. Ein "Hello World" mit 10MB wäre MIR peinlich!
Falk B. schrieb: > Klar muss und sollte man heute nicht > jedes Bit und Byte auf die Goldwaage legen und extremst sparsam > haushalten, das ist weder technisch noch ökonomisch nötig und sinnvoll. Nein, muß man nicht. Beim 'sollte' wär ich mir nicht mehr ganz so sicher. Da geht doch, im vermeintlich schönsten ökonomischen Sonnenschein, das Dilemma schon los. Die Ökonomie, oder sagen wir besser Vernunft, findet dann letztlich Ihr Ende in der IT-Müll Entsorgung, weil das gute Handy oder der PC oder die eigene Hardware zu schwerfällig, nicht mehr erweiterbar, mangels Übersicht störanfällig geworden ist. Und wieder muß neue Hardware her. Zumindest mal für den Bastler gilt doch: Je besser man haushaltet desto mehr Hardware-Optionen hat man. Je besser man haushaltet umso länger kann man sein System nutzen. Je besser man haushaltet desto genauer kennt man in der Regel auch sein System. Und ich sage Dir: Je besser man haushaltet desto größer ist der Spaß am Entwickeln. Das ist -für mich- das Entscheidende! Schließlich kostet jeder Plattform-Wechsel auch viel Zeit. Ob das dann immer in sinnvoller Relation zu den geplanten Anwendungen steht? Auch die neuen Chips kochen eigentlich nur mit Wasser. Von allem gibts meist nur mehr und das sorgt immer auch für weniger Übersicht. Einen neuen Trend finde ich interessant. Die Peripherie immer weiter aufzubohren und etwas intelligenter zu machen. Stichwort Event-System. Damit werden seit einiger Zeit die AVRs aufgepeppt und schwups, ist Bittigkeit und Leistung des Kerns wieder ein Stück uninteressanter geworden.
:
Bearbeitet durch User
Chris D. schrieb: > Wobei es kaum noch neue > Chips gibt, die 5V vertragen. Neuere STM32 sind aber an fast allen Pins 5-Volt tolerant, aeltere an den meisten?
Chris D. schrieb: > Wenn der 40-Tonner praktisch dasselbe kostet, er die LED blinken lässt > und ich mich mit 40-Tonnern sehr gut auskenne, dann gibt es keinen > Grund, mich noch mit PKW und ihren Eigenheiten zu befassen. Auch wenn > 95% des 40-Tonners brach liegen. Die Vergleiche passen doch vorne und hinten nicht. Die 'dickeren' ARM-Prozessoren mögen viel mehr können, sind von den äußeren Abmessungen genau so klein und handlich wie 8-Bitter. Sobald man nur eine einzige Eigenschaft braucht, ist die Anwendung von z.B. STM32Fxxx schon gerechtfertigt. Beispiele sind RAM > 100 KB, viele oder schnelle Timer oder Timer mit 32 Bit, schnelle float/double Berechnungen oder einfach nur priorisierte Interrupts. Die "Beigaben" wie USB, Ethernet, TFT-Controller, Audio- oder Video-Kram kann man doch getrost beiseite lassen, wenn man sie nicht braucht. Auch wenn ich bei Anwendungen nur 5 - 10 % der Möglichkeiten eines z.B. F4xx nutze: ein AVR oder sonstiges 'Kleinzeug' könnte das Problem auch nicht ansatzweise lösen. Wenn der TO also schon AVR genutzt, die Möglichkeiten eines XC161 auch verstanden hat, wäre irgendetwas mit ARM-Kern schon die passende Weiterentwicklung. Udo K. schrieb: > Ich muss aber den Startup Code selber schreiben Du kannst es gerne machen, aber jeder Hersteller liefert zu seinen Controllern passende startup.s (o.ä.) und jeder IDE-Anbieter passende init-Routinen bis zum Sprung nach main().
Falk B. schrieb: > Nicht nur die Profis, auch die Amateure und Laien gehen jeden Tag > massenhaft hirnlos mit Speicher und IT-Ressourcen um. Das ist leider richtig. Aber was nützt es, wenn Du ihnen einen 32-Bitter vorenthältst? Dann schlagen sie im Forum auf und schreien "Hilfe, ich hab kein RAM mehr auf dem AVR!". Gibst Du ihnen jedoch einen STM32, werden sie sich wahrscheinlich gar nicht bis selten melden, weil sie sich schon irre anstrengen müssen, um den Speicher vollzumüllen. Okay, das war jetzt etwas ketzerisch formuliert. Schließlich nimmst Du ihnen mit der "Lösung" STM32 die Chance, zu lernen, mit dem AVR-Speicher hauszuhalten und auszukommen. Du sprichst aber oben von "hirnlos": wie steht's denn da mit Hopfen und Malz?
Chris D. schrieb: > Sprich: bei den 32-Bittern habe ich mittlerweile eine enorme Bandbreite > von "wenig Leistung" für wenige Cent bis zum Schlachtschiff - da ist es > oft Zeitverschwendung, neben der 32-Bit-Reihe und deren Eigenheiten noch > mit einer 8-Bit-Reihe (und deren Problemen) zu kämpfen. Die "Eigenheit" der 8Bitter ist zuallererst ihre Einfachheit. Das allein kann schon sehr viel Zeit sparen. Erst bei umfangreicheren, leistungshungrigen Anwendungen sind die 32 Bitter im Vorteil. > Einzig wenn man extrem Leistung sparen muss oder 5V-Ausgänge gefordert > sind haben die älteren AVRs noch eine Chance. Wobei es kaum noch neue > Chips gibt, die 5V vertragen. Naja, mit einem Versorgungsbereich von 1,8 bis 5,5V bieten sich schon ganz andere, sprich sehr viel mehr Schaltungs- Optionen. Nicht nur bei der Wahl von Interface-Chips oder Sensoren. Denk auch an Mosfet-Ansteuerung oder die Flexibilität bei Versorgung z.B. über eine Solarzelle. 5V sind ein riesengroßer Vorteil!
Falk B. schrieb: > Das stimmt, geht aber am Gesamtproblem vorbei. Nicht nur die Profis, > auch die Amateure und Laien gehen jeden Tag massenhaft hirnlos mit > Speicher und IT-Ressourcen um. Das leidige Problem der Bildformate > ist nur eines davon. Ich bin ja nun weiß Gott kein Kind der sparsamen > (Nach)kriegsgeneration, aber das hirn- und sinnlose Verschleudern von > Ressourcen, auch wenn die teilweise heute nur noch wenig kosten, geht > mir auf den Keks. Mir auch - aber letztendlich habe ich auf dem Board immer nur einen Chip, auf dem einmal AVR und einmal STM32 steht. Die paar mA, die ein STM32 mehr benötigt, spart er vermutlich in der Zeit wieder ein. Ich sehe da keine Verschwendung - im Gegenteil wäre so ein System deutlich zukunftsfähiger, eben weil ich in einem STM32 viel mehr Logik und Software reinpacken kann und das auch schnell auf den neuesten Stand gebracht worden ist. > Nicht alles was hinkt, ist ein Vergleich. Ja, beim STM32 und seinen > ultrabilligen Boards mag das so sein und das ist OK, auch wenn es > historisch gesehen schon gewöhnungsbedürftig ist. > > Allgemein gilt das aber NICHT, denn aufgeblähte technische Lösungen, > nicht nur bei uCs, "beglücken" uns immer mehr. Der Toaster mit WLAN ist > da nur die Spitze des Eisbergs. > > KISS! Das kann man ja trotzdem haben. Niemand zwingt einen dazu, die Hardware des STM32 komplett zu nutzen. Wie ich schon schrieb, nutzen wir immer nur bestimmte Hardwaregruppen. Manche habe ich überhaupt noch nie angefasst. Und dankenswerterweise kann man die nicht genutzten zumindest bei den STM32 (ich denke, andere sind da ähnlich) ja auch einfach stilllegen. Das würde ich übrigens auch jedem Umsteiger raten: sich nicht erschlagen lassen von dem, was das Ding alles mehr kann als bspw. ein AVR - sondern einfach erstmal mit einem Modul (meist GPIO) anfangen. Wie gesagt: einige Module kenne ich auch nicht - warum auch, wir benötigten sie bisher ja noch nicht. > Spätestens wenn dir ein Hersteller ein ultrafettes, träges Framework auf > Auge drücken will, siehst du das mal ganz fix anders. Ich kenne das Problem, aber: das musst Du ja nicht annehmen. Wir haben uns hier mit der Zeit unsere eigene HAL geschrieben, sehr schlank, schön mit direktem Registerzugriff, ganz ohne StdLib oder der ST-HAL. > Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig > Rechenleistung die Amis zum Mond geflogen sind. Oder mit wie wenig > Rechenleistung in den 80er und 90er Jahren gerade zu aberwitzige Effekte > auf den Heimcomputers gezaubert wurden. Auch wenn der normale > Entwickleralltag nicht die Zeit und Möglichkeiten zur Entwicklung eines > Superalgorithmuses bietet, sollte man das nicht ganz aus den Augen > verlieren. Das stimmt, aber das ist dann eher ein Softwareproblem als eins einer Controllerfamilie. Wenn man einen Blick in die Referenzhandbücher der STM32-Linie wirft, dann sieht man schnell, dass die Hardwaremodule dort kein Hexenwerk darstellen und man auch dort einen Pin recht einfach toggeln kann - ganz ohne Framework. > Und last but not least habe ich auch einen gewissen sportlichen wie auch > fachlichen Anspruch an mich und meine Kreationen. Ein "Hello World" mit > 10MB wäre MIR peinlich! Stimmt. Aber wie schon geschrieben: das muss man ja nicht mitmachen :-) Anton M. schrieb: > Schließlich kostet jeder Plattform-Wechsel auch viel Zeit. Ob das dann > immer in sinnvoller Relation zu den geplanten Anwendungen steht? Auch > die neuen Chips kochen eigentlich nur mit Wasser. Von allem gibts meist > nur mehr und das sorgt immer auch für weniger Übersicht Finde ich ehrlich gesagt nicht. Die einzelnen Hardware-Blöcke sind recht gut gegeneinander abgeschottet und die Sektionen durchaus handlich. Der Bereich GPIO (also alles, was mit dem direkten Setzen von I/O-Pins zu tun hat) umfasst beim STM32F0 bspw. fünfzehn Seiten. Das ist angesichts der gegenüber den AVR doch deutlich erweiterten Funktionalität (PU/PD, Flankenanstiegszeiten etc.) recht übersichtlich und schnell "erlesen".
Falk B. schrieb: > Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig > Rechenleistung die Amis zum Mond geflogen sind. Diese Systeme wurden aber von Experten bedient und kamen dementsprechend mit spartanischen Nutzeroberflächen aus. Für Otto-Normal-User braucht es komplexe GUIs mit Bildchen und Animationen, damit er das Produkt bedienen kann - und kauft! Das gleiche gilt auch für Entwickler - wenn man Smartphones nur in Fortran (sehr effizient) programmieren könnte, würde es viel weniger Apps geben, und daher weniger Verkaufsargumente. Ob eine App etwas schneller oder langsamer läuft kann man nicht in den Marketingprospekt schreiben. Ein hochauflösendes JPEG zu komprimieren braucht vermutlich mehr Rechenleistung als die Berechnung der Flugbahn zum Mond. Was hat das Leben von Otto-Normal-User mehr tangiert - die Mondlandung oder die Möglichkeit, hochqualitative Fotos im Handumdrehen an alle Freunde schicken zu können? Die Astronauten hätten sich bestimmt gefreut, wenn sie mit einer Digicam ohne Nachzudenken tausende Fotos von der Mondoberfläche hätten machen können. Auf der ISS sind normale Windows-PCs im Einsatz. Dazu kommt: Um die Leistung aktueller Computer überhaupt nutzen zu können, ist eine komplexe Software alternativlos. Das fängt beim Kernel an (bei Embedded Systems oft Linux), geht über komplexe Frameworks (OpenGL, OpenCL, dazugehörige Treiber) bis zu aufwendigen Compilern, ohne die man die raffinierte Prozessorarchitektur gar nicht ausreizen könnte. Was an dem "Rechenleistung-zum-Mond-Fliegen"-Spruch immer fehlt: Sie hatten nicht nur einen Computer, sondern auch eine Rakete.
Anton M. schrieb: > Chris D. schrieb: >> Sprich: bei den 32-Bittern habe ich mittlerweile eine enorme Bandbreite >> von "wenig Leistung" für wenige Cent bis zum Schlachtschiff - da ist es >> oft Zeitverschwendung, neben der 32-Bit-Reihe und deren Eigenheiten noch >> mit einer 8-Bit-Reihe (und deren Problemen) zu kämpfen. > > Die "Eigenheit" der 8Bitter ist zuallererst ihre Einfachheit. > Das allein kann schon sehr viel Zeit sparen. Die Zeit sparen sie mir aber beispielsweise schon nicht mehr, weil ich dann hier zwei Familien pflegen müsste. Und Du weisst ja selbst, wie das ist: man vergisst einfach sehr viel, wenn man Dinge lange nicht benötigt. Die Zeit, die ich benötigen würde, um mir wieder die Eigenarten, Fehler und Klippen der AVRs aufzurufen, steht da in keinem vernünftigen Verhältnis, zumal ich bei praktisch jeder Anwendung praktisch keine Nachteile, dafür aber sehr viel mehr Möglichkeiten hätte. > Erst bei umfangreicheren, leistungshungrigen Anwendungen sind die 32 > Bitter im Vorteil. Da sowieso, oftmals gehen viele Dinge mit den AVRs auch nicht mehr, bspw. direkte Displayansteuerung oder Quadraturencoder. >> Einzig wenn man extrem Leistung sparen muss oder 5V-Ausgänge gefordert >> sind haben die älteren AVRs noch eine Chance. Wobei es kaum noch neue >> Chips gibt, die 5V vertragen. > > Naja, mit einem Versorgungsbereich von 1,8 bis 5,5V bieten sich schon > ganz andere, sprich sehr viel mehr Schaltungs- Optionen. Nicht nur bei > der Wahl von Interface-Chips oder Sensoren. Wie gesagt: bei den neueren Entwicklungen gibt es praktisch keine mehr, die 5V unterstützen. > Denk auch an > Mosfet-Ansteuerung Auch da gibt es mittlerweile 3,3V-Typen wie Sand am Meer. > oder die Flexibilität bei Versorgung z.B. über eine > Solarzelle. Begrenzen kann man die Spannung immer recht einfach. > 5V sind ein riesengroßer Vorteil! Hier sind die Anwendungen, bei denen wirklich 5V-Ausgänge nötig waren, über die Jahre mehr und mehr geschrumpft. Und bei unseren Neuentwicklungen ist es sicherlich schon zwei Jahre her, dass ich das letzte Mal eine 5V-Treiberstufe für einen Ausgang spendieren musste. Es gibt natürlich noch so Dinge wie der direkte Betrieb über eine LiIo-Zelle, aber das sind dann wirklich Nischen. Was man im Hobbybereich noch gelten lassen kann sind die Gehäusetypen. DIL ist schön für das Steckbrett. Andererseits gibt es für wenige Cent Adapterplatinen, die man schnell bestückt hat und dann auch problemlos steckbar sind. Oder man greift eben direkt zu so Dingern wie den blauen Pillen.
m.n. schrieb: > Chris D. schrieb: >> Wenn der 40-Tonner praktisch dasselbe kostet, er die LED blinken lässt >> und ich mich mit 40-Tonnern sehr gut auskenne, dann gibt es keinen >> Grund, mich noch mit PKW und ihren Eigenheiten zu befassen. Auch wenn >> 95% des 40-Tonners brach liegen. > > Die Vergleiche passen doch vorne und hinten nicht. Die 'dickeren' > ARM-Prozessoren mögen viel mehr können, sind von den äußeren Abmessungen > genau so klein und handlich wie 8-Bitter. > > <viel Richtiges gelöscht > Du hast aber schon gesehen, dass ich genau Deiner Meinung bin? ;-) Die 40 Tonnen bezogen Falk und ich auf die Leistungsfähigkeit, nicht auf die Gehäusegrößen ;-)
Dr. Sommer schrieb: > Falk B. schrieb: >> Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig >> Rechenleistung die Amis zum Mond geflogen sind. > > Diese Systeme wurden aber von Experten bedient und kamen dementsprechend > mit spartanischen Nutzeroberflächen aus. > Was an dem "Rechenleistung-zum-Mond-Fliegen"-Spruch immer fehlt: Sie > hatten nicht nur einen Computer, sondern auch eine Rakete. Übrigens sah der Rechner für den Flug zum Mond größtenteils so aus: https://www.zdnet.com/pictures/ibm-and-univac-in-the-apollo-program/ Ich meine das waren mindestens fünf IBM360-Klötze, die in Echtzeit die Bahnkorrekturdaten berechneten. Nicht umsonst waren die Astronauten einen Großteil ihrer Zeit mit dem Eingeben und Übermitteln von Zahlenkolonnen beschäftigt. Der "dumme" Taschenrechner an Bord der CM/LM konnte nur sehr einfache Berechnungen durchführen und zeitkritische Operationen auslösen. Auch wenn es viele meinen: da war nix mit "mit kleinem Bordrechner zum Mond". Auch damals steckte da schon ordentlich Rechenpower dahinter.
Chris D. schrieb: > Wie gesagt: bei den neueren Entwicklungen gibt es praktisch keine mehr, > die 5V unterstützen. Die zahlreichen 5V Bauteile in der Welt, die dem Entwickler sonst mehr Auswahl geben würden, sollen wohl auch gleich auf den IT-Müllberg? >> oder die Flexibilität bei Versorgung z.B. über eine >> Solarzelle. > > Begrenzen kann man die Spannung immer recht einfach. Es gibt nichts effizienteres als einen Controller direkt an der Solarzelle betreiben zu können. > Die Zeit, die ich benötigen würde, um mir wieder die Eigenarten, Fehler > und Klippen der AVRs aufzurufen, steht da in keinem vernünftigen > Verhältnis Lustig. Mir würds wohl umgekehrt so mit den 32Bittern und ihren Entwicklungsumgebungen gehen. Bin ich da der Einzige? > Der > Bereich GPIO (also alles, was mit dem direkten Setzen von I/O-Pins zu > tun hat) umfasst beim STM32F0 bspw. fünfzehn Seiten. So läppert sich die 1000 Seiten Doku halt zusammen. Aber braucht das eine Vielzahl der Anwendungen überhaupt? Nein. Und deshalb reicht denen auch ein AVR.
Anton M. schrieb: >> Der >> Bereich GPIO (also alles, was mit dem direkten Setzen von I/O-Pins zu >> tun hat) umfasst beim STM32F0 bspw. fünfzehn Seiten. > > So läppert sich die 1000 Seiten Doku halt zusammen. > Aber braucht das eine Vielzahl der Anwendungen überhaupt? > Nein. Und deshalb reicht denen auch ein AVR. Der Bereich IO hat genau dafür gesorgt, dass ich mit den STM32 nie über das LED-Blinky hinausgekommen bin. Ich habe mir damals ein Discovery-Board gekauft, mir die Toolchain aufgesetzt und das mal umgesetzt. Ergebnis: Für mich ist das nichts. Beim STM32 mit CubeMX ist das Setzen eines Ports eine eher ...aufwändige Prozedur. Man muss eine Struktur deklarieren, und eine Funktion aufrufen:
1 | HAL_GPIO_WritePin(GPIO_PORT[Led], GPIO_PIN[Led], GPIO_PIN_RESET); |
2 | HAL_GPIO_WritePin(GPIO_PORT[Led], GPIO_PIN[Led], GPIO_PIN_SET); |
Ich persönlich (*1)) finde das grausig. Das wäre an Sich nicht schlimm, schließlich kann man das auch einfacher tun. Aber es geht halt in der Art weiter... Dass es auch bei komplizieten 32Bit-µCs anders geht, zeigen beispielsweise PIC32. Da sieht das so aus:
1 | LATBbits.LATB0 = 0; |
2 | LATBbits.LATB0 = 1; |
Natürlich kann man auch klassich mit UND und ODER in LATB herumfummeln, wie man es bei den ATMEGA tut. NATÜRILCH bringen 32-Bitter eine gewisse Komplexität mit sich. Aber bei ST hat man schon einen bestimmten "Stil", der muss nicht gefallen. *1) Meinungsäußerung, nicht Tatsachenbehauptung
Anton M. schrieb: > Chris D. schrieb: >> Wie gesagt: bei den neueren Entwicklungen gibt es praktisch keine mehr, >> die 5V unterstützen. > > Die zahlreichen 5V Bauteile in der Welt, die dem Entwickler sonst mehr > Auswahl geben würden, sollen wohl auch gleich auf den IT-Müllberg? Die Auswahl ist ja nicht geringer - nur werden eben neue IC-Designs nicht mehr bis 5V Spannungsfestigkeit ausgelegt. Das spart Die-Platz und somit Geld. Du bekommst sämtliche Funktionalität, die Du bei 5V hast, mittlerweile problemlos als 3,3V-Version. >>> oder die Flexibilität bei Versorgung z.B. über eine >>> Solarzelle. >> >> Begrenzen kann man die Spannung immer recht einfach. > > Es gibt nichts effizienteres als einen Controller direkt an der > Solarzelle betreiben zu können. Dann nimmst Du eben so viele Zellen, dass Du zwischen 2V und 3,6V landest. Auch das ist kein Problem. >> Die Zeit, die ich benötigen würde, um mir wieder die Eigenarten, Fehler >> und Klippen der AVRs aufzurufen, steht da in keinem vernünftigen >> Verhältnis > > Lustig. Mir würds wohl umgekehrt so mit den 32Bittern und ihren > Entwicklungsumgebungen gehen. Bin ich da der Einzige? Nein, und das ist ja auch ok. Wenn man sich mit etwas sehr gut auskennt und das die Anforderungen abdeckt, dann sollte man dabei bleiben. Hier stiegen und steigen die Anforderungen eben so weit, dass 8-Bitter einfach nicht mehr die Leistungsfähigkeit hatten/haben, das zu erfüllen. Um eben genau diese Zweigleisigkeit nicht mehr zu haben wurde der alte AVR-Zopf abgeschnitten zu Gunsten einer erheblich gestiegenen Auswahlmöglichkeit an Leistungsbandbreite. >> Der >> Bereich GPIO (also alles, was mit dem direkten Setzen von I/O-Pins zu >> tun hat) umfasst beim STM32F0 bspw. fünfzehn Seiten. > > So läppert sich die 1000 Seiten Doku halt zusammen. Jepp. Was natürlich auch daran liegt, dass die STM32 viele Module haben, die man bei AVRs vergeblich sucht. Und auch 1000 Seiten bestehen letzendlich nur aus einzelnen Kapiteln, die in sich abgeschlossen sind. 500 der 1000 Seiten habe ich sicherlich noch nie gelesen. Wenn man die entsprechende Hardware nicht benötigt, wäre das auch vergeudete Zeit. > Aber braucht das eine Vielzahl der Anwendungen überhaupt? > Nein. Und deshalb reicht denen auch ein AVR. Hier reicht es schon, wenn nur 20% unserer Anwendungen diese Leistungsfähigkeit benötigen. Mit den STM32 kann ich eben all das machen, was ich mit den AVRs machen konnte - und noch deutlich mehr. Ich muss die Leistungsfähigkeit der neuen 32-Bit-Kerne nicht immer nutzen - aber ich kann, wenn immer es nötig ist. Das gibt mir als Entwickler deutlich mehr Freiheiten.
ohje schrieb: > Man muss eine Struktur deklarieren, und eine Funktion > aufrufen: Muss man nicht. Das geht auch z.B. so:
1 | GPIOA->BSRR = (1 << 3); |
setzt Pin PA3. ohje schrieb: > Da sieht das so aus: Das riecht nach einer Union mit Bitfield und "volatile". Daraus macht der Compiler bestimmt 2 einzelne Zugriffe die jeweils wieder Read-Modify-Write sind - ineffizient! Solche structs kann man sich genau so auch für die STM32 bauen. Ist aber halt hässlich.
Dr. Sommer schrieb: > ohje schrieb: >> Man muss eine Struktur deklarieren, und eine Funktion >> aufrufen: > > Muss man nicht. Das geht auch z.B. so: >
1 | GPIOA->BSRR = (1 << 3); |
> setzt Pin PA3.
Das meine ich.
Man muss die StdLib und die ST-Hal nicht nutzen, sondern kann sich auch
direkt die Register anschauen - ohne diesen ganzen Definitionswust.
Gefühlt 95% der Register werden sowieso nur einmal bei der
Initialisierung beschrieben und dann nie wieder geändert. Selbst ganz
ohne HAL-Ambitionen kann man sich dafür sehr leicht eine "Init-Funktion"
basteln, in der man sich zu den einzelnen Registern Kommentare schreibt,
diese entsprechend der Hardwareblöcke gruppiert und dann die einzelnen
Blöcke anpasst und per Auskommentieren bei Bedarf ein/ausschaltet.
:
Bearbeitet durch Moderator
Anton M. schrieb: > Chris D. schrieb: >> Der >> Bereich GPIO (also alles, was mit dem direkten Setzen von I/O-Pins zu >> tun hat) umfasst beim STM32F0 bspw. fünfzehn Seiten. > > So läppert sich die 1000 Seiten Doku halt zusammen. > Aber braucht das eine Vielzahl der Anwendungen überhaupt? > Nein. Und deshalb reicht denen auch ein AVR. Der STM32 z.B. hat bei den GPIO: - zuschaltbare PullUp/Down Widerstände - Setz-/Clear Register um einzelne Bits zu ändern, ohne dass ein Read-Modify-Write nötig ist (-> Threadsicher / Interruptsicher) - Matrix um einige Peripherie-Funktion auf unterschiedliche GPIO Pins legen zu können (-> leichteres Routen der Platine) - Jeder Pin Interruptfähig. Das braucht nunmal ein paar Seiten mehr. Die Programmierung wird durch diese extra Features deutlich leichter wenn man Threadsicher / Interruptsicher die IO-Pins beschreiben möchte. Bei anderen µC muss man erst mal den Interrupt deaktivieren, damit das nicht unerwünschte Effekte bringt. Auch die zuschaltbaren PullUp/Down/OC-Funktionen vereinfachen das Layout, da man den ein oder anderen Widerstand sparen kann. Das fällt unter das Motto: Wenn man es nie hatte braucht man es nicht, jedoch wenn man es mal hatte will man es nicht mehr missen ;-)
Dr. Sommer schrieb: > Das riecht nach einer Union mit Bitfield und "volatile". Daraus macht > der Compiler bestimmt 2 einzelne Zugriffe die jeweils wieder > Read-Modify-Write sind - ineffizient! Nö. Unter "Key features" für den PIC32MX-Core steht im Referenzhandbuch: "Atomic bit manipulations on peripheral registers (Single cycle)" Ein solches wäre LATB. Wenn du selber lesen willst: http://hades.mech.northwestern.edu/images/2/21/61132B_PIC32ReferenceManual.pdf Jaja, da kommt sie wieder, die Fraktion, die PIC32 mit PIC verwechselt ;-)
Moin, ich würde nur zwei Denkanstösse geben wollen: 1.) Harvard vs. Neumann Architektur 2.) state maschine vs. event driven Alle Ansätze haben durchaus ihre Berechtigung, den Königsweg gibt es nicht, auch wenn die Jünger der jeweiligen Systeme so etwas immer wieder behaupten werden. Wieso wird denn der MSP430 empfohlen, ist der nicht abgekündigt (meine ich als Beitrag gelesen zu haben)?
Dr. Sommer schrieb: > Falk B. schrieb: >> Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig >> Rechenleistung die Amis zum Mond geflogen sind. > > Diese Systeme wurden aber von Experten bedient und kamen dementsprechend > mit spartanischen Nutzeroberflächen aus. Stimmt. > Für Otto-Normal-User braucht es > komplexe GUIs mit Bildchen und Animationen, damit er das Produkt > bedienen kann - und kauft! Jain. Natürlich steigen die Ansprüche der Käufer, auch wenn ein Großteil davon Unfug ist. Und viele Bedienkonzepte durch GUI aufgeblasen, kompliziert und nervig werden. Ein GUI hat viel Potential. Sowohl vom besser und einfacher machen, als auch zur totalen Katastrophe ;-) > Das gleiche gilt auch für Entwickler - wenn > man Smartphones nur in Fortran (sehr effizient) programmieren könnte, > würde es viel weniger Apps geben, und daher weniger Verkaufsargumente. > Ob eine App etwas schneller oder langsamer läuft kann man nicht in den > Marketingprospekt schreiben. Stimmt. > Ein hochauflösendes JPEG zu komprimieren braucht vermutlich mehr > Rechenleistung als die Berechnung der Flugbahn zum Mond. Was hat das > Leben von Otto-Normal-User mehr tangiert - die Mondlandung oder die > Möglichkeit, hochqualitative Fotos im Handumdrehen an alle Freunde > schicken zu können? Naja, da war das mit dem "one giant leap for mankind" wahrscheinlich nur für's Poesiealbum ;-) > Dazu kommt: Um die Leistung aktueller Computer überhaupt nutzen zu > können, ist eine komplexe Software alternativlos. Mit diesem Wort wäre ich vorsichtig. Klares JAIN! Natürlich kann man aktuelle Computer nicht sinnvoll mit einem ultraschlanken DOS befeuern, aber die Auswüchse diverser Frameworks sollte man dennoch benennen, auch wenn sie die wenigsten beheben können. > Das fängt beim Kernel > an (bei Embedded Systems oft Linux), geht über komplexe Frameworks > (OpenGL, OpenCL, dazugehörige Treiber) bis zu aufwendigen Compilern, > ohne die man die raffinierte Prozessorarchitektur gar nicht ausreizen > könnte. Stimmt. Aber es gibt leider auch das Problem, daß diese Frameworks teilweise oder komplett aufgebläht sind, nicht nur der Java-Kram. Und Performance anscheinend immer nebensächlicher wird. "Kauf dir halt nen neuen PC mit fetter SSD und RAM und 100 CPU-Kernen". Es ist da nur allzuoft ERBÄRMLICH, was da so abgeliefert wird.
Wegen dem Argument "verschwenderische Programmierung" ... bei kleinen µC mit wenigen KB RAM hat man kaum eine Chance noch extra Aufzeichnungen ein zu programmieren. z.B. ein Ablauf der Fehlerhaft ist, da kann man sich Merker Punkte erzeugen und das mal schnell in ein paar KB RAM sich einfach so nebenher aufzeichnen was da passiert. Wer hat, der kann, wer nicht hat, der sucht länger ...
Chris D. schrieb: > Um eben genau diese Zweigleisigkeit nicht mehr zu haben wurde der alte > AVR-Zopf abgeschnitten zu Gunsten einer erheblich gestiegenen > Auswahlmöglichkeit an Leistungsbandbreite. Was ja auch oft vollkommen richtig ist. Die STM32 sind wohl eher ein gutes Beispiel, wie eine große Controllerfamilie eine große Leistungsbandbreite abdecken kann. Vom kleinen M0 mit 48MHz bis zum 100MHz+++ Monster mit FPU und allem PiPaPo. Und ja, die 32Bitter knabbern auch die Marktnische der 16 und 8-Bitter an. Was vollkommen OK ist, möge der Bessere gewinnen. Ob sie die 8-Bitter mittel- und langfristig verdrängen werden, bleibt abzuwarten. Die Spielregeln haben sich geändert, der exorbitante Preisverfall und die gleichermaßen gestiegene Funktionsdichte machen es möglich und sinnvoll. Trotzdem darf und kann man die "alten" AVRs noch sinn- und liebevoll nutzen ;-)
Markus M. schrieb: > - zuschaltbare PullUp/Down Widerstände Haben andere auch, auch der AVR, wenn gleich nur Pull Up. > - Setz-/Clear Register um einzelne Bits zu ändern, ohne dass ein > Read-Modify-Write nötig ist (-> Threadsicher / Interruptsicher) Ist gut, aber historisch eher ein Workaround für den eher langsamen IO-Zugriff der ARMs mit ihrer Pipeline ;-) > - Matrix um einige Peripherie-Funktion auf unterschiedliche GPIO Pins > legen zu können (-> leichteres Routen der Platine) Nett, aber nicht kriegsentscheidend. > - Jeder Pin Interruptfähig. Haben die neueren AVRs auch. > Das braucht nunmal ein paar Seiten mehr. Die Programmierung wird durch > diese extra Features deutlich leichter wenn man Threadsicher / > Interruptsicher die IO-Pins beschreiben möchte. Bei anderen µC muss man > erst mal den Interrupt deaktivieren, damit das nicht unerwünschte > Effekte bringt. Das sind 2 läppische Befehle mit je einem Takt. Bei solchen Sachen muss man SO oder SO wissen was man tut, egal ob es der Prozessor "allein" kann oder nicht. Allein schon dann, wenn es portabel sein soll bzw. portiert wird. > Auch die zuschaltbaren PullUp/Down/OC-Funktionen vereinfachen das > Layout, da man den ein oder anderen Widerstand sparen kann. In Millionenstückzahlen spielt das eine Rolle, eher kaum.
Da gerade das Pro und Kontra von AVR und STM32 besprochen wird, haette ich eine Frage: irgend jemand hier, der z.Zt. beide benutzt? Mich interessiert naemlich die Frage, wie es mit der Geschwindigkeit von ATATMEL-ICE im Vergleich zu ST-Link bzw. J-Link von Segger steht. Ich würde gerne hin und wieder Atmegas einsetzen, aber irgendwo im Hinterkopf habe ich die Erinnerung, dass das Debuggen zumindest mit dem Dragon kein Spass war.
svensson schrieb: > Wieso wird denn der MSP430 empfohlen, ist der nicht abgekündigt (meine > ich als Beitrag gelesen zu haben)? Das habe ich noch nie gehört, mag aber sein. Wo hast du das gelesen, wenn ich fragen darf?
Bin auch ein Fanboy vom STM32 BluePill Board und möchte den grossen Speicher und die unglaublich flexibel einzusetzenden Peripheriemodule nicht mehr missen. Für mehr als Bastelprojekte oder Funktionsmuster würde ich die STM32F103 jedoch nicht einsetzen, weil die halt doch sehr alt sind (waren es nicht sogar eine der ersten, welche ST vor über 10 Jahren herausgebracht hatte?) und gerade die komplexeren Peripheriemodule wie USB wurden inzwischen massiv verbessert. Jedenfalls finde ich es nett von ST, dass sie diese Chips auch nach über 10 Jahren noch in Massenproduktion herstellen.
ohje schrieb: > "Atomic bit manipulations on peripheral registers (Single cycle)" > Ein solches wäre LATB. Ja Moment, aber weiß der Compiler das auch? Falk B. schrieb: > Und viele Bedienkonzepte durch GUI aufgeblasen, Viele User können erstaunlich schlecht mit Computern umgehen. Als Informatiker/Ing macht man sich das nicht klar. Höchstbezahlte UX-Experten stecken sehr viel Arbeit da rein, dass die Apps auch von denen gut bedienbar sind. Die GUIs sind daher entsprechend simpel aussehend, aber intern komplex. Man lässt lieber ein paar erfahrene User über komische Konzepte schimpfen als viele DAU-Kunden zu verlieren. Mehmet K. schrieb: > Mich interessiert naemlich die Frage, wie es mit der Geschwindigkeit von > ATATMEL-ICE im Vergleich zu ST-Link bzw. J-Link von Segger steht. Der J-Link ist beim Single-Steppen so schnell dass man keine Verzögerung bemerkt; praktisch wie lokal. Die Geschwindigkeit des Flash-Vorgangs kannst du auf der Segger-Seite nachlesen. Der ST-Link oder der TI XDS sind deutlich langsamer. Atmel weiß ich nicht.
Silvano C. schrieb: > svensson schrieb: >> Wieso wird denn der MSP430 empfohlen, ist der nicht abgekündigt (meine >> ich als Beitrag gelesen zu haben)? > > Das habe ich noch nie gehört, mag aber sein. Wo hast du das gelesen, > wenn ich fragen darf? Früher hatte ich oft MSP430 verwendet und diese auch weiterempfohlen. Mit ihnen war es im Vergleich zu Konkurrenzprodukten viel einfacher, ein stromsparendes, batteriebetriebenes Gerät zu entwickeln, welches im Standby nur uA schluckte. In der Zwischenzeit habe aber alle Konkurrenten nachgezogen und von TI kam kaum noch was Neues und das wird sich wohl auch nicht mehr ändern.
Mehmet K. schrieb: > Da gerade das Pro und Kontra von AVR und STM32 besprochen wird, haette > ich eine Frage: irgend jemand hier, der z.Zt. beide benutzt? Ja ich. Ich habe bisher folgende Mikrocontroller genutzt (die häufigsten zuerst): ATmega328 ATtiny13 ATmega644 STM32F103C8T6 ATtiny2313 Xmega128D3 AT89C2051 Und noch ein paar einzelne andere, die hier nicht der Rede Wert sind. Der STM32F103, den ich auch empfehle) ist für mich nur einer von vielen, die ich gerne benutze. Den AT89C2051 nutze ich schon lange nicht mehr. Ich hatte ihn bis zum Wechsel auf AVR allerdings sehr gerne benutzt.
Bei den 32 Bit ARM gefällt mir auch der lineare Adressraum. Lesen aus dem Flash? Geht genau so wie lesen aus dem RAM oder von jeder anderen Adresse. DAS ist einfach besser als die PROGMEM bzw. _FLASH Kacke bei AVR.
:
Bearbeitet durch User
Mehmet K. schrieb: > Ich würde gerne hin und wieder Atmegas einsetzen, aber irgendwo im > Hinterkopf habe ich die Erinnerung, dass das Debuggen zumindest mit dem > Dragon kein Spass war. So habe ich das auch in Erinnerung - zumindest mit Debug Wire. Der Atmel ICE soll angeblich schneller sein. Kann das jemand bestätigen? Bei AVR beschränke ich mich inzwischen auf Debug Meldungen auf ein serielles Terminal. ST-Link (sowohl von ST als auch die chinesischen Klone) arbeiten zusammen mit der Eclipse IDE viel schneller, als ich Debug-Wire mit dem Dragon erlebt hatte. Mit dem ST-Link habe ich richtig Spaß. Schön zu hören, dass man für zusätzliches Geld mit dem J-Link noch schneller arbeiten kann.
Tut doch nicht so, wie wenn ein Cortex M4F sooo viel Rechenleistung hätte! Der ist bei vielen praktischen Anwendungen schnell am Ende. Denkt da mal an Signalverarbeitung, ein einfacher FIR Filter im Audio Bereich kann da schon mal locker 50% der Recheneistung brauchen. Oder ein Webserver, der aus einer halbwegs modernen Anwendung heute schwer wegzudenken ist. Da gehen locker >50 kByte RAM und >500 kByte Flash drauf. Und da ist noch nicht der Ethernet Stack dabei. Ein modernes TFT GUI vielleicht? Noch mal 250 kByte RAM für Icons, Bilder und Fonts. Schnittstellen ohne Verschlüsselung? Ganz grossen Bähhh bei heise.de, und schon wieder sind 20% der Rechenleistung pfutsch. Jede Anwenung hat heute interne LOG Daten, die alles mögliche mitspeichern... wieder 100 kByte Flash weg. Klar, wenn ich nur alle Millisekunden mal mit ein paar Pins wackeln muss, und langsame veraltete Schnittstellen verwende, tut es ein AVR auch. Sind 32 Bitter Verschwendung? Natürlich nicht. Die Chip Fläche ist kleiner als die von 8 Bittern, die in Uraltprozessen gefertigt werden. Ausgenommen vielleicht die mit viel RAM 8 Bit ist praktisch tot! Sicher gibt es 8 Bit auch in 20 Jahren noch zu kaufen (auch heute gibts noch 6502 in NMOS), aber entwickelt wird dafür nur mehr fürs Hobby und für ein paar Nischen. Aber wenn 8 Bit den Zweck erfüllen ist es auch total Ok, die zu verwenden, vorallem wenn man sich damit auskennt. Das ganze ist ja keine Ideologie, sondern Mittel zum Zweck.
Udo K. schrieb: > Tut doch nicht so, wie wenn ein Cortex M4F sooo viel > Rechenleistung > hätte! Und ich dachte die FPU und DSP-Erweiterungen wären für genau sowas wie Audio gemacht... Wenn der M4F dann doch nicht reicht, nimmt man z.B. einen Cortex-M7. Oder doch einen Cortex-A. Man muss nichtmal einen neuen Compiler installieren und kann sogar vorhandene Algorithmen ohne Neukompilieren übernehmen.
Man kann die STM32F103 ja auch mit 8 MHz takten (dann entfällt die angeblich komplexe Konfiguration). In der Tat mache ich das ziemlich oft so.
Stefanus F. schrieb: > Man kann die STM32F103 ja auch mit 8 MHz takten (dann entfällt die > angeblich komplexe Konfiguration). In der Tat mache ich das ziemlich oft > so. Verstehe auch nicht was daran so komplex sein soll. Ein paar Prescaler und Muxe im Clocktree einstellen. Das ganze ist grafisch im Datenblatt und sogar grafisch im CubeMX zu bewundern. Raketenwissenschaft sieht anders aus.
Mehmet K. schrieb: > Mich interessiert naemlich die Frage, wie es mit der Geschwindigkeit von > ATATMEL-ICE im Vergleich zu ST-Link bzw. J-Link von Segger steht. Den ATATMEL-ICE hatte ich mal. Der hat mich nicht vom Hocker gehauen. Aktuell habe ich eine kleine Serie F407 mit ST-Link programmiert: 45800 Bytes in 2,4 s. Dies nur als Hausnummer. Debugging mit irgendeinem ICE beim AVR habe ich nie gemacht. Beim STM32 kann man sich die Register/Variablen zur Laufzeit ansehen, ohne den Prozessor anzuhalten. Per SWD werden nur 2 Pins benötigt.
Udo K. schrieb: > Klar, wenn ich nur alle Millisekunden mal mit ein paar Pins wackeln > muss, und langsame veraltete Schnittstellen verwende, tut es ein AVR > auch. Haha. Es gibt viele auch sehr leistungsfähige Projekte damit. > 8 Bit ist praktisch tot! Wo lebst Du? Auch der 8Bit Markt geht weiter kräftig nach oben. Die AVR Familie vergrößert sich weiter. > Aber wenn 8 Bit den Zweck erfüllen ist es auch total Ok, die zu > verwenden, vorallem wenn man sich damit auskennt. So ist das, und nicht anders.
Stefanus F. schrieb: > Man kann die STM32F103 ja auch mit 8 MHz takten (dann entfällt die > angeblich komplexe Konfiguration). In der Tat mache ich das ziemlich oft > so. Man kann den STM32 auch überhaupt nicht konfigurieren, dann läuft der mit der Reset Default Einstellung, das sind je nach Typ 8MHz oder 16MHz (HSI Clock) und braucht dabei nicht einmal einen externen Quarz.
m.n. schrieb: > Debugging mit irgendeinem ICE beim AVR habe ich nie gemacht. Beim STM32 > kann man sich die Register/Variablen zur Laufzeit ansehen, ohne den > Prozessor anzuhalten. Per SWD werden nur 2 Pins benötigt. Ja beim Thema Debugging hat es AVR einfach nicht drauf. Erstmal braucht das ISP Interface viel zu viele Pins und dann gibt es keine gute HW Untersützung. Erst das viel zu teure ICE, dann der unsägliche Dragon und dann die "billig" ICE Variante für immer noch 100 EUR. Dazu das JTAG und debugWire Mischmasch. STM32 haben ein 2 Pin SWD Interface über das alles an Programmierung und Debugging geht. HW gibts ab 5 Euro vom Chinesen oder 20 EUR Original. Software mit GDB und OpenOCD mitsamt Eclipse und sonstiger Integration ist auch null Problem. Keine Ahnung warum sich die AVR da bisher immer schwer getan haben. Bis heute.
Anton M. schrieb: > m.n. schrieb: >>Per SWD werden nur 2 Pins benötigt. > > Beim UPDI moderner AVRs nur einer. Du hast gewonnen! Wie geschrieben, habe ich beim AVR nie einen einzigen benötigt ;-)
Anton M. schrieb: > m.n. schrieb: >>Per SWD werden nur 2 Pins benötigt. > > Beim UPDI moderner AVRs nur einer. Ja super. Das 3. Interface für AVRs. Genau DAS macht es halt nicht besser.
Anton M. schrieb: > Udo K. schrieb: >> Klar, wenn ich nur alle Millisekunden mal mit ein paar Pins wackeln >> muss, und langsame veraltete Schnittstellen verwende, tut es ein AVR >> auch. > > Haha. Es gibt viele auch sehr leistungsfähige Projekte damit. > >> 8 Bit ist praktisch tot! > > Wo lebst Du? Auch der 8Bit Markt geht weiter kräftig nach oben. > Die AVR Familie vergrößert sich weiter. > >> Aber wenn 8 Bit den Zweck erfüllen ist es auch total Ok, die zu >> verwenden, vorallem wenn man sich damit auskennt. > > So ist das, und nicht anders. Der gesamte Microcontroller Markt geht die letzten Jahre kräftig nach oben. Nur deshalt und wegen der Altbestände (Projekte und Entwickler) halten sich die 8-bitter noch.
Udo K. schrieb: > Der gesamte Microcontroller Markt geht die letzten Jahre > kräftig nach oben. Ja. Das eine schließt das andere nicht aus. > Nur deshalt und wegen der Altbestände (Projekte und Entwickler) > halten sich die 8-bitter noch. Falsch. Es gibt sie weil sie es für vieles weiter tun. Da ist gar kein Ende abzusehen. Cyblord -. schrieb: > Ja beim Thema Debugging hat es AVR einfach nicht drauf. Erstmal braucht > das ISP Interface viel zu viele Pins und dann gibt es keine gute HW > Untersützung. Erst das viel zu teure ICE, dann der unsägliche Dragon und > dann die "billig" ICE Variante für immer noch 100 EUR. > Dazu das JTAG und debugWire Mischmasch. Den ICE gibts als Platine ab 49€. Mit dem Debugging bin ich zufrieden. Der Mischmasch ist halt historisch gewachsen. Und wohl auch Folge mancher undurchdachten Ingenieurs-Entscheidung. Cyblord -. schrieb: > Ja super. Das 3. Interface für AVRs. Genau DAS macht es halt nicht besser. Immerhin, das Interface wird immer besser.
:
Bearbeitet durch User
Beitrag #5713619 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > dann die "billig" ICE Variante für immer noch 100 EUR. Die billige Variante ist der ATATMEL ICE PCBA, den gibt's hier für 49€: http://shop.myavr.de/Systemboards%20und%20Programmer/Atmel%20ICE%20Programmerboard%20(ATATMEL%20ICE%20PCBA).htm?sp=article.sp.php&artID=200142 Jens
Udo K. schrieb: > Tut doch nicht so, wie wenn ein Cortex M4F sooo viel Rechenleistung > hätte! > Der ist bei vielen praktischen Anwendungen schnell am Ende. Es wird wohl bald Abhilfe geben und Linuxunterstützung... https://github.com/torvalds/linux/blob/master/Documentation/arm/stm32/stm32mp157-overview.rst
Appropos AVR kann nix und die 32er haben die besseren IO Möglichkeiten, also appropos "ihr habt alle keine Ahnung": IO Register des xmegas: PORTA_OUT PORTA_OUTSET PORTA_OUTCLR PORTA_OUTTGL PORTA_DIR PORTA_DIRSET PORTA_DIRCLT PORTA_DIRTGL Plus ein halbes Duzend Interrupt Register. Und dann von wegen "der hat nur PullUps": PORTA_PINnCTRL (für jeden PIN einzeln konfigurierbar): TOTEM BUSKEEPER PULLDOWN PULLUP WIREDOR WIREDAND WIREDORPULL WIREDANDPULL INPUTDISABLE BOTHEDGES RISING FALLING LEVEL Das einzige Gegenargument, was ich wirklich gelten lasse, ist der Preis. Die Features sind aber allesamt absolut genital!
Rödel schrieb: > Die Features sind aber allesamt absolut genital! Da stimme ich zu. Eher was für untenrum. Und die Port Features von oben finden sich nur bei den aller neusten AVRs.
Cyblord -. schrieb: > Bei den 32 Bit ARM gefällt mir auch der lineare Adressraum. > > Lesen aus dem Flash? Geht genau so wie lesen aus dem RAM oder von jeder > anderen Adresse. > DAS ist einfach besser als die PROGMEM bzw. _FLASH Kacke bei AVR. Recht hast du. C ist absolute Kacke. Da kann aber der AVR Kern nichts dafür. Wenn du aus dem SRAM lesen willst, nutzt du ld, wenn du aus dem Flash lesen willst, nutzt du lpm. Was ist daran so kompliziert? Gar nichts. Hätte C eine vernünftige Struktur und nicht diese historisch aufgeblasene Klammerapokalypse, wäre das auch nicht "Kacke".
Cyblord -. schrieb: > Und die Port Features von oben finden sich nur bei den aller neusten > AVRs. Was nimmst du für Zeug, um die xmegas als "die allerneuesten" zu bezeichnen? Was immer es ist, du solltest davon runterkommen.
Rödel schrieb: > Cyblord -. schrieb: >> Und die Port Features von oben finden sich nur bei den aller neusten >> AVRs. > > Was nimmst du für Zeug, um die xmegas als "die allerneuesten" zu > bezeichnen? Was immer es ist, du solltest davon runterkommen. Sorry X-Mega hab ich nicht auf dem Schirm. Die sind doch ein Witz. > Hätte C eine vernünftige Struktur und nicht diese historisch > aufgeblasene Klammerapokalypse, wäre das auch nicht "Kacke". Ok. Danke. Weitergehen.
Falk B. schrieb: > Das stimmt, geht aber am Gesamtproblem vorbei. Nicht nur die Profis, > auch die Amateure und Laien gehen jeden Tag massenhaft hirnlos mit > Speicher und IT-Ressourcen um. Das leidige Problem der Bildformate > ist nur eines davon. Ich bin ja nun weiß Gott kein Kind der sparsamen > (Nach)kriegsgeneration, aber das hirn- und sinnlose Verschleudern von > Ressourcen, auch wenn die teilweise heute nur noch wenig kosten, geht > mir auf den Keks. Aus gegebenem Anlaß, auch wenn es kein Mikrocontroller ist. https://www.mikrocontroller.net/topic/467222#5713392 "Eine über 700MB große PDF Datei :O Wer soll die öffnen?" VDSL ein, Hirn aus (tm).
Udo K. schrieb: > Klar, wenn ich nur alle Millisekunden mal mit ein paar Pins wackeln > muss, und langsame veraltete Schnittstellen verwende, tut es ein AVR > auch. Oder wenn man einen intelligenten Schaltwandler erstellen muss, der im us Bereich präzise schalten muss und nicht ausfallen darf, weil einige der überflüssigen Transistoren irgendwas machen, was keiner braucht und auch keiner vorhergesehen hat. Aber solche Aufgaben bekommen die meisten heutzutage eh nicht mehr gebacken und die Tätigkeit beschränkt sich aufs unkritische Front End "alle paar ms was blinken lassen" oder "Webserver aufsetzen".
Rödel schrieb: > Hätte C eine vernünftige Struktur und nicht diese historisch > aufgeblasene Klammerapokalypse, wäre das auch nicht "Kacke". Wie würde das denn in einer hypothetischen perfekten Programmiersprache besser gehen? Du hast in dieser Sprache eine Abstraktionseinheit, z.B. Modul/Klasse/Funktion implementiert, welchem du z.B. eine Referenz auf Daten übergeben möchtest. Diese Einheit möchte jetzt die referenzierten Daten laden. Woher weiß sie, ob sie per "ld" oder per "lpm" zugreifen muss? Wenn das Referenzieren von Daten, wie in C, per Pointer funktioniert, kann man einem Pointer nicht ansehen ob er in den Flash oder RAM zeigt. Die hypothetische perfekte Programmiersprache könnte als Pointer-Datentyp etwa einen 17-bit-Typ verwenden, bei welchem ein zusätzliches Bit angibt, ob der Pointer in den Flash oder RAM zeigt. Das passt aber schlecht auf eine 8-Bit-Architektur - ineffizient. Die Programmiersprache könnte wie Java eine große Tabelle mit Datenelementen benutzen, in welchen sich die 17bit-Pointer befinden, und die übergebenen Referenzen sind nur Indices auf die Tabelle. Das braucht aber eine Stufe Indirektion mehr - ineffizient. Wie soll die perfekte Programmiersprache das machen? Oder anders formuliert: Da ja alle effizienten und damit kompilierten Sprachen letztendlich Maschinen/Assembler-Code produzieren müssen, wie würde ein Speicher-agnostischer Zugriff funktionieren? Angenommen man hat eine Funktion "superprint" implementiert, welcher man 3 Pointer (X, Y und Z) auf 3 Speicherblöcke übergibt. Woher weiß die Funktion, ob in X ein Zeiger auf Flash oder RAM steht, ob sie somit ld oder lpm braucht? Bei ARM ist die Antwort einfach - die Funktion muss es nicht wissen, laden geht immer per ldr. Aber bei AVR...? Rödel schrieb: > Oder wenn man einen intelligenten Schaltwandler erstellen muss, der im > us Bereich präzise schalten muss und nicht ausfallen darf Die Cortex-M und -R sind schneller und z.B. dank NVIC besser für Echtzeit-Aufgaben geeignet als AVR.
Falk B. schrieb: > Aus gegebenem Anlaß, auch wenn es kein Mikrocontroller ist. > > https://www.mikrocontroller.net/topic/467222#5713392 > > "Eine über 700MB große PDF Datei :O Wer soll die öffnen?" > > VDSL ein, Hirn aus (tm). Hehe ;-) OT: Aber man muss auch zu sich selbst ehrlich sein. Selbst mein ja doch schon älteres Galaxy S5 macht 5312x2988 Pixel große Bilder. Und ich reduziere die Auflösung auch nicht, weil ja mal ein Foto dabei sein könnte, aus dem man gerne ein A0-Plakat machen möchte - oder Mikrofilm ;-) Ansonsten ist es bei einer 64GB-Karte einfach egal. Ich lösche auch praktisch keine Fotos mehr. Wozu auch? Die Karte wird einfach nicht voll, bis ich den ganzen Wust auf eine 128er wuchte. Gleiches gilt für Festplatten. Die Zeiten, wo ich auch nur halbwegs mit zu wenig HDD-Speicher zu kämpfen hatte, sind lange vorbei. Selbst die 1TB-Platten, auf die wir hier unsere Sicherungen machen, werden und werden nicht voll. Und da ist auch aller alter Sch.... dabei, Musik, irgendwelche alten Ubuntu-ISO's. Ich mache mir nicht die Mühe, das Unwichtige, bei dem ein Datenverlust kein Verlust wäre, irgendwie auszufiltern. Das Suchen und Löschen in den alten Beständen wäre aufwändiger als das alles einfach komplett auf die neue, riesige Platte zu knallen. Wir haben heutzutage Platz und auch Rechenleistung satt - es ist einfach so :-/ Dementsprechend sehen die neuen Frameworks natürlich auch aus.
Cyblord -. schrieb: >> Was nimmst du für Zeug, um die xmegas als "die allerneuesten" zu >> bezeichnen? Was immer es ist, du solltest davon runterkommen. > > Sorry X-Mega hab ich nicht auf dem Schirm. Die sind doch ein Witz. "Sorry, ich habe xmega nicht auf den Schirm, weiss nichts über die Teile, setze die nicht ein, hab sie nie gesehen, will sie auch nicht kennen, denn als ich sie mir nie angeschaut habe, habe ich schnell gemerkt, dass die ein Witz sind." Mann du musst vielleicht Kopfschmerzen haben. >> Hätte C eine vernünftige Struktur und nicht diese historisch >> aufgeblasene Klammerapokalypse, wäre das auch nicht "Kacke". > > Ok. Danke. Weitergehen. Dito. Geh bitte weg. Und zwar weit.
Und was macht der "intelligente" Schaltwandler, was ein UC3842 nicht macht (bin wirklich interessiert)? Das kann man natürlich machen, aber da brauchst du bei 230 Volt auf jeden Fall viel analoge Schutschaltung davor, egal ob mit nem Cortex Mx mit eingebauten ADC, Comparator und PWM Modul, oder mit nem 8-bitter.
Rödel schrieb: > Cyblord -. schrieb: >>> Was nimmst du für Zeug, um die xmegas als "die allerneuesten" zu >>> bezeichnen? Was immer es ist, du solltest davon runterkommen. >> >> Sorry X-Mega hab ich nicht auf dem Schirm. Die sind doch ein Witz. > > "Sorry, ich habe xmega nicht auf den Schirm, weiss nichts über die > Teile, setze die nicht ein, hab sie nie gesehen, will sie auch nicht > kennen, denn als ich sie mir nie angeschaut habe, habe ich schnell > gemerkt, dass die ein Witz sind." Mann du musst vielleicht Kopfschmerzen > haben. Naja, er hat nicht ganz Unrecht. Welchen Vorteil hat man bei der xmega-Serie denn noch gegenüber einem echten 32-Bitter? - keine 5V mehr - keine "bastlerfreundlichen Gehäuse" - teurer - geringere Taktraten und nur 8-Bit -> deutlich langsamer Für mein Empfinden gab es schon bei deren Erscheinen (das in der Tat schon einige Jährchen zurück liegt) nur ein Urteil: "zu spät"
Rödel schrieb: > "Sorry, ich habe xmega nicht auf den Schirm, weiss nichts über die > Teile, setze die nicht ein, hab sie nie gesehen, will sie auch nicht > kennen, denn als ich sie mir nie angeschaut habe, habe ich schnell > gemerkt, dass die ein Witz sind." Mann du musst vielleicht Kopfschmerzen > haben. Och nööö, jemand mag deine XMega Krücken nicht. Du armes Ding. Und C ist dir auch zu schwer. Du hast es echt nicht leicht. Bist aber unterhaltsam.
Cyblord -. schrieb: > Du hast es echt nicht leicht. Doch, hat er. Dazu muß man sich nämlich nur mit einer Controller-Familie gut auskennen. Wenn die mitbringt was man braucht ist es doch super. Chris D. schrieb: > Welchen Vorteil hat man bei der xmega-Serie denn noch gegenüber einem > echten 32-Bitter? Ein XMega ist den gewohnten AVRs immer noch tausendmal näher als jeder 32er. Das ist DER Vorteil schlechthin und der zählt für Asm-Programmierer doppelt.
Anton M. schrieb: > Doch, hat er. Dazu muß man sich nämlich nur mit einer Controller-Familie > gut auskennen. Wenn die mitbringt was man braucht ist es doch super. Ich setze da eher auf universelles Verständnis der Materie und geistige Agilität. Und hänge mich nicht krampfhaft an eine einzige Architektur. > Ein XMega ist den gewohnten AVRs immer noch tausendmal näher als jeder > 32er. Das ist DER Vorteil schlechthin und der zählt für > Asm-Programmierer doppelt. Hauptsache alles wie gewohnt. Nichts neues. Nicht denken. Ich gebe zu, das ist eine Haltung die meiner diametral entgegen läuft.
Wenn wir jetzt mal sachlich bleiben und so kranke Typen wie cyblord ignorieren, dann bleibt doch folgendes unstrittig a) Der TO (der wahrscheinlich schon längst das weite gesucht hat), hat in der Vergangenheit immer mit atmegas gearbeitet. Die sind ihm jetzt zu schwach geworden und er will was besseres. b) Es wurde ARM, PIC32 und xmega vorgeschlagen. Ich kenne die PIC32 auch nur soweit, dass ich mir die mal kurz angeschaut habe und dachte, dass mir der Umstieg von AVR einfach zu mühsam wäre und ich dann auch direkt ARM nehmen könnte. Deshalb sollte man sich doch auf folgendes einigen können: Wenn jemand ganz frisch reinkommt, vielleicht sogar beruflich damit arbeiten muss, dann würde ich auch sagen, nimm ARM. Die können ja auch nur besser werden in den Punkten, in denen die derzeit noch schlecht sind. Wenn jemand aber die ganze zeit hobbymässig atmega gemacht hat (und darum ging es hier, falls ihr das vor lauter stm32 verliebtheit vergessen habt), und es auch ein Hobby bleiben soll, was einfach nur Spass machen soll, dann lautet meine Empfehlung ganz klar XMEGA. Warum? Beim ARM muss man quasi von ganz von vorne anfangen. Das fängt ja schon bei der Toolchain an. Beim xmega kann ich einfach beim avrdude oder Atmel Studio weiterarbeiten. Der Umstieg ist schmerzfrei.
Und der xmega bietet einfach so viel mehr an Features, wo man dann langsam reinwachsen kann.
Chris D. schrieb: > Aber man muss auch zu sich selbst ehrlich sein. Selbst mein ja doch > schon älteres Galaxy S5 macht 5312x2988 Pixel große Bilder. > > Und ich reduziere die Auflösung auch nicht, weil ja mal ein Foto dabei > sein könnte, aus dem man gerne ein A0-Plakat machen möchte - oder > Mikrofilm ;-) Jaja, bei wievielen deiner tausenden Bilder wurde daraus Realität? > Ansonsten ist es bei einer 64GB-Karte einfach egal. Ich lösche auch > praktisch keine Fotos mehr. Wozu auch? Die Karte wird einfach nicht > voll, bis ich den ganzen Wust auf eine 128er wuchte. Eben. Genau DIESER Irrsinn geht mir auf den Keks! Denn er ist nicht auf Bilder beschränkt, er wuchert in fast alle Lebensbereiche, nicht nur ins Design von Elektronik. Verschwendungswahn an allen Fronten. Und wenn mal keine 64GB Karte da ist, wird gejammert, daß das alles UNMÖGLICH machbar ist. > Gleiches gilt für Festplatten. Die Zeiten, wo ich auch nur halbwegs mit > zu wenig HDD-Speicher zu kämpfen hatte, sind lange vorbei. Selbst die > 1TB-Platten, auf die wir hier unsere Sicherungen machen, werden und > werden nicht voll. 640kB sind genug . . . > Und da ist auch aller alter Sch.... dabei, Musik, > irgendwelche alten Ubuntu-ISO's. Ich mache mir nicht die Mühe, das > Unwichtige, bei dem ein Datenverlust kein Verlust wäre, irgendwie > auszufiltern. Datenmüllkippe. Wenn gleich es um den unwichtigen Müll nicht schade ist, verleitet es aber ebenso zum Schlendrian mit wichtigen Daten. > Das Suchen und Löschen in den alten Beständen wäre aufwändiger als das > alles einfach komplett auf die neue, riesige Platte zu knallen. Was in diesem Kleinformat vielleicht noch funktioniert, wird bei größeren Sachen scheitern. Eine TB++ große Datenbank sollte man nicht so betreiben. > Wir haben heutzutage Platz und auch Rechenleistung satt - es ist einfach > so :-/ Das gleiche sagten wir vor Jahrzehnten vom Wasser. Weltweit im "Überfluß" vorhanden. Oder vielleicht doch nicht? > Dementsprechend sehen die neuen Frameworks natürlich auch aus. AHA! Das ist schlicht und ergreifend Dekadenz! https://de.wikipedia.org/wiki/Dekadenz
Rödel schrieb: > Wenn jemand aber die ganze zeit hobbymässig atmega gemacht hat (und > darum ging es hier, falls ihr das vor lauter stm32 verliebtheit > vergessen habt), und es auch ein Hobby bleiben soll, was einfach nur > Spass machen soll, dann lautet meine Empfehlung ganz klar XMEGA. > > Warum? Beim ARM muss man quasi von ganz von vorne anfangen. Das fängt ja > schon bei der Toolchain an. Beim xmega kann ich einfach beim avrdude > oder Atmel Studio weiterarbeiten. Der Umstieg ist schmerzfrei. Würde ich nicht empfehlen. Meiner Meinung nach ist der einzige Vorteil der 8-bitter die relativ einfache Peripherie, die man sich an einem Nachmittag anschauen kann. Genau diesen Vorteil hat der XMega nicht. Soweit ich gehört habe, hat der XMega die gleiche Peripherie wie der Atmel ARM uC. Das was viele noch 8-bit Verliebte nicht verstanden haben, ist dass der Cortex uC im Prinzip genauso einfach ist wie ein 8-bitter. Der Unterschied ist doch nur, dass die Register 32 Bit sind. Das ist erst mal alles. Ist doch nicht sooo schlimm :-) Die Komplexität kommt durch die Peripherie, wo sich viele erst mal erschlagen fühlen. Da liegt der Trick darin, alle Peripheriemodule zu ignorieren, die man nicht braucht. Man braucht sie nicht mal initialisieren, die tun per Default nichts.
Falk B. schrieb: > Chris D. schrieb: > >> Aber man muss auch zu sich selbst ehrlich sein. Selbst mein ja doch >> schon älteres Galaxy S5 macht 5312x2988 Pixel große Bilder. >> >> Und ich reduziere die Auflösung auch nicht, weil ja mal ein Foto dabei >> sein könnte, aus dem man gerne ein A0-Plakat machen möchte - oder >> Mikrofilm ;-) > > Jaja, bei wievielen deiner tausenden Bilder wurde daraus Realität? Das sollte der Smilie andeuten ;-) >> Ansonsten ist es bei einer 64GB-Karte einfach egal. Ich lösche auch >> praktisch keine Fotos mehr. Wozu auch? Die Karte wird einfach nicht >> voll, bis ich den ganzen Wust auf eine 128er wuchte. > > Eben. Genau DIESER Irrsinn geht mir auf den Keks! Denn er ist nicht auf > Bilder beschränkt, er wuchert in fast alle Lebensbereiche, nicht nur ins > Design von Elektronik. Verschwendungswahn an allen Fronten. Und wenn mal > keine 64GB Karte da ist, wird gejammert, daß das alles UNMÖGLICH machbar > ist. Das Problem ist doch, dass Du kleinere Karten praktisch nicht mehr bekommst, und wenn, dann zum fast identischen Preis. Natürlich nimmt man da das dickere Ding. >> Und da ist auch aller alter Sch.... dabei, Musik, >> irgendwelche alten Ubuntu-ISO's. Ich mache mir nicht die Mühe, das >> Unwichtige, bei dem ein Datenverlust kein Verlust wäre, irgendwie >> auszufiltern. > > Datenmüllkippe. Wenn gleich es um den unwichtigen Müll nicht schade ist, > verleitet es aber ebenso zum Schlendrian mit wichtigen Daten. Nö, das nicht. Dafür hat man ja sein Versionssystem. >> Das Suchen und Löschen in den alten Beständen wäre aufwändiger als das >> alles einfach komplett auf die neue, riesige Platte zu knallen. > > Was in diesem Kleinformat vielleicht noch funktioniert, wird bei > größeren Sachen scheitern. Eine TB++ große Datenbank sollte man nicht so > betreiben. Haben wir hier ja nicht. >> Wir haben heutzutage Platz und auch Rechenleistung satt - es ist einfach >> so :-/ > > Das gleiche sagten wir vor Jahrzehnten vom Wasser. Weltweit im > "Überfluß" vorhanden. Oder vielleicht doch nicht? Doch, ist sie. Und: die Dinger verbrauchen auch noch deutlich weniger Energie als die alten Chips. >> Dementsprechend sehen die neuen Frameworks natürlich auch aus. > > AHA! > Das ist schlicht und ergreifend Dekadenz! > https://de.wikipedia.org/wiki/Dekadenz Nee, das Abendland geht deswegen nicht unter, nur weil man heute auf etwas 1000 mal so viel speichern kann wie vor 20 Jahren und die Leute das nutzen. Für mich macht es keinen Sinn, in die Sortierung der Altbestände wertvolle Lebenszeit zu investieren. Die werden einfach mitkopiert - fertig. Und wenn ich sie nie mehr benötige, dann soll es so sein. Trotzdem kann man aber bei seinen Projekten darauf achten, nicht zu verschwenderisch zu sein. Ich möchte aber auch nie wieder dieses Bytegeschiebe wie damals in einem Projekt, bei dem die 8kB des Atmega8515 wirklich bis auf den letzten Platz gefüllt waren. Das hat unendlich viel Zeit gekostet. Da nehme ich heute lieber direkt den dicksten STM32-"Brummer" bis zur Serienreife und specke dann erst soweit wie nötig ab. Das spart viel Zeit und Nerven.
svensson schrieb: > Wieso wird denn der MSP430 empfohlen, ist der nicht abgekündigt (meine > ich als Beitrag gelesen zu haben)? Das war wohl dort: Beitrag "MSP430 Aufkündigung?" Dann haben alle auf den OP eingeschlagen ...
Dr. Sommer schrieb: > Wie würde das denn in einer hypothetischen perfekten Programmiersprache > besser gehen? Du hast in dieser Sprache eine Abstraktionseinheit, z.B. > Modul/Klasse/Funktion implementiert, welchem du z.B. eine Referenz auf > Daten übergeben möchtest. Diese Einheit möchte jetzt die referenzierten > Daten laden. Woher weiß sie, ob sie per "ld" oder per "lpm" zugreifen > muss? Das sind alles Fragen die sich ergeben wenn man in dieser abstrakten Welt zuhause ist. Einen einfachen Controller wie den AVR kann man aber noch auf unterster Ebene mit Klartext ansprechen. Ob lds oder lpm- das weiß der 8Bit Programmierer hier noch. Aus dessen Sicht wirkt die aufgepflanzte Abstraktion mit ihrer Unmenge an Sprachkonstruktionen, Abhängigkeiten und Optionen wie überflüssiger Overhead. Dem AVR kannst Du noch direkt sagen 'schalt diesen Pin ein' ohne sich dafür durch eine Unmenge an Modulen/Klassen/Funktionen wühlen zu müssen und ohne zuvor aufwendig alles mögliche zu initialisieren. Abstraktion wird meines Erachtens erst beim Hantieren mit funktional größeren Systemen und Datensätzen zum Vorteil. Cyblord -. schrieb: > Hauptsache alles wie gewohnt. Nichts neues. Nicht denken. Ich gebe zu, > das ist eine Haltung die meiner diametral entgegen läuft. Am Denken müssen besteht auch in der 8-Bit Welt kein Mangel. Es soll schließlich eine Aufgabe gelöst werden. Dabei ist es von Vorteil, wenn man sich möglichst auf das Problem fokussieren kann und nicht auf das Werkzeug muß. "Hauptsache alles wie gewohnt" oder "Neues lernen" - was ist zur Problemlösung nun vorteilhafter? Das eine ist möglicherweise schon zu umständlich, das andere möglicherweise zu aufwendig: Ständige Umstellungen fressen halt Zeit und Geld und kosten Mühe, die wiederum dann der Problemlösung fehlen. Ich halte es eigentlich fürs Hobby so daß ich mir interessiert die Neuentwicklungen anschaue. Bislang bin ich aber noch jedes Mal zum Schluß gekommen, daß meinen Projekten wohl ein (zukünftiger) AVR immer ausreichen wird.
Die Xmegas haben wirklich beeindruckende Peripherie. Mehr geht kaum, oder? Bei STM32 gefällt mir die grosse Auswahl. Zu wenig Speicher? Kein Problem. Zu wenig oder zu viele Pins? Auch kein Problem. Zu langsam? Dann nimm die nächst höhere Serie. Zu viel Stromverbrauch? Dann wechsele zu einer L Serie. Da ist für jeden etwas passendes dabei. Und für die "kleine" Welt habe ich ja immer noch meine geliebten ATtinies und den auch noch relativ kleinen ATmega328. Für mich ergänzen sich STM32 und AVR prima zu einem Gesamtbild. Nur weiss ich nicht, wo ich da die Xmega unterbringen soll. Sie sind zweifellos toll, aber auch teuer. Da kann ich lieber gleich einen ARM Controller nehmen und von dessen grösserer Vielfalt und Geschwindigkeit profitieren. Was die Programmierung angeht finde ich die Unterschiede nicht so gravierend, dass ich diese zum Auswahlkriterium machen würde. Wenn so ein Xmega128D3 nur 1 bis 2 Euro kosten würden, wäre er für mich attraktiver. Aber nicht zum aktuellen Preis (ab 3,50€). Chris D. schrieb: > Für mein Empfinden gab es schon bei deren Erscheinen nur ein Urteil: "zu spät" Ja, sehe ich auch so.
Udo K. schrieb: > dass der Cortex uC im Prinzip genauso einfach ist wie ein 8-bitter. > Der Unterschied ist doch nur, dass die Register 32 Bit sind. > Das ist erst mal alles. Ist doch nicht sooo schlimm :-) Verharmlosung sollte bestraft werden :-)
Dr. Sommer schrieb: > Falk B. schrieb: >> Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig >> Rechenleistung die Amis zum Mond geflogen sind. ... > Was an dem "Rechenleistung-zum-Mond-Fliegen"-Spruch immer fehlt: Sie > hatten nicht nur einen Computer, sondern auch eine Rakete. Vor allem hatten sie über Funk, wenn auch nur über 2-beinige Modems, Zugriff auf die dicksten Mainframes dieser Zeit. Die haben nicht nicht mit ihren "C64 mit gehäkelter Firmware" die Bahn für die Rückkehr der Apollo13 berechnet, sondern dies den Boliden daheim überlassen. Heute nennt man das IoT-Cloud und ist ähnlich leichtgewichtig.
Carl D. schrieb: > Dr. Sommer schrieb: >> Falk B. schrieb: >>> Auch wenn der Vergleich hinkt. Denkt mal drüber nach, mit wie wenig >>> Rechenleistung die Amis zum Mond geflogen sind. > ... >> Was an dem "Rechenleistung-zum-Mond-Fliegen"-Spruch immer fehlt: Sie >> hatten nicht nur einen Computer, sondern auch eine Rakete. > > Vor allem hatten sie über Funk, wenn auch nur über 2-beinige Modems, > Zugriff auf die dicksten Mainframes dieser Zeit. Die haben nicht nicht > mit ihren "C64 mit gehäkelter Firmware" die Bahn für die Rückkehr der > Apollo13 berechnet, sondern dies den Boliden daheim überlassen. > Heute nennt man das IoT-Cloud und ist ähnlich leichtgewichtig. Ich bin mir eigentlich recht sicher, dass die das zur Not auch per Hand und mit dem HP Taschenrechner ausgerechnet hätten :-)
Chris D. schrieb: >> Jaja, bei wievielen deiner tausenden Bilder wurde daraus Realität? > > Das sollte der Smilie andeuten ;-) Jaja. > >> Eben. Genau DIESER Irrsinn geht mir auf den Keks! Denn er ist nicht auf >> Bilder beschränkt, er wuchert in fast alle Lebensbereiche, nicht nur ins >> Design von Elektronik. Verschwendungswahn an allen Fronten. Und wenn mal >> keine 64GB Karte da ist, wird gejammert, daß das alles UNMÖGLICH machbar >> ist. > > Das Problem ist doch, dass Du kleinere Karten praktisch nicht mehr > bekommst, und wenn, dann zum fast identischen Preis. > > Natürlich nimmt man da das dickere Ding. Sicher, dagegen spricht auch nix. Aber mit Resourcen haushalten, und ich meine nun weiß Gott nicht schwäbisch sparen, ist NIE von Nachteil. >> Datenmüllkippe. Wenn gleich es um den unwichtigen Müll nicht schade ist, >> verleitet es aber ebenso zum Schlendrian mit wichtigen Daten. > > Nö, das nicht. Dafür hat man ja sein Versionssystem. Du verstehst es nicht. Ich rede nicht von dir als Einzelfall sondern von der gesamtgesellschaftlichen Wirkung. >> Was in diesem Kleinformat vielleicht noch funktioniert, wird bei >> größeren Sachen scheitern. Eine TB++ große Datenbank sollte man nicht so >> betreiben. > > Haben wir hier ja nicht. Dito!!! >>> Wir haben heutzutage Platz und auch Rechenleistung satt - es ist einfach >>> so :-/ >> >> Das gleiche sagten wir vor Jahrzehnten vom Wasser. Weltweit im >> "Überfluß" vorhanden. Oder vielleicht doch nicht? > > Doch, ist sie. Und: die Dinger verbrauchen auch noch deutlich weniger > Energie als die alten Chips. Ach ja? Warum muss ein Smartphone dann jeden Tag mindestens einmal ans Ladegerät? > >>> Dementsprechend sehen die neuen Frameworks natürlich auch aus. >> >> AHA! >> Das ist schlicht und ergreifend Dekadenz! >> https://de.wikipedia.org/wiki/Dekadenz > > Nee, das Abendland geht deswegen nicht unter, nur weil man heute auf > etwas 1000 mal so viel speichern kann wie vor 20 Jahren und die Leute > das nutzen. Hab ich nicht behauptet, aber es HAT deutlich mehr Wirkungen, als du ind ich uns denken können! > Für mich macht es keinen Sinn, in die Sortierung der Altbestände > wertvolle Lebenszeit zu investieren. Die werden einfach mitkopiert - > fertig. Und wenn ich sie nie mehr benötige, dann soll es so sein. Davon war auch nicht die Rede. Sondern vom AKTIVEN, bewußten Resourcenumgang. Man muss nich 08/15 Bilder mit 20MP speichern oder verschicken etc. > Trotzdem kann man aber bei seinen Projekten darauf achten, nicht zu > verschwenderisch zu sein. DAS meine ich! Heureka! > Ich möchte aber auch nie wieder dieses Bytegeschiebe wie damals in einem > Projekt, bei dem die 8kB des Atmega8515 wirklich bis auf den letzten > Platz gefüllt waren. Das hat unendlich viel Zeit gekostet. Keine Bange, außer Mark Watney muss das keiner in der Zukunft tun ;-) > Da nehme ich heute lieber direkt den dicksten STM32-"Brummer" bis zur > Serienreife und specke dann erst soweit wie nötig ab. Das spart viel > Zeit und Nerven. Das ist ja normal!
Stefanus F. schrieb: > Wenn so ein Xmega128D3 nur 1 bis 2 Euro kosten würden, wäre er für mich > attraktiver. Aber nicht zum aktuellen Preis (ab 3,50€). Ach so? Wieviel Million Stück verbaust du jedes Jahr? (Mann O Mann)
Falk B. schrieb: > Wieviel Million Stück verbaust du jedes Jahr? Einen, wenn es hoch kommt. Er ist mir halt für primitive LED Blinker zu schade.
Udo K. schrieb: > mit dem HP Taschenrechner ausgerechnet hätten Bestimmt nicht. Als HP anfing, Taschenrechner zu bauen, wurde das Apollo-Programm eingestellt. Aber sieh dir mal den Film "Apollo 13" an. Das ist der Flug mit der Explosion an Bord. Da gibt es eine Szene, in der sie in Houston mit Rechenschiebern die Daten vom Raumschiff nachrechnen.
Anton M. schrieb: > > Verharmlosung sollte bestraft werden :-) Seit wann darf Moby eigentlich wieder schreiben? Noch dazu in trautem Beisammensein mit Moderatoren?
Stefanus F. schrieb: > Falk B. schrieb: >> Wieviel Million Stück verbaust du jedes Jahr? > > Einen, wenn es hoch kommt. Er ist mir halt für primitive LED Blinker zu > schade. Das ist fast jeder uC, auch ein Tiny für 50 Cent.
Moin, > Altlasten wischt Euch 'mal den Schaum vom Mund... > kleinere Chipflächen Nicht zwangsläufig ist das Die kleiner, sondern die Strukturen. Und bei kleineren Strukturen passen nun einmal bei gleicher Fläche mehr Elemente (=Funktionen oder RAM) darauf. Es ist allerdings zu bezweifeln, daß die kleinen Strukturen ebenso haltbar sein werden. Und da hier immer von Nachhaltigkeit/Langlebigkeit gejammert wird, könnte es schon hilfreich sein, wenn die Elektronik dann auch noch in 20 Jahren funktioniert... Übrigens gibt es sogar noch 4-Bitter für Spezialanwendungen. Und dann kommt noch der Sicherheitsaspekt hinzu. Je komplexer das Framework wird, desto mehr Bugs befinden sich darin. Es kann doch nicht wünschenswert sein, ständig jeden µC mit Updates versorgen zu müssen, obwohl es vielleicht lukrativ wäre.
svensson schrieb: > Je komplexer das > Framework wird, desto mehr Bugs befinden sich darin. Das Gleiche kann man auch über den Chip selbst sagen, schon mal die Erratas von STM32 Controllern mit denen von AVR Chips verglichen? 25 Seiten für den STM32F103, 6 Seiten für den ATMega328. Natürlich hat der STM mehr Peripherie, in der sich Fehler einschleichen können, aber das ist ja genau der Punkt.
Also der TO hat tatsächlich noch nicht das Weite gesucht, auch wenn das hier gar nicht so einfach war. Aber schön das es im wesentlich eine nette Diskussion war und kein Glaubenskrieg ;) Resumee Vorschläge als Nachfolger der AVR bzw. des 328P: - XMega Serie: gute Peripherie, kein großer Umstieg, teurer, weiterhin 8Bit - STM32 Serie: sehr gute Peripherie, große Range/Auswahl, günstig, 32bit, große Community - PIC32: steht den anderen vermutlich in nicht viel nach, ich kenne die alten PIC auch zum Teil und fand sie nicht schlecht, sind im Thread aber eher wenig behandelt worden - MSP430: eher so der aussenseiter in 16bit, ist im Thread nur am Rande behandelt worden Mein Fazit - 8bitter sind für mich nicht tot, das ich nen AVR für kleine Projekte weiterhin nehme schließe ich ja gar nicht aus - Nachfolger wird wohl jetzt (zumindest erstmal zur Evaluierung) der STM32F072C8 bzw. CB. Entscheidungsgründe: - Umstieg auf 32Bit halte ich für sinnvoll. Gibt einem mehr Möglichkeiten, auch wenn man sie vielleicht nicht immer braucht. Aber sie kosten objektiv betrachtet nichts, weder Ressourcen noch monetär. - Der Umstieg an sich ist für mich auch Hobby. Ich lernen gerne was neues. - Die Peripherie hat so ziemlich alles was ich mir wünsche und hat weniger Kinderkrankheiten als die des F103 - Die Controller sind einfach zu beschaffen und günstig, ebenso Programmer, wenn auch die F0x2 lange nicht so einfach beschaffbar/günstig wie die F103 (gibt damit offenbar keine Blue Pills etc. wenn jemand welche kennt bitte Info an mich, ansonsten kommt der Käfer zum testen erstmal auf ne Adapterplatine) - Große Community, Libs, Beispiele. Danke allen nochmals für den Input. Könnte glaub ich jetzt erstmal geclosed werden ;)
Falls Du Keil mit dem STM32x0xx nutzen willst, hier gibt es von Keil einen kostenlosen Lizenz-Key: http://www2.keil.com/stmicroelectronics-stm32/mdk
Thomas E. schrieb: > Udo K. schrieb: >> mit dem HP Taschenrechner ausgerechnet hätten > > Bestimmt nicht. Als HP anfing, Taschenrechner zu bauen, wurde das > Apollo-Programm eingestellt. Pünktlich zur Mondlandung gab's der "Taschenrechner" HP9100A. 20kg > Aber sieh dir mal den Film "Apollo 13" an. Das ist der Flug mit der > Explosion an Bord. Da gibt es eine Szene, in der sie in Houston mit > Rechenschiebern die Daten vom Raumschiff nachrechnen. In der Holliwood Version vielleicht. In echt nahm man lieber /360-Mainframes, wie man hier auf S.17 nachlesen kann: http://www.horst-zuse.homepage.t-online.de/seidel-apollo-2016-final.pdf
Angehängte Dateien:
-
stm32f0.png
35 KB
Etwas schmalbrüstiger, aber für den Anfang ... https://www.watterott.com/de/STM32F030F4P6-Minimum-Systerm-Board-Cortex-M0?xef95f=694ef3d64aa6e678969c273e93402164 Jens
Carl D. schrieb: > Thomas E. schrieb: >> Udo K. schrieb: >>> mit dem HP Taschenrechner ausgerechnet hätten >> >> Bestimmt nicht. Als HP anfing, Taschenrechner zu bauen, wurde das >> Apollo-Programm eingestellt. . > Pünktlich zur Mondlandung gab's der "Taschenrechner" HP9100A. 20kg . >> Aber sieh dir mal den Film "Apollo 13" an. Das ist der Flug mit der >> Explosion an Bord. Da gibt es eine Szene, in der sie in Houston mit >> Rechenschiebern die Daten vom Raumschiff nachrechnen. . > In der Holliwood Version vielleicht. In echt nahm man lieber > /360-Mainframes, wie man hier auf S.17 nachlesen kann: Oder besser auf S.29 > http://www.horst-zuse.homepage.t-online.de/seidel-apollo-2016-final.pdf
Alec T. schrieb: > XMega Serie: gute Peripherie... > STM32 Serie: sehr gute Peripherie... Ich habe eher den Eindruck, dass die Peripherie der Xmega wesentlich umfangreicher ist, als die der STM32 (mit Ausnahme von CAN und USB). Andererseits muss man nicht immer den dicksten haben wollen. Bei meinen Fahrzeugen halte ich das ebenso.
Guckt euch das mal an: https://de.rs-online.com/web/p/products/8224049/ Ein Nucleo64 Board mit STM32F072 für nur 11€ - Inklusive originalem ST-Link und USB-UART. Das ist doch Geil, oder?
Stefanus F. schrieb: > Ich habe eher den Eindruck, dass die Peripherie der Xmega wesentlich > umfangreicher ist, als die der STM32 (mit Ausnahme von CAN und USB). In der Tat war aber für mich genau das ausschlaggebend...
Stefanus F. schrieb: > Alec T. schrieb: >> XMega Serie: gute Peripherie... >> STM32 Serie: sehr gute Peripherie... > > Ich habe eher den Eindruck, dass die Peripherie der Xmega wesentlich > umfangreicher ist, als die der STM32 (mit Ausnahme von CAN und USB). Wenn CAN und USB fehlen, dann fehlt aber schon heutzutage sehr wichtige Peripherie :-} Davon abgesehen: welche Peripherie fehlt denn bei den STM32 gleicher Preisklasse, die es nur beim xmega gibt? Das einzige, was ich bei den STM32 wirklich vermisse, ist EEPROM. Man kann das zwar im Flash auch ganz pfiffig "simulieren" und das funktioniert auch zuverlässig, aber echtes EEPROM ist schon angenehmer. > Andererseits muss man nicht immer den dicksten haben wollen. Bei meinen > Fahrzeugen halte ich das ebenso. Das halte ich - in der Prototypenphase - für einen Fehler. Denn gerade bei Neuentwicklungen ist es oft so, dass man später gerne noch dieses oder jenes hätte. Deswegen fange ich immer mit dem "Dicksten" einer Serie an und gehe erst dann auf die kleineren Typen, wenn Code, Hardware und Anforderungen sich stabilisiert haben. Die andere Vorgehensweise bedeutet nur Stress in der Entwicklung, weil man sehr bald an irgendwelche Grenzen stösst. Ausnahmen davon kann es meines Erachtens nach nur dann geben, wenn es wirklich um Stückzahl geht.
Chris D. schrieb: > Ausnahmen davon kann es meines Erachtens nach nur dann geben, wenn es > wirklich um Stückzahl geht. Auch dann würde ich die Entwicklung mit einem großen Controller anfangen - ist auch angenehmer zum Debuggen, wenn genug Platz im Flash für printf() und Konsorten ist - und dann für das Serienprodukt einen kleineren nehmen. Dank weitgehender Kompatibilität ist die Umstellung auch nicht so aufwendig. Chris D. schrieb: > aber echtes EEPROM ist schon angenehmer. Aber vermutlich eben auch teurer. 10kB Flash ist vermutlich einfacher/billiger als 1kB EEPROM in einen uC zu integrieren, hält aber mit entsprechendem Wear Leveling genau so lange. Ein paar STM32 mit EEPROM gibt's aber.
Dr. Sommer schrieb: > Chris D. schrieb: >> aber echtes EEPROM ist schon angenehmer. > > Aber vermutlich eben auch teurer. 10kB Flash ist vermutlich > einfacher/billiger als 1kB EEPROM in einen uC zu integrieren Ja, das hat offenbar mit dem Herstellungsprozess zu tun. So begründete das damals im ST-Seminar der Chip-Design-Ingenieur. Leute vom Fach können dazu sicherlich mehr sagen. > hält aber mit entsprechendem Wear Leveling genau so lange. Ja, ST hat dazu eine gute AppNote rausgebracht, bei der die Schreibzugriffe minimiert werden: AN2594 - EEPROM emulation in STM32F10x microcontrollers > Ein paar STM32 mit > EEPROM gibt's aber. Stimmt, in der L-Serie hab ich welches gefunden. Dann haben sich anscheinend doch noch mehr beschwert und die neuen Familien haben es :-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Das einzige, was ich bei den STM32 wirklich vermisse, ist EEPROM. Man > kann das zwar im Flash auch ganz pfiffig "simulieren" und das > funktioniert auch zuverlässig, aber echtes EEPROM ist schon angenehmer. Vor allem weil die Flash Pages recht groß sind, und man recht viel Platz verschwendt, wenn man nur ein paar Byte via "EEPROM" sichern will.
Muss kurz meinen Senf zur XMEGA und ARM Diskussion geben. Wenn Leute sagen es gibt ja kaum einen Unterschied zwischen beiden mehr, dann kann ich das jetzt nicht gelten lassen. Natürlich muss ich beim XMEGA mehr Register einstellen als beim AVR. Und natürlich muss ich beim ARM auch Register einstellen. Aber habt ihr euch über das setzen von Registern mal den Aufbau angeschaut? Also bei dem ARM uc ist alles über die Peripheral Busse ja doch mal anders angeknotet. Das sollte man nicht abstreiten und auch nicht unter den Teppich kehren. Das ist natürlich fürs initialisieren von registern egal - für mich sind das aber zwei völlig andere Controller. Und, ja, ich benutze beide (alle drei). Ich habe zwischen stm32, AVR und XMEGA keine Lieblinge und ich fühle mich auch nicht besser oder schlechter wenn ich einen benutze. Ich schreibe nebenbei gesagt auch gerne mal ein Assembler Programm auf einem kleinen avr. Das mache ich vermutlich nicht so effizent wie der c-Compiler nur um diese Diskussion zu vermeiden. Es macht aber Spaß und ist eine gute Alternative zu "malen nach Zahlen" oder Kreuzworträtsel.... Sich nicht aufplustern, nicht als Maß der Dinge sehen und keine Elektronik-Religion gründen. Herrlich.
Cyblord -. schrieb: > Vor allem weil die Flash Pages recht groß sind, und man recht viel Platz > verschwendt, wenn man nur ein paar Byte via "EEPROM" sichern will. Naja, wenn man im echten EEPROM nur ein paar Bytes sichert ist der Rest vom EEPROM genauso verschwendet. Die STM32 haben ja absichtlich viel Flash damit man den auch für Daten nutzen kann. Wenn man überhaupt keine Daten speichert, kann man den frei werdenden Platz auch für Code nutzen - das geht zumindest beim AVR-EEPROM nicht! Chris D. schrieb: > Ja, das hat offenbar mit dem Herstellungsprozess zu tun. So begründete > das damals im ST-Seminar der Chip-Design-Ingenieur. Ah, ja genau das hatte ich vermutet. Chris D. schrieb: > Dann haben sich anscheinend doch noch mehr beschwert und die neuen > Familien haben es :-) Die neuen F7 haben es auch nicht. Ist irgendwie eine Eigenheit der L-Serie. mister x schrieb: > Es macht aber Spaß und > ist eine gute Alternative zu "malen nach Zahlen" oder > Kreuzworträtsel.... Das ist aber beim ARM - insbesondere ARMv7A, Cortex-A - noch viel lustiger, da hat man viel bessere Möglichkeiten sich das Hirn zu verknoten ;-)
Anton M. schrieb: > Ich halte es eigentlich fürs Hobby so daß ich mir interessiert die > Neuentwicklungen anschaue. Bislang bin ich aber noch jedes Mal zum > Schluß gekommen, daß meinen Projekten wohl ein (zukünftiger) AVR immer > ausreichen wird. Das Problem sind Leute wie du, die eben keine Anwendung haben, die über ein bisschen LED blinken raus geht, und dann aber lauthals gegen C und gegen jede Form der Abstraktion plärren. Ich entwickle auch noch viel auf 8 Bit AVR, aber niemals in Assembler. Wenn du mal ein bisschen mehr machst, irgendwelche "Stacks" nutzt, Sensorbusse, DMX, irgendwelche Kommunikationsprotokolle mit anderen Geräten usw., dann brauchst du diese Abstraktion um halbwegs ordentlich entwickeln zu können. Bei beliebig simpler Applikation kann ich jedes Feature und jede Abstraktion als unsinnig und überflüssig darstellen.
:
Bearbeitet durch User
Hmmm, ich hab vor drei Jahren fürs Hobby mit den ATXMegas (32A4) angefangen, weil die noch mit 0,8mm Pitch zu haben sind (Bei STM hab ich nur 0,5mm gefunden. Das ist mir a bisserl eng für Selbstgeätztes).
Framulestigo schrieb: > ich hab vor drei Jahren fürs Hobby mit den ATXMegas (32A4) angefangen, > weil die noch mit 0,8mm Pitch zu haben sind (Bei STM hab ich nur 0,5mm > gefunden. Das ist mir a bisserl eng für Selbstgeätztes). die neuen STM32G0 gibts auch im TQFP-32 mit 0.8mm pitch z.B. https://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-mainstream-mcus/stm32g0-series/stm32g0x1/stm32g071kb.html
Framulestigo schrieb: > (Bei STM hab ich nur 0,5mm > gefunden. Das ist mir a bisserl eng für Selbstgeätztes) Die TQFP32-STMs haben 0,8mm Pin-Abstand. Jens
Cyblord -. schrieb: > Das Problem sind Leute wie du, die eben keine Anwendung haben, die über > ein bisschen LED blinken raus geht Woher weißt Du das? Folgerst Du das aus der fixen Meinung > Wenn du mal ein bisschen mehr machst, irgendwelche "Stacks" nutzt, > Sensorbusse, DMX, irgendwelche Kommunikationsprotokolle mit anderen > Geräten usw., dann brauchst du diese Abstraktion um halbwegs ordentlich > entwickeln zu können ??? Du kannst Dir eben nicht vorstellen und eingestehen, daß zum Verarbeiten einer Vielzahl von Sensoren, zum Realisieren von Kommunikationsprotokollen, zu vielfältigem In/Output simples Asm ganz genauso langt, wenn man nur damit umzugehen weiß. Abstraktion möchte ich deshalb nicht abgewertet wissen, nur ist und bleibt sie Overhead, der erst ab einer bestimmten komplexen Funktionalität und Datensumme zwingend wird, da sonst die Entwicklungszeit völlig aus dem Ruder läuft. Grundsätzlich ist Asm zwar viel feinkörniger, mit System als Baustoff im Lego-Prinzip zum Aufbau der tollsten Bauten aber ganz genauso verwendbar. Und das mit einem winzigen Bruchteil der zu beherrschenden Sprachmittel hochgezüchteter Abstraktion bzw. OOP.
gfdh schrieb: > die neuen STM32G0 gibts auch im TQFP-32 mit 0.8mm pitch > z.B. > https://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-mainstream-mcus/stm32g0-series/stm32g0x1/stm32g071kb.html Wow, die gabs vor drei Jahren aber noch nicht?!? Is ja lustig, warum bauen die von STM jetzt auf einmal größere Gehäuse? Allein wegen mir? Das nenn ich aber mal Service.
Scherz beiseite: Ich hab damals schon nicht alles angeschaut, nur so bei den herkömmlichen Shops, was es da so einzeln an ICs gab.
Anton M. schrieb: > Du kannst Dir eben nicht vorstellen und eingestehen, daß zum Verarbeiten > einer Vielzahl von Sensoren, zum Realisieren von > Kommunikationsprotokollen, zu vielfältigem In/Output simples Asm ganz > genauso langt, Da habe ich in der Tat so meine Schwierigkeiten. Ich würde mir gerne mal einen von dir erstellten Kommunikationstack in ASM anschauen. Möglich ist natürlich alles in ASM. Aber irgendwann macht es keinen Sinn mehr, ist nicht mehr übersichtlich, nicht mehr wartbar, nicht mehr erweiterbar. Und wozu? Weil man zu faul oder zu doof ist auf eine Hochsprache zu wechseln?
:
Bearbeitet durch User
Anton M. schrieb: > Udo K. schrieb: >> dass der Cortex uC im Prinzip genauso einfach ist wie ein 8-bitter. >> Der Unterschied ist doch nur, dass die Register 32 Bit sind. >> Das ist erst mal alles. Ist doch nicht sooo schlimm :-) > > Verharmlosung sollte bestraft werden :-) Aber er hat recht.
Cyblord -. schrieb: > Und wozu? Weil man zu faul oder zu doof ist auf eine Hochsprache zu > wechseln? Wenn Du Sallos rund haben willst, dann MUSST Du sie lutschen. Da geht kein Weg dran vorbei.
Und welche Hochsprache sollte das sein? C? Ist doch auch nur ein besserer Assembler für Denkfaule.
Thomas E. schrieb: > Udo K. schrieb: >> mit dem HP Taschenrechner ausgerechnet hätten > > Bestimmt nicht. Als HP anfing, Taschenrechner zu bauen, wurde das > Apollo-Programm eingestellt. > > Aber sieh dir mal den Film "Apollo 13" an. Das ist der Flug mit der > Explosion an Bord. Da gibt es eine Szene, in der sie in Houston mit > Rechenschiebern die Daten vom Raumschiff nachrechnen. Da hast du recht, und ich lag falsch. Die hatten damals nur einen Rechenschieber und den Kuli für den Notfall. Ich habe ja letztens seit langer Zeit wieder Nachhilfe in Mathe gegeben. Ich habe ganz schön gestaunt, wie ich gesehen habe, dass bei eine Mathe Schularbeit heute gar nicht mehr gerechnet wird! Da gab es nur mehr Verständnisfragen - das Rechnen übernimmt eh das Computerprogram.
> Und wozu? Weil man zu faul oder zu doof ist auf eine Hochsprache zu > wechseln? Nein. Weil man's kann. Und man bei Anwendungen wie z.B. Emulatoren erhebliche Geschwindigkeitszuwächse gegenüber C-Compilaten erreicht. Mir kommt es eher so vor, dass viele Leute sich günstige STM32 Boards zugelegt haben und irgendwie darauf hoffen, dass jemand mal ein anspruchsvolles Projekt veröffentlicht, das auch auf ihrem Board läuft. Jörg
Jens schrieb: > Die TQFP32-STMs haben 0,8mm Pin-Abstand. Das sind mittlerweile auch für mich oft die Favoriten. Auch weil es sowohl kleine M0 (z.B. stm32F042) als auch größere M4 (stm32f334) gibt die auch CAN haben und pinkompatibel sind. Bei den kleinen könnte ST nur etwas mehr Flash spendieren. 32K sind manchmal doch etwas wenig, vor allem in der Debugphase.
Udo K. schrieb: > Ich habe ja letztens seit langer Zeit wieder Nachhilfe in Mathe gegeben. > Ich habe ganz schön gestaunt, wie ich gesehen habe, dass bei > eine Mathe Schularbeit heute gar nicht mehr gerechnet wird! Das war schon vor 30 Jahren so, auch damals hatten wir schon Taschenrechner für das schnöde "Numbercrunching". Gefragt wurde in den Arbeiten auch nicht nach Zahlen sondern eher nach Sachen wie "wo schneidet die Tangente des Wendepunkts die y-Achse in Abhängigkeit von t" oder "zeige daß dieses und jenes gleich ist". Allenfalls in der Physik (also in der angewandten Mathematik wenn man so will) wollte man auch hin und wieder mal konkrete Zahlen als Ergebnis sehen und auch da war ein Taschenrechner selbstverständlich.
Joerg W. schrieb: > Mir kommt es eher so vor, dass viele Leute sich günstige STM32 Boards > zugelegt haben und irgendwie darauf hoffen, dass jemand mal ein > anspruchsvolles Projekt veröffentlicht, das auch auf ihrem Board läuft. Habe ein Funktionsmuster von einem umfangreichen Projekt mittels Bluepill realisiert (inkl. I2C, UART, USB Composite device, Timern für PWM, Timer für WS2812, DMA, FreeRTOS etc.) und das funktioniert einwandfrei. Man kann lästern wie man will, aber mit CubeMX, HAL und FreeRTOS kann man halt schon sehr schnell solche Projekte umsetzen. Für das Endprodukt nehmen wir dann aber einen moderneren, pinkompatiblen STM32F30x.
Das stimmt schon. Aber in dieser Schularbeit gab es auch keinen Rechenweg wie ihn aus meiner Schulzeit kenne (also länger als eine Zeile). Da fand ich auf dem Papier grad mal 1-2 einfache Gleichungen. Das war mehr eine Art von Multiple Choice Test mit hinterlistig gestellten Fragen zum ankreuzen. Der Taschenrechner ist inzwischen durch einen symbolischen Rechner (wie Wolfram Mathematika) auf dem Laptop ersetzt worden. Aber das ist jetzt schon ziemlich offtopic.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.