Hallo Forumsgemeinde, ich habe privat einige Projekte mit atmega32 ausgeführt (Hardware Arduino Nano) und bin sehr zufrieden. Nun stelle ich fest, dass ich für die Weiterentwicklung des letzten Projektes ZWEI 16-Bit Timer/ Counter benötige, die die 8-Bit Prozessoren von AVR scheinbar nicht haben. --> http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR Was tun? Ich würde gerne - auch perspektivisch - auf 32bit gehen und dann auch auf eine Cortex-Mx Architektur, aber ich vermute viel Einarbeitungszeit und zu zahlendes Lehrgeld, bis ich auf dem Stand bin, den ich jetzt bei den Atmel Prozessoren habe, auch wenn der Stand nicht gerade hoch ist. Der deutschsprachige Support ist dünner als bei den AVR, Beispielcode auch. Ausserdem scheint jeder Hersteller seine Extralocke um die Architektur zu stricken. Frage: 1) Wie lange dauerte der Umstieg typischerweise bei Euch von AVR atmega32 auf z.B. STM32F4 (nur IDE einrichten, Chip initialisieren, ADC auslesen, Ports setzen, timer/ counter mit Interruptaufruf, Umschreiben von ca. 600 Zeilen linearem C-Code), 1 Tag, 1 Woche, 1 Monat? 2) Ist der Umstieg bei ARM Cortex-Mx von z.B. ST auf Freescale dann auch nochmal eine Hürde oder sind die Unterschiede zwischen der Herstellern der gleichen Architektur eher gering? Danke für Eure Einschätzung Umsteiger
2x 16 Bit Timer findest du bei vielen 8-Bit AVRs. Nur weil dein grottenalter Mega32 die nicht hat, solltest du keine falschen Schlüsse ziehen. Schau mal in Richtung Mega1284. Aber auch viele kleinere Kaliber haben mindestens 3 Timer (2 davon 16 Bit). Dazu 2x UART und/oder 2x SPI sind keine Seltenheit. Schau dir mal die parametrische Suche auf der Atmel Seite an.
:
Bearbeitet durch User
Umsteiger schrieb: > Nun stelle ich fest, dass ich für > die Weiterentwicklung des letzten Projektes ZWEI 16-Bit Timer/ Counter > benötige, die die 8-Bit Prozessoren von AVR scheinbar nicht haben. Z.B. der ATmega2560 hat 4 16Bit-Timer mit je 3 PWM-Ausgängen. Als DIP mit 2 16Bit Timern gibt es den ATmega162 und den ATmega1284.
okay, da lag ich wohl daneben. Und den ATmega2560 scheint es sogar noch als preiswertes Board bei Arduino zu geben. Danke für Eure Hinweise, doch_nicht_Umsteiger, jedenfalls jetzt noch nicht.
@ Umsteiger (Gast) >doch_nicht_Umsteiger, jedenfalls jetzt noch nicht. Vor allem wäre ich mit der Aussage "AVR atmega328 ausgereizt" vorsichtig. Denn das hast du mit hoher Wahrscheinlichkeit NICHT! Um die AVRs wirklich AUSZUREIZEN muss man schon EINIGES machen. Wofür brauchst du den 2. 16 Bit Zähler?
Alternativ Xmega-Reihe. Die haben richtig viel Peripherie, sind aber hier im Forum scheinbar nicht so beliebt... Ob es die im Arduinoformat gibt, weiß ich leider nicht.
Umsteiger schrieb: > Nun stelle ich fest, dass ich für > die Weiterentwicklung des letzten Projektes ZWEI 16-Bit Timer/ Counter > benötige, die die 8-Bit Prozessoren von AVR scheinbar nicht haben. Das stimmt erstens sowieso nicht (Gegenbeispiele, die ich auf Anhieb aus dem Kopf weiss: ATMega1284P, ATTiny441, ATTiny841, die haben allesamt zwei 16Bit-Timer) und zweitens ist es praktisch immer möglich, einen 8Bit-Timer durch Software auf 16 oder mehr Bit zu erweitern. Man muß halt einfach nur programmieren und Datenblätter lesen können. Wenn du also irgendwas ausgereizt hast, dann nur die Grenzen deiner diesbezüglichen Fähigkeiten, nicht aber die der AVR8... > Was tun? Lernen. Das kann auch nicht schaden, wenn du irgendwann in ferner Zukunft tatsächlich mal so weit bist, dass du an die Grenzen der AVR8 stößt. Bei den größeren Eisen wird es nämlich keinesfalls einfacher, sondern nur noch viel komplexer.
@ Felix Adam (Firma: SOMTRONIK) (madifaxle) >Alternativ Xmega-Reihe. Die haben richtig viel Peripherie, Stimmt, die haben DEUTLICH mehr sind aber dennoch sehr ähnlich in der Nutzung. >sind aber hier im Forum scheinbar nicht so beliebt... Naja, der Zuwachs an Power ist halt nicht sooo groß wie bei den 32 Bittern. Ich hab trotzdem einen erfolgreich in einem Projekt eingestzt und musste mich nur wenig um den neuen Controller kümmern, der Übergang war sehr angenehm. Beitrag "Re: Viel RAM am kleinen Controller" >Ob es die im Arduinoformat gibt, weiß ich leider nicht. AFAIK nein.
Falk B. schrieb: > @ Umsteiger (Gast) > >>doch_nicht_Umsteiger, jedenfalls jetzt noch nicht. > > Vor allem wäre ich mit der Aussage "AVR atmega328 ausgereizt" > vorsichtig. Denn das hast du mit hoher Wahrscheinlichkeit NICHT! Um die > AVRs wirklich AUSZUREIZEN muss man schon EINIGES machen. > > Wofür brauchst du den 2. 16 Bit Zähler? Hallo Falk B. es gibt vermutlich kein Projekt, dass alle Fähigkeiten eines AVR gleichzeitig ausreizt, aber mit dem zweiten 16 bit Counter schien ich an dieser Stelle angekommen zu sein. Auch habe ich mich verlassen auf die Aussage im AVR Tutorial (Link oben): "...Alle AVR-Modelle verfügen über mindestens einen, teilweise sogar zwei, 8-Bit Timer. ..." Danach in der Tabelle, in der nur ein 16 Bit Timer aufgeführt werden. Anscheinend gibt es aber doch eine ganze Menge AVRs mit mehr als einem 16 bit Timer. Ich benötige die Timer als Zähler in einem Frequenzumrichter, wie er hier im Forum vorgestellt wurde (Axel Jeromin?). Durch den 8 Bit Timer läßt sich die Frequenz des Drehfeldes am FU nicht so fein einstellen, wie ich es mir gewünscht hätte. Ein 16 Bit Timer/Counter wäre da hilfreich gewesen. Abhilfe scheint ja ein Atmega2560 zu sein, auf einem Arduino Board. Sorry noch mal an alle Liebhaber von AVR Prozessoren. Umsteiger
Umsteiger schrieb: > es gibt vermutlich kein Projekt, dass alle Fähigkeiten eines AVR > gleichzeitig ausreizt Da hast du vermutlich Recht, wobei ich mir bezüglich der ganz kleinen ATTinys hier nicht so ganz sicher wäre. Ich finde in meinem Projektverzeichnis jedenfalls mehrere Projekte, die die Dinger doch recht grenzwertig ausnutzen. Aber tatsächlich bleibt immer mindestens eine wesentliche Funktionalität, die nicht oder nur unvollständig genutzt wird, also Reserven läßt. Was aber sicher ist: Wenn es ein solches Projekt geben sollte, dann ist es ganz sicher ein Assemblerprojekt und kein C-Projekt... Das mußt du begreifen. Mit C läßt du immer Potential der Hardware brach liegen. Der Fluch der Abstraktionen.
Umsteiger schrieb: > Ich benötige die Timer als Zähler in einem Frequenzumrichter, wie er > hier im Forum vorgestellt wurde (Axel Jeromin?). Durch den 8 Bit Timer > läßt sich die Frequenz des Drehfeldes am FU nicht so fein einstellen, > wie ich es mir gewünscht hätte. Es ist doch kein Problem aus einem 8 bit Timer einen 16 bit Timer zu machen. Du musst doch nur ein wenig Bits schubsen/schieben. Das ist doch kein Ding.
Felix A. schrieb: > Alternativ Xmega-Reihe. Wobei die Peripherie über große Strecken schon so viel anders ist, dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen kann. Im Arduino-Format bekommt man sie dann obendrein ebenfalls.
Jörg W. schrieb: > dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen > kann. Jo, wenn man die Zeit hat, sich in 1001 Seiten ARM-Lektüre einzulesen. Und das ist nur das Datenblatt :-/. Ganz zu schweigen von der völlig anderen Architektur. Jörg W. schrieb: > Wobei die Peripherie über große Strecken schon so viel anders ist, Nicht wirklich. Nur umfangreicher und aufgeräumt, DMA-tauglich und Event-System unterstützt. Trotzdem sehr übersichtlich, im positiven Sinn.
Umsteiger schrieb: > Und den ATmega2560 scheint es sogar noch > als preiswertes Board bei Arduino zu geben. und der Arduino mighty 1284p ist viel schlanker mit doppelt so viel SRAM. http://www.ebay.de/itm/Mighty-Mini-ATMega1284p-compatible-with-Arduino-/331463717483?hash=item4d2cc6f26b:g:o1IAAOSw34FVDM6K
Für mich interessanter Thread. Mich würde das auch interessieren, auf welche 32Bitter man am einfachsten umsteigen kann, wenn man vorher Atmegas und XMegas programmiert hat. Wenn es nämlich in Richtung DSP und Bildverarbeitung geht, da wird es mit den 8Bittern eng. ...Im Prinzip gibts ja überall ein Datenblatt, das man lesen kann, aber mich würde es auch interessieren, welche 32Bitter man am "einfachsten" ansprechen kann. mfg
Michael K. schrieb: > Du musst doch nur ein wenig Bits schubsen/schieben. Das ist doch kein > Ding. Jetzt ist mein Interesse geweckt. Jedes mal in einer ISR an einer Variablen rum fummeln oder was?
Bahnfahrer schrieb: > Jörg W. schrieb: >> dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen >> kann. > > Jo, wenn man die Zeit hat, sich in 1001 Seiten ARM-Lektüre einzulesen. Du übertreibst. Das Datenblatt eine SAMD20 ist 700 Seiten lang. Im Gegensatz zum Xmega mit seiner unsäglichen Trennung in XmegaA und XmegaA1 (welches in vielen Kapiteln so tut, als würde es zum Thema was schreiben, um dann nur jeweils eine Seite „Schlagzeilen“ zu liefern) und im Gegensatz zur Cortex-Konkurrenz, die ihre Daten auf ein halbes Dutzend Dokumente verteilt, hat man wenigstens wieder alles in einem Dokument, wie seinerzeit beim AVR schon. Wobei mir gar nicht ganz klar ist, warum das eigentlich 700 Seiten verschlingt, während XmegaA mit 430 auskommt – rein gefühlt finde ich den XmegaA komplexer. > Und das ist nur das Datenblatt :-/. Ganz zu schweigen von der völlig > anderen Architektur. Was interessiert dich in C die Prozessorarchitektur so großartig? Ob der Compiler nun zum Addieren einer 32-Bit-Zahl 2 x 4 8-Bit-Register oder 2 32-Bit-Register beladen muss, kann mir in der Hochsprache recht egal sein. Eigentlich interessieren dich in erster Linie die Peripherals, das Einschalten des richtigen Systemtakts etc. pp. Das ist bei beiden, Xmega und SAMDxx, im Vergleich zur Einfachheit des AVR ein ziemlicher Schritt. > Jörg W. schrieb: >> Wobei die Peripherie über große Strecken schon so viel anders ist, > > Nicht wirklich. Finde ich schon. Nicht unangenehm, aber eben so weit anders, dass man erstmal wieder für jeden Schritt ins Datenblatt gucken muss. > Nur umfangreicher und aufgeräumt, DMA-tauglich und > Event-System unterstützt. Trotzdem sehr übersichtlich, im positiven > Sinn. Genau das ist sie aber bei den SAMDxx ebenfalls. DMA gibt's erst ab SAMD21. Der einzige wirkliche Mehraufwand, den man beim SAMDxx im Vergleich zu den Xmegas hat ist, dass man sich einen Plan über die so genannten generic clock generators vorher machen muss, also festlegen, welche Baugruppe mit welchem Takt arbeitet.
@ Umsteiger (Gast) >> Wofür brauchst du den 2. 16 Bit Zähler? >es gibt vermutlich kein Projekt, dass alle Fähigkeiten eines AVR >gleichzeitig ausreizt, Darum geht es nicht. Aber darum, aus einer gegebenen Hardware richtig viel rauszuholen. Das schafft man vor allem nur mit den richtigen Konzepten und Erfahrung. >Ich benötige die Timer als Zähler in einem Frequenzumrichter, wie er >hier im Forum vorgestellt wurde (Axel Jeromin?). Durch den 8 Bit Timer >läßt sich die Frequenz des Drehfeldes am FU nicht so fein einstellen, >wie ich es mir gewünscht hätte. Ein 16 Bit Timer/Counter wäre da >hilfreich gewesen. Kann sein, kann aber auch das falsche bzw. suboptimale Konzept sein. Denn ein Umrichter arbeitet meist mit konstanter PWM-Frequenz, damit hat man schon mal die grundlegende Zeitbasis (die auch ein 8 Bit TImer problemlos erzeugen kann). Den Rest macht man mit cleveren Konzepten, hier wahrscheinlich DDS. Damit kann man nahezu unbegrenzt fein die Frequenz einstellen. > Abhilfe scheint ja ein Atmega2560 zu sein, auf einem > Arduino Board. Mach mal. >Sorry noch mal an alle Liebhaber von AVR Prozessoren. Warum? Du hast keinen beleidigt, nur dich ein wenig weit aus dem Fenster gelehnt ;-)
@ Bahnfahrer (Gast) >> dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen >> kann. >Jo, wenn man die Zeit hat, sich in 1001 Seiten ARM-Lektüre einzulesen. >Und das ist nur das Datenblatt :-/. Ganz zu schweigen von der völlig >anderen Architektur. EBEN! >> Wobei die Peripherie über große Strecken schon so viel anders ist, >Nicht wirklich. Nur umfangreicher und aufgeräumt, DMA-tauglich und >Event-System unterstützt. Trotzdem sehr übersichtlich, im positiven >Sinn. Meine Rede! Daumen hoch! Beim "Umstieg" vom AVR auf Xmega bekommt man ein gutes Stück mehr Leistung für wenig Einarbeitungsaufwand! Beitrag "Re: AVR atmega328 ausgereizt? Und nun? 32bit?"
@Joachim B. (jar) >> Und den ATmega2560 scheint es sogar noch >> als preiswertes Board bei Arduino zu geben. >und der Arduino mighty 1284p ist viel schlanker mit doppelt so viel >SRAM. Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar. Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel Programm hat. 256kB kriegt man nur mit Workarounds hin, keinesfalls direkt per Arduino-Style! Beitrag "Re: Fehlermeldung Arduino C++"
Falk B. schrieb: > Beim "Umstieg" vom AVR auf Xmega bekommt man ein gutes Stück mehr > Leistung für wenig Einarbeitungsaufwand! Naja, Falk, das ist bei den Cortexen aber auch nicht so viel anders, insbesondere nicht, wenn man bei Atmel bleibt. Wer den Umstieg von MegaAVR auf Xmega als einfach empfindet, der wird auch kein Problem mit so einem SAMDxx haben.
Falk B. schrieb: > Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar. > Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel > Programm hat. Ich denke, dass du hier zu sehr verallgemeinerst. Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein (einschließlich Vorzeichen, schließlich ist foo[-1] ein gültiger Ausdruck), und bei GCC muss das wohl auch alles mit char*-Arithmetik machbar sein. Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den Code. > 256kB kriegt man nur mit Workarounds hin, keinesfalls > direkt per Arduino-Style! Warum eigentlich nicht? Programme mit mehr als 128 KiB funktionieren ja nun schon seit Jahren, warum bei Arduino dann nicht?
@ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> Beim "Umstieg" vom AVR auf Xmega bekommt man ein gutes Stück mehr >> Leistung für wenig Einarbeitungsaufwand! >Naja, Falk, das ist bei den Cortexen aber auch nicht so viel anders, >insbesondere nicht, wenn man bei Atmel bleibt. Kann sein, die SAMD hab ich noch nicht angeschaut. >Wer den Umstieg von MegaAVR auf Xmega als einfach empfindet, der wird >auch kein Problem mit so einem SAMDxx haben. Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für einfachse IO-Konfifiguration machen muss!!! Beispiel gefällig? https://www.mikrocontroller.net/articles/Datenuebertragung-STM32F4
1 | void GPIO_initialisieren(void){ |
2 | |
3 | /* Senddata (Daten) */
|
4 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
5 | // Ports als Output definieren
|
6 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3; // Pins 0,1,2,3 aktivieren |
7 | GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull |
8 | GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz |
9 | GPIO_Init(GPIOC, &GPIO_InitStructure); |
10 | // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config
|
11 | |
12 | /* Steuerleitung */
|
13 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port als Output definieren |
14 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15; // Pin 15 aktivieren |
15 | GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull |
16 | GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz |
17 | GPIO_Init(GPIOC, &GPIO_InitStructure); |
18 | // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config
|
19 | |
20 | /* PS2 -> (Pin 9 -> Daten | Pin 11 -> Clock) */
|
21 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN; // Port als Input definieren |
22 | GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; // Input Modus: Pull-Up |
23 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_11; |
24 | // Pin9 und Pin11 aktivieren
|
25 | GPIO_Init(GPIOE, &GPIO_InitStructure); |
26 | // GPIOE Konfiguration übergeben, Pointer auf Struktur mit Config
|
27 | |
28 | }
|
Dazu kommt das Elend, wählen zu müssen zwischen den Libs zur Zähmung der Hardware, die aber ihrerseits wieder hunderte von Funktionen für alles Mögliche und Unmögliche bereitstellt oder dann doch wieder old school direkter Registerzugriff. Teufel und Belzebub!
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar. >> Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel >> Programm hat. >Ich denke, dass du hier zu sehr verallgemeinerst. Nö, ich berichte von meinen Erfahrungen. >Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein Schon klar, da begrezt die größe pro Objekt auf 32kB beim avr gcc. In Summe gehen aber trotzdem nur 64kB DATEN, weil man sonst über RAMPX adressieren muss. Das geht nur mit Makros und passenden Linkerscripts. >Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den >Code. Das reicht als Problem. >> 256kB kriegt man nur mit Workarounds hin, keinesfalls >> direkt per Arduino-Style! >Warum eigentlich nicht? Programme mit mehr als 128 KiB funktionieren >ja nun schon seit Jahren, warum bei Arduino dann nicht? Weiß ich nicht, bei meinem Test vor einiger Zeit gab es komische Effekte. https://www.mikrocontroller.net/topic/goto_post/4078527 Vermutlich war es aber ein Problem mit Daten >64kB, nicht mit Programm >64kB.
Falk B. schrieb: > Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich > dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der > Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für > einfachse IO-Konfifiguration machen muss!!! Wobei ein wesentlicher Eindruck überhaupt erst durch die unsäglich kompliziert gestaltete ST Library entsteht. Einfache Peripherie erlaubt nur einfache Konfigurationen. Komplexe Peripherie hingegen erlaubt weit mehr Einsatzbereiche, hat aber natürlich auch mehr Konfigurationsoptionen. Das liegt in der Natur der Sache. Nur kann man einen solchen Layer auch eleganter gestalten, als ST das tat. Keine umständlichen und verwirrenden Structs als Parameter, sondern mehr aber dafür einfach gestaltete Funktionen mit überschaubaren Parametern.
@ A. K. (prx) >Nur kann man einen solchen Layer auch eleganter gestalten, als ST das >tat. Keine umständlichen und verwirrenden Structs als Parameter, sondern >mehr aber dafür einfach gestaltete Funktionen mit überschaubaren >Parametern. Mag sein. Aber wo liegt denn da der Vorteil, wenn ich die selbe Anzahl Parameter in ein Struct anstatt direkt in die Register schreibe? Da muss ich fast alles doppelt lernen (oder die Hardware direkt vergessen und NUR auf die ST Lib schauen, auch nicht so doll).
A. K. schrieb: > Nur kann man einen solchen Layer auch eleganter gestalten, als ST das > tat. Man kann es mit ASF natürlich auch genauso kompliziert machen. ;-) Falk B. schrieb: > Vermutlich war es aber ein Problem mit Daten >64kB, nicht mit Programm > >64kB. Gut, das verstehe ich. Ehrlich gesagt, bei mehr als 64 KiB ist mit einfachen 16-bit-Zeigern eben einfach Schluss. Das ist was, wo der ARM einen Systemvorteil hat. Mehr Code hingegen bekommt man (seit Björn Haase das für Bosch gebraucht hat und entsprechen Hand an den Compiler gelegt hat) problemlos auch in einem AVR unter.
Falk B. schrieb: > Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar. > Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel > Programm hat. 256kB kriegt man nur mit Workarounds hin, keinesfalls > direkt per Arduino-Style! jain, ich weiss nix Arduino, Atmel Studio, einen m2560 mit Display bestellt, Bildershow programmiert und als ich über 64k kam ging nix mehr soll normal sein lt. Verkäufer, ich habe es dann bei 64k Bilder belassen, hat mich nicht so interessiert. Jörg W. schrieb: > Ich denke, dass du hier zu sehr verallgemeinerst. > > Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein > (einschließlich Vorzeichen, schließlich ist foo[-1] ein gültiger > Ausdruck), und bei GCC muss das wohl auch alles mit char*-Arithmetik > machbar sein. > > Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den > Code. s.o. beim mighty mini in der Arduino IDE kratze ich grad an der 64k "Grenze"? aber bis jetzt habe ich noch nix bemerkt ausser die fastLED Lib für ws2812b mag den m1284p nicht, alle Timings waren 10% zu lahm, eine ws2812b braucht ja 24 Bit a 1,5µs macht in Summe 30µs, mit dem m328p klappt das derselbe Code im m1284p braucht 33µs für eine LED ist also 10% zu lahm (kein Wunder bei 3 Adressbytes statt 2 Adressbytes), ich habe in delay.h also eingefügt if defined _1284p_ F_CPU x9L/10L ich gauckel dem 10% weniger Takt vor und das Timing passt. Der Autor von fastLED wollte nix machen weil der mighty kein offizieller Arduino ist..... na egal.
Oh weh schrieb: > Michael K. schrieb: >> Du musst doch nur ein wenig Bits schubsen/schieben. Das ist doch kein >> Ding. > > Jetzt ist mein Interesse geweckt. Jedes mal in einer ISR an einer > Variablen rum fummeln oder was? Zum Beispiel. Man könnte zum Beispiel in der ISR für den OVF eine Variable bis 255 hoch zählen und nach dem 256. OVF dann entsprechend reagieren.
Jörg W. schrieb: > Wobei mir gar nicht ganz klar ist, warum das eigentlich 700 Seiten > verschlingt, während XmegaA mit 430 auskommt – rein gefühlt finde > ich den XmegaA komplexer. So so, rein gefühlt also ;-)
Falk B. schrieb:
1 | /* Senddata (Daten) */
|
2 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
3 | // Ports als Output definieren
|
4 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3; // Pins 0,1,2,3 aktivieren |
5 | GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull |
6 | GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz |
7 | GPIO_Init(GPIOC, &GPIO_InitStructure); |
8 | // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config
|
9 | |
10 | /* Steuerleitung */
|
11 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port als Output definieren |
12 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15; // Pin 15 aktivieren |
13 | GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull |
14 | GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz |
15 | GPIO_Init(GPIOC, &GPIO_InitStructure); |
16 | // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config
|
Schlechtes Beispiel. Die zweite Hälfte des Codes hättest du dir sparen können, wenn du Pin15 gleich mit in den oberen Teil verodert hättest.
:
Bearbeitet durch User
Gibt es inzwischen einen XMEGA mit Can Controller? Vor einigen Electronicas habe ich die Atmel Leute danach gefragt, und als Antwort bekommen: Das wird nicht passieren! Fuer mich war es da aus mit den (x)AVRs.
Uwe Bonnes schrieb: > Gibt es inzwischen einen XMEGA mit Can Controller? Vor einigen > Electronicas habe ich die Atmel Leute danach gefragt, und als Antwort > bekommen: Das wird nicht passieren! Fuer mich war es da aus mit den > (x)AVRs. Wir werden dich vermissen....
Uwe Bonnes schrieb: > Gibt es inzwischen einen XMEGA mit Can Controller? Was heißt „inzwischen“? An den Xmegas macht keiner mehr was, sie treiben nun vor allem ihre ARMs weiter. Bei denen gibt's genügend mit CAN.
Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf den Markt bringen musste. Preislich nicht attraktiv, von der Gehäuseform für viele Bastler uninteressant, eingeschränkter Spannungsbereich, dafür ein paar Peripherie-Verbesserungen. Wenn man schon die ganzen Nachteile in Bezug auf Preis, Spannungsbereich und Gehäuseform schluckt, kann man auch gleich auf 32Bit-Controller umsteigen.
@ Gastino G. (gastino) >Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf >den Markt bringen musste. Aufgebohrte AVRs halt. > Preislich nicht attraktiv, Relativ. > von der Gehäuseform für viele Bastler uninteressant, Das war NIE die Zielgruppe! > eingeschränkter Spannungsbereich, Haben fast alle modernen Controller. > dafür ein paar Peripherie-Verbesserungen. Ein "paar"? >Wenn man schon die ganzen Nachteile in Bezug auf Preis, Spannungsbereich >und Gehäuseform schluckt, kann man auch gleich auf 32Bit-Controller >umsteigen. Ansichtssache.
Gastino G. schrieb: > Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf > den Markt bringen musste. Als der XMega designed wurde, war der Siegeszug der ARMs noch nicht so absehbar wie er es heute ist. Aus der Sicht der Halbleiterfirmen sind die ARMs ja ein zweischneidiges Schwert: einerseits haben sie (fast) alle die ARM-Architektur lizensiert und verdienen mit daran, andererseits ist die Marge seitdem sicher deutlich zurückgegangen. Da ist es schon verständlich, wenn einige Firmen versuchten, mit einer eigenen Architektur dagegenzuhalten. Nur rechnet sich das eben nicht mehr, wenn mittlerweile 32Bit ARMs günstiger als viele firmenspezifische 8-Bitter verkauft werden. Gruß, Stefan
Gastino G. schrieb: > von der Gehäuseform > für viele Bastler uninteressant, eingeschränkter Spannungsbereich, dafür > ein paar Peripherie-Verbesserungen. Also SMD und 3,3V sind heute auch bei Bastlern verbreitet. Da wehren sich nur noch ein paar ewig gestrige. DAS ist sicher kein Argument. 5V Controller machen heute spätestens bei der Anbindung an andere Bausteine Probleme. Die sind nämlich auch alle 3,3V. Dann geht das fluchen und pfuschen mit Serienwiderständen, Pegelwandlern, Spannungsteilern und Z-Dioden los.
Cyblord -. schrieb: > 5V Controller machen heute spätestens bei der Anbindung an andere > Bausteine Probleme. Wobei das nun eher kein Argument ist: solange es die AVRs gibt, konnte man sie schon immer auch mit 3,3 V betreiben. Teils musste man dafür die „L“-Versionen nehmen, damit sie dafür auch spezifiziert waren, aber gegeben hat es das seit dem AT90S1200. Gastino G. schrieb: > Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf > den Markt bringen musste. So schlecht war deren Idee ja nicht, sie haben nur am ersten Exemplar so lange herumfummeln müssen, bis er endlich wirklich serienreif war, dass er zu diesem Zeitpunkt dann tatsächlich schon fast technisch überholt war.
Cyblord -. schrieb: > Also SMD und 3,3V sind heute auch bei Bastlern verbreitet. Da wehren > sich nur noch ein paar ewig gestrige. DAS ist sicher kein Argument. Doch, ein im Vergleich zu den ATmegas eingeschränkter Spannungsbereich ist immer ein Argument. Auch mit den ATmegas neueren Datums kann ich problemlos mit 3,3 V arbeiten. Aber eben auch mit 5 V, wenn notwendig. Und SMD hat für mich als Bastler den großen Nachteil, dass ich es nicht mehr stecken kann. Es fallen also Lochraster-Lösungen (evtl. mit Sockel) weg - für jeden Controller braucht man eine Adapter-Platine oder gleich eine fertige Platine. Und wenn man dann noch das Problem hat, dass das "gute" AVR Studio 7 in Verbindung mit dem Atmel ICE ziemlich zuverlässig AVRs in Mini-Ziegelsteine verwandelt, lernt man DIP-Gehäuse noch mehr zu schätzen, die man im STK600 einfach wiederbeleben kann. Fakt ist, dass sowohl beim Spannungsbereich und bei der Gehäuseform Einschränkungen gegenüber den ATmegas bestehen. Und Einschränkungen sind eben fast immer ein Nachteil. Wenn ich mit denen leben muss oder kann, dann kann ich auch gleich auf 32-Bitter umsteigen. Das mag bei kommerziellen Projekten noch etwas anders sein, wo jeder Cent Einsparung wichtig ist, aber für mich als Bastler ist der Xmega völlig uninteressant. > 5V Controller machen heute spätestens bei der Anbindung an andere > Bausteine Probleme. Die sind nämlich auch alle 3,3V. Dann geht das > fluchen und pfuschen mit Serienwiderständen, Pegelwandlern, > Spannungsteilern und Z-Dioden los. Also ich habe hier noch etliche 5 V-Bausteine herumliegen.
Also ich finde auch, dass die ATXMegas schon ihre Berechtigung haben aber klar, es gibt auch viele Alternativen.
Jörg W. schrieb: > Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den > Code. Auch der Zugriff auf Code ist beim M2560 limitiert, denn bei indirekten Sprüngen und Unterprogrammaufrufen braucht man (analog zu RAMPZ beim Datenzugriff) EIND. In C wird das z.B. relevant, sobald man Funktionszeiger benutzt. Und in C++ ist es die Regel, dass man (zumindest implizit) Funktionszeiger benutzt. Zumindest sobald man wirklich von den OO-Fähigkeiten von C++ profitieren will... > Warum eigentlich nicht? Programme mit mehr als 128 KiB funktionieren > ja nun schon seit Jahren, warum bei Arduino dann nicht? Weil dort Funktionszeiger benutzt werden... Wie schön ist es, dass man als Assemblerprogrammierer diese Sachen zwar auch wissen und korrekt berücksichtigen muss, aber einem da wenigstens die Sprache keine Hindernisse entgegen stellt, das Gelernte und Verstandene Wissen einfach und unmittelbar anzuwenden, statt sich damit beschäftigen zu müssen, die Sachverhalte an die Erwartungen historischer (und schon damals geistig ziemlich unterbelichteter) Programmiersprachenkonzepte anpassen zu müssen...
c-hater schrieb: > In C wird das z.B. relevant, sobald man Funktionszeiger benutzt. Ja, und? Das ist doch trotzdem seit fast einem Jahrzehnt gelöst, seit Björn Haase die Trampolines eingeführt hat (die er ja als Idee auch nur aus dem H8 recyclet hat, so ich mich erinnere). Insofern verstehe ich nicht, warum nun ausgerechnet Arduino das wieder als Problem haben sollte. Das einzige wirkliche Thema waren Daten in großen Mengen, da man dort manuell Hand anlegen musste, um das Zeug mit ELPM einzulesen.
Jörg W. schrieb: > Ja, und? Du glaubst doch nicht im ernst, dass jemand, der sich c-hater nennt, dieser Sprache auch nur einen Funken Existenzberechtigung zugestehen wird?
Michael K. schrieb: > Jörg W. schrieb: >> Ja, und? > > Du glaubst doch nicht im ernst, dass jemand, der sich c-hater nennt, > dieser Sprache auch nur einen Funken Existenzberechtigung zugestehen > wird? Das nicht, aber er braucht sich auch nicht zu Dingen zu äußern, in denen er sich ja ganz offensichtlich nicht auskennt.
Jörg W. schrieb: > Das nicht, aber er braucht sich auch nicht zu Dingen zu äußern, in > denen er sich ja ganz offensichtlich nicht auskennt. Das ist eben das, was einen Hater auszeichnet: Er meint, seinen Senf auch dazu geben zu müssen, ohne davon Ahnung zu haben.
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.