Hallo, seit einiger Zeit sollte eigentlich mein Temperaturlogger im Garten arbeiten und über das ganze Jahr ein wenig Statistikmaterial liefern, er misst stündlich die Temperatur über einen DS1822 der übrigens erstaunlich genau arbeitet und speichert sie in einem 32K EEPROM ab. Das System ist auf extrem Low Power getrimmt, wacht RTC gesteuert nur einmal die Minute auf und arbeitet mit einer kleinen Solarzelle samt 3 AAA Akkus ohne Spannungsregler, der 1330 hat eine interne Referenz, die Spannung pendelt zwischen 3.0V und 4,5V je nach Sonne. Am Netzteil getestet klappte das auch alles, er schlief ein und wachte wieder auf. Unterschreitet sie 3.0V greift die Low Voltage Detection und schaltet ab. Der 1330 wird mit internem RC Osillator betrieben, zwischen 4 Mhz und 125 khz. Um äusserlich zu sehen, dass er arbeitet blitzt eine blaue LED, die mit nur 100uA ausreichend hell ist. Das Energie Management habe ich bis ins kleinste Detail ausgearbeitet, er schätzt anhand der Batteriespannung ab ob gerade eine Sonnenwoche ansteht oder eine Regenzeit, passt sich den Jahreszeiten durch den Kalendar der RTC entsprechend an und funkt nur durch den RFM12 an seine Basisstation wenn genügend Energie da ist. Mein Dank auch an den Herrn Heldt hier im Forum, der mir die PCF8563 RTC verkaufte, die wirklich genau läuft, wenn man sie mit einem Trimmer trimmt und die auch beliebig oft abgefragt werden kann ohne falsch zu gehen. Nun ist es aber so, dass sich der 18F1330 nach etlichen Stunden plötzlich aufhängt, dabei hat er nur einen einzigen ResetWatchdog Befehl im Code, der WDT schlägt nach 10s zu. Das System steht einfach, dabei kann das doch gar nicht sein. Der WDT hängt allerdings ebenfalls am INTRC Oszillator. Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben? Ich überlege, ob ich einen 8 Pinner spendiere als externem Watchdog. Gruss, Christian
>PIC 18F1330 hängt sich auf Jööööö. Mein Beileid. >Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben? Nein. Das ist ein Programmfehler. Ueblicherweise auf Zeile 42.
Das Niveau dieses Forums befindet sich leider auch im freien Fall.....
So. Ist es das ? Also der Ansatz bisher ist gut. Ueber das Programm kann ich eher wenig sagen, da unbekannt. Einen sauberen strukturierten Programmaufbau vorausgesetzt, sollte ein fehlerfreies Programm machbar sein. Sorry. Eine Hauptschleife und eine Timer-Tick und es sollte relativ einfach zu zuverlaessig laufen.
bella bella bella marie sie hängt sich auf ich schneid sie ab morgen früh!!! nicht von mir Gast
Hallo Christian, >Nun ist es aber so, dass sich der 18F1330 nach etlichen Stunden >plötzlich aufhängt, dabei hat er nur einen einzigen ResetWatchdog Befehl >im Code, der WDT schlägt nach 10s zu. die Anzahl der ResetWatchdog-Befehle ist ja weniger ausschlaggebend als der Zeitpunkt ihrer Ausführung. Überlege, wo im Programm setzt du den WDT zurück und kann das im Zusammenhang mit: >Das System steht einfach, dabei kann das doch gar nicht sein. Der WDT hängt >allerdings ebenfalls am INTRC Oszillator. überhaupt zu deinem konkreten Problem führen? Du schreibst leider nicht was die Kontroll-LED macht wenn der PIC 'stehenbleibt' >Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben? Nein, bisher hat sich immer ein 'Schuldiger' gefunden. Wie siehts denn mit dem externen EEPROM aus, I2C oder SPI? (Vielleicht 'hängt' da was...?) >Ich überlege, ob ich einen 8 Pinner spendiere als externem Watchdog. Ich befürchte, das wird das Problem nicht lösen. >das machen die PIC`S gern! Unfug! Lass Dir da nichts einreden. Gruss, Edson
Hallo Edson, also wenn ich beim CCS 4.1 Compiler den delay Befehl ohne restart_wdt ausführen lasse, also #use delays (Internal, 4MHZ) dann muss jede Endlosschleife im Code zwangsläufig einen Reset auslöen, egal wo. Bei den EE Routinen sind einige Schleifen dabei, etwa das Warten auf Ende des Schreibens usw. Nur sleep setzt ihn zurück. Es gibt eben nur den einzigen reset_wdt Befehl in der Hauptschleife. Befindet sich der PIC im Sleep Zustand wacht er bei Überlauf auf, befindet er sich in der Codeausführung führt er einen Hardwarereset durch. Die LED blinkt nicht mehr, wenn er stehenbleibt, ist klar. Ein externer WDT ist auf jeden Fall eine doppelte Sicherheit.... Alternativ könnte ich einen Quarz verwenden und die Fail-Safe Struktur des Chips nutzen, der auf einen anderen Osci umschaltet, sobald der primäre versagt aber dann verliere ich wieder zwei Pins, die ich dringend brauche. Das Errate Sheets verrät nichts besonderes, nur die üblichen kleinen Bugs in der Eusart etc. die ich eh nicht brauche. Andererseits: An meiner Wand hängt ein schickes Lochrasterboard mit LCD-Uhrenanzeige mit 18F442, läuft seit zwei Jahren pausenlos durch. Gruss, Christian
> Bei den EE Routinen sind einige Schleifen dabei, etwa das Warten auf Ende > des Schreibens usw. und die haben ein Ausgang im Fehlerfall? PICPICPIC macht das Huhn!!!! ps das beschreibt diese (und andere) Macken! warum sind so viele Leute mit dem Entwanzen von Standard-Befehlsfolgen beschäftigt? und warum nicht nicht ein USB µC 18F4550 in der dritten Variante der klaglos nur (ich verlange ja nicht viel) funktioniert.!!! Warum wird kleinern Unternehmen entsprechende Unterstützunng verwehrt? Antwort: AVR von einem, der seit 20 Jahren mit dem Zeug rummacht
@ Karsten >und die haben ein Ausgang im Fehlerfall? PICPICPIC macht das Huhn!!!! Lass uns doch mal an deinem umfangreichen Erfahrungsschatz teilhaben. Was läuft bei dir schief ? Ich schon ein paar PIC16 und PIC18 verbaut. Und damit meine ich nicht 10 oder 100. Die laufen alle noch.
>also wenn ich beim CCS 4.1 Compiler den delay Befehl ohne restart_wdt >ausführen lasse, also #use delays (Internal, 4MHZ) dann muss jede >Endlosschleife im Code zwangsläufig einen Reset auslöen, egal wo. Ok, von CCS war vorher noch nicht die Rede. Dazu kann ich nicht viel sagen, ich kenne den Compiler nicht. Hast du dir die Assembly mal angeschaut? Ohne den .ASM-Code kann man nur raten, die Lösung mit einem weiteren Watchdog halte ich aber für eher 'unelegant'. Gruss, Edson
>> Vielleicht ein Stack-Overflow oder falsch referenzierter Pointer ? Danke, werde ich mak nachschauen, die Stacktiefe ist allerdings nur 7 und kann maximal 32 sein. INTs benutze ich nicht. Wie aber noch gesagt, der Code kann soviele Fehler haben wie er will, eine Fehlerbehandlung brauche ich nicht, der PIC kann eh darauf nicht reagieren, er hat ja nichts womit er einen EEPROM Fehler beheben kann. Man kann nur hoffe, dass ein Reset das Problem löst. Und der WDT läuft stur durch, wird er nicht resettet wegen einer fehlerhaften Endlosschleife reisst er die Leine und führt den HW Reset aus. Das müsste aber bekannt sein, daher verstehe ich die Fragen nicht ob der Code richtig ist. Das weiss man bei einem Compiler nie so ganz, bei keinem. Ich wollte eigentlich nur wissen, ob es bekannt ist, dass PIC mit INTRC Oszi ab und zu mal stehen bleiben. PS: Der Glaubenskrieg AVR - PIC gehört hier nicht hin. Anbei mal der EE Code als Beispiel warum ich CCS benutze der eine HAL hat, macht einfach mehr Freude und weniger Code.
Hallo, ich hab mir das Ganze nicht angeschaut, mit PIC habe ich auch nichts am Hut, aber: der WDT löst einen Reset aus, weil der Kram irgendwo hängen geblieben ist. Schreibroutine, Lesen des Sensors, Lesen des RTC. Ist denn Sichergestellt, daß diese Peripehrie nach dem Reset in einen definierten Zustand gebracht wird (gebracht werden kann), damit das Ding nicht gleich wieder hängt, weil z.B. der RTC garnicht antworten kann, weil er in einem undefinierten Zustand der Übertragung hängt und da nicht rauskommt? Sind also die Init-Routinen in der Lage, das System aus JEDEM Zustand zu initialisieren und können die externen ICs das auch? Gruß aus Berlin Michael
>der WDT löst einen Reset aus, weil der Kram irgendwo hängen geblieben >ist. So wie ich das verstanden habe löst er eben nicht aus obwohl das Programm steht. Ich schätze mal das der PIC im Sleepmode ist und der WDT ihn da nicht rausholt. Zwar habe ich schon so manches Programm für PICs geschrieben (auch mit CCS) aber den Sleepmode habe ich noch nie benutzt.
Beim AVR-GCC gibt es ne gemeine Sleep-Fallgrube: Wenn man die Sleep-Funktionen benutzt, kann man sich für alle Zeiten schlafen legen und nie wieder aufwachen. Die Bibliotheksfunktionen dürfen nicht benutzt werden, da nicht interruptfest, sondern man muß das Sleep direkt im Sleepmoderegister enablen und direkt den Sleep-Befehl ausführen. Nur so ist sichergestellt, daß der Aufwachinterrupt garantiert enabled ist, bevor die CPU in den Sleepmode geht! Könnte mir beim PIC ein ähnliches Problem vorstellen. Peter
Seltsamerweise benutzt der Poster keinen INT. Wie auch immer das gehen soll.
3355 wrote: > Seltsamerweise benutzt der Poster keinen INT. Wie auch immer das gehen > soll. Ich hab mir das Programm nicht angesehen (PICs sind mir zu kompliziert). Ich hatte nur vermutet, daß der RTC den PIC zyklisch aufweckt wegen Strom sparen. Beim AVR hätte man keinen extra RTC benötigt, da der ja intern mit T2 einen 32kHz-Quarz zählen kann, während der Haupttakt und die CPU schläft. Peter
Ich bin mal davon ausgegangen, dass ein PIC18 praktisch identisch zu einem AVR ist. Bei einem AVR lohnt es sich fuer Stromsparanwendungen einen externen RTC zu verwenden. Eine DS1302 zB kommt mit 200nA durch, was man mit einem AVR als RTC nicht schafft. Dass keine Interrupt verwendet wird ist eine Aussage des Posters. Hat mich nur gewundert, wie das Aufwecken denn gehen soll. Scheint ein Murks zu sein. Ohne Tick macht man nicht viel ausser Delayloops.
Hallo, natürlich habe ich keinen Murks programmiert, mache das ja nicht zum ersten Mal. Die RTC löst am EXT3 Pin eine Flanke aus, diese Flanke setzt intern ein INT Flag im PIC. Der Global INT ist aber gesperrt, daher wird keine Routine angesprungen. Ich frage das Flag manuell ab. Der PIC wacht dadurch auch auf. Externe RTC deshalb weil Lösungen mit 32khz Quarz zu ungenau sind, die am Timer 1 arbeiten, die PCF8563 ist super am I2C Bus. Das Problem scheint aber gelöst zu sein, ein Poster hier hat schon richtig getroffen, nämlich, dass die Peripherie nicht richtig initialisiert wurde. Ich boote den PIC nun mit 256khz hoch und schalte dann erst um nach 100ms, ausserdem habe ich den I2C Bus von 400khz auf 100khz reduziert. Seitdem läuft er durch, er schien nach dem Reset zu hängen, wo weiss ich nicht. Es ist aber bekannt dass die PIC manchmal probleme haben die 40 Mhz zu fahren. Das Thema ist bekannt, sie werden dann schonmal instabil, daher empfehlen die FAE auch nicht schneller als 16 Mhz. Nochwas: Wenn man die PICs einmal durchschaut hat und ich arbeite seit fast 12 Jahren mit denen, dann sind das super Dinger, genau wie die Lite Serie von ST, die kaum jemand im Bastelbereich einsetzt. Die Dinger fahren sich mit men Oldtimer, die Schltung hakt und mein Vater kann ihn nicht fahren aber wenn man es erstmal gelernt hat mit Zwischengas dann fährt er sich super.
Hallo Christian, >Wie aber noch gesagt, der Code kann soviele Fehler haben wie er will, >eine Fehlerbehandlung brauche ich nicht, der PIC kann eh darauf nicht >reagieren, er hat ja nichts womit er einen EEPROM Fehler beheben kann. da hast Du mich falsch verstanden oder ich habe mich ungenau ausgedrückt. Im Prinzip habe ich nicht von fehlerhaften EEPROM-Zugriffen gesprochen sondern wollte allgemein auf mögliche Probleme der Kommunikation (mit der Peripherie) hinweisen. Die Frage nach der Ansteuerung des EEPROM war nur ein Beispiel. >daher verstehe ich die Fragen nicht ob der Code richtig ist. Jetzt aber schon, oder? Die Initialisierung gehört doch zum Programm. >Das weiss man bei einem Compiler nie so ganz, bei keinem. Da hast wohl recht (daher arbeite ich gerne mit ASM). Aber sollte man nicht immer wissen was der Compiler macht, bzw. bei bestimmten Funktionen wider erwarten nicht macht? Damit man Aussagen treffen kann wie z.B. Peter Dannegger(24.05.2008 11:34). >Das Problem scheint aber gelöst zu sein, Gratuliere, dann passt es ja jetzt! >Wenn man die PICs einmal durchschaut hat ... dann sind das super Dinger Absolut! @3355 >Ich bin mal davon ausgegangen, dass ein PIC18 praktisch identisch zu >einem AVR ist. Na ja, hoffentlich hast du jetzt gemerkt dass derlei Vergleiche keinen Sinn machen ;) >Ich schätze mal das der PIC im Sleepmode ist und der WDT ihn >da nicht rausholt. Wie gesagt, derlei Phänomene sind mir nicht bekannt. Gruss, Edson
Hallo Edson, danke für Deine Antwort. Es ist ein Unterschied, um ein System mit Power-Up aufstartet oder aber durch einen Reset neu bootet. Der I2C Buss man ja auch einen definierten Pegel haben, damit die internen Statemachines der Bausteine einen Reset auslösen. Damit ein PIC neu bootet reicht ein Blitz bei einem Gewitter aus oder eine Bohrmaschine, die nebenan betrieben wird. Manche Probleme lösen sich, wenn man das Problem anders formuliert ohne dass man genau weiss, warum es vorher so war. Das sind dann die Probleme, die einem Sorgen bereiten, weil man nicht weiss woran es lag. Ich bin zu faul den ASM des Compilers noch zu untersuchen, gebe auch zu dass ich PIC Asm verlernt habe, seit 1998 wo ich den ersten Compiler benutzt habe, den Byte Craft, der völlig buggy war. PIC Asm sprechen ist wie das Gestammel eines Babys, es ist zwar ein orthogonaler RISC Befehlssatz aber komplexe Sachen lassen sich damit kaum lösen, ich benutze intensiv Strukturen und Zeiger, bin mit Pascal und C aufewachsen. Routinen teste ich daher mit einer Testumgebung im Programm, je weniger man den HAL (Hardware Abstraction Layer) des CCS Compilers benutzt, der die Hardware abstrahiert, umso sicherer kann man sein, dass keine Compilerfehler Ursache sind. Die PIC haben ihre Macken, Microchip wirft teilweise Chips auf den Markt, die gar nicht lauffähig sind "Unter bestimmten Umständen kann es zu einem Programmabsturz kommen, nähere Umstände sind noch nicht bekannt "steht es da im Errata Sheet. Aber selbst der ARM7 den ich noch von NXP benutze strotzt vor Fehlern, selbst 10 Jahre nach Erscheinen als ich noch VHDL Muckl bei NEC war und wir die Peripherie dafür designten. Lassen wir es gut sein, heute hat mich der ADAC auf der A44 wieder reingeholt, weil meine Nockenwelle im Fiat X1/9 den Kopf gesprengt hat. Ab Montag heist es Motor zerlegen. Das sind wenigstens reale Probleme mit echter Hardware :-) Gruss, Christian
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.