mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Gründe gegen einen AVR


Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

immer noch bei der Entscheidung für einen µC. Hab mir das AVR Datenblatt 
angeschaut und sieht schon ziemlich beeindruckend aus im Vergleich zum 
SX nur z.B. der ADC Wandler oder der PWD Ausgang.

Gibt es echte Nachteile oder ist es für den Hobbybereich der ideale 
Prozessor. Gibt es den AVR auch mit mehr als 20Mhz? (Hab aber noch kein 
gefühl dafür wie viel MHz man bei µC wirklich braucht, komme halt aus 
der 32.Bit Welt.

Gruß

Thomas

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachteile vom AVR sind, dass es keinen mit mehr als 4kByte SRAM gibt. 
Dann muss man extern einen Speicher dranhängen. Wenn man viel mit großen 
Zahlen (32bit aufwärts) rechnet, dann wird es ziemlich langsam, aber das 
ist halt bei allen 8bit Controllern so.
Davon abgesehen reichen die 20MHz eigentlich für nahezu alles aus, wenn 
man nicht gerade irgendwelche komplexen DSP Sachen oder ähnliches 
vorhat.

Ich denke vom Preis her sind die im 8bit Segment eindeutig günstig.

Autor: HG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich habe kaum Gründe gegen einen AVR. Ich hab mal auf PICs 
angefangen bin dann auf AVRs umgestiegen und habs nie bereut.

Hier gibts ein super Forum mit super Unterstützung für AVRs!

Soweit ich weiß gibts keine AVRs mit mehr als 20 MHZ, aber für den 
Großteil der Hobbyprojekte mehr als ausreichend. Schau Dir doch mal die 
Projekte an die mit AVRs geacht werden : Webserver, Bilderrahmen, 
Steuerungen, X-Ufo-Steuerungen und und und

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt AVR mit 8 kB RAM.
32 kB oder 64 kB RAM wie bei AT91SAM7 wären trotzdem ganz nett...

Autor: Pro AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir mal kurz den SX angeschaut.
Für mich käm der schon wegen den fehlenden Hardwereschnittstellen nicht 
in Frage, kein SPI, TWI, ADC, UART, PWM, etc

Autor: Michael K. (kichi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Benedikt K.
Es gibt auch AVRs mit 8kB SRAM...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du aus einer anderen Welt bist (32 Bits), dann bleibt doch dort ;-)

AVRs sind klein und handlich, und wenn sie zur Lösung des Problems 
ausreichen auch in Ordnung. Wichtig für Dich sollte sein, daß sie für 
Deine Anwendung ausreichen. Insbesondere Timer, I/O, ... können sehr 
wichtig sein.

Wenn Du aber nicht kleckern willst, dann wäre auch ARM eine Alternative, 
um damit zu spielen. Die beschränken einen nicht durch kleine 
Speichergrößen oder zu kleinen Adressraum. Viel teurer sind sie auch 
nicht.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist, hätte ich doch nachschauen und 8k schreiben sollen.
Aber selbst das ist manchmal wenig, 32kB wären teilweise schön (für 
Webserver usw.)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als kommende Alternative zwischen ARM und üblichen AVRs bietet sich 
vielleicht der ATXMEGA an, der möglicherweise schon auf der embedded 
world vorgestellt wird...? :)

Autor: HG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>möglicherweise schon auf der embedded world

Ja, alle fahren hin, in der Hoffnung das er kommt und dann wirds doch 
nix.

Bis der XMega auf dem Markt ist wird sich der OP bestimmt schon 
entschieden haben und ist bis dahin ein Hervorragender AVR-Programmierer 
;-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bis der XMega auf dem Markt ist...

Mal kurz anfassen würde mir schon reichen... und dann schnell weg damit! 
;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Mist, hätte ich doch nachschauen und 8k schreiben sollen.

Ist mittlerweile auch Schnee von gestern.  Guck dir mal das
part description file ATmega1284P.xml im letzten AVR Studio an...
der hat 16 KiB.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch:

Was sagt denn Deine Glaskugel bezüglich der Verfügbarkeit von
AVR32UCxxx Controllern? Die haben mehr Speicher, sind schneller
als die 8-Bit-AVR's.

Jens

Autor: name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der ad wandler ist vielleicht für manche sachen ein bißchen langsam. 
dann kann man zwar wunderbar per spi einen externen dranhängen, aber so 
richtig einfach ists dann nimmer und es wird teurer. ob das bei anderen 
µC der preisklasse anders ist bezweifel ich aber.

ansonsten finde ich die dinger ganz gut. eigentlich sogar sehr gut.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir grad mal die verschiedenen Typen und Preise bei Reichelt 
angeschaut. So wie es aussieht ist der ATMega 32L8 für 4€ doch wohl 
ideal wenn ich noch nicht abschätzen kann wieviel Ressourcen ich 
brauchen werde oder?

Gruß

Thomas

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die getrennten Adressräume für ROM und RAM sind bei der C-Programmierung 
(zumindest mit GCC) lästig.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie macht sich das bemerkbar? Sollte doch selten vorkommen dass ich per 
pointer arithmetik von ROM nach RAM will oder?

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Befehlssatz ist zwar tausendmal komfortabler als der eines PIC, 
birgt allerdings auch einige Ärgernisse für den Assemblerprogrammierer- 
denn er könnte wesentlich einheitlicher und konsistenter sein. 
Verschiedene Befehle sind (aus Anwendersicht völlig unverständlich) auf 
eine Teilmenge der allgemeinen Register beschränkt. Sowas einfaches wie 
lade Register 7 mit einem Integerwert geht zum Beispiel nicht- nein, es 
muss schon Register 16-32 sein. Dazu diese Beschränktheiten beim Zugriff 
auf I/O Register. Bitadressierbar etwa sind die wenigsten (beim 2560 
noch nicht einmal alle Ports) und dann ist ja da auch noch diese dumme 
Unterscheidung, für den Zugriff IN/OUT oder aber wieder LDS/STS nehmen 
zu müssen. Na ja, da könnte man wohl noch einige Ärgerisse mehr 
hinzufügen oder aber gleich noch einige schmerzlich vermisste 
Instruktionen.  Der Assemblersatz eines Z80 war doch irgendwie 
sympathischer :-) Nun gut, den C-Programmierer  wird's wenig 
interessieren. Und für den Assemblerfrek gibts wohl heutzutage keine 
ernstzunehmende bessere Alternative in dieser 8-Bit Leistungsklasse, 
oder?

Egon

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens wrote:

> Was sagt denn Deine Glaskugel bezüglich der Verfügbarkeit von
> AVR32UCxxx Controllern?

Da habe ich keine Idee.  Ich hätte auch gern einen UC3. ;-)

> Die haben mehr Speicher, sind schneller
> als die 8-Bit-AVR's.

Naja, ein ganzes Stück schneller, aber eben auch energiehungriger.

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von den MHz alleine solltest du dich aber nicht leiten lassen. Auch wenn 
die AVR nur bis 20MHz gehen, so gibt es doch nur einen Teil der Befehle, 
welche  mit 1-2 Takten auskommen. Viele Befehle benötigen 3-4 Takte.

Die PICs z.Bsp. gibt es zwar bis 48MHz (oder noch mehr?), die teilen den 
Takt aber immer durch vier, so das 48MHz eigentlich nur 12MHz 
entsprechen. Allerdings gibt es beim PIC fast keinen Befehl mit 3 oder 
mehr Zyklen.

Ein CALL benötigt beim ATmega32 4 Takte, was bei einem Takt von 20MHz 
also 5 MIPS entsprechen würde. Der selbe Befehl bei einem PIC 18F2550 
benötigt nur 2 Zyklen, was 8 Takte entspricht. Daraus ergeben sich 6 
MIPS. Bei anderen Befehlen ist es anders herum.

Daraus ergibt sich, dass ein PIC mit 48MHz vermutlich genau so schnell 
ist wie ein AVR mit 20MHz (zumindest ist das meine Meinung).

Sven

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@egon.

Das mit den Registern beim AVR ist auch ein Grund, warum ich bis jetzt 
bei den PICs geblieben bin. Dort gibt es keine Unterscheidung zwischen 
Register und RAM (es sei denn man sieht als Register nur das W an). Für 
mich ist der gesamte RAM Register und ich muss die Werte nicht erst aus 
dem RAM in ein Register kopieren. Finde ich persönlich irgendwie 
einfacher.

Sven

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch:

>Naja, ein ganzes Stück schneller, aber eben auch energiehungriger.

Ich habe jetzt keine Zahlen zur Hand, aber ist das so deutlich?
Irgendwie habe ich noch im Hinterkopf das die gemessen an der
Leistung doch ziemlich gut dastehen sollen. Falsch aufgeschnappt?

Jens

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven Ja, da hast Du natürlich recht. (Fast) alles mit allem machen zu 
können vereinfacht immer ganz enorm und spart so manchen Blick ins 
Datenbuch und auch viele Fehler.

Egon

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart wrote:

> Gibt es echte Nachteile

- Kein ROM im Datenadressraum. Folglich sind konstante Daten (Strings, 
Tabellen) nicht mit normalen Datenadressen erreichbar und machen 
entweder spezielle Compilererweiterungen erforderlich - oder 
umständliche und fehlerträchtige Programmierung (GCC, weils da nicht 
anders geht). Kann auch zur Folge haben, dass manche Funktionen mehrfach 
implementiert werden müssen, ja nach Adressraum des Parameters.

Besser: MSP430 als Beispiel für alle von-Neumann-Typen mit nur einem 
Adressraum. PIC30, obwohl Harvard-Typ, weil Microchip pfiffig genug war, 
ROM in die ungenutzte obere Hälfte des Datenadressraums einzublenden. 
Was bei AVRs grundsätzlich auch möglich gewesen wäre, aber anscheinend 
auch bei dem MegaX nicht realisiert wird.

- Interrupt-feste Modifizierung von Bits in Port- und Steuerregistern 
geht ohne Abschaltung der Interrupts nur in den ersten 32 Adressen, und 
auch dort nur für Einzelbits. Die dafür nötigen AND/OR-Operationen auf 
die I/O-Adressen fehlen RISC-typisch weitgehend.

Besser: So ziemlich alle anderen machen das besser. Sogar bei ARMs, die 
dank RISC ein ähnliches Problem haben, wird das mehr oder weniger 
konsequent über speziell konstruierte Portregister abgefangen, aber in 
jeder Familie anders.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens wrote:

>>Naja, ein ganzes Stück schneller, aber eben auch energiehungriger.

> Ich habe jetzt keine Zahlen zur Hand, aber ist das so deutlich?

Ja, wenn du die höhere Taktfrequenz denn auch benutzen willst.
Aber wenn du das nicht willst, kannst du auch bei den ,,Kleinen''
bleiben.

> Irgendwie habe ich noch im Hinterkopf das die gemessen an der
> Leistung doch ziemlich gut dastehen sollen.

Das schon.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Was bei AVRs grundsätzlich auch möglich gewesen wäre, aber anscheinend
> auch bei dem MegaX nicht realisiert wird.

Naja, der Grund für Harvard ist ja, dass man Daten- und Adressbus
trennen kann und damit parallel zugreifen.  Genau das geht bei
Datenzugriffen in den ROM nicht mehr, weshalb sie zwar auch bei
Harvard möglich sind aber langsamer.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht 
wirklich nett aus.

Hilfe!!! Wer kann das wirklich beurteilen??

Kann es sein, dass es derzeit für den AVR mehr freie Tools gibt?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart wrote:
> Hilfe!!! Wer kann das wirklich beurteilen??

Das kann man erst dann, wenn Du mal erzählst, was Du damit machen 
willst.


Die AVRs kann man z.B. an ner Batterie von 1,8V..5,5V direkt ohne 
Spannungsregler betreiben, was auch ganz nett ist.
Oftmals wird übersehen, daß Spannungsregler auch nen Stromverbrauch 
haben.

Die hochgezüchteten Boliden brauchen dagegen oft ne eng tolerierte gut 
stabilisierte Spannung.


Peter

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also was freie tools angeht ist der AVR spitze, ich kann mit meinen 
gewohnten tools ala gcc, make, ... arbeiten, optimal. Fuer mich immer 
ein Killerargument, da ist man schneller und produktiver.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> weshalb sie zwar auch bei
> Harvard möglich sind aber langsamer.

Klar. Aus Sicht des Hardware-Entwicklers kann ich das durchaus 
verstehen. Es wird komplizierter wenn der Befehlszyklus vom Wert der 
Adresse abhängt.

Wobei Microchip das anscheinend ohne Verzögerung hinbekommt. Aber der 
Befehlszyklus vom PIC30 ist ohnehin ein Kuriosum. Der einzige mir 
bekannte Prozessor, bei dem mal ein überflüssiges Ergebnis in den 
Speicher schreibt um es kostengünstig zu entsorgen (ein Vergleichsbefehl 
ist ein Subtraktionsbefehl, der sein Rechenergebnis in den Stack 
schreibt).

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich überleg eher das da zu benutzen:
http://www.westerndesigncenter.com/wdc/w65c265s-chip.cfm
Nur, 25 Dollars nur wegen 6502/65816-kompatibel ist nicht von Pappe, da 
lohnt sich schon ein kleiner FPGA und der T65 Core im 65816 Modus.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart wrote:

> Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht
> wirklich nett aus.

Lass dich von mir nicht kirre machen. Letztlich haben alle ihre Vor- und 
Nachteile. So hat MSP430 zwar eine wundervolle angenehm zu 
programmierende Architektur. Leidet aber andererseits unter 
bastelunfreundlichen Gehäusen, 5V-Inkompatibilität und geringer 
Funktionalität besonders der kleinen Modelle. Und der GCC für AVR 
scheint mit deutlich besser gepflegt zu werden, als der für MSP430.

Unter dem Strich schneidet daher AVR im unteren Sektor ziemlich gut ab. 
Aber hat eben auch seine schwachen Seiten.

Autor: Komet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne gleich wieder einen Klassenkampf generieren zu wollen nur eine 
kurze Anmerkung:
Mit PICs kannst Du vom Programm aus das (Flash-)ROM relativ einfach 
lesen und es auch (neben dem RAM und dem EEPROM) neu beschreiben. Für 
Datenmengen bis ca. 50k-Byte kann das sehr konfortabel sein.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein (meiner Meinung nach) großer Vorteil der AVRs ist, dass diese 
relativ Fehlertolerant sind.
Wenn man da mal ein Bit, das eigentlich als Reserved beschrieben wird 
setzt, dann funktioniert es trotzdem. Bei anderen Controllern bekommt 
man dann die merkwürdigesten Fehler, quer durch die Peripherie, vor 
allem sind auch solche  Sachen betroffen die mit dem falsch gesetzen 
Register rein garnichts zu tun haben. Und dann ist erstmal Fehlersuche 
angesagt, die teilweise recht lange dauern kann.
Weiterhin haben die AVRs meiner Meinung nach relativ wenige Bugs, naja, 
zumindest die älteren wie mega8, 16, 32 usw.
Gleiches gilt für die recht gute Dokumentation: In jedem Abschnitt ist 
die Funktion ziemlich ausführlich erklärt, dann kommen die Register und 
oft noch Beispiele in C oder Asm.

In diesem Punkt finde ich, dass z.B. die dsPICs eine absolute 
Katastrophe sind. Eine Datasheet von jedem Controller in dem alle 
Features nur kurz angeschnitten werden, aber ausführlich (für alle 
unterschiedlichen Controller) nochmals in extra Datenblättern erklärt 
sind, ist absolut nervig, da man schnell bei einem falschen 
Controllertyp ist. Weiterhin stört mich an denen dass ich einige 
Funktionen nicht richtig zum Laufen bekomme, was an Bugs in den Librarys 
oder im Compiler liegt, oder auch an der teils unvollständigen 
Dokumentation. Sowas sollte man auch bedenken. In dieser Hinsicht sind 
z.B. die AVRs sehr viel besser.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mit PICs kannst Du vom Programm aus das (Flash-)ROM
> relativ einfach lesen

Das geht bei fast allen Controllern, darunter allen leidlich aktuellen 
AVRs. Die Frage ist also nicht, ob man an solche Daten lesend rankommt 
sondern wie. Mit normalen Datenbefehlen (MSP430), oder mit speziellen 
Befehlen (AVR,PIC).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Eine Datasheet von jedem Controller in dem alle
> Features nur kurz angeschnitten werden, aber ausführlich (für alle
> unterschiedlichen Controller) nochmals in extra Datenblättern erklärt
> sind, ist absolut nervig,

Da wirst du mit dem MSP430 auch nicht warm werden. TI macht das genauso. 
Da steht im Datasheet drin, das sei ein Timer vom Typ "A", und in der 
Referenz der Gesamtfamilie sind dann die diversen Timer-Typen 
ausführlich dokumentiert.

Denke aber, das ist Gewöhnungssache.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht
> wirklich nett aus.

Dann fang doch morgen einfach einen neuen Thread namens "Gründe gegen
einen MSP" an ;-)

Oder: Buddelst du nur lange genug, wirst du für jeden Controllertyp
beliebig viele Nachteile finden. Bei jeder Chipentwicklung müssen
Kompromisse eingegangen werden, da sich Geschwindigkeit, Stromverbrauch,
Speicherkapazität, Umfang der On-Chip-Peripherie und Herstellkosten
nun mal nicht gleichzeitig optimieren lassen.

Bei den AVRs habe ich zumindest den Eindruck, dass die genannten
Nachteile nicht "fahrlässig" entstanden sind, sondern bewusst in Kauf
genommen wurden, um nicht an andere Stelle deutlich größere Abstriche
machen zu müssen.

Andere Frage: Wie lange hast du denn in der 32-Bit-Welt gebraucht, um
/den/optimalen Prozessor/Controller für dich zu finden?

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehe mal davon aus, dass hier die XMega gemeint sind:

http://www.atmel.com/corporate/embeddedworld2008.a...

"A New Member of the AVR® Family"

Also Stand besuchen und jemanden schütteln. :-)

Und die UC3 sollen wohl angeblich noch im 1. Quartal 2008 verfügbar 
werden.
Wo mein EVK1101 schon seit August oder so "rumliegt".

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Manual der XMegas ist schonmal irgendwo aufgekreuzt. Die o.A. 
Problematik der I/O-Ports wurde immerhin adressiert, es gibt wie bei 
diversen ARMs nun Register für Bitsetzen und solche für Bitlöschen. 
Ansonsten erinnert mich das eher an 8051 mit 1MB-Speicher - nett 
gedacht, vor allem wenn man nix anderes kann als AVR, aber 32-Bitter 
können sowas besser.

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe bisher mit 16F und 18F-PICs gearbeitet und war rundum 
zufrieden.

Jetzt habe ich ein Projekt, bei dem der Kunde mir mal einen Vertriebler 
seines Distris ins Haus geschickt hat.
Es wird eine BLDC-Motor-Steuerung und da möchte er den kleinsten 
dsPIC33F verbaut haben - 2€ !!!!
Und der kann richtig was ! (3-Phasen-PWM für 3 Halbbrücken bei genügend 
MHz...)

Leider muß ich jetzt in C programmieren, weil die anderen Tools, die ich 
sonst verwende (BASIC) noch nicht den Prozessor unterstützen.
Welcher I**** hat denn C erfunden ?
Und welcher SM-Bruder verwendet diesen Mist auch noch für uCs (Jeder 
Befehl/Zugriff ist eher eine Ausnahme als die Regel) ?
Also - grauenhafte Syntax ! Hätte vor Jahrzehnten schon verboten gehört, 
gleich mit den passenden Lochkarten, Fortran und ALGOL.
Da lob ich mir mein BASIC mit Assembler-Support ohne Linker. !!

Jedenfalls hat mein Kunde auch mal AVRs eingesetzt.
Sollte da heute noch einmal jemand den AVR vorschlagen wird er gekündigt 
oder des Hofes verwiesen. Für einen industriellen Einsatz ist es nicht 
spaßig, daß uCs ohne Ankündigung einfach nicht mehr produziert werden 
oder der Hersteller einfach gar keinen Support liefert bei Bugs im 
Silizium (und das sogar bei einem großen Kunden).
Der ist mit dem Thema durch und setzt nur noch Microchip für 
Neuentwicklungen ein.

Bei meinen bisherigen Projekten konnte ich immer alles realisieren, auch 
die Speed reichte völlig (Ich kann in Assembler und meinen PicBasic Pro 
sehr effektiv programmieren, weil ich es schon länger mache und noch 
weiß, was ein Prozessor bei einem bestimmten BASIC-Befehl machen muß). 
Betriebssicher bis zum Umfallen, Alle Prozessoren in allen Gehäusen 
(auch genügend DIPs für die Bastler und Prototypen!).

Aber - keine Frage - die 16Fs sind schon eine Plage für den 
Assembler-Programmierer und werden auch den C-Compiler ärgern.
Das ist aber alles Käse von gestern - so wie der EEPROM-Bug bei den 
alten AVRs.

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für einen Bastler ist BASIC ja vollkommen okay, aber wenn es 
profesioneller sein soll muss man schon C beherschen. Weil C ist einfach 
Standard, schließlich gibt es für fast jede Plattform einen C compiler 
und der Code ist dadurch sehr portabel.

BASIC ist total unportabel, non-standard und meistens auch langsam 
(kommt ja nicht immer drauf an).

Ich hab mal PICs (18er) und AVRs verglichen, hab bisher nur AVRs benutzt 
- wenn man die Datenblätter mal durchgeht sieht man, dass es eigentlich 
nicht viele Unterschiede zwischen der Peripherie gibt. Ich fand ein paar 
features der PICs sogar noch besser realisiert als beim AVR.

Ich vermute mal AVRs sind für C compiler besser geeignet, weil ein C 
compiler möglichst viele Register braucht und nur schlecht mit einem 
Arbeitsregister zurecht kommt. Was ich am PIC gut finde ist, dass er in 
assembler einfach zu programmieren ist (besonders bei den kleinen Typen, 
bei denen man kaum Platz für ein großes C Programm hat).

Ich vermute mal beide haben so ihre Nachteile, aber im grunde kann man 
alles was man mit einem AVR realisieren kann auch mit einen PIC 
realisieren - oder?

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C und portabel ?

Bei uCs sind die Funktionen eher in der Hardware an bestimmte Register 
und Bits statt an Software gebunden. Da portiert man nix vom AVR zum PIC 
oder MSP, 8051 oder so, da schreibt man quasi alles neu !

Bei C verliert man ja noch schneller den Überblick, was der Compiler 
erzeugt, als bei meinen niedlichen Basic.

Wenn ich mir da die Beispiele für den dsPIC32 ansehe, dann werden da mal 
richtig die Hardware vom DSP eingesetzt, den portiert man dann gar nicht 
ohne Anpassung. Befehle in C gibt es dafür gar nicht und einheitliche 
LIBs auch nicht.

Ich kann es verstehen, wenn man am PC einheitliche Schnittstellen 
definiert und Libs schafft, die von allen Routinen genutzt werden können 
- aber - am uC scheitert das durch die Beschränkung des Einsatzes und es 
wird doch wieder umgeschrieben etc. pp.

C gibt es einfach für jeden uC, weil es einfach die Grundlage für die 
Nutzung des Prozessors bildet, weil es einfach nach dem "Guß" des 
Siliziums immer einen angepaßten C-Compiler gibt, der den richtigen Code 
rauswirft - Optimierungen mal außen vor.
C hat es auch schon immer gegeben, evtl. auch nur aus diesem Grund. Das 
erste, was es für einen neuen Prozessor gibt, ist C!

C beherrschen ?
Ich habe eher den Eindruck, das beherrscht mich !
Wenn ich Konstanten verwende, warum nicht #defines ?
Und welche (int) oder (unsigned) setze ich vor jeden Wert oder immer 
oder auch dazwischen, damit die richtigen Wertebereiche erzeugt werden 
und nicht unnötig umgewandelt werden ?
Floats und Strings vermeide ich sowieso - die Libs sind nichts für einen 
uC !
(da finde ich die signed fracs im dsPIC aber mal richtig gut!)

Aber egal, es ging um den besten uC (Flameware is opened!)

Jeder findet sich da am besten zurecht, wo er aufgewachsen ist !
Ich bin bei 6502 und auch Z80 angefangen (APPLE ][),
habe an pdp8 (mit Schaltern und Lampen wie in alten Filmen) mit der 
words und pages in Assembler gerungen,
habe mal einen MCS-48 bearbeitet (Tastatur-Prozessor in PC-Tastaturen),
auch mal einen 8051 programmiert (direkt aus der Steinzeit!),
und jetzt nach langer Abstinenz zum PIC gefunden.
Ich weiß noch, was ein Byte ist und was es kostet, was eine 
Multiplikation bedeutet und warum man nicht nach einer ATAN-Funktion 
fragt, wenn man eine Tabelle anlegen kann....

Aber dem AVR werden ja sehr starke Funktionen nachgesagt.
Ich hätte bei den PICs auch gerne mal etwas mehr Funktionen, Timer zur 
freien Verfügung, INTs-on-Change...

Ich habe aber auch das Gefühl, daß die dsPIC33s bzw. PIC33s geschaffen 
wurden, um den AVRs das Fürchten zu lehren. Die Funktionen sind schon 
genial.
Man hat ja auch einen Prozessor-Kern zugekauft und das eigene Zeugs über 
Board geworfen... ;-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius Schmidt wrote:

> Ich vermute mal beide haben so ihre Nachteile, aber im grunde kann man
> alles was man mit einem AVR realisieren kann auch mit einen PIC
> realisieren - oder?

Du kannst fast alles mit fast allen Controllern machen, es sei denn der 
Code wird so umständlich, dass er nicht mehr reinpasst oder zu langsam 
ist.

Die Frage ist also eher: Erfüllen die Funktionsmodule (Schnittstellen, 
Timer, ...) die Anforderungen? Wie umständlich ist die Programmierung in 
der favorisierten Sprache?

Ich persönlich finde beispielsweise Banking schaurig, was mich trotz 
aller Neugierde zuverlässig davon abhalten dürfte, jemals mit 12- und 
14-Bit PICs etwas in Assembler anzufangen. Und mit Microchips Assembler 
muss man m.E. das Programmieren gelernt haben, um den schön zu finden. 
Aber hier sind wie genau in den Gefilden des Geschmacks, und um den kann 
man ewig ohne Ergebnis streiten.

Drum: Erst kommen die Anforderungen, dann die Lösung. Nicht umgekehrt. 
Und so gibt es keine Grosse Optimimale Lösung Für Alles (tm).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Rüter wrote:

> Bei C verliert man ja noch schneller den Überblick, was der Compiler
> erzeugt, als bei meinen niedlichen Basic.

Eigentlich nicht. Jedenfalls nicht, wenn man selber mal welche 
geschrieben hat. ;-)

> C hat es auch schon immer gegeben, evtl. auch nur aus diesem Grund.

Ginge es nach Vernunft, wäre möglicherweise Ada führend. Aber als Ada 
rauskam, war es für reale Maschinen nicht handhabbar, und als es 
handhabbar war, war C schon die Universalsprache, so grässlich sie auch 
ist.

Der historische Grund für C: Als in den 80ern die Unis Maschinen, 
Compiler und Betriebssysteme brauchten, da gab es PDP11/VAX, C und Unix. 
Diese Maschinen waren bezahlbar, Compiler und Betriebssysteme für Unix 
entweder kostenfrei oder zumindest günstig. Was man von den Alternativen 
nicht behaupten konnte (PASCAL gabs zwar auch, war aber in der Urform 
für praktische Belange unbrauchbar). Und was diese Leute damals 
mitgenommen haben, damit plagt sich jetzt die ganze Industrie herum.

> Man hat ja auch einen Prozessor-Kern zugekauft und das eigene Zeugs über
> Board geworfen... ;-)

Kann es sein, dass du grad PIC32 (MIPS 32-Bit) und PIC33 (Microchip 
16-Bit) durcheinander bringst?

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Kann es sein, dass du grad PIC32 (MIPS 32-Bit) und PIC33 (Microchip
> 16-Bit) durcheinander bringst?

Ja!

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius Schmidt wrote:
> Für einen Bastler ist BASIC ja vollkommen okay, aber wenn es
> profesioneller sein soll muss man schon C beherschen. Weil C ist einfach
> Standard, schließlich gibt es für fast jede Plattform einen C compiler
> und der Code ist dadurch sehr portabel.
>
> BASIC ist total unportabel, non-standard und meistens auch langsam
> (kommt ja nicht immer drauf an).
>

Ich gebe dir insofern recht, dass C einen eindeutigeren und 
verbreiteteren Standard hat als BASIC. Viele machen aus BASIC eine extra 
Wurst.

Allerdings finde ich gerade im Hinblick auf AVRs das BASCOM BASIC enorm 
effizient. Man kann einfach mit extrem wenig (selbsterklärendem) Code 
relativ komplexe Dinge (UART, I2C) implementieren. Und ob eine Sprache 
langsam ist oder nicht hängt auch damit zusammen wie gut die 
Hochsprachenelemente in ASM und Maschinencode codiert werden. Das ist 
auch Sache des Compilers und nicht der Sprache an sich. Da schenken sich 
BASIC und C praktisch nichts.

Ich programmiere schon seit einiger Zeit PICs in C und AVRs in BASCOM 
BASIC und muss sagen, dass von der Effizienz her BASCOM BASIC mein 
klarer Favorit ist. Ich finde es ist problemorientierter. Zumindest war 
es bei mir so, dass ich bei C mehr "Vorarbeit" leisten musste um eine 
Aufgabe zu verwirklichen als bei BASIC. Aber alles hat Nachteile. Was 
Mathematik angeht ist BASIC grottig.

Autor: zero (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>C beherrschen ?
>Ich habe eher den Eindruck, das beherrscht mich !
Wenn Du mehr Erfahrung damit hast, wird es bestimmt besser.

>Jeder findet sich da am besten zurecht, wo er aufgewachsen ist !
>Ich bin bei 6502 und auch Z80 angefangen (APPLE ][),
Wie heist das heute: lebenslanges Lernen
Im Alter vertraut man halt eher der Erfahrung, als dem Neuen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Der historische Grund für C: ...

Ein zweiter: es war die erste, nun ja, ,,höhere'' Programmiersprache,
die auch dafür geeignet war, große Teile des Betriebssystems damit
zu schreiben (und damit in diesem Feld den Assembler abzulösen).
Damit konnte man sowohl System als auch Anwendungen in dieser Sprache
schreiben.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zero wrote:

>>Ich bin bei 6502 und auch Z80 angefangen (APPLE ][),

> Wie heist das heute: lebenslanges Lernen

Nicht nur heute.  Das war wohl schon immer so.  Lenin wird der
Spruch zugeschrieben: ,,Lernen, lernen, nochmals lernen!''.

Ich habe auch Z80 unter CP/M in Assembler und Pascal programmiert und
(schauder) FORTRAN auf einem RSX-11 kennenlernen dürfen.  Es hat mich
nicht davon abgehalten, C zu lernen und Unix und das Programmieren
von Microcontrollern in mehr als nur dem Assembler, den ich seinerzeit
für den Z8 zur Verfügung habe (wobei ich mich heute noch frage, wie
ich in diesen damaligen Projekten mit einer einfachen 7-Segment-Anzeige
das Debuggen geschafft habe).

Autor: Komet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Wahl der (Software-)Werkzeuge hängt aber auch stark von der 
Aufgabenstellung ab.
Ich programmiere häufig sehr zeitkritische Prozesse. Da bleibt als 
einzige Programmiersparche dann nur noch Assembler übrig. Mit etwas 
Übung ist dann selbst eine Division (mit mehreren Byte großen Divisor) 
kein Problem mehr.

Statt über eine schön bunten Programmieroberfläche freue ich mich auch 
schon mal über einen schnellen und kompetenten Herstellersupport. Ach 
ja, wenn solch eine Software erstmal läuft, sollten auch die Controller 
dazu über Jahre ohne Probleme lieferbar sein. Hier gibt es wohl die 
größten Unterschiede bei den verschiedenen Herstellern.

Autor: Peter X. (vielfrass)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin eigentlich ein Fan vom 8051.
Die schnellen Deivate von SILABS sind super.
So schöne Sachen in Assembler, da kommt ein ARM7 TDMI mit gleicher 
Taktfrequenz nicht hinterher.

Wo der 8081 z.B schreibt
        CPL    P1.7

siehts beim ARM7 so aus:
0x0008039C  E59F0054  LDR       R0,[PC,#0x0054]
0x000803A0  E5901000  LDR       R1,[R0]
0x000803A4  E2211502  EOR       R1,R1,#0x00800000
0x000803A8  E5801000  STR       R1,[R0]
Also hat das 8051-Derivat bei gleicher Taktfrequenz die Nase vorn.
N.B. von Atmel gibt's sogar 8051er mit MP3 Decoder.

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal ARM war auch nie für Mikrocontroller gedacht, sondern eher 
für Spielkonsolen und andere Consumer Geräte.
Also ich kann mir grade nicht wirklich vorstellen mein GP2X mit 
irgendwas anderem als wie dem verbauten ARM7 Doppelkern zu nutzen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja aber so ein arm7 ist schonmal eine ganz andere architektur... das 
teil ist superskalar, ist 32-bit und ein RISC...

dein 8051 ist alles andere als RISC.. und RISC/CISC dirskussionen 
bringen nix weils da einfach von der anwendung abhängt, was schneller 
ist... ich staune noch immer wie schnell mein g4-ibook ist... obwohls 
nur bei knapp 700Mhz läuft...

wenn du nur 8bit zahlen herumschiebst und bit-banging machen willst, 
bringt dir ein arm überhaupt nix... der ist sogar verdammt langsam wenn 
er einzelne pins setzen/lesen muss... wenn du aber mp3 auf dem ding in 
software decodieren willst wirds nicht wirklich probleme machen...

aja.. so ein avr auf 16mhz und 5V braucht gleich viel strom wie ein arm7 
bei 64Mhz der braucht dafür 3.3V (und 1.8 wenn er nicht den regler 
eingebaut hat)

wo wir wieder beim thema "wie einfach kann ich damit arbeiten" wären ;)

avr+irgendwas zwischen 1.8 und 5.5V (wenn die neuen stromspar-teile 
sind.. sonst sind 3V min) und das ding rennt... (wenn man den interenen 
oszillator einschaltet...

ein arm braucht schonmal recht genau eine spannung(en) und der 8051 
kommt dank seiner "der akku kann alles"-architektur einem avr nicht das 
wasser reichen (wenn sie gleich schnell takten)...

so jetzt ist aus mit OT... was nehmen.. 8051, pic, arm, avr, msp430...

8051 ist glaubich unbestritten die meisten code-beispiele, compilier,...
dafür ist die archtiktur nicht zeitgemäß... alleine schon die tatsache, 
dass du portpins nicht auf input schalten kannst oder tristate oder 
pullup,...

zum pic will ich nix sagen weil ich ihn nicht gut genug kenne.. aber 
zumindest bei den compilern schauts dort nicht so gut aus.. dafür gibts 
auch nicht wenig zeug im netz...

arm sind nett, schnell, günstig und es gibt gute compiler 
unterstützung.. dafür darfst du dich auf die suche nach einem 
linker-script, startup-code usw für deinen arm7 machen.. weil arm7 ist 
nicht arm7 zumindest wenn du einen lpc von nxp oder einen von atmel 
nimmst gehts eigentlich ganz brauchbar... ;)

der msp von TI ist für mich absolutes neuland.. ich hab mir mal die 
datenblätter angeschaut.. klingt gut.. bei uns auf der uni habens dazu 
nur gesagt, dass man sich mit den dingern im EMV-Labor richtig probleme 
einhandelt... ein bisserl ESD und tot ist er...

dann noch der avr.... hat alles was man sich wünscht.. schnell, günstig, 
gut unterstützt, und genug doku/libs,...
richtig gut zum einsteigen in die 8-bit welt eben ;)

73

Autor: Peter X. (vielfrass)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibt es einen Microcontroller von Freescale, der STAR 12.

Hatte mal die Instruction Set Summary durchgelesen, da gibt's einen 
Befehl der macht folgendes was ich hier mal versuche zu beschreiben:

Eine bestimmte Anzahl von Bit's (beginnend bei Bit0) im Register 1,
wird um eine bestimmte Zahl nach links geschoben und in Register 2 
eingesetzt.
Die Anzahl der Bits und die Anzahl der schiebungen werden im Befehl 
angegeben.


Leider weiss ich nicht mehr, welcher Mikrocontroller es geau war, noch 
wie der Befehl heisst.  :-(

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans wrote:

> zum pic will ich nix sagen weil ich ihn nicht gut genug kenne.. aber
> zumindest bei den compilern schauts dort nicht so gut aus.. dafür gibts
> auch nicht wenig zeug im netz...

Für PIC14 und PIC16 mag das stimmen, aber für PIC18 gibt es den C18 
Compiler zum kostenlosen download in der student version auch zur 
kommerziellen Nutzung kostenlos. Die Limitierungen die nach Ablauf der 
Probezeit eintreten sind für die meisten wohl nicht von großartiger 
bedeutung (resultiert nur in schlechteren Code, für den Hobby bastler 
ist das wohl kein Problem).

Hab noch nicht wirklich viel mit dem C18 gemacht, aber ich nehme mal an 
da er direkt von Microchip ist wird es keine "Frickellösung" sein die 
sich jemand aus Not zusammengebastelt hat ;)

Ausserdem gibt es ja noch diverse BASICs (wenn man sich das antun will), 
die sind zwar (genau wie beim AVR) auch nicht umsonst aber naja...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius Schmidt wrote:

> Hab noch nicht wirklich viel mit dem C18 gemacht, aber ich nehme mal an
> da er direkt von Microchip ist wird es keine "Frickellösung" sein die
> sich jemand aus Not zusammengebastelt hat ;)

Sag sowas nicht. Der C30 Compiler ist afaik ein gcc Compiler + 
Optimierungen von Microchip. Und genau diese machen Problem und erzeugen 
teilweise unsinnigen, wenn nicht sogar falschen Code.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

...

> Lenin wird der
> Spruch zugeschrieben: ,,Lernen, lernen, nochmals lernen!''.

War der Anlass dieser Äußerung nicht ein Blick in Walter Ulbricht seine 
Schul-Zeugnisse?

Duck & weg...

Zurück zum Thema: Nix ist vollkommen, auch nicht die AVRs. Aber mit 
ihnen kann man (ich) viele Dinge (kostengünstig) realisieren, auf die 
man sonst verzichten müsste. Also mir gefallen die kleinen preiswerten 
AVRs, auch wenn sie noch nicht perfekt sind.

...

Autor: Oliver Keller (ozel-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bernd
man kann auch in C "schöner" programmieren, wenn man sich eine 
entsprechende API baut.

Arduino.cc ist dafür ein nettes Beispiel. Die haben unteranderem auch 
eine Abstrahierungsebene eingeführt, die es theoretisch erlauben würde, 
andere uCs als die bisher verbauten AVRs einzusetzen (sofern es einen 
GCC compiler für diese gibt). Und da man trotzdem alles in reinem C 
(manche Libs sind auch C++) programmiert, kann man sich jederzeit 
entscheiden statt "digitalWrite(PinX,HIGH)" direkt "PORTX &= (1 << 
PinX)" zu schreiben - was natürlich Performancevorteile hat, aber eben 
nicht so "schön" aussieht. Wobei sowas ja relativ ist ... ;-)

Ich finde da sieht man jedenfalls gut, das C im Vergleich zu 
Skriptsprachen in uCs am Ende die flexiblere und portablere Lösung ist.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wo der 8081 z.B schreibt
        CPL    P1.7

> siehts beim ARM7 so aus:
0x0008039C  E59F0054  LDR       R0,[PC,#0x0054]
0x000803A0  E5901000  LDR       R1,[R0]
0x000803A4  E2211502  EOR       R1,R1,#0x00800000
0x000803A8  E5801000  STR       R1,[R0]

> Also hat das 8051-Derivat bei gleicher Taktfrequenz die Nase vorn.

So ein schmarn: Äpfel mit Birnen vergleichen.

Zum einem gibt's viele ARMs die enstprechende Hardware-Register für 
Fast-IO haben, so dass das auch zu einem einzelnen Befehl wird.

Und wenn wir schon mal bei Äpfel mit Birnen vergleichen sind, mach mal 
folgendes mit Deinem 8081:
        MLA     r0, r1, r2, r3

Es gilt eben doch wie immer: Das richtige Werkzeug für die Aufgabe!

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>arm sind nett, schnell, günstig und es gibt gute compiler
>unterstützung.. dafür darfst du dich auf die suche nach einem
>linker-script, startup-code usw für deinen arm7 machen.. weil arm7 ist
>nicht arm7 zumindest wenn du einen lpc von nxp oder einen von atmel
>nimmst gehts eigentlich ganz brauchbar... ;)


Wieso Suche nach einem Linker-Skript oder Startup-Code?
Wenn man den richtigen Hersteller nimmt, ist das alles nicht nötig.

Ich habe gerade mit den ARM-Cortex-M3 von Luminary angefangen. Der 
Einstieg war leichter als mit den AVRs, da Luminary Startup-Code und 
Linker-Skript für den gcc liefert und zudem im Gegensatz zu NXP auch 
eine schöne Peripheral-Library mitliefert (kostenlos natürlich). Dadurch 
muss man sich zumindest am Anfang nicht mal großartig mit den Details 
der Peripherie auseinandersetzen.
Nach nicht mal einem halben Tag hatte ich FreeRtos laufen, dazu 
Interrupts für Timer und USART, wobei letzterer über eine Queue 
gesteuert wurde.
Bei einem Neueinstieg in den AVR hätte ich da länger gebraucht (erst 
recht bei ARM7 von NXP oder Atmel).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael wrote:

> Ich habe gerade mit den ARM-Cortex-M3 von Luminary angefangen. Der
> Einstieg war leichter als mit den AVRs

Ich ziehe es vor, mich nicht auf eine Variante zu beschränken. Jenseits 
von 30-40KB sind mir AVRs zu umständlich - aber wenn man nur Arme oder 
Daumen zur Verfügung hat, wird Batteriebetrieb leicht zum Problem.

Autor: Juergen Harms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte auch erwaehnt werden: die Verfuegbarkeit einer ausgezeichneten 
und gut gewarteten Programmierumgebung (AVR-GCC, AVR-lib etc.) war fuer 
mich das ausschlaggebene Argument fuer die Wahl von AVR - mehr als 
gleich wichtig wie die hier diskutierten Fragen zur Architektur und 
Leistung.

Ein negativer Aspekt: die Qualitaet der Hardwaredokumentation ist bei - 
zumindest manchen - AVRs mehr als mangelhaft - viel Papier, in dem 
trotzdem einiges fehlt, und manches einfach sich als falsch 
herausstellt. Ich habe mit 2 Gruppen Erfahrung gesammelt ATmega 8/16... 
eher positiv, und AT90CANxxx eher Mist - sieht zwar beim ersten 
hinschaun aehnlich gut aus - aber wenn es an Detailfragen geht bekommt 
man sehr schnell graue Haare (besonders schlechte Erfahrung: die 
Dokumentation des CAN Subsystems - und hier fehlen auch weitgehend 
geeignete Application Notes).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.