Ich arbeite im Moment mit einem Atmega328, der aufgrund diverser, nicht umgehbarer floating point Operationen an seine Grenzen stößt und die Berechnungen für die Einstellung eines Messinstruments zu lange dauern. Der wird außerdem nur mit 8MHz betrieben. Ich würde daher gerne langfristig mal auf eine 32 bit Architektur umsteigen. Diese soll nach möglichkeit mit deutlich mehr als 8MHz betrieben werden. Dann wäre es auch nicht so tragisch wenn keine FPU vorhanden ist. Kann mir jemand vielleicht MCUs empfehlen, die von der Peripherie her das gleiche wie der Atmega328 haben (oder mehr) und sich ähnlich einfach handhaben lassen?
Wegen ein paar Floatingpoint Rechnugen fuer eine Anzeige ? Wieviel Updates pro Sekunde benoetigst du ? Mehr als 3 pro Sekunde sind sowieso zu nervoes fuer den Benutzer. Bleib beim ATMega. Allenfalls nicht blockierend programmieren, dann wird's auch schneller.
Conrad J. schrieb: > Kann mir jemand vielleicht MCUs empfehlen, Sieh Dir doch mal die STM32-Serien von ST an.
Flachtroll schrieb: > Wegen ein paar Floatingpoint Rechnugen fuer eine Anzeige ? Wieviel > Updates pro Sekunde benoetigst du ? Mehr als 3 pro Sekunde sind sowieso > zu nervoes fuer den Benutzer. Es geht nicht um anzeigen, sondern um Werte einzustellen für eine Messrampe. Das muss deutlich öfter als 3 mal in der Sekunde passieren.
Eine unendlich oft gestellte Frage hier. Die C/C++ Programmierung sieht erstmal gleich aus, die Peripherie und Core Features machen den Unterschied. Low Level Registerprogrammierung wie bei den AVR geht auch, nur sind die devices viel komplexer und man muss meist mehr einstellen. Dafür gibt es dann viel fertige Unterstützung vom Hersteller oder Drittherstellern.
ESP32 + Arduino und fertig. Was Arduino an Rechenleistung verschenkt bringt der ESP dafür umso reichlicher mit. STMs sind wie das meiste Zeug aktuell Unobtainium, ESP32 gibts als NodeMCU zurzeit problemlos und günstig ($5,20/Stck. und weniger).
moin, ich bin da bei den Teeny's gelandet. der 4.1 ist ein echter hammer. die sind auch unter arduino zu bearbeiten. https://www.pjrc.com/ gruss Horst
Conrad J. schrieb: > Es geht nicht um anzeigen, sondern um Werte einzustellen für eine > Messrampe. Das muss deutlich öfter als 3 mal in der Sekunde passieren. Kann schon sein, aber auch das schafft ein AVR ziemlich zügig. Die größte Begrenzung sitzt meistens vor der Tastatur. Warum nur 8 MHz? 3,3V Betrieb? Die neueren ATXmega können bei 3,3V bis 32MHz, da ist schonmal Faktor 4 kostenlos erreicht. Und last but not least gibt es Festkommaarithmetik, die in vielen Fällen ausreichend und schneller ist.
:
Bearbeitet durch User
Conrad J. schrieb: > Ich arbeite im Moment mit einem Atmega328, der aufgrund diverser, > nicht umgehbarer floating point Operationen an seine Grenzen stößt Das "nicht umgehbar" zweifle ich mal stark an. Floating point scheint zwar auf den ersten Blick das Schweizer Taschenmesser zu sein. Aber bei vielen Ausgabenstellungen reicht auch Integer. Notfalls lang (bis 64 Bit kann der gcc) und/oder als Fixpoint-Arithmetik. Und wenn es um Rampen geht, die kann man auch vorberechnen. > Der wird außerdem nur mit 8MHz betrieben. Er könnte aber mit 16MHz betrieben werden und wäre dann doppelt so schnell. Was spricht dagegen? > Ich würde daher gerne langfristig mal auf eine 32 bit Architektur > umsteigen. Diese soll nach möglichkeit mit deutlich mehr als 8MHz > betrieben werden. Dann wäre es auch nicht so tragisch wenn keine FPU > vorhanden ist. 32 Bit µC sind eine ganz andere Liga. Aber auch die werden entsprechend langsamer, wenn du sie mit Taktfrequenzen weit unter ihren Möglichkeiten betreibst. Und eine floating point Lib ist auch da langsamer als die FPU. > Kann mir jemand vielleicht MCUs empfehlen, die von der Peripherie her > das gleiche wie der Atmega328 haben (oder mehr) und sich ähnlich einfach > handhaben lassen? Gibts nicht. Etwas umlernen mußt du schon. Und im Moment wäre das wichtigste Kriterium wohl ohnehin Verfügbarkeit. Es sei denn, dein "langfristig" von oben meint mehrere Jahre.
Nimm einen Arm-M4 oder. Die haben FPU. Ich mußte auch mal Luftfeuchteberechnungen machen. Das war zwingend notwendig in Floating Point. Und auf dem M0 (ohne FPU) brauchte es doch Rechenzeit, die dann für was anderes fehlte. Aktuell habe ich eine STM H7. Ist aber sehr in der oberen Liga. Dafür angenehm zu benutzen und sehr viel Leistung.
Wenn 3,3V OK sind würde ich mir mal den RP2040 anschauen, den kann man wenigstens kaufen. Mein aktueller Favorit ist der STM32F303, davon habe ich auch genug vorrätig. Aber die gebe ich nicht her.
PittyJ schrieb: > Nimm einen Arm-M4 oder. Die haben FPU. > Ich mußte auch mal Luftfeuchteberechnungen machen. Das war zwingend > notwendig in Floating Point. Wieviel Millionen Berechnungen pro Sekunde waren da nötig, daß man dazu UNBEDINGT ne FPU braucht? > Und auf dem M0 (ohne FPU) brauchte es doch > Rechenzeit, die dann für was anderes fehlte. Glaub ich nicht. > Aktuell habe ich eine STM H7. Ist aber sehr in der oberen Liga. Dafür > angenehm zu benutzen und sehr viel Leistung. Für die faulen und unfähigen Programmierer. Nicht immer, aber oft.
Falk B. schrieb: > Wieviel Millionen Berechnungen pro Sekunde waren da nötig, daß man dazu > UNBEDINGT ne FPU braucht? Das hab ich mich auch gefragt... hier mal mit Nano auf 16Mhz Für 1 berechnungen hat: calc int = 13 berechnet in 4 microSekunde. calc long = 13 berechnet in 4 microSekunde. calc float = 13.00 berechnet in 12 microSekunde. --------- Für 10 berechnungen hat: calc int = 40 berechnet in 4 microSekunde. calc long = 40 berechnet in 8 microSekunde. calc float = 40.00 berechnet in 96 microSekunde. --------- Für 100 berechnungen hat: calc int = 310 berechnet in 4 microSekunde. calc long = 310 berechnet in 4 microSekunde. calc float = 310.00 berechnet in 1064 microSekunde. --------- Für 1000 berechnungen hat: calc int = 3010 berechnet in 4 microSekunde. calc long = 3010 berechnet in 8 microSekunde. calc float = 3010.00 berechnet in 9020 microSekunde. --------- Für 10000 berechnungen hat: calc int = 30010 berechnet in 4 microSekunde. calc long = 30010 berechnet in 4 microSekunde. calc float = 30010.00 berechnet in 97404 microSekunde. selbst bei 1000 Berechnungen brauch er nur 1ms.
Falk B. schrieb: > PittyJ schrieb: >> Nimm einen Arm-M4 oder. Die haben FPU. >> Ich mußte auch mal Luftfeuchteberechnungen machen. Das war zwingend >> notwendig in Floating Point. > > Wieviel Millionen Berechnungen pro Sekunde waren da nötig, daß man dazu > UNBEDINGT ne FPU braucht? Das war eine komplexere Berechnung. Die hatte der Sensorhersteller mit beigelegt. Mit Kompensation zu Temperatur, Druck, Luftfeuchtigkeit und anschliessender Taupunkt Berechnung. Das frickel nicht selber auf Ints um. Wenn sich in der Maschine plötzlich Kondenswasser bildet, will ich nicht Schuld sein. Da nehme ich dann lieber die Originalformeln. Ausserdem mußten gleichzeitig noch diverse andere Dinge stattfinden. An der CPU sind noch ca 12 weitere Sensoren und 3 Kommunikationskanäle. Manche Leute machen mehr, als nur einen Sensor an ihren AVR dranzufädeln. Da nehme ich einen Prozessor mit FPU, und habe meine Ruhe.
PittyJ schrieb: >> Wieviel Millionen Berechnungen pro Sekunde waren da nötig, daß man dazu >> UNBEDINGT ne FPU braucht? > > Das war eine komplexere Berechnung. Die hatte der Sensorhersteller mit > beigelegt. Mit Kompensation zu Temperatur, Druck, Luftfeuchtigkeit und > anschliessender Taupunkt Berechnung. > > Das frickel nicht selber auf Ints um. Ich glaube nicht, das es keine reputable floatin point emulation/library für den avr gibt. Und so ein taupunkt schlägt nicht alle milisekunden um, da ist schon eine Berechnung pro Sekunde mehr als genug. Die NASA hat schliesslich mit Transistorcomputern auch den Mond getroffen.
PittyJ schrieb: > Das war eine komplexere Berechnung. Die hatte der Sensorhersteller mit > beigelegt. Mit Kompensation zu Temperatur, Druck, Luftfeuchtigkeit und > anschliessender Taupunkt Berechnung. > > Das frickel nicht selber auf Ints um. Wenn sich in der Maschine > plötzlich Kondenswasser bildet, will ich nicht Schuld sein. Da nehme ich > dann lieber die Originalformeln. Vollkommen OK. > Ausserdem mußten gleichzeitig noch diverse andere Dinge stattfinden. An > der CPU sind noch ca 12 weitere Sensoren und 3 Kommunikationskanäle. Auch OK. Aber ehe eine 32 BIT CPU, auch wenn es nur ein AMR-M0 ist, in die Knie geht, muss schon einiges passieren. Meistens ist es das schlechte Konzept. > Manche Leute machen mehr, als nur einen Sensor an ihren AVR > dranzufädeln. > Da nehme ich einen Prozessor mit FPU, und habe meine Ruhe. Ja, so machen es leider sehr viele, auch Profis. Keinen Plan, keinen Bock, einfach fette Hardware und Ruhe. Kann man machen, muss man aber nicht gut finden. Lass mich raten. Du hast nicht gemessen und analysiert, WO und WARUM viel CPU-Leistung gebraucht wird.
Conrad J. schrieb: > Es geht nicht um anzeigen, sondern um Werte einzustellen für eine > Messrampe. Für eine Rampe muß man nicht sämtliche Berechnungen bei jedem Einzelschritt vom Urschleim her neu machen. Es reicht, wenn man konstante Operationen aus der Schleife herauszieht und nur das berechnet, was wirklich neu ist.
> Und auf dem M0 (ohne FPU) brauchte es doch > Rechenzeit, die dann für was anderes fehlte. > Wenn 3,3V OK sind würde ich mir mal den RP2040 anschauen, den kann man > wenigstens kaufen. Das ist ein stinkender M0! Es sind sogar zwei stinkende M0! > Mein aktueller Favorit ist der STM32F303, davon habe ich auch genug > vorrätig. Aber die gebe ich nicht her. Das hebt nicht mal Rosemarie Nitribit an. Auch dem fehlt die FPU.
... schrieb: > Das ist ein stinkender M0! Na und? Wenn er vorher mit 8 MHz klar kam sind 133 MHz ein großer Sprung, auch wenn so ein ARM für gleiche Aufgaben ein paar mehr Takte braucht, als AVR. Außerdem hat der TO geschrieben, dass er keine FPU braucht.
Also wenn man auf einem C64 Fraktale berechnet hat, dann ein AVR auch einen poopligen Taupunkt berechnen: https://www.stefanbion.de/fraktal-generator/history.htm
https://www.lcsc.com/product-detail/ST-Microelectronics_STMicroelectronics-STM32G431CBT6_C529355.html Oder einfach zu beschaffen https://www.reichelt.de/raspberry-pi-pico-rp2040-cortex-m0-microusb-rasp-pi-pico-p295706.html?search=rp2040
Conrad J. schrieb: > Kann mir jemand vielleicht MCUs empfehlen, Also meine wahl ist der PSOC5lp weil : * 32 bit / 256MBit * Eingebauter 1x Hohe genauigkeits- deltasigma ADC * Eingebauter 2x SAR ADC * Eingebauter 4xDAC mit Strom/Spannung-ausgang * Eingebauter DC/DC converter speisung ab 0.8V * Speisung bis 5V * Pro port unterschiedliche Vcc moeglich * Viele hardware moeglichkeiten eingebaut (Opamps, 4xDAC Strom/Spannung...) * ... Die unabhangig von controller selber funktionieren koennnen * Flexibele clock-speed moeglichkeiten >> Low power vs High speed * Viele libraries angeboten durch Hersteller * Devboards $10 incl programmer Also viel eingebaute peripherals, nicht viel externe Komponenten benoetigt Nur... was heute oft das problem ist ob die chips jetzt verfuegbar sind (bei viele Hersteller) Patrick aus die Niederlaende
Patrick C. schrieb: > Also meine wahl ist der PSOC5lp weil : ... eierlegende Wollmilchsau .... Ist oft nicht das Mittel der Wahl, weil man das Meiste in einem Projekt gar nicht braucht. Als Experimentierplattform natürlich sehr angenehm.
Falk B. schrieb: > Lass mich raten. Du hast nicht gemessen und analysiert, WO und WARUM > viel CPU-Leistung gebraucht wird. Nö wozu auch. Geplant sind 1000 Einheiten. Kostet eine CPU 5 Euro mehr, weil sie genug Leistung hat, ich aber 2 Monate Entwicklung einspare, dann hat die Firma mehr verdient als durch eine Spar-CPU. Und da nehme ich die CPU, die ich schon kenne, selbst wenn die 50 Prozent überdimensioniert ist. Da kenne ich alle Probleme, die Arbeitsumgebung ist eingerichtet, die API vertraut. Da analysiere ich keinen Monat, ob ich evtl 1/3 Flash weniger brauche, und nehme dann was unbekanntes mit alles Risiken.
Falk B. schrieb: > Ist oft nicht das Mittel der Wahl, weil man das Meiste in einem Projekt > gar nicht braucht. Fuer die art der Projekten die ich mache ist er ja super. Ich design auf maximaler version, wenn design fertig kann ich noch wenn noetig preisweter machen mittels pin-compatible version der weniger resourcen hat. Jetzt musz ich sagen das bei meine Projekten die stuckzahl wenig ist und die Kosten 90% gemacht werden waerend entwicklung, nicht warende die Produktion. Dann ist ein Flexibeler Processor mit viel resources prima. Patrick aus die Niederlaende
Patrick C. schrieb: > Also meine wahl ist der PSOC5lp weil : > * 32 bit / 256MBit > * Eingebauter 1x Hohe genauigkeits- deltasigma ADC > * Eingebauter 2x SAR ADC > * Eingebauter 4xDAC mit Strom/Spannung-ausgang > * Eingebauter DC/DC converter speisung ab 0.8V > * Speisung bis 5V > * Pro port unterschiedliche Vcc moeglich > * Viele hardware moeglichkeiten eingebaut (Opamps, 4xDAC > Strom/Spannung...) Sigma-Delta und interner DC/DC. Dachte immer, sowas schließt sich von selbst aus. Ansonsten is das schon ganz schön krass, wass der an Bord hat.
PittyJ schrieb: >> Lass mich raten. Du hast nicht gemessen und analysiert, WO und WARUM >> viel CPU-Leistung gebraucht wird. > > Nö wozu auch. Geplant sind 1000 Einheiten. Kostet eine CPU 5 Euro mehr, > weil sie genug Leistung hat, ich aber 2 Monate Entwicklung einspare, > dann hat die Firma mehr verdient als durch eine Spar-CPU. Das war gar nicht das Thema. Sondern deine Aussage Beitrag "Re: 32 Bit MCU gesucht" "Nimm einen Arm-M4 oder. Die haben FPU. Ich mußte auch mal Luftfeuchteberechnungen machen. Das war zwingend notwendig in Floating Point. Und auf dem M0 (ohne FPU) brauchte es doch Rechenzeit, die dann für was anderes fehlte." Mein Einwand war und ist "Wieviel Millionen Berechnungen pro Sekunde waren da nötig, daß man dazu UNBEDINGT ne FPU braucht?" > Und da nehme ich die CPU, die ich schon kenne, selbst wenn die 50 > Prozent überdimensioniert ist. Da kenne ich alle Probleme, die > Arbeitsumgebung ist eingerichtet, die API vertraut. Du lenkst vom Thema ab. Es ging nie darum, eine andere CPU-Architektur zu nutzen. > Da analysiere ich keinen Monat, ob ich evtl 1/3 Flash weniger brauche, > und nehme dann was unbekanntes mit alles Risiken. Auch darum ging es nicht. Sondern um deine gewagte Aussage, daß für eine Luftfeuchteberechung eine FPU nötig ist. Und meine Frage, ob du jemals gemessen oder analysiert hast, wo wieviel Leistung verbraten wird, da ja nach deiner Aussage die Berechnung per Software Fließkomma zu langsam war.
Falk B. schrieb: > Auch darum ging es nicht. Sondern um deine gewagte Aussage, daß für eine > Luftfeuchteberechung eine FPU nötig ist. Und meine Frage, ob du jemals > gemessen oder analysiert hast, wo wieviel Leistung verbraten wird, da ja > nach deiner Aussage die Berechnung per Software Fließkomma zu langsam > war. Wie schon gesagt, auf der CPU war auch schon sonst viel zu tun. Und da brauche ich es nicht, dass sie in der FPU-Emulation herumhängt. Für eine 2 Berechnung (Farbkorrektor HLS) habe ich Teile schon in einen Low Prio Thread verpackt, damit die Kommunikation besser reagieren konnte. Damit steigt aber die Komplexität und Fehleranfälligkeit. Das war eine M0 ohne FPU. Da freut man sich über eine STM M7 mit FPU. Das ist entspannter.
PittyJ schrieb: > Da freut man sich über eine STM M7 mit FPU. Das ist entspannter. Man wählt keinen komplexen H7 von ST um Entwicklungszeit zu sparen. Das ist ziemlich absurd. Wenn es ein Cortex M4 ohne komplexes Caching wäre, hätte ich das abgekauft.
PittyJ schrieb: > Wie schon gesagt, auf der CPU war auch schon sonst viel zu tun. Und da > brauche ich es nicht, dass sie in der FPU-Emulation herumhängt. Du kannst deine Aussage nicht begründen. Punkt. > Für eine 2 Berechnung (Farbkorrektor HLS) habe ich Teile schon in einen > Low Prio Thread verpackt, damit die Kommunikation besser reagieren > konnte. Damit steigt aber die Komplexität und Fehleranfälligkeit. > Das war eine M0 ohne FPU. > Da freut man sich über eine STM M7 mit FPU. Das ist entspannter. Das kann jeder Depp.
Falk B. schrieb: > PittyJ schrieb: >> Wie schon gesagt, auf der CPU war auch schon sonst viel zu tun. Und da >> brauche ich es nicht, dass sie in der FPU-Emulation herumhängt. > > Du kannst deine Aussage nicht begründen. Punkt. Warum auch. Mein Chef ist zufrieden. Die Firma macht gut Gewinn. Mein Haus ist abbezahlt. Die Geräte laufen 24/7 ohne Probleme, keine Ausfälle. Was will ich mehr? Nur mir noch beweisen dass es auch mit einem Atmel328 gehen würde? Da habe ich besseres zu tun.
PittyJ schrieb: >> Du kannst deine Aussage nicht begründen. Punkt. > > Warum auch. Also mal wieder nur substanzloses Geplapper. Moderne Märchen erzählen, aka urban legend. Spiel, Satz, Sieg.
Falk B. schrieb: > PittyJ schrieb: >>> Du kannst deine Aussage nicht begründen. Punkt. >> >> Warum auch. > > Also mal wieder nur substanzloses Geplapper. Moderne Märchen erzählen, > aka urban legend. Spiel, Satz, Sieg. Mit solchen Kindereien bist du für mich der größte Looser auf dem Platz. Kein Fachwissen der Welt kann soviel Arroganz und Großkotzigkeit aufwiegen.
J. S. schrieb: >> Also mal wieder nur substanzloses Geplapper. Moderne Märchen erzählen, >> aka urban legend. Spiel, Satz, Sieg. > > Mit solchen Kindereien bist du für mich der größte Looser auf dem Platz. > Kein Fachwissen der Welt kann soviel Arroganz und Großkotzigkeit > aufwiegen. Ein hohes Niveau sieht nur von unten wie Arroganz aus. ;-) Im Ernst. Wenn einer eine Behauptung aufstellt, muss er sie auch sinnvoll begründen können. Erst recht bei "gewagten" Behauptungen. "Extraordinary claims require extraordinary proof." wie die Angelsachsen so schön sagen. Haltlose Behauptungen gibt es im Internet schon genug.
:
Bearbeitet durch User
es geht doch gar nicht darum ob jemand (der sich mit H7 herumschlägt) nicht auch einen Mega328 programmieren könnte. Der TO wollte mehr Power und die AVR haben ihr Limit, auch wenn es nicht ein paar float Berechnungen sind. Nur muss man sich in die 32 Bit Welt auch einarbeiten, und wenn ein Cortex-M da überdimensioniert erscheint, dann ist das trotzdem ist eine gute Übung zum Einstieg. Ich mag diese Kleingeistigkeit nicht. Für 3D Drucker haben die 8 Bitter die Entwicklung nur blockiert. Als man Marlin noch für jede Einstellung neu kompilieren musste, konnte Smoothieware auf dem 32 Bit LPC1769 schon lange SD Karten einlesen und darüber konfiguriert werden. Und per Ethernet gefüttert werden. Mal so als Beispiel. In jede Controller Architektur muss man sich erstmal einarbeiten und ist wieder blutiger Anfänger. Bei den CM reicht das aber für lange lange Zeit bis man DMA, Ethernet, USB, schnelle Displays usw. ausgereizt hat. Da sind 8 Bitter schon lange abgehängt. Aktuell habe ich eine Kiste mit 17x H7 vor mir. Ich kann den Kollegen ja mal sagen das sie nicht programmieren können und das gefälligst mit Mega328 bauen sollen.
Falk B. schrieb: > Ja, so machen es leider sehr viele, auch Profis. Keinen Plan, keinen > Bock, einfach fette Hardware und Ruhe. Kann man machen, muss man aber > nicht gut finden. Profis können rechnen 5€ mehr für die CPU oder 50 Stunden frickeln. Wie viele Stück muss man kaufen, dass sich das Frickeln lohnt: Profi = 200€/h*50h/5€/Stück = 2000 Stück Falk B. = 0€/h*50h/5€/Stück = 0 Stück
Karl schrieb: >> Ja, so machen es leider sehr viele, auch Profis. Keinen Plan, keinen >> Bock, einfach fette Hardware und Ruhe. Kann man machen, muss man aber >> nicht gut finden. > > Profis können rechnen 5€ mehr für die CPU oder 50 Stunden frickeln. Wie > viele Stück muss man kaufen, dass sich das Frickeln lohnt: Jaja, das Gelaber. Mein Gott. Geh mal davon aus, daß ich weiß, was eine Aufwandsabschätzung und Gewinnschwelle ist. https://de.wikipedia.org/wiki/Gewinnschwelle Und geh mal davon aus, daß auch ich weiß, daß bei Einzelstücken oder kleinen Stückzahlen die Entwicklungskosten die Materialkosten um Größenordnungen übersteigen. Ich mache Entwicklung, jeden Tag. Das war aber gar nicht das Thema der Diskussion. Aber auch für dich "Blitzmerker" nochmal langsam. Der Op meint, seine Berechnungen sind zu langsam und er hätte gern mehr CPU Power. Der Op ist ein Bastler, Gewinnschwelle und Kosten sind bedeutungslos. PittyJ stellt eine Behauptung auf, die er keine Sekunde belegen kann. Nix als Ausreden und Ablenkung. So wie bei dir. Auch nix Neues, wenn Leute keine Argumente mehr haben.
Moin, - Conrad J. schrieb: > Ich arbeite im Moment mit einem Atmega328, der aufgrund diverser, nicht > umgehbarer floating point Operationen an seine Grenzen stößt und die > Berechnungen für die Einstellung eines Messinstruments zu lange dauern. > Der wird außerdem nur mit 8MHz betrieben. Das haben ja alle schon gesagt: Man kann auch mit der Frequenz nach oben gehen, aber vielleicht Faktor 3. > Ich würde daher gerne langfristig mal auf eine 32 bit Architektur > umsteigen. Diese soll nach möglichkeit mit deutlich mehr als 8MHz > betrieben werden. Dann wäre es auch nicht so tragisch wenn keine FPU > vorhanden ist. > > Kann mir jemand vielleicht MCUs empfehlen, die von der Peripherie her > das gleiche wie der Atmega328 haben (oder mehr) und sich ähnlich einfach > handhaben lassen? Natuerlich ist ein STM32 schon ein ganz anderes Biest, mehr omphf!, mehr Moeglichkeiten. Ob Du diese Moeglichkeiten brauchst kannst nur Du entscheiden. 1) STM32 et al. haben 3.3V Technologie, d.h es kann sein, dass Du Deine Peripherie anpassen musst, 2) STM32 et al. haben die Moeglichkeit des InCircuit Debuggings, d.h. Du kannst in Deinem Code einen Breakpont setzen und Register/Variablen anzeigen. Das ist DIE Erfindung/Verbessung schlecht hin. Selbst wenn Du einen neuen orginalen ST/Link kaufst, die Lebenszeit die Du mit diese Debugging-Moeglichkeit gewinnst ist unglaublich. Gruesse Th.
Thomas W. schrieb: > 1) STM32 et al. haben 3.3V Technologie, d.h es kann sein, dass Du Deine > Peripherie anpassen musst, wobei die meisten Eingänge 5V tolerant sind. Und wenn die Bastler bei 3,3 V angekommen sind (was die meiste Peripherie heute schon erwartet und nur in Arduino Shields hin- und her gewandelt wird), ist die Welt schon bei 2,5 oder 1,8 V. Thomas W. schrieb: > die Lebenszeit die Du mit diese > Debugging-Moeglichkeit gewinnst ist unglaublich. full ack, aber auch hier verteidigen die Frickler ihr Serial.print() debugging vehemment.
Moin, - ich wollte nur darauf hinweisen, dass der STM32 eine 3v3-Maschine ist. Ob das ein Unterschied macht weiss nur der TO. Beim Debugging: ca. 1990 war das Debugging beim PC ungefaehr wie beim Arduino, bei TurboPascal halt mit PrintLN(). Fuer normales Geld hatte man nix anderes. Als ich (ca. 1993) eine VAX (mit VMS) gesehen hatte (mit dem VAX Debugger) dachte ich: Das ist das Endziel: Sprachen-unabhaengig, Source-code beim Debug zu sehen (step-In, Step-out, Breakpoints), automatisieren von Ablaeufen. Ich war komplett begeistert. OK, 2022: Eclipse mit Debugger ist ungefaehr das. Ein ST-Link-Clone kostet keine 5EUR und spart richtig Lebenszeit. Ich will das nicht mehr missen. Gruesse Th. P.S.: Komplett bloed, aber ein Song ueber den besten Debugger (in 1993): https://catonmat.net/ftp/mark_wheadon-just_one_more_hack.mp3 Ein paar Warme Worte: https://catonmat.net/musical-geek-friday-just-one-more-hack Schon lange her
Ich werfe mal einen neuen Kandidaten ins Feuer - ATSAMC20. Ja, Chipkrise und so, aber Digikey hat erstaunlicherweise gerade ATSAMC21E18A-AUT ab Lager: https://www.digikey.de/de/products/detail/microchip-technology/ATSAMC21E18A-AUT/5875967 Das ist ein Cortex M0+, 48MHz, läuft 2,7V bis 5V, Peripherie bis unters Dach, auf funktionale Sicherheit ausgelegt und der kleinste "E" ist im gleichen Gehäuse wie der Mega328. Und theorethisch gibt es in der Familie zig Varianten, so 48, 64, 100 Pins, weniger Speicher. Der Unterschied zwischen ATSAMC20 und ATSAMC21 ist, der C21 hat CAN-FD, beim 32er Pin 1 Kanal, ab 64 Pins zwei Kanäle. Dabei fällt mir das hier ein: https://github.com/RudolphRiedel/SAMC21_one/blob/master/04_Hardware/SAMC21_one/SAMC21_one.PDF Das liegt hier noch, aber inzwischen benutze ich hauptsächlich die "J" Version mit 64 Pins und 2 CAN-Kanälen. Oder den dickeren ATSAME51J (der nicht zu bekommen ist), der ist bis auf einen Pin kompatibel zum C21J und ist ein Cortex M4F mit noch mehr Peripherie. Ich bin da ran, weil ich vor ein paar Jahren die Notwendigkeit gesehen habe im Job CAN-FD unterstützen zu müssen. Und eine Alternative zu denen ist mir immer noch nicht in die Finger gekommen.
:
Bearbeitet durch User
Axel S. schrieb: >> Der wird außerdem nur mit 8MHz betrieben. > > Er könnte aber mit 16MHz betrieben werden und wäre dann doppelt so > schnell. Was spricht dagegen? nein, sogar mit 20 Mhz
>2) STM32 et al. haben die Moeglichkeit des InCircuit Debuggings, d.h. Du >kannst in Deinem Code einen Breakpont setzen und Register/Variablen >anzeigen. Das ist DIE Erfindung/Verbessung schlecht hin. Selbst wenn Du >einen neuen orginalen ST/Link kaufst, die Lebenszeit die Du mit diese >Debugging-Moeglichkeit gewinnst ist unglaublich. Das haben die AVRs allerdings auch. Nur brauchst du dort keinen ST-Link sondern einen Atmel-ICE o.ä.
PittyJ schrieb: > ich aber 2 Monate Entwicklung einspare, > dann hat die Firma mehr verdient als durch eine Spar-CPU. Oder Du wunderst Dich, warum die Super-Duper CPU genau so langsam ist, weil Du den Flaschenhals nicht beseitigt hast. Ein Profiling, wo es klemmt, kostet keine 2 Monate. Oftmals erreicht man durch simples Umstellen des Programmablaufs mehr Optimierung, als durch stupide Erhöhung der CPU-Frequenz und damit des Stromverbrauchs.
Thomas W. schrieb: > ca. 1990 war das Debugging beim PC ungefaehr wie beim > Arduino, bei TurboPascal halt mit PrintLN(). Das stimmt nicht. Die Turbo Pascal IDE von Borland aus dem Jahr 1990 hatte einen richtigen Debugger. http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_6.0_Users_Guide_1990.pdf
Stefan ⛄ F. schrieb: > Thomas W. schrieb: >> ca. 1990 war das Debugging beim PC ungefaehr wie beim >> Arduino, bei TurboPascal halt mit PrintLN(). > > Das stimmt nicht. Die Turbo Pascal IDE von Borland aus dem Jahr 1990 > hatte einen richtigen Debugger. > > http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_6.0_Users_Guide_1990.pdf OK, ich hatte bei TP 3 aufgehoert. Und da war das Debugging nicht so fortschrittlich... Vielleicht war es auch schon/erst 1986 (Zeitzeugen sind nicht die besten Zeugen) Gruesse Th.
Wie lange braucht eigentlich ein 32Bitter mit 200MHz für delay_1ms() gegenüber einem 8Bitter an 8MHz? Ohne Profiling ist der Griff zu einer schnelleren CPU komplett sinnlos.
Christoph M. schrieb: > Thomas W. schrieb: >> 2) STM32 et al. haben die Moeglichkeit des InCircuit Debuggings, d.h. Du >> kannst in Deinem Code einen Breakpont setzen und Register/Variablen >> anzeigen. Das ist DIE Erfindung/Verbessung schlecht hin. Selbst wenn Du >> einen neuen orginalen ST/Link kaufst, die Lebenszeit die Du mit diese >> Debugging-Moeglichkeit gewinnst ist unglaublich. > Das haben die AVRs allerdings auch. Moin, jein... Natürlich gibt es beim AVR auch InCircuit Debugging. Die Arm CoreSight Unit der Cortex-M bietet aber deutlich mehr Debugging Features und manche können ohne Einfluss auf die Ausführungsgeschwindigkeit der Applikation genutzt werden (z.B. Data Breakpoints). Gruß, Michael
GigaDevice GD32VF. Ist auch sanktionssicher, und verfügbar. Video zum Einstieg unter https://www.youtube.com/watch?v=XZvkdkvxgSs. Bei Fragen kannst du mich auch anschreiben (PN hier im Forum).
Rudolph R. schrieb: > Ich werfe mal einen neuen Kandidaten ins Feuer - ATSAMC20. Dem kann ich nur zustimmen. Bei mir verlief der Umstieg vom ATmega32m1 auf den ATSAMC20, aufgrund des selben Herstellers, der selben Tool, ähnlicher Datenblätter etc., recht gut.
Ingo Less schrieb: > Sigma-Delta und interner DC/DC. Dachte immer, sowas schließt sich von > selbst aus. Man braucht es nicht beiden zu nutzen, in mein Projekt benutze ich DCDC um spannung flexibel anzubieten (wegen stromverbrauch). Auch processorclock wird zwischen 3MHz und 48MHz hin und her gesetzt. Da alles integriert ist kan man 'einfach' der delta-sigma synchronisieren mit frequenz von DC/DC oder sogar DC/DC ausschalten waehrend der messung und danach wieder einschalten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.