Hallo,

das Board ist heute angekommen.
Der Anschluss klappt wunderbar, hat dann auch erstmal ein Firmwareupdate gemacht ohne Probleme.
Standartmäßig ist ein ATMEGA8515 auf dem Board.

Ansonsten habe ich das vorinstallierte Programm mal gelöscht und ein einfaches, welches ich per Copy&Paste aus dem Internet habe auf den Chip geflasht.
Klappt soweit auch alles wunderbar.

Aber trotzdem stehe ich hier noch ziemlich planlos da.
Auch aus dem Tutorial von mikrocontroller.net für AVR werde ich nicht schlauer.
Schon im ersten Satz werden Wörter durch den Raum geworfen mit denen ich nichts anfangen kann.

Gibt es villeicht ein gutes Buch bei denen auch wirklich die Grundlagen beschrieben werden?
Also auch der Aufbau und die Funktionsweise des Controllers, die Grundbefehle in Assembler mit praktischen Beispielen welche man dann am Board testen kann?
Oder gibt es sogar so etwas als Tutorial im Internet?

Bei mikrocontroller.net z.B. ist folgendes Beispiel direkt am Anfang des Tutorials
"include "m8def.inc" ; Definitionsdatei für den Prozessortyp einbinden

ldi r16, 0xFF; lade Arbeitsregister r16 mit der Konstanten 0xFF
out DDRB, r16 ; Inhalt von r16 ins IO-Register DDRB ausgeben

ldi r16, 0b11111100 ; 0b11111100 in r16 laden
out PORTB, r16 ; r16 ins IO-Register PORTB ausgeben

ende: rjmp ende ; Sprung zur Marke "ende" -> Endlosschleife "

Aber dort wird verlangt, dass man die Grundkentnisse ja schon besitzt.
Denn was ist denn das ARbeitsregister? Was ist DDRB?

Klar, man kann das alles einzeln bei Wiki nachschlagen aber da wird man noch unsicherer weil dort alles bis ins kleinste Detail erklärt ist und nicht nur die Grundlagen fürs Erste.

MfG
d0um

Zitat :

Denn was ist denn das ARbeitsregister? Was ist DDRB?

Das alles steht im Datenblatt des Prozessors, das du gründlich lesen solltest, bevor du eine konkrete Schaltung aufbaust.

Weil diese Datenblätter vom Hersteller gepflegt werden, sollte man auch stets die neueste Version verwenden, denn manchmal werden erst erst nach der Auslieferung der Chips Probleme offenbar, deren Umgehung "Workaround" oder Behebung in den Datenblättern bzw. den Addenda dazu beschrieben wird.

Ausserden gibt es gewöhnlich ein zusätzliches Dokument, das den Befehlssatz "Instruction Set" bis ins Detail beschreibt.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Wie erwähnt, erfolgt das Programmieren in Assembler verdammt hardwarenah, du wirst also nicht ums Datenblatt herumkommen.

Dort ist, wie ich bereits erwähnte, auch eine Instruction Set Summary dabei, die wirklich alle Mnemonics samt Operatoren und Statusregister-Änderung beinhaltet.

Zudem enthält das komplette Datenblatt auch Beispielkodes zu bestimmten Sachen, somit erklärt sich auch noch einiges.

Die Datenblätter von Atmel, muss man einfach sagen, sind so gut, dass man damit eigentlich alleine lernen könnte .

_________________

Danke!

Das ist ja ein ganzes Buch das Datenblatt mit über 200 Seiten.

Nur wird man halt von der Menge an Informationen regelrecht erdrückt.
Wie gesagt, ich denke ein gutes Buch ist das Beste für den Anfang bei mir.

Eines welches auch die Grundlagen von Anfang an erklärt.
Sonst sehe ich wirklich schwarz...

Die Grundlagen bestehen doch aber nur aus den diversen Logikbausteinen.

eine CPU macht, mal vereinfacht ausgedrückt, nichts anderes.

Ich habe mir damals die Liste mit den Befehlen ausgedruckt, und täglich in der Bahn gelernt.

Zudem ist in der Hilfe/Dokumentation zum AVR Studio eine exzellente Bescheibung aller Befehle, sogar mit Opkodes und so weiter, enthalten.
Das ist eines der wenigen Windowsanwendungen, die ich vermisse, seit ich auf Linux umgestiegen bin.


Das blöde ist bei dir, dass, soweit ich mich recht entsinne, du keine Programmiersprache beherrscht, also gewisse Grundlagen aus dieser Sicht fehlen.

Allerdings kann das auch ein Vorteil sein, denn wenn man beispielsweise Basic oder C++ kann, dann kommt einem Assembler, also das direkte Programmieren in Maschinensprache, etwas "umständlich" und langatmig vor .

_________________


[ Diese Nachricht wurde geändert von: DonComi am 20 Dez 2007 19:22 ]

Genau das ist das Problem bei mir!

Ich habe ja keine Probleme letztendlich die externe Beschaltung zu realisieren wenn der µC erstmal programmiert ist.
Aber da ich wirklich absolut null Erfahrung mit Programmiersprachen habe sind die Programmtexte für mich nur eine willkührliche Aneinanderreihung von Worten.

Vor allem wird sich an jeder Ecke gestritten ob denn nun C oder Assembler besser/einfacher ist.
Da ich im Moment von keinem eine Ahnung habe würde ich das nehmen, wo man schneller Erfolgserlebnisse hat.

Was ich mich als frage:
Ist es villeicht "einfacher" am Anfang einen ATtiny mit Minimalausstattung zu nehmen?
Dort habe ich nicht so viele IO Ports ect..
Und je weniger Ausstattung desto weniger Verwirrung.
Bzw. gibt es villeicht allgemein einen µC von Atmel der "gutmütig" ist.
Ich brauche ja den ganzen Schnickschnack wie A/D Wandler ect. nicht für den Anfang.
Das sind nur zusätzliche Fehlerquellen...

Zitat : d0um hat am 20 Dez 2007 19:58 geschrieben :

Vor allem wird sich an jeder Ecke gestritten ob denn nun C oder Assembler besser/einfacher ist. Da ich im Moment von keinem eine Ahnung habe würde ich das nehmen, wo man schneller Erfolgserlebnisse hat.

Auch wenn mich DonComi und Jornbyte gleich wieder schlagen werden.
Aber ich hatte meine ersten (nachvollziehbaren) Erfolgserlebnisse mit Bascom + einem Mega8.
Dafür gibts ein (nach meiner Meinung) sehr gutes deutsches Buch von Roland Walther.Assembler ist mir nach wie vor so unbekannt wie das innere des Mondes,aber mit der an Basic angelehnten Bascomsache habe ich das zumindest soweit kapiert,einfache Sachen selber proggen zu können.Sogar den A/D Wandler hab ich irgendwann verstanden.

_________________
Manche Männer bemühen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitätstheorie.
(Albert Einstein)

Im Moment habe ich einen ATmega8515L drauf.
Aber ich habe auch noch einen ATmega 16 und einen ATmega 32.

Ich weiß nicht inwiefern sich Vor- bzw. Nachteile sich mit den Chips bzgl. bestimmter Programmiersprachen ergeben.
Aber Basic soll wohl nur für bestimmte Chips gehen und keine Zukunft haben falls man mal ein bisschen weiter gehen möchte.

Moin,

Wie gesagt, wenn du wirklich ernsthafte Sachen mit den µCs machen willst, dann rate ich von Basic ab, egal, ob man damit schneller Erfolge bekommt oder nicht.

Einen Erfolgt bekommt man auch damit:
.include "m8.def"
ldi r16, 1
out DDRA, r16
out PORTA, 1
ende:
rjmp ende
;Dieses Programm kann eine LED anschalten, die an bit0 des Ports A hängt.

Das ist so das einfachste Programm, das man sich vorstellen kann.

In Basic wäre das Ganze wesentlich komplexer und redundanter:

$include "mega8"
$baud = 9600
$crystal = 1000000

Config Porta.0 = Output

Porta.0 = 1

End


Also, davon mal abgesehen, dass das selbe in reinem Assembler nur 8 Bytes benötigt ist es wesentlich einfacher zu verstehen als dieser abstrakte Basicklimmzug.
Ich rate auch gleich von C ab, denn C ist eine sehr umfangreiche, komplexe Sprache. Du müsstest dich quasi in zwei neue Welten einarbeiten: in die Hardware der µController und in die Programmierung mit C. Das kann frustrierend werden.
Später, wenn Assembler so weit kein Problem mehr ist und dir der µC vertrauter ist, dann kannst du C lernen. Der Compiler für C erzeugt so guten Maschinenkode, dass da ein Assemblerprogrammierer kaum mitkommt. Sicherlich wären in manchen Situationen manuelle Assemblerprogramme wesentlich effizienter, aber auch nicht mehr einfach portabel, also für andere Architekturen nutzbar.

Beispielsweise laufen auf einigen Kontrollern von mir C-Prozeduren, die 1:1 auch auf einem alten 438er mit Unix laufen.
Das geht mit Assembler nicht, da es einmal der x86-Satz und einmal der AVR-Satz ist.
Die AVR-Assemblersprache ist aber für diese Controller verdammt gut entwickelt und die Dinger sind sehr schnell und effektiv. Wenn ich da an andere Kontroller denke, merke ich, wie angenehm AVRs sind.



---
So, ihr wolltet meine Meinung dazu, da habt ihr sie.

_________________


[ Diese Nachricht wurde geändert von: DonComi am 20 Dez 2007 21:27 ]

Zitat :

Auch wenn mich DonComi und Jornbyte gleich wieder schlagen werden.

Hatte ich das schon beendet?

@d0um
Aber nun im ernst. So ein Controller besteht aus einem Taschenrechner, einem Wecker, ne Reihe an D-FlipFlop und Schieberegister, Ram und EEProm. Den Programmflash lasse ich mal weg. Wozu der da ist.. na der "merkt" sich dein Programm. Du könntest nun denken ich würde dich veräppeln wollen, dem ist nicht so.
Fangen wir noch mal mit dem Taschenrechner an. Das ist der eigentliche Prozessor. Darin sind Register. Wir rechnen mal 1+2+3.
Da wird jeder Wert in ein Register geschrieben, das ist so beim Taschenrechner. Der Atmel hat 32 Stück davon. Die werden für die Abarbeitung des Programms gebraucht.

Was ist der Wecker? Ein einfacher NE555, nein ist es nicht aber von der Funktion her fast vergleichbar wenn es um Zeit geht. Das Ding wird da Timer genannt. Mit dem kannst du Vor oder Zurück zählen oder in einer bestimmten Zeit was zählen lassen. Natürlich musst du dem Timer sagen, was er wie machen soll. Deinem Wecker sagst du ja auch, wann er in der Morgenstunde bimmeln soll.

Nun kommen wir mal zu paar LED oder so was. Das soll draußen angeschlossen werden. Dazu sind die oben erwähnten D-FlipFlop zuständig. Das sind die Port's. Wenn da was geschaltet werden soll, müssen die ja auch wissen, was wann wo geschaltet wird. Das gute an den Dinger ist, die können dem Proz auch sagen, was "draußen" los ist. Dazu müssen die die Richtung wechseln, also Schalten die nix raus sondern rein. Einen Befehl haste schon benannt, DDRB.

Wozu ist (sind) Schieberegister da? Damit kannst du z.B. eine Serielle Schnittstelle (die UART's) betreiben. Auch diese will wissen, wie schnell es gehen soll.

Nun ja, es soll ja kein Buch hier werden. Ich wollte dir nur aufzeigen, dass es verschiedene Komponenten in so einem kleinen Käfer gibt. Damit sind wir auch wieder beim Ausgangsthema. Es ist egal, ob du mit ASM, C oder Basic Programme schreibst. Den Inhalt von so einem Keks lernst du nur mit ASM richtig kennen. Die Befehle teilen sich also in verschiedene Bereiche (Gruppen) auf. Befehle für den internen gebrauch und für die Peripherie. Hier ist die Peripherie gemeint, was am Käfer intern angeschlossen ist, also nicht mit einem Draht verbunden werden muss. Daher unterscheidet man auch zwischen interner und externer Peripherie.

Du hast auch so eine "include m8def.inc" angesprochen. Du wirst diese Dateien lieben, wenn du deren Sinn verstehst. Aber auch das ist einfach. Dazu verwenden wir mal den PortB,0. Das Datenblatt vom Mega8 sagt das er am Pin 14 angeschlossen ist. Beim Mega8515 ist es Pin 1 am Chip. In einem Programm sagst du lasse die LED am PortB,0 leuchten, die Include sucht, wo das steckt und trägt die richtigen Werte selbst ein. Nur so ist es auf einfache weise möglich, den Keks gegen einen anderen auszutauschen.

Das soll nun für heute genügen, will noch ein trinken...


_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

Zitat : DonComi hat am 20 Dez 2007 21:24 geschrieben :

...Das ist so das einfachste Programm, das man sich vorstellen kann...

Vielleicht nicht das Einfachste, aber das Falscheste.
Leider hat dein Programm mehr Bugs als Bytes:
Der Name des Include-Files stimmt nicht,
der Mega8 hat keinen PortA
und wenn er den hätte, könntest du ihn nicht direkt adressieren.


Ich fürchte, dass ein Anfänger mit der Umsetzung und dem Debuggen solcher Beispiele überfordert ist.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !


[ Diese Nachricht wurde geändert von: perl am 21 Dez 2007  0:02 ]

Sehr geehrter perl,

Hier ging es um ein Beispiel, dass sowieso nicht 1:1 kopiert werden sollte. Und ob die Datei jetzt m8.def oder m8def.inc oder meinetwegen m8.h heißt ist völlig egal, das hängt u.a. vom Compiler/Assembler und von den Benennungen der Definitionsdateien ab.
Und das der PortA beim mega8 nicht vorhanden ist, spielt hier auch keine Rolle, hab einfach, da ich ja sonst auch noch anderes zu tun habe, ohne viel Nachzudenken m8 geschrieben.

Hätte ich sowas gemacht, wie

ldi foo, 12
out bar, foo

würde ein Compiler auch meckern, wenn die Bezecihner unbekannt sind.

Also, lass doch solche Beiträge, ich habe sonst auch noch genug andere Dinge zu tun und kann mir sowas ersparen.


_________________


[ Diese Nachricht wurde geändert von: DonComi am 21 Dez 2007  0:44 ]

Schöne Erklärung von Jornbyte.
Ich würde auch empfehlen, zuerst den Assembler der einen Maschine
zu lernen. Chipwechsel halte ich für Quatsch, das Prinzip bleibt
immer das Gleiche und man muss ja anfangs nicht alle Peripherie
nutzen, die der Chip hergibt.

Nachdem Du einmal den Assembler eines Prozessors verstanden hast,
ist es auch nicht mehr so schwer, sich in andere Architekturen
einzuarbeiten.
Das Ding kennt eigentlich nur eine Reihe von ziemlich doofen Befehlen,
die es ähnlich auch bei anderen Prozessoren gibt.
Es gibt mehrere Register, die man laden kann ( quasi eine Schublade,
wo ein beliebiger Wert drin steht ) und andere Befehle machen dann
z.B. eine Rechenaufgabe ( +,-, and, or usw. ) mit den Werten in 2
Schubladen und das Ergebnis wird dann wieder in eine andere Schublade
ablegt.

Das Ergebnis lässt sich dann von einer "Schublade" z.B. mit anderen
Assembler Kommandos auf die Portpins ausgeben.

Ich halte auch den Einstieg über Assembler für die didaktisch
geschickteste Variante.
Wenn man zuerst eine Hochsprache lernt, kann man die Programme zwar
schneller erstellen und sie sind portabel, aber wenn man damit
anfängt, kennt man den technischen Hintergrund nicht und weiss nicht,
was "unter dem Blech" passiert. In Assembler weiss man ganz genau, was
wann passiert und kann das Timing exakt vorhersagen.
Hochsprachen lösen es einfach irgendwie ( meistens vielleicht sogar
performanter, als man es selbst in Assembler hinbekäme ).
Der Nachteil ist dann, dass man einer Blackbox vertrauen muss und
Fehlverhalten mitunter nur durch try&error wegbekommt.
Das Programmieren ist in Hochsprache abstrakter und einfacher, aber
damit allein hat man nicht den Durchgriff, wenn was nicht so läuft,
wie man es sich gedacht hat. Wenn man den darunterliegenden Prozessor
und seinen Assembler kennt, kann man ausserdem C-Programme schreiben,
die spezifischen Eigenschaften des Prozessors entgegenkommen.

Es ist alles kein Teufelswerk oder nur für Super-Überflieger zu begreifen.
Die Asssembler-Kommandos sind an sich recht simpel, wenn man einmal
verstanden hat, wie die Maschine prinzipiell funktioniert.

Ich würde sagen, Datenblatt lesen, und ein einfaches SELBST erstelltes
Programm versuchen ( Taster gedrückt->LED ein, Taster offen->LED aus).
Später dann vielleicht ein Lauflicht mit Warteschleife usw.

Gruß,
Stefan


[ Diese Nachricht wurde geändert von: Nukeman am 21 Dez 2007  0:48 ]