Re: Interruptroutine Capture Compare Kategorie: Programmierung C (von PeterS - 22.08.2009 12:04) | ||
Als Antwort auf Re: Interruptroutine Capture Compare von Josef - 21.08.2009 10:23 | ||
| ||
> > > > > hallo > > > > > das problem besteht darin, dass die interruptroutine keine abfrage (if, switch usw.) > > > > > oder einen Unterprogrammaufruf verträgt. > > > > > > > > Hi, das mag Dir so erscheinen ist aber nicht so. If's etc. funktionieren In IRQ Routinen, sonst > > > > würde die ganze DCF Library nicht funkionieren. > > > > > > > > > sobald ich in die unten angeführte interruptroutine ein if einbaue verabschiedet sich der prozessor. > > > > > > > > > > void Timer3_ISR(void) > > > > > { > > > > > x[a]=Timer_T3GetPM(); > > > > > Irq_GetCount(INT_TIM3CAPT); // Interrupt zurücksetzen > > > > > } > > > > > > > > > > will man nun ein signal mit unterschiedlichen Pulslängen messen, funktioniert das nur > > > > > wenn man im hauptprogamm ein while (x[a]==0; einbaut und anschlie�end die Messung > > > > > wieder startet (Bemerkung: ist aber nicht sinn eines interrupts, wenn man wartet bis der interrupt > > > > > abgearbeitet ist) > > > > > > > > Man sollte immer! im Interrupt nur das nötigste erledigen, und den Rest im normalen Programm > > > > verarbeiten. Dabei erlaubt der Interpreter seinen IRQ Routinen viel mehr, als eine wirkliche > > > > CPU durchgehen liesse. > > > > > > > > Gruss Peter > > > > > > > > > oder man lässt den code durchrasseln und macht immer wieder eine abfrage -> dann übersieht man > > > > > irgendwann einen puls, wenn der codedurchlauf zu lange wird. > > > > > gibts hier eine lösung? > > > > > > > > > > gru� > > > > > josef > > > > > > :-( -> schwache antwort > > > > Nein, denn das ist eine Verhaltensregel, und keine Erklärung von Fehlern. Eine laufende Interrupt- > > routine blockiert das Multithreading und andere Interrupts. Deshalb ist es normalerweise unklug, > > zuviel in einer IRQ Routine zu erledigen. > > > > > ich glaube nicht, wenn man eine if x[a]>0 m++; Abfrage in die interruptroutine einbaut, das eine lange ist. > > > beim 10msec interrupt -> DCF 77 programm werden auch unterprogrogramme in der interruptroutine > > > ausgeführt und es funktioniert. > > > warum genau beim timer 3 nicht? > > > > Ich kann Dir versichern, das es keinen Unterschied in der Abarbeitung von 10msec IRQs oder Timer3 > > IRQs gibt. Ich mu� es eigentlich wissen, denn ich habe es implementiert. Es gibt aber wie oft, > > auch andere Faktoren. Wie lang sind eigentlich die Impulse, die Du messen willst? Wäre es möglich, > > das Deine Programmlogik durcheinanderkommt, wenn die Impulse kürzer sind, als die Abarbeitung > > der IRQ Routine? Da ich Dein Hauptprogramm nicht kenne, ist das natürlich nur eine von mehreren > > möglichen Hypothesen. > > > > Gruss Peter > > > > > gru� josef > > hallo Peter > > habe aufgrund deiner ausführungen ein setup durchgeführt und siehe da alles das wie oben beschrieben > funktioniert. der UTI Baustein auch 3Stück mit je 3 PT1000 werden einwandfrei abgearbeitet. > > danke für deine Hilfe > gru� josef > wenn es erwünscht ist könnte ich das Projekt als Beispiel zur verfügug stellen. > > noch zwei fragen > wird es bei der definition von der seriellen in zukunft auch 9 Datenbits zu definieren geben? Nein, das ist ziemlich exotisch und arbeitet auch nicht mit dem Modell der seriellen IRQ Buffer zusammen. Du kannst aber über DirAcc_Write() das UCSRB Register schreiben, und dort den 9-Bit Mode setzen. Für den Fall wo das 9. Bit immer Null ist, wie Du es wahrscheinlich brauchst, sollte das gehen. > und kann man die Ports, die auf ausgang geschaltet sind abfragen auf deren zustand? Du schreibst doch selbst die Werte auf die Ports, merk Dir doch in einer byte Variable den Zustand. Gruss Peter | ||
Antwort schreiben Antworten: ![]() |
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum