Forum: Mikrocontroller und Digitale Elektronik Testprogramm für Pollin Evaluationboard


von T. F. (n3ssaja)


Lesenswert?

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
int main (void) {           
4
 
5
   DDRD  = 0xff;             
6
   PORTD = 0x60;  // PIN PD5 und PD6 auf HIGH         
7
 
8
   while(1){};                       
9
 
10
   /* wird nie erreicht */
11
   return 0;                 
12
}

Leider klappt es mit dem obenstehenden Code nicht. Kann mir jmd sagen 
was ich da falsch mache? Ich programmiere mit AVR-Studio.

von awfr (Gast)


Lesenswert?

high bedeutet aus das is dir schon klar oder?

von awfr (Gast)


Lesenswert?

normalerweise :)

von Stefan B. (stefan) Benutzerseite


Lesenswert?

awfr schrieb:
> high bedeutet aus das is dir schon klar oder?

Beim den beiden Pollin AVR Boards nicht. Deren LEDs sind active high 
geschaltet.

Pollin ATMEL Evaluations-Board
Pollin Funk-AVR-Evaluationsboard

von Stefan B. (stefan) Benutzerseite


Angehängte Dateien:

Lesenswert?

0x60 = 0b01100000 = (1<<PD6)|(1<<PD5)

Der Quelltext
1
// Atmega8
2
#include <avr/io.h>
3
4
int main (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.

von Jens (Gast)


Lesenswert?

Deine while Schleife ist falsch.

Versuche mal:

while(1)
    ;

Die {} kannst du dir sparen.

Gruß, Jens

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Die while(){}; ist nicht falsch im Sinn von "funktioniert nicht" oder 
"muss ausgebessert werden". OK, das ; ist wirkungslos :)

von awfr (Gast)


Lesenswert?

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.

von Link zu (Gast)


Lesenswert?

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! ;-)

von T. F. (n3ssaja)


Lesenswert?

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
1
<avr/io.h>
 ?? Ist das vielleicht ein falsches??

von Link zu (Gast)


Lesenswert?

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. ;-)

von Klaus W. (mfgkw)


Lesenswert?

@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!)

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von Link zu (Gast)


Lesenswert?

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. ;-)

von Klaus W. (mfgkw)


Lesenswert?

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.

> ...

von Link zu (Gast)


Lesenswert?

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... ;-)

von Klaus W. (mfgkw)


Lesenswert?

nicht deine Schuld - wäre der Text mit einem c-Tag geschrieben
und vernünftig eingerückt, würde man ihn auch leichter erfassen.

von T. F. (n3ssaja)


Lesenswert?

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 :-)

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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?

von T. F. (n3ssaja)


Lesenswert?

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! 
;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.