Forum: Mikrocontroller und Digitale Elektronik AVR atmega328 ausgereizt? Und nun? 32bit?


von Umsteiger (Gast)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Umsteiger (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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?

von Felix A. (madifaxle)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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.

von Umsteiger (Gast)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Bahnfahrer (Gast)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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

von Max K. (laternenjoe)


Lesenswert?

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

von Oh weh (Gast)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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 ;-)

von Falk B. (falk)


Lesenswert?

@ 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?"

von Falk B. (falk)


Lesenswert?

@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++"

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

@ 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!

von Falk B. (falk)


Lesenswert?

@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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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.

von Moby A. (moby-project) Benutzerseite


Lesenswert?

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 ;-)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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
von Uwe Bonnes (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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....

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Gastino G. (gastino)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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.

von Stefan K. (stefan64)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Gastino G. (gastino)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

Also ich finde auch, dass die ATXMegas schon ihre Berechtigung haben 
aber klar, es gibt auch viele Alternativen.

von c-hater (Gast)


Lesenswert?

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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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
Noch kein Account? Hier anmelden.