Hallo Zusammen
Ich verwende den CN7 (RB5) als Interrupteingang. Von einem externen UART
erhalte ich Low wenn Daten im FIFO sind und High wenn dieser leer ist,
der Interrupt. ist ok.
Nun habe ich das Problem, daß das Auslesen aus dem Fifo nicht
funktioniert
weil ich eine Schleife dafür verwende und den Eingang RB5 auf Low
kontrolliere wenn dieser High ist wird die Auslesung abgebrochen.
Beim durchsteppen im Debugger funktionierts, aber in Echtzeit nicht.
Hier wird der RB5 als High eingelesen obwohl er Low ist und dadurch nur
ein Zeichen einliest und dann die Schleife verläßt. Was mache ich
falsch?
Das ist meine Schleife.
**********************
do
{
vPbInPufWr(vUartRegReadFifo(0));
if(PORTBbits.RB5){
ucBit=1;
}
}
while(ucBit==0); //Empfangs-FIFO leer?
*****************************
Bitte. Danke.
Lg.
Johann K.
Hi, nur auf die Schnelle: ISt der PORTB denn auch richtig auf digitalen Eingang konfiguriert und ganz sicher nicht irgendeine Zweitfunktion aktiviert? ICh habe aktuell den 32mx795 nicht komplett von der Beschaltung im Kopf da ich mich seit zwei Wochen mit einem STM ARM rumschlagen muss. Müsste erst nachsehen. Bei den 8Bittern liegt aber auf PortB beispielsweise oft der AD Wandler und der ist da dann auch noch nach Reset aktiv. Liest man bei aktivierten AD Wandler dann einen PORTB Pin aus erhält man immer HIGH! Prüfe mal das DB, ich komme gerade nicht dazu, bin gerade auf dem Sprung. Eventuell liegt da ja schon das Problem. Gruß Carsten
Was passiert, wenn zwischen dem Auslesen des Fifos und dem Einlesen RB5 eine Verzögerung eingefügt wird?
Hallo Dieser Pin hat auch eine AD Funktion aber seit ich folgende Zeile eingefügt habe AD1PCFGbits.PCFG5 = 1; funktioniert der interrupt ohne Probleme. Kann es sein wenn man den Pin als CNx verwendet das man ihn nicht mehr als RBx auslesen kann? Wenn ich im Debugger durchsteppe F7 wird der Eingang richtig erkannt und die Schleife liest den Fifo aus bis er leer ist und dann ändert der Eingang auch sein Potential, aber in Echtzeit ..mmmm. Schöne Scheiße. Ich werd noch rumspielen vielleicht stoß ich noch auf etwas. Lg. Johann K.
Hallo Zusammen Vergesst das Problem ich habe gerade gemerkt es ist kein Problem des Eingangs und zwar geht's mit einer For-Schleife mit definierten 10 Durchläufen auch nicht. Muss was mit der SPI Abfrage UART PIC was zutun haben. Lg. Johann K.
Hallo Bitte haltet mich nicht für blöd, es hat doch mit dem Eingang RB5 (CN7) zu tun, mit der For-Schleife funktioniert es doch, ich habe nur im falschen Array geschaut, in das die Daten nach der Auslesung geschrieben werden. Ich habe nun die Anregung einer Verzögerung vom Roland versucht und siehe da es funktioniert. Ich bin zwar von einer Verzögerung nicht begeistert und ich kanns auch nicht verstehen, denn beim Einsprung in die Serviceroutine des Interrupts wird erkannt das der Eingang Low ist und nun sind z.B acht Byte im Fifo des Uart die über die SPI ausgelesen werden und bis zum letzten Zeichen ändert sich das Signal am Eingang RB5 nicht und warum erkennt der PIC den Eingang plötzlich als High obwohl noch immer Low. Lg. Johann K.
Klatec schrieb: > Ich habe nun die Anregung einer Verzögerung vom Roland versucht und > siehe da es funktioniert. Ich bin zwar von einer Verzögerung nicht > begeistert und ich kanns auch nicht verstehen Es ist doch ein externer UART. Welche Timings hat dieser zu bieten, sprich, in welcher Zeit schaltet er den Pin von Low auf High, nachdem er merkt, dass sein FIFO leer ist? Unabhängig davon: Dass der gleiche Pin den Interrupt triggert und zugleich in dieser ISR abgefragt wird ... was passiert, wenn während der ISR-Abarbeitung wieder Zeichen in den FIFO geschrieben werden? Wie wäre es mit - in main() Schlafen legen - der Interrupt verlässt nur den Schlafmodus - im normalen Programm danach solange den FIFO auslesen, bis dieser leer ist Irgendwie ist das alles etwas durcheinander. Was passiert in vUartRegReadFifo()? Wird da per SPI in der ISR der FIFO des externen UARTs ausgelesen? Wenn dem so ist, dann würde ich das aus der ISR ins normale Programm verlegen.
Hallo Roland Die Schnittstelle bedient einen Peripherie-Bus zwischen der MCU und den Ein- und Ausgabebaugruppen, dieser wird im Master/Slave-Verkehr geführt. Es ist so das im ext. Uart vom Master acht Byte stehen und es werden keine mehr vom Slave geschickt bis der Master ein ACK gesandt hat. Ich habe die Auswirkung des Problems schlecht beschrieben. Der Interrupt erfolgt bei High auf Low, und es gibt acht Byte lang keine Änderung an diesem Eingang. Die oben angeführte Schleife wird jedoch nur einmal durchlaufen weil der Eingang als High erkannt wird obwohl er Low ist und daher die Zeit in der der Pegel sich ändert nicht relevant ist weil noch 7 Byte lang noch kein Thema ist. Ablauf: Der ext. Uart empfängt Daten und durch einen Level wird nach 8 Byte ein Interrupt (CN7) ausgeführt. In der _ISRxxx springe ich in eine Routine die eine Abfrage an den Uart macht und feststellt was den Interrupt ausgelöst hat und dann springe ich in die Routine die den Fifo ausliest. Aber das ist eine gute Idee, ich werde einfach eine Variable setzen die nach dem Aussprung aus der _ISRxxx die nachträgliche Abarbeitung der nachfolgenden Routinen durchführt. Eigentlich hätte mir dies selbst einfallen können, denn bei den Ein- und Ausgabebaugruppen die ich mit einem PIC18 realisiert habe mache ich dies bei einigen INT auch so. Danke. Lg. Johann K.
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.