Forum: Mikrocontroller und Digitale Elektronik RS232 blockiert Main Programm?


von Dennis (Gast)


Lesenswert?

Habe eine Problem:

Und zwar habe ich den Programmcode von ( 
http://www.projektsammlung.de/projekte/rfid-reader-modul/ ) übernommen 
zu einem RFID Chip (U2270b) der mir meine Transponder ID wunderschön auf 
meinem Display anzeigt. Funktioniert Super. Auch in meine RS232 ISR 
Routine komme ich.

Sobald ich jetzt aber an meiner DSub Stecker auf meinem Board ein 
Modemkabel anschließe (mit einem USB/RS232 Adapter) funktioniert meine 
Funktion nicht mehr. Es lässt sich dann keine Transponder ID mehr auf 
dem Display anzeigen. Es bleibt einfach funktionslos.

Wenn ich das Kabel wieder rausziehe funktioniert alles wieder.

Dann habe ich ein kleines Testprogramm geschrieben um meine RS232 
Verbindung zu testen (buchstabe an PC senden) ... funktioniert.

Löst in meinem Programm ein Interrupt aus sobald ich ein RS232 Kabel 
anschließe? An was könnte das liegen?

Mein µC ist der Atmega32.

Grüße

von Wegstaben V. (wegstabenverbuchsler)


Lesenswert?

Dennis schrieb:
> An was könnte das liegen?

mit Schaltplan bzw. Foto vom Versuchaufbau  könnte man eine vorsichtige 
Analyse wagen ...

von Thorsten R. (jonas93)


Lesenswert?

http://up.picr.de/20738360yh.jpg

hier der gewünschte schaltplan :)

von Pepe (Gast)


Lesenswert?

Läuft der Prozessor nach dem Anstecken noch ?
Falls nicht, vielleicht einfach RX & TX vertauscht ? Stecker bzw. Buchse 
verwechselt ? ( Es gibt  RS232 Kabel, die parallele Datenleitungen haben 
und welche die überkreuzte Leitungen haben. )

von Thorsten R. (jonas93)


Lesenswert?

Rx und Tx kann nicht vertauscht sein .. da ich mal ein Beispielprogramm 
geschrieben hab das mir schön ordentlich die Zeichen an den PC sendet...



Prozessor läuft noch.

: Bearbeitet durch User
von spess53 (Gast)


Lesenswert?

Hi

>Rx und Tx kann nicht vertauscht sein .. da ich mal ein Beispielprogramm
>geschrieben hab das mir schön ordentlich die Zeichen an den PC sendet...

Passiert das im auch im ausgeschalteten Zustand? RS232 ist nicht 
unbedingt hotplagfähig.

MfG Spess

von Thorsten R. (jonas93)


Lesenswert?

spess53 schrieb:
> Hi
>
>>Rx und Tx kann nicht vertauscht sein .. da ich mal ein Beispielprogramm
>>geschrieben hab das mir schön ordentlich die Zeichen an den PC sendet...
>
> Passiert das im auch im ausgeschalteten Zustand? RS232 ist nicht
> unbedingt hotplagfähig.
>
> MfG Spess

werde ich gleich morgen mittag probieren.. ob das echt daran liegt. *.*

von Thorsten R. (jonas93)


Lesenswert?

geht immernoch nicht... sobald ich ein rs232 kabel an mein board 
anschließe kann ich kein rfid transponder mehr einscannen

***UPDATE***
Sobald ich den USB / RS232 Converter von CSL an mein RS232 kabel 
anschließ geht es nicht mehr... liegt es jetzt am Converter?


Sobald ich aber ein einfaches Programm (Zeichen zum PC sende) auf mein 
Atmega spiele geht des... aber mein Hauptprogramm mit RFID scannen geht 
nicht...

whats the fuck

bitte um hilfe ich verzweifle jetzt bald

: Bearbeitet durch User
von Thorsten R. (jonas93)


Lesenswert?

genauer gesagt sobald TX und GND mit dem USB Converter RX und GND 
verbunden ist geht nix mehr :(((((((((

von Karl H. (kbuchegg)


Lesenswert?

Dennis schrieb:
> Habe eine Problem:
>
> Und zwar habe ich den Programmcode von (
> http://www.projektsammlung.de/projekte/rfid-reader-modul/ ) übernommen

was genau muss man sich unter übernommen vorstellen?

So wie ich das sehe, gibt es in den Routinen für den Mega8 (mindestens) 
einen Fehler
1
...
2
    UCSRB   = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN);                      // UART TX und RX einschalten und RX Interrupt aktivieren

schön.
Da wird also der Receive Complete Interrupt freigegeben.
Aber ich kann in keinem C File aus dem downgeloadetem Zip-File eine ISR 
dafür finden.

: Bearbeitet durch User
von Thorsten R. (jonas93)


Lesenswert?

Ich hab zwar einen Mega32 aber soviel anders ist da ja nicht..:
hier ist die ISR Routine die steht in der RFID-Reader-Modul.c
1
ISR(USART_UDRE_vect)
2
{
3
    uint8_t temp_sreg_TX;
4
5
    temp_sreg_TX = SREG;                                                // Status-Register sichern
6
7
    UDR=TXQueueBuffer [pOutQueueTX];                                    // Sendet Zeichen
8
9
    if(pOutQueueTX == QBLength_TX-1)
10
       pOutQueueTX = 0;
11
    else
12
       pOutQueueTX++;
13
14
15
    if(pOutQueueTX == pInQueueTX)
16
    {
17
       UCSRB   &= ~(1<<UDRIE);                                          // UART TX Interrupt für leeres Sendedatenretister ausschalten
18
    }
19
20
    SREG = temp_sreg_TX;                                                // Status-Register rückschreiben
21
22
    return;
23
}

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Thorsten R. schrieb:
> hier ist die ISR Routine die steht in der RFID-Reader-Modul.c
>
>
1
> ISR(USART_UDRE_vect)
2
> {
3
>

Diese ISR ist aber fürs Senden. Oben wird eine ISR per RXCIE aktiviert, 
die fürs Empfangen zuständig ist. Die fehlt offenbat bei Dir. Folge: µC 
schmiert ab, sobald ein Zeichen reinkommt.

von oszi40 (Gast)


Lesenswert?

> Sobald ...
Versuch doch mal eine Prüf-Schleife als Gegenprobe RX-TX WENN das ohne 
Störung geht, vermutet meine Glaskugel, dass der Converter stört oder 
ein Masseproblem evtl. besteht od. der Empfang irgendwie per Funk 
gestört wird. dann wäre zu prüfen ob eine Ortsveränderung Besserung 
bringt.
Nullmodemkabel? Beitrag "Welche Nulmodem-Kabel-Sorten gibt es?"

von Karl H. (kbuchegg)


Lesenswert?

Frank M. schrieb:

> Diese ISR ist aber fürs Senden. Oben wird eine ISR per RXCIE aktiviert,
> die fürs Empfangen zuständig ist. Die fehlt offenbat bei Dir. Folge: µC
> schmiert ab, sobald ein Zeichen reinkommt.

Oder zumindest wenn die UART 'denkt' das da was reinkommt.
Was beim Anstecken von einem Kabel durchaus schon mal sein kann, da da 
ja ein Eingang (der an und für sich keinen definierten Pegel hat) ein 
Pegel aufgezwungen wird, den die Auswertung als Flanke ansieht.
Selbst wenn sich daraus dann ein ungültiges Zeichen ergibt, ist das für 
die UART nichts desto trotz dein einlaufendes Zeichen. Der Receive 
Interrupt wird aufgerufen -> die ISR existiert nicht -> der µC wird 
resettet.


Alles in allem sind die UART Routinen aber wirklich nicht so prickelnd 
geschrieben, als das man die nicht ersetzen könnte.

: Bearbeitet durch User
von Karl H. (kbuchegg)


Lesenswert?

Abgesehen davon sehe ich in dem ganzen Code auch keinen wirklichen 
Grund, warum der UART Receiver überhaupt freigegeben werden sollte.

'Auf Vorrat für den Fall der Fälle' ist mir als Begründung ehrlich 
gesagt zu wenig. Man sieht immer wieder, was dabei rauskommt, wenn man 
eigentlich nicht benötigte Baugruppen freigibt bzw. deren Interrupts 
frei gibt.

: Bearbeitet durch User
von Karl H. (kbuchegg)


Lesenswert?

Ach noch was.
Du hast aber schon daran gedacht, des EEProm-Hex File auch in den Mega32 
zu brennen?

von Thorsten R. (jonas93)


Lesenswert?

also das hat denk ich definitiv nichts mit der ISR von der RS232 zu 
tun...


ich habe jetzt komplett die ISR Routinen von der RS232 auskommentiert +

das gesamte setup von der UART..
1
    // -------------------- UART --------------------
2
    // uint16_t  myUBRR;                                                    // 16-Bit breite Speichervariable für Baudratenberechnung
3
    // myUBRR  = F_CPU/(UART_BAUD_RATE*16L)-1;                             // Berechnung der Baudratenwerte für das UBRR-Register im Asynchronous Norma
4
    // UBRRH   = (uint8_t) (myUBRR>>8);                                    // Setzt Highbyte des UBRR-REgisters
5
    // UBRRL   = (uint8_t) myUBRR;                                         // Setzt Lowbyte  des UBRR-Registers
6
    // UCSRB   = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN);                      // UART TX und RX einschalten und RX Interrupt aktivieren
7
    // UCSRC   = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0);                    // Setzt die Bits für die Betriebsart Asynchron 8N1


sobald der usb / rs232 converter am kabel hängt .. geht nix mehr.

ich denke das hat was mit dem converter zu tun. hat jemand vielleicht 
noch eine idee?

vielen dank aber trotzdem für die vielen antworten und die hilfe.

von Karl H. (kbuchegg)


Lesenswert?

Thorsten R. schrieb:

> ich denke das hat was mit dem converter zu tun. hat jemand vielleicht
> noch eine idee?

trügt mich meine Erinnerung oder sagtest du nicht weiter oben, du 
hättest die UART für sich alleine getestet?
Wie hast du das denn dort gemacht, wenn nicht mit dem Konverter?

: Bearbeitet durch User
von Thorsten R. (jonas93)


Lesenswert?

das stimmt das ist richtig das stutzt mich ja auch...

aber der converter stört irgendwie meine RFID...

von W.S. (Gast)


Lesenswert?

Thorsten R. schrieb:
> ich denke das hat was mit dem converter zu tun. hat jemand vielleicht
> noch eine idee?

Na klar, ne Menge Ideen.

Aber wieso kommst du mental nicht weiter, als bloß zu vermuten, daß das 
"mit dem converter zu tun" hat?

Hast du denn keinen Oszi, um dir mal die Signale selbst anzuschauen? 
Notfalls in so einer ISR ein freies Pin mal anzusteuern, während sie 
läuft.

Hast du keine Lust, zu allererst deine seriellen I/O-Routinen SELBST 
auf Vordermann zu bringen, bis sie vernünftig ausprobiert sind und das 
tun, was man von einem robusten Hardwaretreiber erwartet?

Jaja, ich weiß, den meisten Leuten ist es schlichtweg zu viel, das 
Manual GRÜNDLICH zu lesen.

Also, schau nach, ob tatsächlich sämtliche betreffenden Interrupts (RX, 
TX, ggf. Status usw) mit Handlern versehen sind. Dann schau nach, wie 
sich diese Handler im Fehlerfalle verhalten: Pufferüberlauf, -unterlauf, 
Breaks und Formatfehler. Wenn das alles richtig behandelt wird, dann 
stürzt dein µC auch nicht ab und er blockiert auch nicht.

Ein sehr häufiger Fehler ist es, auf ein TxEmpty falsch zu reagieren, 
wenn es bereits nix mehr zu senden gibt. Schau nach, wie es bei deinem 
µC läuft, wenn diese Kondition auftritt.

W.S.

von Karl H. (kbuchegg)


Lesenswert?

Thorsten R. schrieb:
> das stimmt das ist richtig das stutzt mich ja auch...
>
> aber der converter stört irgendwie meine RFID...

Das heisst UART und Konverter funktionieren miteinander.

Nun, da du in diesem Fall eine funktionierende UART zur Verfügung hast:
Es ist nicht verboten sein Programm mit Ausgaben an die UART zu spicken 
und so den µc mitschreiben zu lassen was er wann und aus welchem Grund 
macht. Wenn der Konverter die RFID Hardware stört, dann sollte sich das 
in diesem Mitschrieb ja zeigen.

von Thorsten R. (jonas93)


Angehängte Dateien:

Lesenswert?

Karl Heinz schrieb:
> Thorsten R. schrieb:
>> das stimmt das ist richtig das stutzt mich ja auch...
>>
>> aber der converter stört irgendwie meine RFID...
>
> Das heisst UART und Konverter funktionieren miteinander.
>
> Nun, da du in diesem Fall eine funktionierende UART zur Verfügung hast:
> Es ist nicht verboten sein Programm mit Ausgaben an die UART zu spicken
> und so den µc mitschreiben zu lassen was er wann und aus welchem Grund
> macht. Wenn der Konverter die RFID Hardware stört, dann sollte sich das
> in diesem Mitschrieb ja zeigen.

Vielen Dank für die Mithilfe.

Aber ich konnte das Problem durch einen anderen Converter von einem 
Mitschüler lösen. Jetzt funktioniert es einwandfrei. Nichts desto trotz 
werde ich die ISR Routinen noch sauber umschreiben. :-)

Der Converter wo nicht ging: 
http://www.amazon.de/dp/B008FKABG0/ref=sr_ph?ie=UTF8&qid=1422196061&sr=1&keywords=csl+adapter

Funktionierender Converter:
http://www.delock.de/produkte/G_61460/merkmale.html

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.