mikrocontroller.net

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


Autor: T. F. (n3ssaja)
Datum:

Bewertung
0 lesenswert
nicht 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.
#include <avr/io.h>

int main (void) {           
 
   DDRD  = 0xff;             
   PORTD = 0x60;  // PIN PD5 und PD6 auf HIGH         
 
   while(1){};                       
 
   /* wird nie erreicht */
   return 0;                 
}

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

Autor: awfr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
high bedeutet aus das is dir schon klar oder?

Autor: awfr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
normalerweise :)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
0x60 = 0b01100000 = (1<<PD6)|(1<<PD5)

Der Quelltext
// Atmega8
#include <avr/io.h>

int main (void) 
{           
  DDRD = (1<<PD6)|(1<<PD5); // PD5 und PD6 Ausgang
  PORTD = (1<<PD6)|(1<<PD5); // PD5 und PD6 HIGH

  while(1){};                       
}

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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine while Schleife ist falsch.

Versuche mal:

while(1)
    ;

Die {} kannst du dir sparen.

Gruß, Jens

Autor: Stefan B. (stefan) Benutzerseite
Datum:

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

Autor: awfr (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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
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! ;-)

Autor: T. F. (n3ssaja)
Datum:

Bewertung
0 lesenswert
nicht 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
<avr/io.h> 
 ?? Ist das vielleicht ein falsches??

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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. ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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!)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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. ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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.

> ...

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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... ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: T. F. (n3ssaja)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: T. F. (n3ssaja)
Datum:

Bewertung
0 lesenswert
nicht 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! 
;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.