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

Noe, ich bin wohl Einzelkaempfer. :-)

Falls du dich dazu entscheidest dann schau mal hier:

Der OP dort hat eine ganze Rolle mit M16C62A und gibt sie sehr guenstig ab. Der M16C62A ist schon was aelter. Deshalb laesst er sich nicht mit den Renesas E8/E8A brennen, sondern nur seriell ueber RS232. Aber ich vermute mal das ist kein Hindernis fuer dich.

Dafuer bekommst du sehr viel CPU fuer dein Geld. 96k Flash, 20kRam!

Ich habe fuer diese CPU ein kleines Testboard gemacht wo RS232, LEDs, I2C, SPI/Grafikanschluss, 1Wire und eine MicroSD Karte drauf ist. Bei Interesse koennte ich das Layout rueberwachsen lassen. (email)

Ausserdem habe ich genau auf dieser CPU einen Multitasker geschrieben:

Selbst wenn man nicht multitasken moechte kann dieses Project interessant sein wenn man unter Linux programmieren moechte. Da ich dort sowohl C (boese :) wie auch Assembler verwende und man nur make eingeben muss (nachdem man den Compiler installiert hat) um ein fertiges Binarie zu erzeugen.

Falls du eine moderne CPU willst dann schau mal hier:

Der M16C/29 ist aktuell und den setze ich auch in der Firma ein. Wirklich ein schoenes Teil. Lies dir mal durch was da alles an Peripherie drin ist.

Solltest du nicht unter Linux programmieren wollen sondern unter Windows dann gibt es dort die Oberflaeche von Renesas. Die heisst HEW und enthaelt den Compiler und den Debugger. Oh..und den Assembler auch. :-) Diese Oberflaeche ist umsonst, allerdings bist du auf einer maximalen Codegroesse von 64kbyte beschraenkt. Das sollte aber fuer Assembler wohl ausreichen. Es soll aber moeglich sein, ich selber habe es nie ausprobiert, auch unter Windows den gcc zu installieren und dann unter HEW zu nutzen.

Ich wuerde dir empfehlen dir diese Oberflaeche mal anzuschauen. Die vielen Moeglichkeiten erschlagen einen zuerst etwas, aber wenn du bisher nur alte 6502 gewohnt bist, dann wird dir bei den Moeglichkeiten des Debuggers vermutlich der Mund offen stehen bleiben.

Noch was zur Erklaerung. Die R8C/M16C haben bieten normalerwiese einen Unterstuetzung fuer einen speziellen Debugger/Brenner von Renesas. Das ist der E8(alt) oder E8a(neu). Zusaetzlich kann man die CPUs aber auch ueber RS232 brennen und debuggen. Der Debugger laedt dann ein Stueck von sich selbst in den Flash der CPU und braucht auch etwas Ram. Allerdings geht dadurch eine RS232 verloren. Da die CPUs aber immer mindestens 2x RS232 haben kann man das normalerweise auch verschmerzen. Ein M16C kann dagegen auch noch mehr serielle Schnittstellen haben!

Und hier noch das Assemblerhandbuch:

Olaf

Weil ich das seit >20J nimmer gemacht hab. Gab damals für den Oric ein Forth aus England, und beim späteren Elektor-Forth (Birkemeyer) war ich ein wenig involviert, weil ich dem Autor mit dem speziellen DOS half. Hab beides glaubich sogar noch, sind aber keine Compiler gewesen.

Damals war ich mit der Notation dank meines HP10C noch vertrauter als heute:)

Wie gesagt, ich kenns noch von früher, hab eben vieles vergessen.

Damals hatte ich das sehr schnell drin und auch bissl was damit gemacht, vor allem weils schön nah an der Hardware war. Neuere Forth-Systeme habe ich mir nach dem Elektor-Dings nimmer angeschaut, stattdessen mich mal versucht mit Pascal, Modula-2 und Oberon anzufreunden (und es sehr schnell wieder seingelassen). Auf dem Atari gabs ja alles. Landete zum Schluß dann doch wieder bei BASIC (Omikron, GFA), Forth gabs auch glaubich, hatte ich aber nie probiert.

Ich schaus mir aber gerne mal an.

Am 21.10.2010 16:34, schrieb Dietmar Belloff:

Assembler auf AVR fand ich angenehm. (Bis ich merkte, daß C auch keine schlechteren Ergebnisse bringt.)

...

MSP430 ist auch nett. Für meine Begriffe ist bei denen die Peripherie aber umständlicher anzusteuern.

...

Ich habe mir "damals" ein AVR-Testbrett selbst gebaut: Einen 40pinner in die Mitte einer Lochrasterplatine, rundherum die Pins mit Pfostenleisten verbunden. Versorung und Quarz direkt angelötet, SPI auf Pfostenleiste mit Standardbelegung für die meisten Programmer.

Im Laufe der Zeit habe ich das Ding ganz einfach durch Verbinden weiterer Pfostenleisten um RS232, einen MMC-Kartenanschluß, USB

Wenn man will, lötet man noch LEDs an die Ports. Dann sieht man immer ungefähr, was gerade passiert.

Billiger und flexibler geht das IMO nicht.

Falk

Forth macht einsam und dick! Weil in de.x.x.x.forth kommt nur alle paar Monate mal ein Posting und dann geht immer darum in welchem Lokal sie sich treffen wollen. :-P

Ach, das gilt doch wohl fuer jede Programmiersprache.

An dem Tag an dem ich meine Controller sprechen hoere haenge ich den Job an den Nagel und ziehe auf eine einsame Insel. :-D

Olaf

Die Jungs aus de.x.x.x.forth haben, vermutlich im Restaurant , auch einen Interpreter fuer das R8C13-Board aus der Elektor geschrieben. Wird dich dann gleich an alte Zeiten erinnern. :)

Olaf

Am 21.10.2010 22:47, schrieb Joerg:

Besser als eingefleischte Vegetarier :-)

Butzo

Herzlichen Dank, wieder was gelernt:)

Assembler kannst Du etwas, BASIC auch, C willste nicht (Full ACK) warum nicht Forth? Da haste alles, von Assembler über HLL bis Metasprache. Alles in einer Umgebung!

Die Deutsche Forthgesellschaft e.V. (FG) freut sich immer, wenn sie uC Boards mit Forth verleihen kann.

google hat mit +deutsche +forth +gesellschaft 955.000 Treffer, bis Mo solltest Du da durch sein :)

BTW, wenn Du das Forth Grundkonzept mal kapiert hast (da reichen wenige Stunden!), dann sehen alle CPUs gleich aus, jedenfalls solange Du den Assembler nicht einschaltest. Sie sind nur unterschiedlich schnell.

Denn das Geheimnis ist: Forth ist eine virtuelle Maschine, die interaktiv mit Dir spricht. Das kennst Du ja schon von Basic und selbst bis auf Bitebene kannst Du mit HLL arbeiten.

Die FG hat auch vieles für (Neu)einsteiger zu bieten.

Saludos Wolfgang

Nö, ich hab hier ein T40 mit Minidock extra für sowas stehen, der hat noch richtige Schnittstellen dran:)

Allerdings. Danke schonmal für den Tip, den schreib ich mal an!

Gerne, ich melde mich dann bei Dir.

Die Dinger sind allerdings keine DIL-Gehäuse, also SMD löten? Erschwert das Ganze etwas, aber wird schon gehen.

Da mein T40 eine leicht wechselbare Festplatte hat könnte ich da auch Linux draufpacken. Mache ich nur nicht, nicht noch ein OS. Da ist XP drauf, das muß reichen, sind sonst zuviele Baustellen.

Ich finde ja schon die aktuellen Möglichkeiten mit Flash und ISP genial, davon konnte ich damals nur träumen. Schon der kurzzeitig genutzte 6809 war eine Offenbarung beim Programmieren, das genutzte Host-System (Dragon32/64) dagegen eine Katastrophe ... Habe mir damals einen EPROM-Simulator gebaut um die Brennereien zu umgehen. Die ganze Entwicklungsumgebung damals war sowieso mehr oder weniger selbstgestrickt ...

Das denk ich auch. Wobei ich das Ding für MIDI-Anwendungen einsetzen will, da brauche ich ja nur eine der beiden Seriellen, mit geänderter Baudrate. Muß mal schaun ob das mit dem Ding überhaupt geht (31,25Kbaud). Spezielle Programmer mag ich gerne umgehen, kommt mir also gerade recht.

Herzlichen Dank. Schau ich mir mal an. Wie gut, daß ich noch meine Bücher zu den 68k-CPUs habe, schätze mal die kann ich da brauchen. Irgendwo fliegt sogar noch eine 68008 rum:)

Wenn Du mich fragst, dann so in etwa...

: MAIN TASK# off \ mit 1. TASK anfangen BEGIN TASK# >task EXECUTE \ Task ausführen ESC? ABORT" was Du wollen?" \ Operator Eingriff :)

TASK# INC \ nächste TASK TASK# maxTASK# >= IF TASK# off THEN AGAIN ;

\ :p

Wie ich schon an anderer Stelle schrieb: in FORTH sehen alle CPUs gleich aus :)

Saludos Wolfgang

Kommt darauf an in welche Richtung Du gehen willst, mit dem Butterfly bist Du schon ziemlich eingeengt. Würde auch ehr zu den Pollin-Boards greifen oder zu einem STK500 das sehr viele ATmegas unterstützt.

Ich habe früher auch alles in Assembler gemacht, aber heute gibt es da wirklich fast gar keinen Grund mehr dafür...

Gerald

War ein Fehler von Dir, sich nicht anzusehen, was ein Forther mit einem uC anstellen kann. Alle HW Fritzen waren bisher immer leicht zu begeistern. Sie können nach wenigen Stunden/Tagen Einarbeitung in Forth ihre uC in der HW austesten und ihre HW ohne Untserstützung eiens Softies in Betrieb zu nehmen.

Die SW Leuts tun sich da schwerer, dennen bricht ein Kartenhaus zusammen und das wollen sie nicht wahrhaben :)

Nein.

Saludos Wolfgang

Hmm, und ich dachte, das mit dem dicker werden wäre bei mir ein körperliches Gebrechen: extremes Hohlkreuz und Bindegewegsschwäche :)

Eigentlich nicht, denn alle anderen Programmiersprachen haben HW Abhängigkeiten von denen dich die Forth engine erstmal völlig freistellt. Je weiter Du dann aber an die HW kommst, gibt es dann ggf. aber auch die eine oder andere Besonderheit. Die serielle Schnittstelle ist normalerweise integraler Bestandteil der Forth engine, da brauchst Du dich nicht zu kümmern, bei anderen Sprachen suchst Du nach passenden Modulen und sei es nur für die Initialisierung...

Mit anderen Worten: die Kommunikation mit dem Target ist eingebaut. Ebenso der Compiler im Target.

Forther ätzen:

Bei C hat der Programmierer den Compiler im Kopf. Bei Forth hat der Programmierer den Compiler im Target. :)

Sprachausgabe mit Forth hab ich schon gemacht. War IIRC mit einem Phonem Generator so um 1985. Ging recht gut, klang etwas blechern aber war um Welten besser und vor allem extrem Kompakt. Damals waren Eproms klein und teuer...

Saludos Wolfgang

Das ist in Forth genauso schlimm hardwareabhängig wie z.B. in C. In beiden Sprachen ist z.B. nicht exakt definiert, wieviel Bits ein "int" in C, oder eine "cell" in Forth hat. Und in Forth hat man dann noch je nach Hardware oder Implementierung Dinge wie Alignment usw. zu beachten, wovor einen C meist bewahrt. Kann also gut sein, daß ein standardkonformes und hardwareunabhängiges Programm dennoch nicht in jeder ebenfalls standardkonformen C oder Forth Implementierung läuft.

Gut ist natürlich bei Forth, daß es nicht so speziell notwendige Schlüsselwörter gibt um z.B. eine Interrupt-Funktion zu kennzeichnen. Das wird dann in Forth per CODE direkt in Assembler programmiert ;-)

Olaf Kaluza :

Vom Z80 gibts doch auch nen netten Nachfolger: den Rabbit. (rabbit.com) Z80 ist ja auch cool, weil ich da die Hexentsprechung der Befehle noch im Kopf hab C3-JMP, C9-RET usw., das ging sogar mal ohne die asm.com :-). Verfügbarkeit ist in .de aber eher mies denk ich.

M.

Ich habe mir den Butterfly vor einigen Jahren zugelegt aber nie etwas damit gemacht. Ist ne tolle Sache, aber meiner Meinung nach für den Anfang zu umständlich.

Besser ist es, ein möglichst einfaches Board, z.B. von Pollin zu nehmen, oder einfach einen ATmega8 auf Lochraster oder Steckbrett aufzubauen.

Was mich begeistert hat, war der problemlose Einstieg in WinAVR bzw. GCC. Das Installationsfile für Windows runterladen, installieren und läuft.

Dazu noch Ponyprog und los gehts.

Für die Anpassung des Makefiles muss man vieleicht im Web etwas suchen und lesen, ist aber auch keine große Sache.

Gruß

Stefan DF9BI

Hat sich nicht sehr verändert.

Den Verein gibts weiterhin:

Von mir noch eine Zeitschrift auf pdf für Controller die bestenfalls 1x/Jahr erscheint und nicht so frei zugänglich ist:

Es gibt auch andere Implementierungen aus hierzulande z.B. für R8C:

MfG JRD

Falk Willberg :

Der MSP430 ist in Assembler recht bequem zu handhaben, 16 Register, auf die man alle Befehle anwenden kann. Haben die sich wohl von ner alten DEC PDP-11 abgeguckt. Spart das ständige rein- und rausgelade im Vergleich zu rein akku- basierten Controllern. (Praktisch hat man 12 universale Register und 4 spezielle, nen dedizierten Akku gibt es aber nicht). Entweder sind es 16 bit Register oder 20bit (MSP430F5*).

Die Peripherie ist komplizierter zu konfigurieren als bei andren Controller

- Ursache ist ganz einfach die grössere Flexibilität die man da hat.

M.

Ist beim AVR auch so, dazu noch 16 weitere Register, die man für viele Befehle verwenden kann.

Seit meinem ersten C-AVR-Projekt habe ich Assembler aber noch nicht wieder vermisst. :-)

Gruß Henning