Hallo,
hier mal eine extrem dumme Frage:
Was würde passieren, wenn ich per PonyProg ein "LED-Blinkprogramm" auf
den Flash-Speicher des Mikrocontrollers brennen würde, ohne vorher einen
Bootloader zu brennen?
Würde jetzt die LED ganz normal blinken, sobald der Mikrocontroller
aktiviert wird oder würde gar nix passieren?
Und was ist der Vorteil an einem Bootloader?
MfG
Seikuassi
@ Seikuassi (Gast)
>Was würde passieren, wenn ich per PonyProg ein "LED-Blinkprogramm" auf>den Flash-Speicher des Mikrocontrollers brennen würde, ohne vorher einen>Bootloader zu brennen?
Dein Programm wird ordnungsgemäß in den Flash geschrieben.
>Würde jetzt die LED ganz normal blinken, sobald der Mikrocontroller>aktiviert wird
Ja.
>Und was ist der Vorteil an einem Bootloader?
Dass man zum Programmieren keinen ISP-Adapter braucht sondern das direkt
per RS232 machen kann, welche meist sowieso zur Kommunikation verwendet
wird.
Ein Bootloader ist auch nichts anderes als ein Programm...
Ein Beispiel für einen Bootloader könnte z. B. ein Programm sein,
welches nach einem Prozessor-Reset für sagenwirmal 100ms auf dem CAN-Bus
nach einem Befehl "Firmware-Update" wartet. Wird in dieser Zeit kein
solcher Befehl empfangen, startet das "normale" Programm (bzw. springt
der µC zur Startadresse des "normalen" Programms).
Mit anderen Worten ist ein Bootloader ein dem "richtigen" Programm
vorgeschaltetes Programm, welches hauptsächlich für Firmwareupdates über
andere Kanäle als die normale Flash-Prozedur erlaubt. Damit macht es
keinen Unterschied, ob Dein "richtiges" Programm einen Bootloader
"darunter" hat oder nicht (Mit einer Ausnahme: Bei Bootloader-Einsatz
kann es notwendig sein, beim Compilieren des "richtigen" Programms
diverse Adressen anzupassen (Programm-Einsprungadresse,
Interrupt-Einsprungadressen etc.).
Dumme Fragen gibt es nicht! Nur dumme Antworten ...
Also, wenn Du ein Blinkprogramm in Deinen Mikrocontroller programmierst,
dann blinkt die LED sobald Du die Spannung an den Controller anlegst.
Der typische Sinn und Zweck eines Bootloaders ist, daß Du das Programm
z.B. per RS232 oder per SDKarte oder per USB in Deinen Microcontroller
bringst. Du brauchst dann also nicht mehr ein spezielles
Programmiergerät (ISP oder JTAG) dafür. Der Controller kann dann in
Deinem Zielgerät (z.B. eine Steuerung) vom Kunden selbst z.B. per USB
mit einer neuen Firmware ausgestattet werden.
Das würde ich ein wenig relativieren und die Antwort vom Prozessortyp
abhängig machen. Beim AVR wird erst, wenns denn genutzt wird und die Bit
richtig gesetzt sind, der Bootloderadressbereich angesprungen. Dann kann
das Blinkprogramm auf den ganz normalen Reset-Flasheinsprungpunkt
compiliert werden.
Beim ARM habe ich so einen Mechanismus nicht, und der eventuelle
Bootloader liegt am Reset Flasheinsprungpunkt. Somit muss das
Blinkprogramm ganz woanders hin compiliert werden.
Habe ich nun das Blinkprogramm compiliert für Bootloader, wirds
eventuell nicht laufen.
Hätte nicht gedacht, dass es so einfach ist. Damit meine ich allerdings
nicht schwere Projekte. Ich bin ja noch ein blutiger Anfänger. Aber
Grundlagen sind nun mal das Wichtigste.
Nächste Frage:
Ich werde jetzt also in Zukunft mit C Mikrocontroller programmieren.
Allerdings bräuchte ich noch die verschiedenen ".h"-Dateien (Bsp.:
io.h).
Wäre nett, wenn einer von euch eine zip-komprimierten Ordner machen
würde, der alle include-Dateien beinhaltet.
Danke im Voraus!
Seikuassi schrieb:> Wäre nett, wenn einer von euch eine zip-komprimierten Ordner machen> würde, der alle include-Dateien beinhaltet.
NeNe, die sind bei der Toolchain dabei. Lade dir WinAVR runter.
Wenn du das AVR Studio und das WinAVR installiert hast, dann sind die .h
Dateien schon in den richtigen Ordnern.
Wenn du - wie in vielen Beispielen - einfach
<code>
#include <avr/io.h>
#include <util/delay.h>
</code>
dann findet der Compiler das schon richtig. Und im AVR Studio kannst du
die auch bequem angucken.
PS: Wie geht das mit dem Code-Tag?
Ähh, also ich habe jetzt WinAVR installiert und werde später eben den
mitgelieferten Editor nutzen, doch wo genau befinden sich die
include-Dateien? Und was meinst du mit Toolchain. Tut mir Leid, aber mit
dem Begriff kann ich nichts anfangen.
Danke im Voraus!
Ah, danke für den Tipp!
Wo finde ich denn eigentlich die "make-file"?
Denn bei mir sagt der immer:
>make.exe: *** No rule to make target `all'. Stopp>Process Exit Code: 2>Time taken: 00:01
Wie kann ich nun aus der "main.c"-Datei eine ".hex"-Datei machen?
Danke im Voraus!
Ich gehe mal davon aus, dass du AVR-Controller mit AVR-Studio
programmieren willst.
In AVR-Studio ein Projekt öffnen, Code eintippen, Build clicken, und das
Hex steht im default-Ordner.
Ohne AVR-Studio (z.B. wegen Apple oder Linux) ist es komplizierter.
Es gibt aber kein Programm, dass eine .c-Datei direkt in eine .hex-Datei
konvertieren kann?
So ähnlich wie mp3-Konverter, wisst Ihr? Ich weiß, dass das ein
schlechtes Beispiel ist, aber vom Prinzip, versteht Ihr?
So ein Programm von Privatleuten o. Ä. .
Danke im Voraus!
Okay, verstehe...es gibt also nicht so ein Programm. Konnte ich ja nicht
wissen.
Eigentlich benutze ich nicht AVR Studio, sondern den mitgelieferten
Programmer-Editor, der bei WinAVR dabei war.
Eigentlich habe ich mir das so vorgestellt:
1.: Im Programmer-Editor den C-Code und die Include-Dateien eingeben.
2.: Auf "make all" im Toolmenü klicken.
3.: Die konvertierte .hex-Datei befindet sich im Speicherort der
.c-Datei.
4.: PonyProg2000 öffnen und die .hex-Datei auf den AVR brennen.
5.: Mikrocontroller testen.
6.: Fertig!
Doch bei "make all" sagt gibt der PC den weiter oben genannten Fehler
an.
Bitte um Hilfe.
Danke im Voraus!
Seikuassi schrieb:> Okay, verstehe...es gibt also nicht so ein Programm. Konnte ich ja nicht> wissen.>> Eigentlich benutze ich nicht AVR Studio, sondern den mitgelieferten> Programmer-Editor, der bei WinAVR dabei war.>> Eigentlich habe ich mir das so vorgestellt:>> 1.: Im Programmer-Editor den C-Code und die Include-Dateien eingeben.> 2.: Auf "make all" im Toolmenü klicken.> 3.: Die konvertierte .hex-Datei befindet sich im Speicherort der> .c-Datei.> 4.: PonyProg2000 öffnen und die .hex-Datei auf den AVR brennen.> 5.: Mikrocontroller testen.> 6.: Fertig!>> Doch bei "make all" sagt gibt der PC den weiter oben genannten Fehler> an.> Bitte um Hilfe.
Es sei denn das wurde irgendwann mal geändert:
Das makefile musst du aber selber schreiben!
d.h. da fehlt ein Punkt
1.a.: makefile schreiben oder mit einem makefile-Generator erzeugen
lassen
Ansonsten stimmt der Ablauf, wie du ihn skizziert hast.
Pink Shell schrieb:> PS: Wie geht das mit dem Code-Tag?http://www.mikrocontroller.net/articles/Formatierung_im_ForumSeikuassi schrieb:> Ähh, also ich habe jetzt WinAVR installiert und werde später eben den> mitgelieferten Editor nutzen, doch wo genau befinden sich die> include-Dateien?
Bei mir z.B. D:\WinAVR-20100110\avr\include
Wobei das eigentlich egal ist weil der Pfad im Makefile steht und es
reicht wenn du #include <avr/io.h> schreibst. Unterschied <> und "" bei
include ist dir klar?
> Und was meinst du mit Toolchain.
Toolchain ist die gesamte Kette an Programmen die du benutzt, also
Compiler+Assembler+Linker. WinAVR halt.
> Denn bei mir sagt der immer:
Da kann ich dir leider nicht helfen... Du benutzt aber schon das
Programmers Notepad welches mit WinAVR installiert wurde? Makefile ist
normalerweise da wo deine Projektdateien (.c und .h) sind und heisst
makefile. Ist aber eine Sache für sich, guck hier ins Tutorial (oben
links).
Seikuassi schrieb:> Es gibt aber kein Programm, dass eine .c-Datei direkt in eine .hex-Datei> konvertieren kann?
Naja, fast. Es sind mehrere Programme, die Toolchain eben. Wobei das
Zusammenspiel der Programme vom makefile gesteuert wird.
Es gibt hier in der Artikelsammlung eine prima Grafik dazu vom Herrn Lay
glaube ich aber ich finde die gerade nicht. :-(
Grober Keil schrieb:> Endlich werden deine Fragen der Überschrift gerecht!
Troll dich.
> Eigentlich benutze ich nicht AVR Studio, sondern den mitgelieferten> Programmer-Editor, der bei WinAVR dabei war.
Kannst du auch.
> Eigentlich habe ich mir das so vorgestellt:
So sollte das auch funktionieren... Warum es bei dir nicht geht weiß ich
wie gesagt nicht, da muss ein Profi drauf gucken. In der Zwischenzeit
kannst du ja mal WinAVR und ProgNotepad deinstallieren und neu
installieren, vielleicht löst das das Problem schon? Oder mal nach der
Fehlermeldung googeln? Ich nutze übrigens Code::Blocks.
Alle Klarheiten beseitigt? :-)
Deine Vorgehensweise ist im Prinzip schon richtig - der Fehler lässt auf
ein unvollständiges Makefile schließen (es scheint jedoch vorhanden zu
sein, sonst würde das Programm make sich über ein fehlendes Makefile
beschweren).
Leider kenne ich mich mit Programmer's Notepad (den meinst Du
wahrscheinlich) überhaupt nicht aus, aber prinzipiell sollte es nicht so
verschieden von anderen Editoren mit einer Schaltfläche für "make all"
sein. Daher: Finde und öffne die Datei "Makefile" im Projektordner bzw.
-pfad, und schaue, ob es dort einen Eintrag "all:" gibt.
Besser bzw. für einen Anfänger wohl einfacher wäre es allerdings wohl,
AVR Studio zu installieren; dort ist auch gleich das Programm zum
Brennen des µC integriert.
troll schrieb:> @KHB: Gibt es nicht eine Vorlage/Standardmakefile die bei WinAVR dabei> ist? (Ich hab das Problem nicht, C::B übernimmt diesen ganzen> Futzelkram...)
Ich hab eine himmelalte WinAvr Installation auf der Maschine.
Da gibt es im 'sample' Ordner ein Beispiel und laut unserem Wiki über
AVR-GCC-Tutorial/Exkurs Makefiles soll das eine gute Ausgangsbasis
für eigene Makefiles sein.
Persönlich benutze ich ausschliesslich AVR-Studio, da brauch ich nicht
selber an Makefiles rumbasteln.
Hinzufügen möchte ich noch, dass auf meiner WinAvr Installation es auch
noch im obersten WinAvr Verzeichnis ein Subverzeichnis 'mfile' gibt,
welches einen Makefile-Generator darstellt.
Aber wie man den benutzt, weiß ich auch nicht. Bei mir ist das ein TCL
File und meine Konfiguration ist schon ein wenig 'lädiert', so dass ich
das nicht ausprobieren kann.
> Alle Klarheiten beseitigt? :-)
Fast...
Im "Exkurs Makefiles" werden die einzelnen Parameter der makefile
aufgelistet. Allerdings habe ich schon den Adapter von s-huehn
(http://s-huehn.de/elektronik/avr-prog/avr-prog-alt.htm; 2.Bild)
nachgebaut.
Wie muss ich nun in der makefile den Programmieradapter nennen (STK200
zum Beispiel geht ja schlecht!).
Danke im Voraus!
Seikuassi schrieb:> Wie muss ich nun in der makefile den Programmieradapter nennen (STK200> zum Beispiel geht ja schlecht!).
Da musst du in die Hilfe von Ponyprog gucken wie man das ansteuert.
Karl Heinz Buchegger schrieb:> Hinzufügen möchte ich noch, dass auf meiner WinAvr Installation es auch> noch im obersten WinAvr Verzeichnis ein Subverzeichnis 'mfile' gibt,> welches einen Makefile-Generator darstellt.
Bei mir (wenige Wochen alte Installation) gibt es das auch, inkl.
Hilfedatei (im Anhang, ist ja eh alles OpenSource). Geschrieben vom hier
gutbekannten Jörg Wunsch...
Aha, da gibt es ja tatsächlich einen "makefile-Editor" im WinAVR.
Da kann man ja schon vieles einstellen. Allerdings weiß ich noch immer
nicht, wie der Programer heißen soll...
Weiß einer von euch, was ich dort für dieses ISP-Programmiergerät
(http://s-huehn.de/elektronik/avr-prog/avr-seriell.gif) eingeben soll?
Wenn diese Frage beantwortet ist, kann ich es gleich mal testen.
Danke im Voraus!
Es hat nicht so geklappt, wie ich es dachte. Naja...ich werde in Zukunft
jetzt doch AVRStudio nutzen.
Eine Frage hätte ich noch zu einem Beispielcode. Am Besten, man
beantwortet sie so, wie Falk Brunner´s (falk) erste Antwort:
Philipp Buchmann schrieb:> Eine Frage hätte ich noch zu einem Beispielcode. Am Besten, man> beantwortet sie so, wie Falk Brunner´s (falk) erste Antwort:
Und was ist jetzt die Frage?
> .include "m8def.inc">> anfang:> ldi r16, 0b11111111> out PORTB, r16>> ldi r16, 0b11111110> out PORTB, r16>> rjmp anfang
Dieses Programm jedenfalls ist nicht sehr sinnvoll.
Schon alleine deshalb nicht, weil der PORTB nie auf Ausgang gestellt
wird.
AVR-Tutorial
Philipp Buchmann schrieb:> Es hat nicht so geklappt, wie ich es dachte. Naja...ich werde in Zukunft> jetzt doch AVRStudio nutzen.
Du musst ja nicht notwendigerweise ein 'make all' benutzen. Gibt es denn
bei dir im PN keine anderen Menüpunkte? Irgendwas in Richtung 'Make
Compile' oder 'Make Program' oder 'Make HEX'?
und dann brennst du eben das HEX-File mit Ponyprog in den µC.
Ich bin noch bei den Grundlagen.
Dazu eine Frage (und jetzt kommt wirklich eine Frage):
Wie lautet die Zeile, bei der ich einen Wert eines einzelnen Pins eines
Mikrocontrollers (beispielsweise PB2) in ein Register laden kann?
Seikuassi schrieb:> Ich bin noch bei den Grundlagen.>> Dazu eine Frage (und jetzt kommt wirklich eine Frage):>> Wie lautet die Zeile, bei der ich einen Wert eines einzelnen Pins eines> Mikrocontrollers (beispielsweise PB2) in ein Register laden kann?>>
1
in r16,
...und jetzt?
>> Danke im Voraus!
Die kleinste Einheit auf deiner 8 Bit Maschine ist ein BYTE. Also musst
du schon das ganze Byte (in diesem Fall aus PINx) lesen und dir dann mit
Bitoperationen (z.B. & PB1) das gewünschte Bit, welches deinem Portpin
entspricht, rausfiltern.
gruß cyblord
Ich denke es ist jetzt wirklich hoch an der Zeit, dass du anfängst das
AVR-Tutorial
zu studieren.
Hier haben nämlich die wenigsten Lust, dir seitenweise Litaneien zu
Dingen zu schreiben, die im Tutorial des langen und breiten in
verdaulichen Happen präsentiert und durchgekaut werden.
Falls du es noch nicht gemerkt hast: Der Text
AVR-Tutorial
ist ein Link. Drück drauf und fang zu lesen an. Wenn deine Hardware
bereits läuft, kannst du im 3. Kaptitel "I/O-Grundlagen ..." anfangen.
Damit und mit den weiteren Kapitel bist du auf Wochen hinaus
beschäftigt.
Bitte lies dir mal das Tutorial und die AVR Assembler Befehle durch.
Was bedeutet für dich: "denn der Wert soll ja nur in
das Register geladen werden". Wie willst du ein Bit, in einen
Byte-Register laden? Wie stellst du dir vor was da drin steht? Mit der
obigen Methode steht da entweder 0 oder ungleich 0 drin. (1,2,4,8 je
nach Pin-Nummer) und das wird mit TST überprüft.
gruß cyblord
>Ich denke es ist jetzt wirklich hoch an der Zeit, dass du anfängst das>AVR-Tutorial>zu studieren.>>Hier haben nämlich die wenigsten Lust, dir seitenweise Litaneien zu>Dingen zu schreiben, die im Tutorial des langen und breiten in>verdaulichen Happen präsentiert und durchgekaut werden.
Tut mir Leid.
Wenn ich das richtig verstanden habe, dann kann ich mit
1
sbic
bzw.
1
sbis
die einzelnen Ports abfragen, wenn diese dementsprechend als Eingang
definiert sind, oder?
Mit freundlichen Grüßen
Seikuassi
> bewirkt, dass der ganze Port> eingelesen wird und in r16 abgelegt wird.
Jep.
> 2.: Mit
1
andi r16, 0b00000100
> spezifiziere ich PB2.
"spezifiziere ich"? Sprich deutsch! Durch das ver-UND-en mit der 1-Bit
Konstante wird ein Bit maskiert. Wenn das entsprechnende Bit im Register
nicht gesetzt war, dann steht jetzt der Wert 0 im Register, sonst ein
Wert != 0.
> 3.: Was bewirkt
1
tst r16
> ?
Es ist überflüssig.
> 4.: Die 4. Zeile ist eigentlich unnötig, denn der Wert soll ja nur in> das Register geladen werden, oder?
Es ist aus anderen Gründen überflüssig. Du willst ja ein Bit testen,
also eine Fallunterscheidung machen "Bit ist gesetzt" vs. "Bit ist nicht
gesetzt". Solche Verzeigungen im Programmablauf werden in Assembler
üblicherweise durch bedingte Sprünge realisiert. Wobei als Bedingung nur
ein gesetztes (bzw. nicht gesetztes) Flag oder eine Kombination von
Flags erlaubt ist. Freundlicherweise erledigt das ANDI oben schon das
Setzen des Z Flags, wenn das Register nach der Operation den Wert 0
enthält.
Und deswegen, weil ANDI das Flag bereits setzt, ist ein nachfolgendes
TST unnötig.
Aus dem logisch leichter erschließbaren C Code
1
if(PINC&0x04){
2
/* foo */
3
}else{
4
/* bar */
5
}
wird in Assembler etwas wie
1
if:
2
IN r16,PINC
3
ANDI r16, 0x04
4
BREQ else
5
6
then:
7
; foo
8
RJMP endif
9
10
else:
11
; bar
12
13
endif:
14
; nächstes Assembler-Statement
Es werden 2 Labels gebraucht (if: und then: oben nur für mehr Klarheit).
Im Code folgen linear der Test, der then-Code, der else-Code und
ein Label hinter dem Ende des if-Statements. Nach dem Test führt ein
bedingter Sprung über den then-Zweig hinweg oder eben nicht. Wenn der
then-Zweig genommen wird, wird dann andererseits der else-Zweig
übersprungen.
Speziell beim AVR kommt dazu, daß er außer bedingten BRanch Befehlen
auch Skip-Befehle hat, um in Abhängigkeit von den Flags einen einzelnen
Befehl zu überspringen. Das spart Code, z.B. wenn das if keinen
else-Teil hat und der then-Teil nur ein einzelner Befehl ist.
Fazit: bei Assembler kommt es auf Details an. Und schnell hingerotzte
Postings wie das von Troll (sic!) verwirren möglicherweise mehr als sie
erhellen.
XL
Axel Schwenke schrieb:> Und deswegen, weil ANDI das Flag bereits setzt, ist ein nachfolgendes> TST unnötig.
Ok, ich hab wohl schon zu lange das Instruction Set nicht mehr
angefasst...
> Und schnell hingerotzte> Postings wie das von Troll (sic!) verwirren möglicherweise mehr als sie> erhellen.
Naja, ich schreib doch keinen Roman wenn es im Tutorial steht. Ich helfe
ja gerne aber da gilt dann irgendwann doch rtfm... (oder rtft =
tutorial...)
Thread beobachten
Seitenaufteilung abschalten