Guten Tag
Ich habe mal versucht, einen PIC zum laufen zu bringen. Das Program an
sich funktioniert fast ganz so wie ich es gerne hätte, würde der PIC
nicht penetrant die While (1){..} (eigentlich eine endlosschlaufe)
ignorieren
der Coode sieht folgendermassen aus:
Wie gesagt, es funktioniert alles, nur dass der PIC, wie ich vermute,
nach jedem Durchlauf ganz von vorne beginnt. Der Lautsprecher den ich
mit der Variable Ton ansteuere piepst nämlich alle paar Sekunden, sowohl
dass ja nicht möglich sein sollte, da sich der Pic später in der
While-schleife verweilen sollte.
Vielleicht liegt es daran, dass die Zeile mit den Konfigurationen
auskommentiert ist. Ich habe keinen blassen was dort gemacht wird, da
ich dass aus einem Programm aus dem Lehrbetrieb übernommen habe, weis
nur das der Kompiler nichts davon kennt und mir 20 Errors ins Gesicht
wirft.
Wäre sehr froh, wenn jemand helfen könnte :)
MFG
Hallo. Ich will demnächst auch mit PICs anfangen. Bin kein Experte, aber
könnte es am auskommentierten watchdogtimerdisable liegen?
//__CONFIG (WDTDIS ...
Siehst so aus, als scheint dein PIC immer wieder "abzustürzen"
Es fehlen leider wichtige Informationen ...
Welcher PIC? (Es gibt da sehr viele verschiedene Typen.)
Schaltplan?
So kann ich nur mit allgemeinen Ratschlägen dienen:
- Kondensatoren zwischen Vdd und Vss direkt am PIC
- Resetpin richtig beschalten oder MCLRE_OFF konfigurieren
- Brown Out Detection abschalten
- Watch Dog Reset abschalten
- Einfaches, kurzes Testprogramm, um Stacküberlauf auszuschließen
Und noch eine Bitte:
So umfachreichen Code nicht wieder im Beitrag posten, sondern als
Dateianhang mit richtiger Dateiendung, und für kurze Code-Fragmente im
Beitrag die entsprechenden Code-Tags verwenden.
;-)
Ich weiss nicht, was dein PIC macht, wenn du eine switch struktur hast,
die keinen Fall für "Light==0" kennt, aber Light 0 werden kann (nach
Light==10)
Vielleicht definierst du noch einen default case, der einfach nichts
macht.
Pascal schrieb:> der Coode sieht folgendermassen aus:> ...> fPortinitialisierung(void)
Und den übersetzt Dein C-Compiler ohne irgendwelche Kommentare?
C sieht seit 1989 vor, daß bei Funktionsdeklarationen und -Definitionen
der Datentyp des Rückgabewerts angegeben wird - void, wenn nichts
zurückgegeben wird.
Pascal schrieb:> #include "delay.h" //* Headerdatei Delayfunktionen */> #include "delay.c" //* Delayfunktionen */
Und das solltest Du Dir auch noch mal ansehen.
Pascal schrieb:> Wie gesagt, es funktioniert alles, nur dass der PIC, wie ich vermute,> nach jedem Durchlauf ganz von vorne beginnt.
Dann grenzt das ein. Vor der loop eine Led einschalten (mit delay) die
bei Neustart wieder ausgeht.
selbst ich, der schon einige zeit mit PICs arbeite, mache ganz am anfang
eines projekts mit einem neuen PIC erstmal ein blinklicht - und in der
letzten zeit, bleibt das meist bis zum schluss einfach im hintergrund:
wenn da was blinkt, weiss ich, dass der PIC zu 95% ordnungsgemäss läuft
:-)
ich würde dir das selbe vorschlagen: erstmal ein blinklicht, und dann
nach und nach das projekt mit code füllen. das hat den unglaublichen
vorteil, dass man nicht lange suchen muss, wo(!) ein fehler liegt, wenn
mal was nicht richtig läuft.
Hallo,
schau mal in den config Bits, ob nicht der Watchdog eingeschaltet ist.
Wenn ja, schalten ihn aus oder setzte regelmässig den Watchdogtimer
zurück.
Der kann das verursachen, wenn er regelmässig des Reset zieht, weil dann
immer ein Hochlauf passiert.
Hat mich bei meinem ersten Blinkprogramm ein paar Stunden gekostet...
Ich denke nach wie vor das Programm durchläuft deine gesamte
Lichtsequenz, und am Ende der Sequenz setzt du "Light=0;"
Da es keinen case für 0 in der select struktur gibt, vermute ich gibt es
eine exception, die einen Reboot hervorruft.
Easylife schrieb:> Ich denke nach wie vor das Programm durchläuft deine gesamte> Lichtsequenz, und am Ende der Sequenz setzt du "Light=0;"> Da es keinen case für 0 in der select struktur gibt, vermute ich gibt es> eine exception, die einen Reboot hervorruft.
Ein Default-Zweig wird eigentlich nach C-Standard automatisch angelegt
und ist insofern nicht erforderlich, wenn keine spezielle Aktion
ausgeführt werden soll.
Danke für die Ratschläge.
Im Anhang das Schema. Ein Hardwarefehler ist auszuschliessen.
Nun Zuerst die Fehlermeldung, wenn ich die Configuration nicht mehr
auskommentiere:
Wenn ich im entsprechenden Headerfile nachschaue finde ich
interessanterweise die Befehle, darum habe ich auch mittlerweile
verstanden, was hier geschieht.
Darum ahbe ich den Programcode ensprechend angepasst.
1
#define WDTDIS=0x3FF7; //Die konfiguration habe ich so aus dem pic.h File geholt
2
#define PWRTDIS=0x3FFF; //ob es funktioniert weiss ich nicht, aber es gibt keine
3
#define MCLRDIS=0x3FDF; //Fehler die der Compiler mir anzeigt
Ähem, ich habe die ganze Diskussion nicht Wort für Wort gelesen, aber:
Bei einem PIC-Compiler hatte ich mal ein sehr ähnliches Problem,
while(1) wurde einfach nicht korrekt übersetzt. Anstelle dessen habe ich
dann ein for(;;) eingebaut und fertig. Für eine tiefere Analyse hatte
ich keine Lust, denn die Anweisung hat den gleiche Effekt.
War ein CCS Compiler, Version weiß ich nicht mehr.
Wie geraten habe ich ein Test Programm geschrieben, funktioniert.
Peter schrieb:> - Läuft dein PIC ?
ja
> - ConfigWord richtig gesetzt ?
Ist ausgeklammert, demfall eher nicht, wegen beschriebenem fehler
> - Taktquelle ?
interner Quarz, funktioniert.
> - Reset richtig beschaltet ?
RB3 auf masse gezogen,(5k6)
> - PIC richtig beschaltet ?>Bestimmt> - Hast du SIMULIERT ?
Nein, können sie mir eine Software empfehlen?
Michael L. schrieb:> Welcher PIC? (Es gibt da sehr viele verschiedene Typen.)
16F887
> Schaltplan?
jep, vorher
> So kann ich nur mit allgemeinen Ratschlägen dienen:
:)
> - Kondensatoren zwischen Vdd und Vss direkt am PIC
Ja
> - Resetpin richtig beschalten oder MCLRE_OFF konfigurieren
MCLR=RB3 ist pull down auf masse.
> - Brown Out Detection abschalten
nein, weil bisher beschiebener fehler.
> - Watch Dog Reset abschalten
nein weil bisher beschiebener fehler.
Wenn meine pseudokonfiguration funktioniert wie ich sie in der
vorletzten antwort geschireben habe, dann ist das jetzt erledigt.
> - Einfaches, kurzes Testprogramm, um Stacküberlauf auszuschließen
gemacht, hat funktioniert.
Easylife schrieb:> Ich weiss nicht, was dein PIC macht, wenn du eine switch struktur hast,> die keinen Fall für "Light==0" kennt, aber Light 0 werden kann (nach> Light==10)
gemacht, ändert leider nichts.
Rufus Τ. Firefly schrieb:>> fPortinitialisierung(void)>> Und den übersetzt Dein C-Compiler ohne irgendwelche Kommentare?
Nein, er hat keine ersichtlichen Probleme damit
> C sieht seit 1989 vor, daß bei Funktionsdeklarationen und -Definitionen> der Datentyp des Rückgabewerts angegeben wird - void, wenn nichts> zurückgegeben wird.
Wie meinen sie das genau? es ist void eingetragen, und die Funktion soll
auch nichts zurückgeben, was sie meine Meinung nach auch tut.
> Pascal schrieb:>> #include "delay.h" //* Headerdatei Delayfunktionen */>> #include "delay.c" //* Delayfunktionen */>> Und das solltest Du Dir auch noch mal ansehen.
Die funktionieren, der grösste Fehler kann sein, dass die
Delayfunktionen auf andere Frequenzen als mein interner Standard 4MHz
tackt ist. Aber das stört im Moment noch nicht
Harald schrieb:> Bei einem PIC-Compiler hatte ich mal ein sehr ähnliches Problem,> while(1) wurde einfach nicht korrekt übersetzt. Anstelle dessen habe ich> dann ein for(;;) eingebaut und fertig...
Habe ich auch bereits versucht, hatte leider nichts gebracht.
Vielen Dank an alle für die Mühe und Antworten.
Pascal schrieb:>> - Resetpin richtig beschalten oder MCLRE_OFF konfigurieren>MCLR=RB3 ist pull down auf masse.
Du meinst sicher RE3.
>> - Brown Out Detection abschalten>nein, weil bisher beschiebener fehler.
Bei eine stabile Betriebsspannung und wenn die Kondensator nicht fehlen,
sollte das nicht so kritisch sein.
>> - Watch Dog Reset abschalten>nein weil bisher beschiebener fehler.
Das ist definitiv eine mögliche Ursache, wenn der Watch Dog nicht
abgeschaltet ist, und nicht rechtzeitig zurückgesetzt wird.
>> Pascal schrieb:>>> #include "delay.h" //* Headerdatei Delayfunktionen */>>> #include "delay.c" //* Delayfunktionen */>>>> Und das solltest Du Dir auch noch mal ansehen.> Die funktionieren, ...
Was Rufus damit sagen wollte: Man includiert nur Header-Files.
Klar funktioniert das trotz dem irgendwie, aber es ist schlechter Stil,
der dir irgendwann auf die Füße fällt.
Genau so kann man Funktionen in Header-Files schreiben, tut es aber
nicht.
Wie sieht das kurze Testprogramm aus, und was bedeutet "es hat
funktioniert"?
;-)
Hallo
Ich hatte mittlerweile etwas zeit, und habe das Problem gefunden.
Wenn ich das PWM einschaltem möchte stürzt der Pic früher oder später
ab.
Die Fehleranalyse findet man im Anhang.
Ich habe den Code für das PWM im Internet gefunden, genau hier:
http://www.micro-examples.com/public/microex-navig/doc/097-pwm-calculator.html
da habe ich direkt das aus dem Codebeispiel auf dem unteren Teil der
Seite kopiert.
Nun wenn ich im Datenblatt des Pics nachschaue werde ich nicht schlau,
was in den Registern genau passiert. Kann mir das vieleicht jemand
erklären? Wahrscheinlich findet sich auch dort der Fehler.
Freundliche Grüsse
Pascal schrieb:> Wenn ich das PWM einschaltem möchte stürzt der Pic früher oder später> ab.
Ist die Formulierung "sobald ich die Akustik einschalte kommen Fehler"
richtig?
Was hängt am PWM?
- Können Störungen entstehen. z.B. ist ein Speaker auch ein Generator.
- Reicht die Stromversorgung, ist die zum Pic getrennt vom Leistungsteil
Pascal schrieb:>> - Resetpin richtig beschalten oder MCLRE_OFF konfigurieren> MCLR=RB3 ist pull down auf masse.
MCLR ist RE3. Ausserdem gehört der per Pull-up an VCC, nicht an Masse!
Kann möglich sein, daß ich mich irre.
Ein MCU ist ein Microkontroller meine einem mehr oder weniger dürftigen
Befehlssatz. Ein Teil bevorzugt für das bißchen Speicher Assembler und
der Rest machts nicht uter C/C++.
Genaugenommen ist die Sprache völlig Wurscht: ein MCU, egal ob von Atmel
oder Microchip versteht eine dürftige Untermenge dessen, was selbst der
dürftigste schon an die Schmerzgrenze treiben könnte.
C wird als portabel angepriesen, was aber nicht stimmt.
Pascal soll es wohl geben
Basic war schon nie das Gelbe vom Ei.
Verzweigungen gibt es - mehr üder weniger dürftig,
Fallentscheidungen: sucht man vergeblich
Dafür wird man als Atmel Kunde gearscht, den HEX-Code so in den Chip zu
kriegen, daß er nachträglich noch korrigiert werden kann.
Nur mal janz dumm gefragt:
ist das wirklich alles, was angeboten wird, ohne TQFP 100 auf die
Leiterplatte zu kleben, oder lese ich nur im falschen Forum, weil der
Luxus paar Türen weiter wohnt?
Selbst bei nem lächerlichen Sprungbefehl stellt sich Microchip mehr
Beine als der Käfer welche hat.
Fragen nach Python kann aich mir wahrscheinlich in die Haare schmieren.
OOP in C++ bei den paar Bytes Flasch + keine Möglichkeit, Code im RAM
auszuführen, halte ich für nen Kindergartenwitz.
In welcher Idiotenanstalt wohnen diese "Entwickler" eigentlich?
michael "meikel" D. schrieb:> Kann möglich sein, daß ich mich irre.> ...
Was ist dir denn passiert?
Niemand wird zu einem µC gezwungen, außer vielleicht ein paar Besuchern
von Lehranstalten.
Thread beobachten
Seitenaufteilung abschalten