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

...allerdings sind einige Register sehr speziell, was die Anwendung betrifft. Gerade wenn ich mal etwas komplexere Programmteile mit intensiver Registernutzung programmiert habe, bin ich immer wieder in die Falle getappt, dass gerade DIESER Befehl nicht mit dem aktuell genutzten Register funktioniert. Dann muss man anfangen die Regsiter hin und her zu tauschen...

Ja, der generierte Code (WinAVR) ist garnicht so schlecht und man muss sich nicht um die Verteilung der Register etc. kümmern. Schreibe auch nur noch ganz kritische Programmteile die viele tausend mal durchlaufen werden (z.B. in Interrupts) in ASM...

Grüße Markus

Reply to
Markus Marquardt
Loading thread data ...

Ist sie auch, das macht sie in der Praxis ja so schnell. Ein AVR der staendig im RAM rumfuhrwerken muss kommt nur noch auf die halbe Geschwindigkeit wenn es hochkommt (externes RAM ist noch langsamer als internes).

Vielleicht so in der Art:

---------------------------------------------------------------------- /* Init (4 Takte) */ ldi YL, lo8(TaskRam) /* TaskPointer auf ersten Task */ ldi YH, hi8(TaskRam + 1) texec: /* Ausfuehren */ tswitch: /* Taskwechsel (7 Takte) */ ldd ZL, Y+20 /* NextPointer laden */ ldd ZH, Y+21 movw Y, Z /* TaskPointer updaten */ rjmp texec /* Task ausfuehren */

----------------------------------------------------------------------

Richtig haesslich wird Assembler mit AVR erst, wenn man mehr als

64KiByte Adressraum benutzen will.

Micha

Reply to
Michael Baeuerle

Matthias Weingart schrieb:

Genau. Und man lernt hexadezimal rückwärts zählen. Rabbit war mir bis vorhin gar kein Begriff. Sieht ja auf den ersten Blick sehr wie Zilog aus. Aber dann kommts: "The nature of the failure is that the memory address translation does not take place and so the appropriate memory chip select will not be enabled for the second instruction. In the case of external I/O operations where the I/O strobes on Port E may be enabled, an I/O "chip select" (I/O strobe) will take place instead of a memory chip select." "Rabbit users are unlikely to encounter this problem because the sequence of instructions that exhibit the bug is never generated by the Dynamic C compiler or in any of the standard libraries."

Jetzt wissen wir um die Vorzüge von C gegenüber Assembler. Dazu heißt es: "Even though these 16-bit addresses are a valuable asset, they do create some complications because a memory-mapping unit is needed in order to access a reasonable amount of memory for modern C programs."

Klar.

MfG hjs

Reply to
Hans-Jürgen Schneider

Am 21.10.2010 20:01, schrieb Frank Buss:

Dafür hat man aber auch eine deutlich kürzere Lernkurve.

Da Assembler heute sowieso nur noch zu didaktischen Zwecken oder kurze, zeitkritische Programmabschnitte in Frage kommt, ist das ein nicht zu verachtender Vorteil.

Hergen

Reply to
Hergen Lehmann

Hallo Stefan,

Am 22.10.2010 09:07, schrieb Stefan Brröring:

Dann noch das eclipse Plugin, und man hat eine wirklich gute IDE :-). Der Workflow geht dann in einem Rutsch bis zum upload mit avrdude.

Allerdings eine Anmerkung: die Version 20100110 von winavr enthält einen gcc, der deutlich größeren Code erzeugt (ca. 10-20%) als z.B. die Version 20060421. Deshalb verwende ich diese alte Version teilweise noch.

Das entfällt mit eclipse, da sich die IDE um alle Abhängigkeiten kümmert.

Grüße, Kurt

--
KHTronik - Kurt Harders
Elektronik, Softwareentwicklung, Opensource-Beratung
 Click to see the full signature
Reply to
Kurt Harders

Einfach nur mal zum Rumprobieren. Dachte mir, daß das da am einfachsten geht weil auch schon Display dabei und so Sachen.

Für mich gibts (außer Forth oder Bascom) keine Alternative dazu:)

--
Bye, Dietmar
Reply to
Dietmar Belloff

Rafael Deliano :

Eigentlich schon; zumindest war es mal Usenetbrauch unbenutzte Gruppen wieder zu löschen; naja aber mittlerweile würde man da vermutlich die halbe .de- Hierarchie löschen müssen. dse ist mittlerweile eine der frequentiertesten Gruppen ...

M.

Reply to
Matthias Weingart

Gibbet sogar in PY, hab diverse rabbits hier hinter mir (eingepackt) stehen :) Ok, hab sie im Container mitgebracht, aber die Beschaffung in D war nicht so schwierig.

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

## Originalempfaenger: /de/sci/electronics

Jein, bei Forth erledigt das der Kernel für Dich, d.h. wenn das System startbar ist, ist CELL CELL+ ... bereits definiert. Solange Du nicht ganz tief im Schlamm wühlst, brauchst Dich nicht zu kümmern und Du nicht gerade auf einem Marc4 bist, ist es i.a. völlig unerheblich, wieviel bits die HW breit ist. Eine CELL hat mindestens 16bit (Ausnahme Marc4 :)

Wenn es in DPANS Forth geschrieben ist, sollte es eigentlich laufen. Das war das Ziel. Je HW spezifischer Du was programmierst, umso eher geht es latürnich nicht :] Sachen wie ALIGNED... machen das aber auch transparent und braucht man erst, wenn man das letzte an Geschwindigkeit oder Platz rausquetschen muss.

Ich hab auch schon Forth gesehen, wo der IR per HLL definitionen gemacht werden konnte und erst wenn das mal zu langsam sein sollte, dann muss man CODE benutzen. Sehr praktisch bei User Interfaces, der normale Tipper schafft nicht 10 IR/sec, da reicht das völlig und ist dann sehr elegant.

Ich schreibe fast immer erst alles in HLL und teste es interaktiv aus. Wenn das zu langsam ist, programmiere ich die Bremser dann in CODE um, das ist sehr einfach, denn die Struktur hat die HLL definition schon erledigt, muss man dann nur noch abkupfern. Beide def parallel testen/ aufrufen, ggf. in Schleife automatisch, wenns übereinstimmt. bissu feddich. Weiter mit der nächsten Aufgabe.

Mir gefällt auch, dass man bei Forth i.a. Top-Down designed und Bottom- Up programmiert. Da hat man die übelsten Kracher schon sehr früh im Projekt erschlagen und tappt nicht in die Falle: es geht ja schon alles, die ganze GUI blinkt und glänzt und 1 Tag vor Inbetriebnahme fällt auf, das sich die Daten garnicht mit der geforderten Geschwindigkeit einlesen lassen...

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

Jein, ist ein optimierter Z80 mit ein paar Abweichungen im Befehlssatz und ein paar Erweiterungen und leider ein paar `Besonderheiten`. Recht schnell. Nicht alles kann 1:1 vom Z80 übernommen werden.

Jau, ein übler bug!

It`s not a bug, it`s a feature! :o

Haben die das immer noch nicht auf der Reihe? Kümmert sich wohl keiner drum, weil der unbeleckte C-Programmierer das sowieso nicht merkt?!

Ist kein wirklich grosses Übel, nur wissen muss man es :)

Bei den rabbits gibts auch etliche, die statt 2,54 2,0 mm Raster haben. Da wirds dann tricky, wenn man das auf Lochraster aufbauen muss/will.

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

Man kann die deutschen Anwender nicht zwingen, die tummeln sich alle in c.l.f.. "Der Duft der grossen weiten Welt" wie es Peter Stuyvesant formuliert hat. Da es eine recht aktive holländische Gruppe gibt die mit deutsch nicht perfekt klar kommt ist die europäische Integration auf englisch eben einfacher.

Spezifische Probleme sind auch daß in d.c.l.f nicht unbedingt alle Leser über OT-Themen a la Controller, Anwendungen glücklich sind. Und "on topic"-Themen a la "language lawyer"-ismus wie in C keinen Sinn machen, weil alle realen Forth-Systeme unterschiedlich sind.

Gegen eine Löschung von c.l.f würde inzwischen nichtmal mehr von den Forth-Anwendern viel Widerspruch zu erwarten sein. Newsgroups sind generell am absteigenden Ast.

FORTH e.V. experimentiert ( Sinn oder Unsinn egal ) mit allem was neu ist: Forth-Chat per Internet Relay Chat (IRC) Forth auf Twitter usw.

MfG JRD

Reply to
Rafael Deliano

C ist ( auf einer geeigneten CPU ) Alternative zu Assembler, weil es ja eigentlich als maschinenunabhängiger Assembler mit einigen HLL-Erweiterungen gedacht war.

Bei FORTH ist es realistischer wenn man HLL und Assembler im System gut integriert parallel verfügbar hat. Und sich dann bei jedem kleinen Unterprogramm die eine FORTH-Applikation ausmachen frei entscheiden kann ob man es in HLL ( kompaktere Source, einfacher zu debuggen, portabel, aber langsam ) oder in Assembler ( umfangreichere Source, schwieriger zu debuggen, aber schnell ( Faktor 10 )) implementiert.

MfG JRD

Reply to
Rafael Deliano

Nein, die Lernkurve ist steiler, denn auch wenn es weniger Befehle sein mögen, hat man mehr zu beachten und mit den wenigen Befehlen das richtige auszudrücken will auch gelernt sein. Zahlen im Dezimalsystem schreiben ist ja auch einfacher als in Binärsystem. Und wenn dann noch nette Dinge wie spezielle Eigenheiten der einzuhaltenden Abarbeitungsreihenfolge hinzukommen, z.B. daß bei MIPS der nächste Befehl, der nach dem Branch steht, auch noch ausgeführt wird wenn der Branch springt, wenn ich mich recht erinnere, dann wird es wirklich lustig. Besser C nehmen, wenn es geht.

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

Ich meinte du willst dir vermutlich erstmal keinen teuren Debugger kaufen. Das schoene an Renesas ist halt das sie sich auch mit einer normalen RS232 brennen und debuggen lassen.

Ich weiss zufaellig das der im Internet angegebene Preis bei einer Abnahmemenge von 10 noch verhandelbar war. :-)

Ja. Ich glaube mit DIL bekommt man auch nichts aktuelles mehr.

formatting link

So sieht mein Testboard aus. Ich fuerchte ich mag SMD. Man muss sich vielleicht beim loeten etwas mehr anstrengen, aber dafuer braucht man nicht soviele Loecher zu bohren. Und schlimmer noch ich neige dazu exotische Teile zu verwenden die in meiner Bastelkiste rumliegen.

BTW: Wusstet ihr eigentlich schon das rote und gruene LEDs in SOT23 ihre Anschlussse an unterschiedlichen Stellen haben? ARGH!

Linux ist halt besser weil man dann neben dem schreiben in Newsgroups noch etwas programmieren kann. :-)

Das ist jetzt anders. Die Umgebung von Renesas laesst eigentlich keine Wuensche offen. Allerdings braucht man auch laenger als eine Stunde um damit umzugehen.

Das geht mit Sicherheit. Die CPUs koennen mit fast jedem Quarz beliebige Baudraten fahren weil du keinen festen Teiler hast sondern einen einstellbaren Zaehler.

ICh weiss nicht. Ein 68k ist doch nochmal eine Nummer dicker. Ich habe lange den 68332 programmiert. Das ist einfach eine richtig dicke CPU und kein Microcontroller. Da ist ein M16C doch noch etwas ueberschaubarer. Die M16C wurden wohl darauf optimiert codeeffizient zu sein. (z.B nur 24Bit Zeigerregister) Wer aber einen 68k verwendet hat der hat auch immer 512kB Ram/Flash gehabt und dem war sowas total egal.

Olaf

Reply to
Olaf Kaluza

Bei mir auch. Lag aber daran das ich damals noch auf dem Papier assembliert habe. Ausserdem habe ich seit damals eine starke Aversion gegen relative Spruenge. Unheilbar fuerchte ich. :)

Olaf

Reply to
Olaf Kaluza

Das ist sie ohne Zweifel. Das ist ja auch das Gute an ihr, denn u.a. das macht sie so schnell.

Das verstehe ich nicht, irgendwas scheint da nicht zu stimmen, vermutlich fehlt eine Zeile und zwar zwischen Zeile 1 und Zeile 2 entweder ein "ldc [a1],fb" oder ein "mov.w a1,fb". Auf jeden Fall scheint bei dir fb in Zeile 2 noch nicht initialisiert zu sein. Ich kann mich aber täuschen, weil ich den instruction set von Renesas nicht kenne und auch auf die Schnelle nicht auftreiben konnte.

Ich deute das jedenfalls so, daß es sich um eine primitive einfach verkettete Liste von Speicherbereichen handelt, auf die normalerweise über das Register fb mit Offset zugegriffen wird. Auf Offset 20 des jeweiligen Speicherbereiches liegt der Zeiger auf den nächsten, der Zeiger auf den allerersten wird vor Durchlaufen der Kette als immediate value in ein Adreßregister geladen. Wenn das soweit richtig ist, dann würde meine AVR-Implementierung so aussehen (Z entspricht a1, Y entspricht fb):

LDIW Z,_TaskPointer ;2 movw Y,Z ;1 (Das ist, was bei dir IMHO fehlt)

;Zugriff auf die Felder der Taskstruktur ab hier über Y+Offset möglich

LDDW Z,Y+20 ;4 (bei internem Speicher) movw Y,Z ;1

;Zugriff auf die Felder der nächsten Taskstruktur ab hier über Y+Offset ;möglich

Das zweite Zeilenpaar stellt schon die vollständige Iteration über die Taskstrukturen dar. Kostet (ohne Prüfung einer Abbruchbedingung) nur 5 Takte pro Task.

Könnte ich also bei 5MHz CPU-Takt über eine Million Tasks/s iterieren. Naja, dazu bräuchte ich allerdings wenigstens 22MB RAM, die hat mein Kleiner sowieso nicht annähernd...

Die uppercase Memnonics sind übrigens natürlich Macros, geschuldet der Tatsache, daß es sich nur um eine 8Bit-CPU handelt. sie bestehen im Kern jeweils nur aus zwei Zeilen Assemblercode. LDDW z.B. ist (für diesen konkreten Fall vereinfacht) so implementiert:

.MACRO LDDW .IF LITTLE_ENDIAN ldd @0L,@1 ldd @0H,@1+1 .ELSE ldd @0L,@1+1 ldd @0H,@1 .ENDIF .ENDMACRO

Der Assembler von Atmel erlaubt mir auch C-Style-Macros, aber ich spare mir hier mal die Grausamkeiten von Multiline-Macros, Stringification und String-Concatenation, der das Macro genauso unleserlich machen würde, wie der gesamte C-Scheißdreck scheinbar naturgemäß grundsätzlich weitgehend unleserlich sein muß. Nur C-Freaks finden diesen ganzen Scheißdreck logisch und verständlich, ich muß jedesmal grübeln, wenn ich so einen Erguß lesen und verstehen muß.

Whow, das ist C in Reinkultur. Nur als herausragendes Item:

"volatile void *next;"

Ich lach' mich tot. Das ist ein stinkender beschissener Pointer auf irgendwas unbestimmtes. Wozu muß man das erst derart umständlich deklarieren? Typsicherheit is' ja wohl bei der Deklaration genauso wenig vorhanden wie in Asm, oder nicht? Also wozu dann dieses ganze völlig sinnlose Geraffel?

Und komm' mir jetzt bloß nicht mit "Portabilität". Dann zerpflücke ich deine Argumentation schneller als du diese eine Zeile Bullshit schreiben konntest!

Reply to
Heiko Nocon

Was kostet der?

Nur mal so zum Vergleich: MEGA1284P (128k FLASH, 16k RAM) im bastlerfreundlichen DIL40 kostet bei Pollin als EINZELSTÜCK 6,95¤. Und ist nahezu vollständig Pin- und vollständig Instruction-kompatibel zu praktisch allen ATMEGAs bis runter zum MEGA16P.

Sowas nenne ich KONTINUITÄT und VERFÜGBARKEIT. Einziger Wermutstropfen: von der Ankündigung bis zur tatsächlichen Verfügbarkeit hat's fast zwei Jahre gedauert...

Reply to
Heiko Nocon

Ehrlich gesagt weiss ich es nicht mehr genau. Ich glaube ich habe

15Euro fuer 10Stk bezahlt. (inklusive Versand) Aber beschwoeren moechte ich es nicht. Aber die sind ja auch alt.

Ein aktueller M16C29 liegt so bei 5-6Euro. (einstellige Stueckzahlen)

Ich wuerde ja DIL40 als bastlerunfreundlich ansehen. So ein fettes Gehaeuse und dann nur 40Pins? Nein Danke. Da loete ich lieber ein bisschen SMD, spare mir das bohren und habe dann 100Pins.

Ein weitere Nachteil von AVRs. Sie sind nur kompatible zu AVRs. :-D

Glaubst du R8C/M16C/M32 sind nicht Instruktionskompatible? Oh, und wo du soviel Wert auf Kompatibilitaet legst, bei Renesas sind sehr viele Controller auch Gehaeusekompatibel. Genauer gesagt haben sie eine derart grosse Breite an kompatiblen Typen die es dann auch nochmal in Unterteilungen je nach Groesse von Flash und Ram gibt, das ich mich manchmal Frage ob das wirklich not tut.

Aber das ist doch vollkommen normal. Du kannst auf dem Board was ich hier gezeigt habe auch einen aktuellen M16C/6C mit integriertem USB draufloeten wenn du moechtest.

Olaf

Reply to
Olaf Kaluza

Nein da fehlt nichts zwichen. Das ist ja nur ein Ausschnitt. Der Framebuffer stand vorher auf den letzten struct wo die Register der letzten Task gespeichert wurden, und wird jetzt auf den naechsten struct gesetzt um die Daten fuer die kommende Task rauszuholen.

Schonmal ueber kalt Duschen nachgedacht?

Was hast du daran auszusetzen? Was ist daran umstaendlich?

Ich verstehe nicht was du daran als sinnlos ansiehst?

Olaf

Reply to
Olaf Kaluza

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.