mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Attiny45 bug


Autor: Daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich stehe noch ganz am Anfang mit der AVR-Programmierung in C; 
vielleicht könnt ihr mir bei einem Problem helfen...

Ich habe dieses Programm für einen Attiny45 geschrieben, um erstmals 
Interrupts auszuprobieren.

Falls mithilfe eines Tasters Pin 5 auf 0V gezogen wird, soll die an Pin 
6 anliegende Led für 1/2 Sek aussetzen. Den Reset Pin habe ich übrigens 
mit Vcc verbunden.
Leider tut sich - nichts. Also gar nichts, die Led leuchtet nicht, 
Drücken des Tasters ändert auch nichts.

Dass ein Programm nicht gleich funktioniert, ist ja normal, aber ich 
weiß nicht, wo ich beim Debuggen ansetzen soll, da mir keine Fehler beim 
Kompilieren angezeigt werden.

Wäre super, wenn mir jmd. meine Fehler nennen könnte :D

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PCINT0 != INT0

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, kurz und knackig, aber etwas mehr Info wäre nett. Das Bit heißt doch 
"INT0"?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder anders: könnte ich die Zeile auch so schreiben?

GIMSK |= (1 << 6);

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Hm, kurz und knackig, aber etwas mehr Info wäre nett. Das Bit
> heißt doch
> "INT0"?

Wenn das Bit "INT0" heißen soll, dann möchte die ISR bestimmt 
"INT0_vect" genannt werden.

: Bearbeitet durch User
Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, da fällt der Groschen bei mir. Doch warum leuchtet die Led erst gar 
nicht? eigentlich ist doch Pin 6 als Ausgang und High geschaltet?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Ah, da fällt der Groschen bei mir. Doch warum leuchtet die Led erst gar
> nicht? eigentlich ist doch Pin 6 als Ausgang und High geschaltet?

wie ist die LED angeschossen? gegen GND oder VCC?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wie ist die LED angeschossen? gegen GND oder VCC?

Oder verkehrt herum:)

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Doch warum leuchtet die Led erst gar
> nicht? eigentlich ist doch Pin 6 als Ausgang und High geschaltet?

Meine telepathischen Fähigkeiten sind leider noch nicht so weit 
entwickelt, dass ich diese Frage beantworten könnte.

Bis dahin würde ich dir empfehlen:
1. Den für dieses Problem unrelevanten Code löschen
2. Schaltplan prüfen
3. Messen

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Oder verkehrt herum:)

Nenene, soweit war ich schon XD

Gut, wenn ihr meint, der Code hat soweit keine bösen Fehler, probier ich 
halt noch ein bisschen rum...

was könnte ich denn noch löschen, so groß ist das Programm doch nun 
nicht?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> was könnte ich denn noch löschen, so groß ist das Programm doch nun
> nicht?

Sach mal.....

OK, ich machs mal für dich:
 
#define F_CPU 1000000

#include <avr/io.h>
 



int main(void)
{
  
  DDRB |= (1 << 1);
  PORTB = 0xFF;
   
    while (1) ;
    return 0;
}

Das dürfte der optimale Testcode, für dein "LED leuchtet nicht Problem" 
sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Gut, wenn ihr meint, der Code hat soweit keine bösen Fehler,

Wenn es der oben gepostete Code ist: der hat. Wenn es ein mittlerweile 
geänderter Code ist: den kennt niemand.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> #define F_CPU 1000000
Mein Fehler!

Besser:
#define F_CPU 1000000L
(tut der LED aber nicht weh!)

: Bearbeitet durch User
Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Arduino Fanboy:

Das Problem ist ja nicht, das ich die Led nicht generell an oder 
ausschalten kann, und auch mit _delay_ms habe ich schon experimentiert, 
hat alles geklappt.
Bolß möchte ich, bevor ich z.b. mit timern rumprobiere, erstmal 
Interrupts verstehen, deshalb diese "Übung".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dir empfehlen, für die Bits in Registern die Namen zu 
verwenden, statt numerischer Positionen. Bei den GPIO-Bits ist das egal, 
die sind selbsterklärend, aber die Bits in MCUCR, GIMSK etc sind es 
nicht. Was zu Folge hat, dass man erst einmal ins Datasheet schauen 
muss, bevor man mit deinem Code überhaupt was anfangen kann. Vielen ist 
das zu blöd und ignorieren deinen Beitrag deswegen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Besser:
> #define F_CPU 1000000L

Weshalb sollte das besser sein?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Nenene, soweit war ich schon XD

Nur weiss immer noch niemand, wie die LED dranhängt.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, kann ich verstehen.

Ich fürchte, es wird einfach auf trial and error hinauslaufen; am besten 
beginne ich wohl mit funktionierenden Codebeispielen Anderer und 
variiere die dann. Im Moment steh ich hier nunmal auf dem Schlauch, und 
auch der verbesserte Code bringt keine Resultate. Ist wohl noch ein 
langer weg bis zur ersten ADC kontrollierten PWM.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Nur weiss immer noch niemand, wie die LED dranhängt.

Naja, die Anode an Pin 6, über die Kathode ist über einen Widerstand mit 
GND verbunden. Und die Led leuchtet, wenn ich an ihr manuell 5v anlege.

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Arduino F. schrieb:
>> Besser:
>> #define F_CPU 1000000L
>
> Weshalb sollte das besser sein?

In diesem Fall ist es nicht zwingend nötig, oder besser. Aber sobald mal 
irgendwann eine UART Berechnung hinzukommt, oder überhaupt eine 
Berechnung. Dann macht das L bzw UL schon einen großen Sinn.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Draco schrieb:
> In diesem Fall ist es nicht zwingend nötig, oder besser. Aber sobald mal
> irgendwann eine UART Berechnung hinzukommt, oder überhaupt eine
> Berechnung. Dann macht das L bzw UL schon einen großen Sinn.

Bei einem Compiler mit Integer-Grüsse 16-Bit besteht zwischen 1000000L 
und 1000000 kein Unterschied. Beides hat den gleichen Datentyp "long". 
Folglich besteht auch in einer Rechnung, die diesen Wert nutzt, kein 
Unterschied.

Anders wäre es beim Suffix UL.

: Bearbeitet durch User
Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attiny45 != 16Bit

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Draco schrieb:
> Attiny45 != 16Bit

Mehr als das ist es aber auch nicht und nur da wärs ein Unterschied.

Hab die Formulierung aber schon korrigiert, weil ich sicher war, dass da 
jemand rückwärts drüber stolpert ;-). Es geht um die Sicht des 
Compilers, und für den ist das ein 16-Bitter. Weniger geht per C 
Standard nicht, da die Datentypen fürs Maschinenwort int/unsigned sind 
und die sind auf mindestens 16 Bits festgelegt.

Dezimale Konstanten, die nicht in "int" passen, sind automatisch "long". 
Auch ohne Suffix.

: Bearbeitet durch User
Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was bezweckst Du damit?

PCMSK |= (1 << 0);

(Ich frage, weil Du damit nichts erreichst ... :-) )


Dann solltest Du auch deswegen nochmal ins Datenblatt schauen:

GIMSK |= (1 << INT0);    //Pin Change Interrupt enable

Willst Du den Pin Change Interrupt aktivieren - oder wie codiert INT0?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Was bezweckst Du damit?
> PCMSK |= (1 << 0);
> (Ich frage, weil Du damit nichts erreichst ... :-) )

Ist sinnvoller als
  PCMSK |= 1;
denn wenn du mal den Pin wechselst, dann ist
  PCMSK |= 1<<3;
deutlich richtiger als
  PCMSK |= 3;

Noch besser ist allerdings
  #define TASTER 0
  PCMSK |= 1<<TASTER;

: Bearbeitet durch User
Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ist sinnvoller als

Nö, wenn dann schreibt man sinnvoller Weise
PCMSK |= (1 << PCINT0);

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Nö, wenn dann schreibt man sinnvoller Weise

Yep.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

jeder Code über 10 Zeilen funktioniert NIE auf Anhieb. Bestenfalls 
gibt er falsche Resultate, mit denen Du auf den Fehler schliessen 
kannst. Sonst musst Du IMMER irgendwelche Zwischenresultate irgendwie 
ausgeben können zum Debugging.

Gruss Chregu

Autor: Paul B. (paul_baumann)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Christian M. schrieb:
> jeder Code über 10 Zeilen funktioniert NIE auf Anhieb.

In C nicht -das ist wohl wahr.

MfG Paul

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> In C nicht

Hallo Paul!

Ja, aber wer programmiert schon C...

Gruss Chregu

Autor: Paul B. (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian M. schrieb:
> Ja, aber wer programmiert schon C...

Masochisten?
:)
MfG Paul

Autor: *.* (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Dabei ist C kaum mehr als vereinheitlichter Assembler...

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian M. schrieb:
> jeder Code über 10 Zeilen funktioniert NIE auf Anhieb. Bestenfalls
> gibt er falsche Resultate, mit denen Du auf den Fehler schliessen
> kannst. Sonst musst Du IMMER irgendwelche Zwischenresultate irgendwie
> ausgeben können zum Debugging.

Na, Du musst aber echt deprimiert sein. Ich hoffe, Du programmierst 
nicht beruflich :-)

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*.* schrieb:
> Dabei ist C kaum mehr als vereinheitlichter Assembler...

Quark, C ist bloß eine Vereinfachung für die Leute denen Basic zu schwer 
ist!

Christian M. schrieb:
> Hallo Daniel,
>
> jeder Code über 10 Zeilen funktioniert NIE auf Anhieb. Bestenfalls gibt
> er falsche Resultate, mit denen Du auf den Fehler schliessen kannst.
> Sonst musst Du IMMER irgendwelche Zwischenresultate irgendwie ausgeben
> können zum Debugging.
>
> Gruss Chregu

Ach Mensch, D weiß man nun nicht ob man Mitleid haben sollte oder ihm 
eine Umschulung zum Zeitungsboten ans Herz legt.

Wenn ich das mal so Rechne... In zehn Zeilen Code, eine Zeile für die 
Debugausgabe... Das sind dann 10% des Codes. Krass! :'D Da wären hier im 
Forum aber so einige Arbeitslos wenn das deren Chefs mitbekommen!

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Draco schrieb:
> Ach Mensch

Freut mich, dass Du so gut programmieren kannst. Ich hoffe, das gibt Dir 
einen Ausgleich zu Deinen sozialen Kompetenzen!

Gruss Chregu

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>     while (1) ;
>    return 0;

Diese beiden Zeilen darfst du weglassen. Der avr-gcc fügt entsprechenden 
Maschinencode ggf. automatisch ein.

> jeder Code über 10 Zeilen funktioniert NIE auf Anhieb

Du ärmster. Ich programme jede Woche hunderte Zeilen am Stück (manchmal 
sogar über 1000, Kommetare und Leerzeichen nicht mitgezählt) und häufig 
funktionieren sie auch auf Anhieb. Bin ich jetzt bein Superheld? Sicher 
nicht, sondern einfach nur fortgeschritten, wie jeder andere es auch 
kann.

Autor: AVR-Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel

1. Benutze in Deinem Code die Bit-Namen wie sie im Datenblatt stehen und 
nicht ... (1<<1). Dann hast Du eine größere Chancem dass jemand helfen 
will.

2. Wenn Du Deinen Code korrigiert hast, poste in erneut. Wie soll sonst 
jemand wissen, welche Fehler Du neu eingebaut hast?

3. Wenn Du einen Programmfehler suchst, teste die Programmroutine, die 
den Fehler zeigt, isoliert. D.h. wenn die LED nicht leuchtet, dann wirf 
alles raus, was nichts mit genau diesem Pin und dieser LED zu tun hat.

4. Bei einem µC gibt es neben Software-Fehlern auch die Möglichkeit von 
Hardware-Fehlern - je nachdem, was Du mit dem Ding vorher gemacht hast.
Also nimm z.B. mal einen anderen Pin. Oder einen anderen µC.

5. Es soll auch Leute gegeben haben, die hatten zwar keinen Fehler beim 
Kompilieren, haben aber die dicke Fehlermeldung beim Flashen übersehen 
und wunderten sich dann, warum ihr neuer kleiner Freund den Code nicht 
ausführt, von dem er nie gehört hat.

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.