Hallo,
Ich habe mir vor wenigen Tagen das Evaluation Board von Pollin gekauft.
Das von Pollin zur Verfügung gestellte Testprogramm als HEX File klappt
auch( Beide LED´s und der Summer funktionieren).
Ich wollte nun die beiden LED´s mit einem ATmega8 selber ansteuern.
Folgenden Code habe ich dazu geschrieben.
1
#include<avr/io.h>
2
3
intmain(void){
4
5
DDRD=0xff;
6
PORTD=0x60;// PIN PD5 und PD6 auf HIGH
7
8
while(1){};
9
10
/* wird nie erreicht */
11
return0;
12
}
Leider klappt es mit dem obenstehenden Code nicht. Kann mir jmd sagen
was ich da falsch mache? Ich programmiere mit AVR-Studio.
0x60 = 0b01100000 = (1<<PD6)|(1<<PD5)
Der Quelltext
1
// Atmega8
2
#include<avr/io.h>
3
4
intmain(void)
5
{
6
DDRD=(1<<PD6)|(1<<PD5);// PD5 und PD6 Ausgang
7
PORTD=(1<<PD6)|(1<<PD5);// PD5 und PD6 HIGH
8
9
while(1){};
10
}
ist geeignet die beiden LEDs auf dem Pollin Board dauerhaft zum Leuchten
zu bringen.
Vielleicht ist etwas beim Kompilieren oder beim Übertragen schief
gegangen. Im Anhang die HEX-Datei zu diesem Programm. Das funktioniert
bei mir. Damit kannst du Kopilierfehler aufspüren.
Übertragungsfehler kannst du aufspüren, wenn du diese Hex-Datei wieder
aus dem Atmega8 ausliest und wir das Ergebnis mit dem Original
vergleichen.
Stefan B. schrieb:
> Beim den beiden Pollin AVR Boards nicht. Deren LEDs sind active high> geschaltet.
im endeffekt auch egal. ich würde einfach
PORTD = 0xFF;
while(1)
{
for(int i=0;i<1000000;i++)
{
PORTD = ~PORTD;
}
}
schreiben, dann kann man schon mal einige fehler ausschliessen.
awfr schrieb:
> Stefan B. schrieb:>> Beim den beiden Pollin AVR Boards nicht. Deren LEDs sind active high>> geschaltet.>> im endeffekt auch egal. ich würde einfach> PORTD = 0xFF;> while(1)> {> for(int i=0;i<1000000;i++)> {> PORTD = ~PORTD;> }> }>> schreiben, dann kann man schon mal einige fehler ausschliessen.
Öhm, wenn das funktioniert, dann sieht man aber auch nur kurzzeitig ein
durchgehendes leuchten der LEDs, da das Auge diesen schnellen Wechsel
nicht erkennen kann.
Ich bin mir aber sicher, das
1
PORTD=~PORTD;
nicht funktioniert.
Und das Leuchten ist schon sehr kurz, denn bei 8MHz hast du
1/8000000*1000000 ja nur eine Gesamtdauer 1/8sec.
Für die ganz Genauen, ja da ist eine ungenaue Überschlagsrechnung, da
fehlen die genauen Takte für die Befehle und für das Springen in der
Schleife. Es ist Sonntagfrüh, da reicht das einfach mal! ;-)
Danke für die vielen Antworten, aber das Problem besteht weiterhin.
@Stefan B: Ich habe dein Hexfile auf den µC geschickt. Damit leuchten
die beiden LED´s einwandfrei. Schreibe ich den Code jedoch selber, so
wie du ihn oben stehen hast, und spiele dann das HEX File rüber klappts
nicht!
Wenn ich den µC wieder auslese und das HEXfile mit deinem vergleiche
stimmt dieses auch nicht überein.
Ich kann mir dieses Phänomen nicht erklären. Liegt das vielleicht an dem
header
Tobias Frede schrieb:
> Ich kann mir dieses Phänomen nicht erklären. Liegt das vielleicht an dem> header<avr/io.h> ??
Ähm, kannst du uns mehr Infos zu deinem Verdacht geben?
Ob ich dir weiterehlfen kann, weiß ich nicht, aber grundsätzlich wäre es
hilfreich wenn du uns verrätst was du wie und womit machst.
Ich denke da an:
-das von dir verwendete Betriebssystem
-IDE/Compiler
-wie flasht du (wobei das kein Problem zu sein scheint)
ansonsten wird diese Rätselrate-Stunde noch ewig dauern. Da fehlt
zumindest mir die Lust zu. ;-)
@Link:
Genau das ist ja der Trick an der Lösung.
Die LEDs gehen so schnell an und aus, dass sie aussehen, als
würden sie einfach nur leuchten.
Wegen des ständigen Ein- und Ausschaltens sind sie unter dem
Strich etwas dunkler als wenn man sie dauernd an hätte, aber
dafür hat man den Vorteil, daß es gleichermaßen funktioniert
für Schaltungen, bei denen sie bei 1 leuchten ebenso wie bei
0.
(Zu beachten der schöne Blocksatz, den ich hier hin bekommen
habe!)
Tobias Frede schrieb:
> @Stefan B: Ich habe dein Hexfile auf den µC geschickt. Damit leuchten> die beiden LED´s einwandfrei. Schreibe ich den Code jedoch selber, so> wie du ihn oben stehen hast, und spiele dann das HEX File rüber klappts> nicht!
Also stimmt etwas beim Kompilieren nicht. Das Board funktioniert und das
Übertragen funktioniert. Das ist doch schon was! Um das Problem weiter
einzukreisen, muss man sich, wie unser ungeduldiger chinesischer Freund
Link zu schreibt, die verwendeten Werkzeuge und dein Arbeitsverfahren
ansehen.
> Wenn ich den µC wieder auslese und das HEXfile mit deinem vergleiche> stimmt dieses auch nicht überein.
Selbst mein Hexfile ausgelesen kann anders aussehen als mein originales
Hexfile. Das liegt in der Natur der Hexfiles. Man muss sich nicht die
Textdarstellung ansehen sondern die Maschineninformation. Das kann man
z. B. wenn man das Hexfile in einem AVR-Simulator oder AVR-disassembler
(AVR Studio) ansieht. Für den Anfänger ist das heavy stuff, deswegen
hatte ich geschrieben:
>> Übertragungsfehler kannst du aufspüren, wenn du diese Hex-Datei wieder>> aus dem Atmega8 ausliest und wir das Ergebnis mit dem Original>> vergleichen.
Mit viel Glück kann man dann auch sehen, ob falsche Einstellungen z. B.
falscher Prozessor beim Kompilieren verwendet wurden.
Klaus Wachtler schrieb:
> @Link:> Genau das ist ja der Trick an der Lösung.>> Die LEDs gehen so schnell an und aus, dass sie aussehen, als> würden sie einfach nur leuchten.
Für Software-PWM ist es noch zu früh. ;-)
Und die SW-PWM dauert immerhin auch etwas mehr als eine 1/8 Sekunde,
wobei, was passiert, wenn das Programm sich nach der for-Schleife
beendet? Der letzte angelegte Wert ist ja 0xff? Bleiben die LED an?
Klaus Wachtler schrieb:
> (Zu beachten der schöne Blocksatz, den ich hier hin bekommen> habe!)
Haste fein gemacht, wie viele Stunden du daran wohl gewerkelt hast. ;-)
Stefan B. schrieb:
> wie unser ungeduldiger chinesischer Freund> Link zu schreibt
<prust>
Eigentlich kommt 'Link zu' woanders her. ;-)
Link zu schrieb:
> Klaus Wachtler schrieb:>> @Link:>> Genau das ist ja der Trick an der Lösung.>>>> Die LEDs gehen so schnell an und aus, dass sie aussehen, als>> würden sie einfach nur leuchten.> Für Software-PWM ist es noch zu früh. ;-)> Und die SW-PWM dauert immerhin auch etwas mehr als eine 1/8 Sekunde,> wobei, was passiert, wenn das Programm sich nach der for-Schleife> beendet? Der letzte angelegte Wert ist ja 0xff? Bleiben die LED an?
Ist es jetzt immer noch zu früh? :-)
Um die for-Schleife rum steht doch noch eine while(1).
Ich würde tippen, daß das Programm nach der for-Schleife wieder
damit weitermacht.
Den awfr-Tip finde ich nach wie vor hilfreich und habe daran
nichts zu meckern.
> ...> Haste fein gemacht, wie viele Stunden du daran wohl gewerkelt hast. ;-)
nee, hat sich so ergeben. Ich finde es eben deshalb lustig.
> ...
Klaus Wachtler schrieb:
> Den awfr-Tip finde ich nach wie vor hilfreich und habe daran> nichts zu meckern.
Und ich gehe jetzt mal Brille putzen... wenn ich schon anfange
while-Schleifen zu übersehen... ;-)
Danke für eure Hilfe.
Mein Fehler war, das AVR-Studio mit dem falschen Prozessor kompiliert
hat. Wenn ich jetzt jedoch ein neues Projekt anlege, als Debug Platform
"AVR-Simulator" und den Prozessor ATmega8 wähle, wird mir kein HEX-File
erzeugt. Dieses brauche ich aber dringend, da ich den µC über die ISP
Schnittstelle flashe.Welchen Grund kann das haben?
Falls nötig: Ich benutze AVR Studio 4, Version 4.12, Servicepack 4
Wäre schön wenn ihr mir nochmal weiterhelfen könnt :-)
Du musst ausserdem Build oder Rebuild all ausführen. Und AVR Studio kann
Meldungen ausgeben, wenn etwas beim Build oder Rebuild all schiefgeht.
Die Meldungen findet man in dem Fenster unter den Tabs Build und
Messages. Es gab auch mal Probleme mit bestimmten Pfadnamen. Hast du
dein Projekt in einem Pfad mit Leerzeichen oder Sonderzeichen angelegt?
Super Stefan es geht endlich! Ich habe AVR Studio noch einmal neu
installiert und wie durch ein wunder klappts jetzt. Nochmal vielen Dank
für Euer Bemühen bei der Fehlersuche. Jetzt ist der Sonntag gerettet!
;-)