mikrocontroller.net

Forum: Compiler & IDEs Hallo Welt macht nicht was es soll


Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich fange gerade an mit avr c-programmierung und wollte mit dem hallo
welt/ led blink starten. (ich nutze das gcc Plugin für das AVR-Studio
in der grundinstallation)

Wenn ich im Debugmodus schrittweise das Programm durchlaufe passiert
erstmal das was passieren soll.
1. Pin wird als Ausgang gesetzt
2. Schleife startet
3. Pin wird 0 gesetzt
4. es wird in die delay.h gesprungen und 500ms gewartet

Jetzt jedoch sollte der pin 1 gesetzt werden und dann wieder in die
delay.h gesprungen und gewartet werden.
Was jedoch passiert ist:

1.es wird NICHT in die delay.h gesprungen
2. es wird aber trotzdem gewartet
3. der Pin wird erst NACH dem warten 1 gesetzt

Da jetzt die Schleife von neum startet wir der Pin sofort wieder 0
gesetzt und man kann nur ganz ganz kurz sehen das der pin zwischendurch
auf 1 geht.

Das ist das was ich beobachtet habe... Was mache ich falsch? Passiert
das bei jemand anders genauso?
Was muss ich ändern damit es so läuft wie es eigentlich sollte (erst
pin auf 1 setzen, DANN das zweite mal warten (vielleicht sogar MIT dem
Sprung in die delay.h Datei wie beim ersten aufruf von Delay))??

Der Code ist so kurz das ich ihn gleich hier einfüge.
Sorry wenn es nur ein dummer Anfängerfehler von mir ist, ich würde mich
aber freuen wenn mir jemand helfen kann (irgendwo muss man ja anfangen
:))


#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#define F_CPU 3686400UL
#endif
#include <util/delay.h>



int main(void)
{
DDRC|= (1 << 5);
while (1) {
PORTC&= ~(1 << 5);
_delay_ms(500);
PORTC|= (1 << 5);
_delay_ms(500);
}
}

Autor: MasterFX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also gucken wird doch mal deinen Quellcode an:
int main(void)
{
   DDRC|= (1 << 5);
   while (1) {
     PORTC&= ~(1 << 5);
     _delay_ms(500);
     PORTC|= (1 << 5);
     _delay_ms(500);
   }
}
Dein Problem ist, dass du mit &= arbeitest. bla &= 5 bedeutet ja nichts
anderes als bla = bla & 5. Beim AVR ist PORTC aber nicht zum lesen
gedacht, sondern dafür sind PINC. Sonst liest du den internen Zustand
der Pull-Up Widerstände
Du musst also machen:
int main(void)
{
   DDRC |= (1 << 5);
   while (1) {
     _delay_ms(500);
     PORTC = PINC ^ (1 << 5);
   }
}

Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die schnelle Antwort.
Das versteh ich aber nicht so ganz.

1. ich habe es umgeändert und das Problem mit dem Delay ist immernoch
das selbe (es hat sich also nicht wirklich was geändert (habe neu
compiliert))

2. Wenn ich das richtig verstanden habe dann dürfte ja DDRC |= (1 <<
5); ebenfalls nicht funktionieren (ist doch das gleiche Prinzip oder?)

3. Die Anweisung PORTC&= ~(1 << 5); zum löschen eines bits steht doch
aber genau so sogar in dem AVR GCC Tutorial auf mikrocontroller.net
dann sollte das doch eigentlich auch funktionieren oder?

Danke schonmal für weite Hilfe

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MasterFX,

das ist Quatsch mit Soße.

Will man einen Ausgang ändern, muß man natürlich das Ausgangsregister
lesen, damit die anderen Pins unbeeinflußt bleiben.

Beim Lesen des Eingaberegisters würde man dagegen z.B. ner Taste an nem
anderen Pin den Pullup klauen.


Peter

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
Registername &= ~(1 << 5) löscht schon das Bit. Aber den Zustand eines
Pins liest man wie MasterFX schon sagte mit dem __PIN__X-Register. Da
hift nur das Kapitel über die Portregister im Datenblatt noch einmal
ganz genau zu lesen

Gruß

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder mal: Die _delay_ms-Funktion kann keine 500ms auf einmal! Die
max. Verzögerung ist 262,14ms/F_CPU [in MHz]! Macht also bei Deinen
3,6864MHz ungefähr 71 ms maximal... Müsstest dann mit ner for-Schleife
mehrere Aufrufe hintereinander machen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Programm ist grundsätzlich in Ordnung,
nur gibt es 1 klitzekleine Nebenbedingung
im Zusammenhang mit Delay.

Du kannst mit _delay_ms keine 500 ms warten!
Die maximale Zeit ist in delay.h dukomentiert und ist von der CPU
Frequenz abhängig. Du kannst aber mal davon ausgehen, dass
das nicht mehr als 20 ms sein werden. (Schau doch mal in
delay.h hinein. Ist auch nur eine Textdatei)

Entweder packst du also den _delay_ms Aufruf in eine Schleife
oder du machst einfach ein paar _delay_ms() hintereinander, wobei
jeder einzelne nicht länger als 20 ms dauern darf.

PS: Das mit PIN und PORT so wie MasterFX das gemeldet hat, ist
natürlich Unsinn. Du willst ja den momentanen Zustand des
AUsgangsports lesen um dort ein Bit zu toggeln. So wie du das
hast, ist das schon richtig.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja.
Da ist noch was. Hast du am PORTC das JTAG Interface abgeschaltet?
Da sind ein paar Pins am C-Port die per default auf JTAG geschaltet
sind und dann in der echten Hardware für Ärger sorgen. Also
entweder JTAG per Fuse abschalten oder einen anderen als den
C-Port benutzen.

Autor: MasterFX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Heinz
Setzt der Compiler das richtig um? (weil man doch eigentlich nur PINC
lesen soll/darf).

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> weil man doch eigentlich nur PINC lesen soll/darf

Wo steht das?

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PORTC ist ein normales Read-Write-Register und lässt sich als solches
selbstverständlich lesen. Wäre auch für viele Anwendungen schlimm,
wenns nicht ginge. Ich z.B. möchte in manchen Fällen schon gerne
wissen, welchen Zustand mein Ausgangstreiber hat, v.a. dann, wenn er in
ISRs verändert werden kann...

Autor: MasterFX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn der Port auf Eingang gestellt ist darf man den Status nicht
mit PORTx abfragen,weil man dann nur den Zustand der Pullup Widerstände
abfragt. Ich hatte gedacht bei Output wäre das ähnlich bzw. es gäbe evtl
Probleme wenn nicht der gesamte Port als Ausgang konfiguriert sind.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kommt drauf an, ob Du den Eingangswert abfragen willst oder ob Du
wissen willst, ob Deine Pull-Ups eingeschaltet sind! Denk doch bitte
mal nach, was Du da überhaupt schreibst! Wo wird denn bitteschön oben
auch nur irgendein Eingangszustand abgefragt??? Es soll lediglich der
aktuelle Stand von PORTC mit einem neuen Wert versehen werden, und das
geht genau so wie Andre es geschrieben hat!

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also wenn der Port auf Eingang gestellt ist darf man den Status
> nicht mit PORTx abfragen,weil man dann nur den Zustand der Pullup
> Widerstände abfragt.

Man darf schon, eben genau wenn man den Status der Pullup-Widerstände
abfragen will.

> Ich hatte gedacht bei Output wäre das ähnlich bzw. es gäbe evtl
> Probleme wenn nicht der gesamte Port als Ausgang konfiguriert
> sind.

Man liest halt von PORTC das, was man beim letzten mal reingeschrieben
hat. Welche Pins da als Eingang und welche als Ausgang definiert sind,
spielt dabei keine Rolle.

Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe jetzt die Dlayanweisung geaendert und zwar in nur 20ms
(von 500).
Das Problem ist leider nach wie vor das gleiche.

1. Es wird nur beim ersten aufruf von delay in die delay.h gesprungen.
(ich meine nicht nur ein einziges mal sondern immer nur das delay was
als erstes in der Schleife erscheint)
2. es wird trotzdem (auch bei dem zweiten delay) gewartet (ich glaube
aber es wird immer gleich lange gewartet egal ob ich 20ms oder 500
angebe)
3. erst NACH dem warten wird der Pin 1 gesetzt (und somit, weil die
Schleife an der Stelle ja von vorn losgeht, sofort wieder auf 0)

Kann es sein das das was ich im Dbugmodus sehe sich "in Echt" dann
anders verhaelt? Das nur der Simulator irgendwie ein Problem hat und
wenn ich das ganze wirklich auf den ATMega spiele richtig funktioniert?
(ich habe mein "Spiel-board" naemlich noch nicht und probiere nur mit
AVR-Studio rum)

Danke schonmal fuer weitere Tipps,wuerde mich freuen wenn ich das
kleine Anfaengerprogramm dazu ueberreden koennte genau das zu tun was
es eigentlich soll :)

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du im Debugger/Simulator einfach auf 'Run' geklickt hast und
keine Breakpoints an den entsprechenden Stelle gesetzt hast, dann hinkt
die Anzeige sowieso hinterher und zeigt in den meisten Fällen alles an,
nur nicht den aktuellen Zustand. Du musst es dann entweder mit
Breakpoints machen oder das ganze im Einzelschritt-Modus durchspielen.
Dann weißt Du genau, was passiert.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Delays in der Simulation sind immer übel.  Außerdem ist das
inline-Code, damit hat jeder Debugger mehr oder minder Probleme
in der Anzeige (da ja mitten in der Funktion die Quelldatei
umschaltet).

Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das was ich beschrieben habe habe ich im Einzelschrittmodus
festgestellt.

Also die Stelle auf die es ankommt:

- ende des ersten delays (die delay.h wird verlassen)
- (click naechster Schritt)
    --> es wird nicht in die delay.h gesprungen
    --> es wird gewartet
    --> nach dem Warten wird der Pin 1 gesetzt und der gelbe Pfeil
springt wieder hoch zu der Zeile wo der Pin wieder 0 gesetzt wird
- wenn ich nochmal auf naechster Schritt clicke wird der Pin dann
wieder 0 gesetzt (was ja an der Stelle auch in Ordnung ist)

Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joerg Wunsch:

es ist also wahrscheinlich das der Debugger nur Probleme hat mir den
korrekten aktuellen Zustand anzuzeigen und korrekt zwischen den Datein
zu wechseln, mein AVR wuerde aber richtig agieren?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

Autor: Andre Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK in ca 10 Tagen bekomme ich mein MyAVR board und dann werd ich das mal
"in Echt" probieren und gucken was passiert.


@MasterFX:
Ich weiss jetzt was Du meinst.
Wenn Du ein als Eingang gesetzten Pin lesen willst (also wissen willst
was da von aussen anliegt) dann musst Du PINX nehmen (weil Du mit PORTX
den PullUp lesen wuerdest).
Wenn Du aber wissen willst welchen Wert ein momentan als Ausgang
gesetzter pin hat (und das wollen wir ja an der Stelle damit wir das
nutzen koennen um den Zustand zu aendern [wie Du ganz oben beschrieben
hattest]) DANN musst Du PORTX benutzen.
Was man nutzen muss haengt also davon ab ob der Pin als Ausgang oder
als Eingang gesetzt ist.

Wenn das so stimmt wie ich es jetzt geschildert habe kann ja nochmal
jemand kurz ein OK geben, wenn es falsch ist bitte berichtigen.

Danke

Andre

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK.

Du kannst natürlich auch bei einem auf Ausgang geschalteten
Pin PINx lesen, dann liest du den realen Wert am Pin, nicht
das Ausgaberegister.  Das kann ein Unterschied sein -- wenn
jemand einen Kurzschluss am Ausgang gebaut 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.