Hallo zusammen.
Ich bearbeite gerade ein Buch, um mich in die Programmierung von
Microcontrollern ein zu arbeiten.
Dazu habe ich Eclipse mit AVR-Erweiterung eingerichtet und möchte jetzt
die Beispiele durchgehen.
Das Beispiel:
1
2
#include<iostream>
3
#include<avr/io.h>
4
#include<avr/iotn13.h> // ATtiny13
5
6
usingnamespacestd;
7
8
#define TAKT 1000000UL // Unsigned long 32 Bit Bereich 0 - 4.294.967.295
9
#define BAUD 9600UL // Standard ist 16 Bit Bereich 0 - 65535
10
11
12
intmain(){
13
14
intx=0;
15
x=TAKT/(16UL*BAUD)-1;// Beispielberechnung
16
cout<<"x = "<<x<<endl;// Kontrollausgabe
17
}
In der Console von Eclipse erscheint nur der Ausführungspfad, sonst
nichts.
In anderen Projekten funktioniert das cout. Wieso hier nicht?
Gruß
Frank
Woher soll denn bitte der AVR wissen, wohin das cout gehen soll? Das
wird so nix. Du musst schon ein bisschen Grips in die µC-Entwicklungs
stecken.
Gruß
Marius
Frank Thie schrieb:> In der Console von Eclipse erscheint nur der Ausführungspfad,> sonst nichts.> In anderen Projekten funktioniert das cout. Wieso hier nicht?
Ähm.
Wie und wo soll denn der AVR was ausgeben, wenn du nach cout schreibst?
UART? (welche Baudrate ist eingestellt, wieviele Bis per Zeichen, Stopp
bits)
LCD? (welches genau. Text? Grafik?)
7-Segmentanzeige?
LED-Matrix?
Morsecode-Ausgabe?
Bluetooth?
Sieh es ein.
Ein AVR hat per Default keine Konsole. Wenn du eine haben willst, dann
musst du sie dir erst mal selber machen.
Genau das ist einer der UNterschiede zum erlernen einer
Programmiersprache auf dem PC. Ein PC hat per Default so etwas wie eine
Konsole, da er einen Bildschirm hat und die Runtime davon weiß. Und die
Programmierumgebung ist so eingerichtet, diesen auch zu benutzen und als
cout zur Verfügung zu stellen. Ohne das du etwas dazu beitragen muss.
Auf einem AVR fängst du ganz unten bei nahezu 0 an. Es gibt so gut wie
keine Infrastruktur, die aus dem Stand heraus ohne dein Zutun für dich
benutzbar wäre.
Frank Thie schrieb:> Ich bearbeite gerade ein Buch, um mich in die Programmierung von> Microcontrollern ein zu arbeiten.
Welches?
Weil, C++ cout auf einem ATtiny13 ist schon ein sehr sportlicher
Versuch. 1 k FLASH, 64 Bytes RAM. Da passt nicht mal ein Bruchteil der
internen Kontrollstrukturen eine C++ Streams rein.
Und wenn demnächst wieder jemand ankommt, der mir erzählen will, dass
man Mikrocontroller nicht mehr in Assembler oder C, sondern mindestens
in C++ programmiert, der soll mir mal cout auf einem ATtiny13 vorführen.
M, nicht Q schrieb:> Und wenn demnächst wieder jemand ankommt, der mir erzählen will, dass> man Mikrocontroller nicht mehr in Assembler oder C, sondern mindestens> in C++ programmiert, der soll mir mal cout auf einem ATtiny13 vorführen.
Der springende Punkt ist, dass cout (oder stream Ausgabe) keines von den
C++ Featuren ist, die auf einem µC (besonders nicht auf den kleinen),
einen irgendwie gearteten Sinn machen.
Hallo.
Danke für die rege Beteiligung.
Das Buch heist
"Microcomputertechnik mit Controllern der Atmel AVR-RISK-Familie".
Und weil ich vorher ein Buch mit C++ durch hatte, dachte ich, es ging
mit cout und wurde von mir eingefügt, um x zu kontrollieren.
Die Berechnung selber soll nur die Verwendung der Variablen darstellen
und nicht einem tieferen Sinn genügen.
Der ATtiny13 stammt noch von einem Blink-Versuch, andere ucś sind
bestellt.
Im Buch wird ein ATmega16 verwendet.
Ich dachte, wenn ich "#include <iostream>" verwende, könnte ich cout
verwenden. Ich werde es mal mit printf versuchen.
Dank und Gruß
Frank
@ Karl Heinz.
Danke für die Erläuterung.
Da der Code ja noch auf meinem Rechner läuft und so garnicht auf dem uc
laufen soll, dachte ich daran, Kontrollen von Variablen mit cout ein zu
richten.
Frank Thie schrieb:> @ Karl Heinz.>> Danke für die Erläuterung.>> Da der Code ja noch auf meinem Rechner läuft
Der 'läuft' ganz sicher nicht auf deinem Rechner.
Der läuft höchstens innerhalb eines Simulators. Die nobelste Aufgabe
eines Simulators ist es aber, die zu simulierende Hardware (hier den
Tiny13) in möglichst allen Details 100% nachzubilden. 100% nachbilden
bedeutet aber auch: wenn der Tiny13 keine Konsole hat, dann hat auch der
simulierte Tiny keine. Was es aber in der Simulation gibt: einen
Debugger, mit dem du dir den Zustand der simulierten Umgebung bzw. die
Werte von Variablen ansehen kannst, während der simulierte Tiny13
innerhalb der Simulation dein Programm abarbeitet.
Benutze für deine C++-Studien einen PC-Compiler und keinen AVR-Compiler.
Soweit kannst du deinem C++ Compiler schon über den Weg trauen, dass er
C++ Code korrekt umsetzt. Für alles andere kannst du so vorgehen
* benutze den Simulator/Debugger
* wenn du in der realen Hardware ein LCD am µC hängen hast, dann benutze
das (mit den dafür zuständigen Funktionen), um dir Zwischenwerte
ausgeben zu lassen
* selbiges mit der seriellen Schnittstelle
* hast du ein Problem mit einem Algorithmus, der dem Prinzip nach
unabhängig von der Hardware ist, dann bette den Algorithmus in ein PC
Programm ein, und debugge den Algorithmus am PC um den Denkfehler zu
finden.
Karl Heinz schrieb:> Der springende Punkt ist, dass cout (oder stream Ausgabe) keines von den> C++ Featuren ist, die auf einem µC (besonders nicht auf den kleinen),> einen irgendwie gearteten Sinn machen.
Eben.
Frank Thie schrieb:> Da der Code ja noch auf meinem Rechner läuft und so garnicht auf dem uc> laufen soll, dachte ich daran, Kontrollen von Variablen mit cout ein zu> richten.
Auf deinem Rechner ist das ok. Auf dem AVR gibt's halt einfach kein
cout. printf gibt es dort auch, aber du mußt wie erwähnt dazu erst
definieren, wo die Ausgaben hingeschrieben werden sollen.
Dein Programm sieht aber weder für den PC, noch für den AVR passend aus,
da einerseits #include <iostream>, was es auf dem AVR nicht gibt und
andererseits #include <avr/io.h>, was es auf dem PC nicht gibt.
Noch eine Anmerkung:
Frank Thie schrieb:> #include <avr/iotn13.h> // ATtiny13
Das macht man nicht. Man gibt avr/io.h und teilt dem Compiler über
-mmcu=atttiny13 mit, welchen Prozessor man hat. Das prozessorspezifische
Header-File wird dann automatisch dazu passend gewählt.
Frank Thie schrieb:> Ja wie kann ich denn dann Variableninhalte kontrollieren?
Mit einem Debugger oder indem du dir den Variableninhalt über ein
geeignetes Interface (Display, UART, Funk etc.) an ein Gerät sendest,
das Daten ausgeben kann.
Edit: Wobei der Debugger hier wegfällt.
Daniel H. schrieb:> Mit einem Debugger oder indem du dir den Variableninhalt über ein> geeignetes Interface (Display, UART, Funk etc.) an ein Gerät sendest,> das Daten ausgeben kann.
Allerdings, und genau darauf wollte ich ja die ganze Zeit hinaus, sind
das alles Dinge, die man sich auf einem AVR erst mal selber machen muss.
Was wiederum bedeutet, dass man das dann schon können muss.
Da hat man es auf dem PC leichter. Denn dort ist cout schon sinnvoll mit
einem Ausgabegerät verknüpft, wenn main() startet.
Aber Frank, ich kann dich beruhigen.
Bei deinen ersten Programmen wirst du das alles nicht sehr vermissen.
Denn all das sind Dinge, die gerade für die ersten programme nicht sehr
typisch sind. IN deinen ersten Prgorammen wird nicht viel gerechnet und
das was gerechnet wird, das kannst du im Kopf leicht nachvollziehen. Und
wenn nicht: Ab in den Debugger damit und nachgesehen was wirklich
passiert.
Zum anderen stellt sich auch des öfteren die Frage "welcher
Programmzweig wird denn zb in einem if wirklich genommen". Fragen dieser
Art kann man zb durch Aufleuchtenlassen einer LED (oder eben nicht
aufleuchten) einfach klären.
Also: so schlimm ist es nicht. Es gibt Möglichkeiten zum Debugging. Aber
es sind halt andere als du es am PC unter Mithilfe von cout gewohnt
warst.
@Karl Heinz
Achso, wenn ich AVR Eclypse benutze, dann läuft das über einen
Simulator, Danke für die Info.
LCD und so hatte ich noch nicht, ich bin gerade bei meinem ersten
Beispiel im Buch und war überrascht, das cout nicht funktionierte. Aber
jetzt weis ich ja, warum. Danke also.
@ Rolf Magnus
Ich hatte mit #include <iostream> versucht, cout zum laufen zu bekommen,
wusste ja noch nicht, das der attiny simuliert wird und es also garnicht
funktionieren kann. Werde also #include <iostream> rausnehmen.
Wenn ich "-mmcu=attiny13" einsetze, kommt "expected unqualified-id
before ‘-’ token".
@ Daniel H
Das sind ja Themen für Fortgeschrittene, das kommt wohl noch später,
aber Danke.
@ Karl Heinz
Danke für den Tipp mit der LED und für die weiteren Erläuterungen und
für dein Mut machen.
War halt nur überrascht, das cout nicht funktionierte, aber das hat sich
ja geklärt. Ist halt blöd, wenn beim ersten Programm was nicht
funktioniert aber mit eurer Hilfe hab ichs ja verstanden.
Danke also an alle
und Gruß
Frank
Frank Thie schrieb:>> Achso, wenn ich AVR Eclypse benutze, dann läuft das über einen> Simulator, Danke für die Info.
Was meinst du mit "AVR Eclypse" ? Was genau hast du installiert?
Oliver
Eclipse:
The AVR Plugin is an extension to the C/C++ Development Toolkit to
support development for the Atmel AVR series of embedded processors.
Aber was ist hiermit?
Wenn ich "-mmcu=attiny13" einsetze, kommt "expected unqualified-id
before ‘-’ token".
Frank
Frank Thie schrieb:> Eclipse:> The AVR Plugin ...
Ok. Dann mal Klartext: Du hast keinen Simulator.
Eclipse ist ein erweiterter Editor, mehr nicht. Das braucht zum
compilieren einen Compiler, den du zusätzlich installieren musst. In
deinem Fall ist das der avr-gcc. Das AVR-plugin sorgt nur dafür, daß
Eclipse passende makefiles für den AVR-gcc erzeugen kann. Da ist kein
Simulator dabei.
Der avr-gcc erzeugt code für einen AVR (welch Überraschung). Dieser Code
läuft nicht auf einem PC. Der läuft nur auf einem AVR.
Du hast jetzt zwei Möglichkeiten: Ein board mit einem AVR drauf nehmen,
und da einen JTAG-Debugger dranhängen (Atmel Dragon oder JTAG 2/3). Der
kann dann mit AVIce und gdb aus Eclipse deine Programme ausführen.
Oder aber simulavr installieren (was unter Windows eine Katastrophe
ist), und den als Simulator verwenden.
Aber selbst dann wird ein cout nicht funktionieren. avr-gcc kommt ohne
C++ libaries, der kennt kein cout.
Frank Thie schrieb:> Wenn ich "-mmcu=attiny13" einsetze
Du brauchst überhaupt nichts einzusetzen, den passenden Prozessor wählst
du in den projektsettings unter AVR aus. Gebau deise Dinge wickelt das
AVR-plugin ab.
Oliver
simulavr dient als Backend (debug-server) für ein Debug-Frontend, zB
avr-gdb oder insight.
Dazu müssen beide Tools miteinander verheiratet werden.
Aaaaaber wenn du noch nicht mal weist auf welcher Maschine dein Code
eigentlich ausgeführt wird, denkst dass Eclipse einen AVR Simulator
hätte oder dein Tiny auf magischem Weg Texte auf deinen PC erscheinen
lässt - tut mir leid - dann ist das noch ein paar Hausnummern zu groß
für dich.
Ich sags nur sehr sehr ungern, aber mir scheint AVR Studio unter Windows
ist für dich momentan das ideale Gesamtpaket. Da hast du alles, IDE,
Compiler, Simulator und später auch on-target Debugger unter einem Hut.
Dir fehlt noch zuviel um das Potpori an Tools, welches ich z.B. hier
unter Linux am laufen habe einzurichten und miteinander zu verheiraten.
Das erzeugt nur Frust am Anfang und du wirst die Lust verlieren.
Und leg bitte dein Buch weg und arbeite dafür hier auf der Seite das
avr-gcc Tutorial durch. Komplett bis hinten. Inklusive LCD und UART
Teil.
Danach wirst du diesen Thread hier nochmal mit einem Schmunzeln lesen.
Du sagst du hast weitere Controller bestellt? Darf man fragen, wie du
die betreibst? Also Welches Board (selber gesteckt, Pollin, STK500)?
Hi Masl.
Danke für deine Hinweise, aaaaber:
> Masl schrieb:> Aaaaaber wenn du noch nicht mal weist auf welcher Maschine dein Code> eigentlich ausgeführt wird, denkst dass Eclipse einen AVR Simulator> hätte oder dein Tiny auf magischem Weg Texte auf deinen PC erscheinen
Letzteres hab ich nie behauptet; war eine Fehlinterpretation am Anfang
des Threads.
Dafür dürfte der UART zuständig sein.
Bezogen auf die angesprochene Problematik war es nicht entscheidend, ob
ein Simulator oder der eingeschränkte Befehlssatz des avr-compilers für
das nicht funktionieren des cout ursächlich war.
Nur wenn das hier expliziet behauptet wird, dann nehm ich als Anfänger
das erstmal zur Kenntnis.
Und die Maschine, auf der bei mir alles läuft, ist mein Computer. ;-)
Aber gut, wenn du meinst, das zusammenbinden von zwei Programmen währe
zu kompliziert, nehm ich das ebenfalls zur Kenntnis, aber auf Windows
hab ich keine Lust mehr.
Debuggen ist ja auch noch nicht mein Thema, obwohl ,irgendwann muss ich
da ja auch mal ran.
Board ist:
http://www.modellbau-und-mehr.de/UDB-28-Universelles-Entwicklungs-Board
Programmer:
http://shop.myavr.de/Programmer%20und%20Bridges/mySmartUSB%20light.htm?sp=article.sp.php&artID=200006
Gruß
Frank
Frank Thie schrieb:> Bezogen auf die angesprochene Problematik war es nicht entscheidend, ob> ein Simulator oder der eingeschränkte Befehlssatz des avr-compilers für> das nicht funktionieren des cout ursächlich war.
Du hast es immer noch nicht.
Ein analoges Beispiel:
Du bist an ein normales Auto gewohnt. Das kaufst du, steigst ein,
schaltest den Autoradio ein und die Klimaanlage.
Hier, mit deinem Tiny, hast du aber kein normales Auto. Du hast eine
Bodenplatte, einen Motor, 4 Räder, ein Lenkrad und einen Sitz. Wenn du
ein Autoradio willst, dann musst DU das einbauen. Und auch der beste
Pannenhelfer kann daran nichts ändern.
Das hat nichts mit eingeschränktem Befehlssatz zu tun! Du bist hier auf
dem nackten Silizium unterwegs. All die Softwareschichten, die auf einem
PC zwischen deinem Programm und dem Silizium liegen, die fehlen auf
deinem Tiny! Dafür ist dein Tiny-Programm dann aber auch nur 3 Bytes
groß, während ein minimales PC-Programm gleich mal ein paar KiloByte auf
die Waage bringt, weil da eben eine Unmenge an Unterbau automatisch
mitkommt, von dem du nichts merkst, der aber den Komfort zb. einer
Streamausgabe an cout mitbringt.
Der SImulator simuliert das nackte Silizium. Der Simulator kann daher
auch nicht irgendwie magisch ein cout aus dem Hut zaubern. Denn in
erster Linie hat der COmpiler das Programm für das nackte Silizium
erstellt und auf dem gibt es diesen Teil nun mal nicht.
Eingeschränkt ist er ja deshalb, weil er angepasst an die existierenden
Möglichkeiten des uc ist.
So weit hab ich das schon verstanden.
Was soll denn so schwer sein, Eclipse mit simulavr bekannt zu machen?
Kennst du eine Seite, die das Thema behandelt?
Hier auf der Seite im Artikel "Simulation" steht ein wenig, und dann hab
ich eben gegoogelt. Ich hab das aber recht schnell aufgegeben weils
irgendwie nicht richtig lief. Muss aber dazu sagen, ich hab mich nicht
so lange damit beschäftigt.
Das hier war noch als Leiche in einem makefile: Damit startest du den
debug Server. Du kannst ja mal anfangen zu Recherchieren, was der Aufruf
genau macht.
Danach musst du dich mit einem Debugger-Frontend deiner Wahl damit
verbinden. Wenn du noch nie mit Eclipse gedebuggt hast würd ich aber für
erste Versuche avr-gdb verwenden, das ist nicht gleich so überladen.
So, ich hab noch weiter gegraben:
Das hier ist der Inhalt einer Datei namens "avr-gdb.conf":
1
filebuild/bin/out.elf
2
targetremotelocalhost:4242
Und das hier der Aufruf von ddd (ein graphisches FrontFront-End für
gdb):
1
ddd--debugger"avr-gdb -x avr-gdb.conf"
.
Das Ganze zusammengefasst:
Du startest den Simulator, dieser lauscht auf den Port 4242 nach
ankommende Verbindungen.
Du startest ddd.
ddd liest die Konfigurationsdatei, findet dort den verwendeten Port und
die Binärdatei, und verbindet sich zum Server.
Ja Danke Masl.
Das ist auch hilfreich: simulavr --help
Oben mein Link von 20.28 zeigt schön das Einbinden in Eclipse.
Als Standard-Port-Adresse verwendet simulavr 1212.
Frank Thie schrieb:> Wenn ich "-mmcu=attiny13" einsetze, kommt "expected unqualified-id> before ‘-’ token".
Das gehört auch nicht in den Code, sondern ist ein
Kommandozeilenparameter des Compilers.
Thread beobachten
Seitenaufteilung abschalten