MCU für Assembler: AVR oder doch was Anderes?

"Dietmar Belloff" schrieb im Newsbeitrag news:1jqq09i.ot3gr4xaw8e6N% snipped-for-privacy@gmx.de...

Dann nimm doch deren Nachfolger, 68HC05/08/11/12, die vor allem dadurch auffallen, daß nicht jeden tag ein neuer uC angekündigt wird und ein anderen als schon veraltet gilt. Allerdings hat Freescale nach wie vor den Einzelkunden nicht in Sicht, entsprechend mies ist die Verfügbarkeit. Reichelt ist eher keine Quelle, Farnell hat viele.

Auch Hitachi/Renesas/Mitsubishi R8C/M16C sind dem recht ähnlich, ein abgespeckter 68000.

Bei mehr Leistungshunger Coldfire (68k-basierte) von Freescale.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://freenet-homepage.de/mawin/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Solche Fragen sind dazu geeignet, Glaubenskriege heraufzubeschwören ;-)

Ich habe bis vor einigen Jahren 8031 in Assembler programmiert. Dann PIC, ganz früher Z80.

Seitdem ich AVRs verwende sehe ich aber keine Notwendigkeit bzw. keinen Sinn mehr darin, in Assembler zu arbeiten. Da verwende ich WINAVR bzw. GCC.

Die Ablehnung von C als Programmiersprache für Microcontroller ist ein bischen so, wie die Neigung mancher Leute, lieber einen Haufen TTLs miteinander zu verwursteln, als einen MC einzusetzen ;-)

Gruß

Stefan DF9BI

Hallo Dietmar,

Meine Empfehlung haengt von Deiner Motivation ab.

Wenn Du Assembler programmieren moechtest weil Du nichts anderes kannst, dann nimm den AVR. Der ist ist bequem und hat viele Fans.

Andererseits, wenn Du Assembler bevorzugst weil Du Kopfnuesse und Puzzles magst, dann nimm einen PIC. Da kann man immer wieder einen ueberraschenden Kniff (er)finden. "Normale" Programme sind dagegen aber nur holprig zu implementieren.

Also ich wuerde heute kein Assembler mehr machen. Und wenn doch dann kein AVR weil das eine RISC CPU ist und da keine Freude aufkommt.

Aber Z80 war doch total super. Hatte auch viel bessere Mnemonics. :-D

Es gibt Microcontroller auf 68k Basis. Das duerfte fuer jemanden der noch Assembler programmiert wohl das beste sein.

Sagen wir mal lieber weil da alle Blinden von den Einaeugigen abschreiben koennen. AVR ist damit grossgeworden das sie halt als erstes Flash zu bieten hatten und man sie im System neu programmieren konnte. Andererseits ist es dadurch ziemlich egal was die CPU fuer ein Gehaeuse hat weil du sowieso nur dein Kabel zum Debugger auf die Platine aufsteckst.

Zu spaet. :-)

Du koenntest dir noch R8C/M16C anschauen. Das ist eine 16Bit CPU und die Befehle erinnern IMHO ein bisschen an 68k.

Hier mal ein paar Beispiele:

cmp.w #1,28[fb] Wortvergleich ueber Framebuffer jeq _ts1 mov.w 0[sp],22[fb] TOS nach Zeiger auf Framebuffer

mov.w 20[fb],[a1] Framebuffer auf Adresse von Zeiger kopieren

pushm r0,r1,r3,a1 ein paar Register auf den Stack

sstr.b Loescht einen Speicherblock ueber Zeiger und Registerzaehler. smovb Stringkopie.

Enter/Exitd STackframe

mul,mulu,div,divu 16x16=32Bit Multiplikation mit und ohne Vorzeichen.

Na? Da will man doch keinen AVR mehr benutzen oder?

Olaf

Meine Assembler-Experimente mit dem AVR haben mich irgendwie sehr an den

6502 erinnert, nur dass man endlich mal genug Register hat.

Mit dem Eval-Board von Pollin kann man den AVR fuer kleines Geld einfach mal ausprobieren.

Gerrit

Definitiv ja. Schon deshalb, weil es nur hierfür eine zumindest einigermaßen brauchbare vollständige Entwicklungsumgebung für Asm ohne jede künstliche Beschränkung für lau gibt.

Natürlich kann es durchaus Ausnahmen geben, wo spezielle Vorteile andere Architekturen so sehr zum Tragen kommen, daß sie die Vorteile der AVRs überwiegen. Wenn z.B. absehbar ist, daß die Mehrheit der Entwicklungen eher im Bereich der ultrakleinen und ultrasparsamen batteriebetriebenen Applikationen liegen wird, dann könnte man auch ernsthaft über MSP430 nachdenken.

Ich sehe da keinen prinzipiellen Unterschied zum AVR. Naja, klar, der AVR ist nur ein 8-Bitter, aber sonst?

Stackframes brauchen nur Hochsprachen wirklich, in Asm mit 32 Registern zur Parameterübergabe braucht man die praktisch nie. Push/Pop von Registerlisten ist ganz nett und vermeidet viele Schusselfehler, kann man aber mit entsprechenden Macros auch problemlos nachbauen. Also auch nicht wirklich nötig.

Was bleibt da wirklich?

Und dann kommen dagegen die Vorteile der AVRs: Die schiere Geschwindigkeit bei der Mehrzahl der Operationen. Mit wieviel MHz muß man z.B. einen R8C/M16C laufen lassen, um einen Puls von 100ns an einem IO-Pin sicher von einem mit 200ns unterscheiden zu können?

Und so sprach Olaf Kaluza:

Also, dass muss mir jetzt mal jmd. erklären.

Roland

Dann schau dir mal so einen RISC-Befahlssatz an. Wie der Name schon sagt, sind weniger Befehle implementiert, daher muß man meist mehr schreiben, um dasselbe wie bei CISC-Befehlssätzen zu erledigen. Aber dann kommt meist noch hinzu, daß es für manche Befehle interessante Flags gibt, z.B. schiebe beim Laden eines Registers den Wert gleichzeitig noch ein wenig und verknüpfe ihn mit einem anderen Wert. Außerdem kann man durch geschicktes Aliasing usw. die meist vielen Register bei RISC-CPUs gut ausnutzen. Das alles optimal von Hand beachten zu wollen, erfordert viel Denkarbeit (falls man es wirklich schnell braucht) und der resultierende Code ist dann eher Einweg-Code (also man kann ihn schreiben, aber nach einem Jahr versteht man nicht mehr, was man denn da geschrieben hat). Solche Optimierungen braucht man zwar meist nicht, aber moderne C-Compiler können das von vorneherein für den gesamten Code ohne manuelle Arbeit und wird auch noch kürzer (falls man nicht in Forth programmiert), was bei vielen Microcontrollern wegen kleinem Flash wichtig ist.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

snipped-for-privacy@gmx.de (Dietmar Belloff) schrieb:

So ungefähr habe ich vor 10 Jahren auch mal da gestanden, nach 10 Jahren Pause. Vorkenntnisse vor allem Z8/Z80 damals. Dann habe ich mir einen PIC genommen und eine Eieruhr damit programmiert. Ich habe daran so lange debuggt, dass ich mir geschworen habe, dass mein nächster Controller einer sein wird, für den es einen freien Compiler gibt. Das hat mich dann zu den AVRs gebracht. Das Verhältnis von Aufwand zu Nutzen ist einfach drastisch besser als bei Programmierung in Assembler.

Wenn du partout kein C willst, kannst du alternativ auch Ada machen ;-), oder als Kaufoption Bascom.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Zwar verkünden sie "product longevity" 10-15 Jahre:

was zwangsweise nur eine begrenzte Zahl Typen betreffen kann. Unklar ob dann wirklich alle Gehäusevarianten und ROHS/Blei usw. verfügbar sind. Und in 15 Jahren hat Freescale wohl 4x den Besitzer gewechselt und gehört einem Chinesen.

MfG JRD

"Dietmar Belloff" schrieb im Newsbeitrag news:1jqq09i.ot3gr4xaw8e6N% snipped-for-privacy@gmx.de...

Fuer richtig bitsuechtige ist Assembler schon eine gute Wahl, mach ich auch gerne. Deshalb meine Empfehlung; 8051/8052-Derivate z.B. mit USB von Atmel oder TI, gibts jede Menge gute Tools.

Auch empfehlenswert: MSP430, gibts jetzt auch mit USB oder in einer echten

0,9V Vaiante (Da macht Assembler auch noch richtig Sinn).

Oder man schreibt sich selber einen FPGA Soft-Core und schreibt einen Assembler dazu, sehr lehrreich...

RISC, also echter RISC mit z.B. OOO (Out-Of-Order execution) oder Hazard-umschiffungen im Binaercode etc. macht wahrscheinlich in Assembler keinen Sinn, wegen der strikten Codestruktur. Aber lehrreich ist das sicher auch.

MIKE

Das hatte ich auch schon überlegt, wollte mir zum rumprobieren eher den Butterfly angeln, um zu schaun ob AVR was für mich ist.

--
Bye, Dietmar

Schaut gut aus, danke, den hatte ich ja ganz vergessen. Scheint nicht so verbreitet zu sein wie die Anderen, oder? Mal nach Boards suchen.

Stimmt, das kommt mir doch bekannt vor, auch wenn AVR im ersten Moment ähnlich ausschaut - im Detail isses dann doch komplexer.

--
Bye, Dietmar

Dieses trifft zu.

Den hab ich genau aus diesem Grund sowieso gleich außen vor gelassen:)

Örgs, nee. Hab mit einem Neueinstieg schon genug Hürden, da muß ich die nicht auch noch haben.

Danke für die klaren Aussagen.

--
Bye, Dietmar

Ok, klingt gut, ich dachte die sind inzwischen eher durch die ganzen AVR, PIC, ARM etc verdrängt worden.

Farnell geht doch nicht für Endkunden, oder? Digikey hat aber auch welche seh ich gerade.

Die hab ich völlig vergessen, danke, mal schaun gehen.

--
Bye, Dietmar

Das ist eins der stärksten Argumente für AVR, ja.

So etwas hatte ich eigentlich nicht im Sinn.

--
Bye, Dietmar

Vielleicht vertue ich mich ja, es ist schon eine Weile her das ich das letzte mal einen AVR in Assembler programmiert habe, aber ich habe den Eindruck als wenn die CPU sehr registerzentriert war.

Hier mal ein Ausschnitt aus dem Multitasker den ich letzte Tage geschrieben habe:

/* TaskPointer auf das TaskRam der naechsten Task setzen */ _ts3: mov.w #_TaskPointer,a1 /* Position von TaskPointer */ mov.w 20[fb],[a1] /* TaskRam[].next -> TaskPointer */ ldc [a1],fb /* FramePointer anpassen */ /* Ab hier zugriff auf die Daten der naechsten Task */

Daten zum Programm: typedef volatile struct { [...] volatile void *next; /* 20 Naechste Task */ [..] } TaskMemory;

/* Liste mit den Daten der Tasks, kann gross werden! */ EXT TaskMemory TaskRam[MAX_TASKS]; /* Pointer auf den Datensatz der gerade aktiven Task */ EXT void *TaskPointer;

Obiger Assemblercode wandert also ein Element durch eine einfach verkettete Liste. Wie wuerdest du das mit einem AVR machen?

Olaf

Moin!

Doch, über

Gruß, Michael.