Hi,
ich bin dabei einen Treiber fuer einen RFID in C zu implementieren.
Soweit so gut. Ich habe es nach der Spezifikation implementiert,
zumindest dachte ich das. Ich habe vom Hersteller die command txt
bekommen und das erste Beispiel mal so zu UART geschrieben. Mit einem
logic Analyzer habe ich alles gecaptured. Ich sehe bei meinen bytes erst
einmal kein Problem. Aber merkwuerdigerweise antwortet der RFID Reader
einfach mit einem langen LOW. Ich verstehe nicht warum. Kann mir
vielleicht wer weiter helfen? Der Hersteller war leider bisher auch
keine grosse Hilfe.
Rufus Τ. F. schrieb:> Worauf läuft Dein Programm?
Auf dem STM32F1. Die lib laeuft innerhalb von RIOT OS. Die Doku zum UART
von RIOT ist hier:
http://riot-os.org/api/group__drivers__periph__uart.html
Die nutzen auch 8N1, also das sollte demnach kein Problem sein.
> Gibts das Manual auch in etwas sinnvollerem als *.doc?
Leider nein... Kann es dir gerne in ein PDF umwandeln.
/e: Habs mal in ein PDF umgewandelt.
Bei solchen Problemen sollte man die Fehlerquellen reduzieren.
Hast Du schon mal Deinen RFID-Leser an der seriellen Schnittstelle eines
PCs (natürlich mit den passenden Pegelwandlern) angeschlossen?
Da könntest Du mit einem simplen Terminalprogramm oder einem
Schnittstellentestprogramm à la "Hterm" mit dem Ding kommunizieren.
Hast Du schon mal irgendeine andere UART-Anwendung mit Deinem STM32 zum
Laufen gebracht, so daß Du sicher sein kannst, daß Du da alles richtig
machst?
Du könntest auch hier mit geeigneten Pegelwandlern mit einem PC
kommunizieren.
Damit kannst Du beide Seiten der Kommunikation mit einer Gegenstelle
austesten, von der Du mit gewisser Sicherheit annehmen kannst, daß sie
funktioniert.
Rufus Τ. F. schrieb:> Bei solchen Problemen sollte man die Fehlerquellen reduzieren.>> Hast Du schon mal Deinen RFID-Leser an der seriellen Schnittstelle eines> PCs (natürlich mit den passenden Pegelwandlern) angeschlossen?>
Ja, mit der seriellen console von platformio. Hat nicht so gut
funktioniert.
>> Da könntest Du mit einem simplen Terminalprogramm oder einem> Schnittstellentestprogramm à la "Hterm" mit dem Ding kommunizieren.>
Hterm muss ich mir mal anschauen.
>> Hast Du schon mal irgendeine andere UART-Anwendung mit Deinem STM32 zum> Laufen gebracht, so daß Du sicher sein kannst, daß Du da alles richtig> machst?>
Jupp. Hab hier Lora Module liegen die ich in RIOT OS mit UART
angesteuert habe. Ich habe ja auch Screenshots vom logic Analyzer
gemacht. Da sieht man ja, was ueber die Leitung geht.
Hab auch RX und TX vertauscht, um zu schauen, ob ich da nichts
durcheinander gebracht habe. Aber da kommt gar nichts zurueck. Der RFID
Reader bleibt einfach die ganze Zeit auf HIGH. Er antwortet ja mit einem
bit und bleibt dann haengen.
Dirk schrieb:> Lt. Fotos sendest du mit 9,6k lt. Doku versucht der Reader 57,6k ...> vielleicht gibt das Missverständnisse??
Achso schuldige, ganz vergessen. Ja, man kann die baudrate mit einem
Tool auf dem PC aendern. Habe ich getan. Danach konnte ich mich, mit dem
USB Tool, auch nur noch mit 9.6k mit dem Reader verbinden. Also an der
baudrate liegt es nicht.
Ich habe allerdings daran gedacht, ob das was mit active low oder high
zu tun hat. Also ob man das umdrehen muss. Aber das waere ja nicht mehr
8N1 standard, oder?
... was ist denn das für ein RFID? Zieht das die Stromversorgungspower
aus dem Funkfeld? Muss sich das Teil erst wieder aufladen? ... und und
und ...
Hallo Philipp B.,
hast Du die Details schon erläutert?
Gruß
Bernd
Bernd B. schrieb:> ... was ist denn das für ein RFID? Zieht das die Stromversorgungspower> aus dem Funkfeld? Muss sich das Teil erst wieder aufladen? ... und und> und ...>> Hallo Philipp B.,>> hast Du die Details schon erläutert?>> Gruß>> Bernd
Also: Ist ein Reader, mit dem man passive Tags lesen kann. Das
Datenblatt gibt es hier:
http://www.chafon.com/productdetails.aspx?pid=535
Der Reader ist an ein 9V Netzteil angeschlossen. Ich steuere das an aus
ueber ein Solid State Relay und habe das auch im logic analyzer mit
drin. Also wann ich es aus und an geschaltet habe.
Ist aber das erste mal, dass ich mit RFID arbeite. Daher: Bitte fragen
stellen, wenn was unklar ist. :) Ich moechte das Problem ja loesen.
Danke euch schon einmal fuer die Hilfe!
Philipp B. schrieb:> Also: Ist ein Reader, mit dem man passive Tags lesen kann.
... ich könnte mir vorstellen, dass sich die Tags erst wieder aufladen
müssen, bevor sie antworten. Oder wartest Du auf Antwort, die nicht aus
dem Tag kommt?
Gruß
Bernd
Philipp B. schrieb:> Der Reader ist an ein 9V Netzteil angeschlossen. Ich steuere das an aus> ueber ein Solid State Relay und habe das auch im logic analyzer mit> drin. Also wann ich es aus und an geschaltet habe.
Und der Sinn des Ganzen ist ?
Ich würde erstmal Netzteil eingeschaltet lassen und erst nach 1 sec
oder so anfangen zu senden.
So wie ich das sehe, fangen beide zur gleichen Zeit an und die ersten
3 bit sind gleich - schon mal überlegt warum ?
Marc V. schrieb:> Philipp B. schrieb:>> Der Reader ist an ein 9V Netzteil angeschlossen. Ich steuere das an aus>> ueber ein Solid State Relay und habe das auch im logic analyzer mit>> drin. Also wann ich es aus und an geschaltet habe.>> Und der Sinn des Ganzen ist ?>> Ich würde erstmal Netzteil eingeschaltet lassen und erst nach 1 sec> oder so anfangen zu senden.>> So wie ich das sehe, fangen beide zur gleichen Zeit an und die ersten> 3 bit sind gleich - schon mal überlegt warum ?
Ich habe den Reader 50ms vorher an gemacht. Ich kann auch eine Sekunde
warten. Nein, habe ich nicht verstanden, warum er direkt antwortet,
obwohl meine bytes noch gar nicht durch sind. Bin wahrscheinlich auch zu
unerfahren um da eine Idee zu haben.
Philipp B. schrieb:> Achso schuldige, ganz vergessen. Ja, man kann die baudrate mit einem> Tool auf dem PC aendern. Habe ich getan. Danach konnte ich mich, mit dem> USB Tool, auch nur noch mit 9.6k mit dem Reader verbinden. Also an der> baudrate liegt es nicht.
Wie hast du die Baudrate geändert ?
Marc V. schrieb:> Philipp B. schrieb:>> Achso schuldige, ganz vergessen. Ja, man kann die baudrate mit einem>> Tool auf dem PC aendern. Habe ich getan. Danach konnte ich mich, mit dem>> USB Tool, auch nur noch mit 9.6k mit dem Reader verbinden. Also an der>> baudrate liegt es nicht.>> Wie hast du die Baudrate geändert ?
Der Reader hat einen internen USB to UART controller. Also USB an den
Windows PC und uebere diese Delphi Anwendung die baudrate gaendert.
Nachdem ich diese Probleme mit meinem STM32 und UART hatte, habe ich
auch nochmal gecheckt, ob ich ueber USB und das Tool noch tags lesen
kann. Funktioniert noch. Ich habe auch schon ueberlegt das Ding
aufzuschrauben, dort den logic analyzer dran zu machen und zu schauen
wie das tatsaechlich arbeitet.
Philipp B. schrieb:> Der Reader hat einen internen USB to UART controller. Also USB an den> Windows PC und uebere diese Delphi Anwendung die baudrate gaendert.
Und was hat dir Rufus vorgeschlagen ?
Rufus Τ. F. schrieb:> Hast Du schon mal Deinen RFID-Leser an der seriellen Schnittstelle eines> PCs (natürlich mit den passenden Pegelwandlern) angeschlossen?>> Da könntest Du mit einem simplen Terminalprogramm oder einem> Schnittstellentestprogramm à la "Hterm" mit dem Ding kommunizieren.
Mach dich mit HTerm bekannt, es ist relativ einfach und sende
selbst die entsprechenden Bytes.
Wenn es klappt, kannst du es mit deinem Programm versuchen.
Philipp B. schrieb:> Ich habe auch schon ueberlegt das Ding> aufzuschrauben, dort den logic analyzer dran zu machen und zu schauen> wie das tatsaechlich arbeitet.
... und ob die mit tx/rx beschrifteten Anschlüsse wirklich entsprechend
verbunden sind (falls überhaupt ersichtlich) irgendwie liest es sich
mittlerweile so als wenn rx einen Taster(???) erwartet und tx evtl. ein
'enable'-Anschluss für ??? (Verstärker'/Signallampe/.....) ist (ganz
passt das auch nicht aber rs232 das nicht antwortet sondern die ersten
beiden Flanken als 'Echo' ausgibt und danach x??? ms low bleibt....)
Das Manual sagt:
> The reader communicates with host (MCU，MPU，Controller) using serial> communication interface RS232/ RS485 or TCPIP
Du sagst:
> Der Reader hat einen internen USB to UART controller. Also USB an den> Windows PC und uebere diese Delphi Anwendung die baudrate gaendert.
Also wie genau hängt da jetzt der Controller dran?
Am RS232? Einfach dran gehängt, oder mit entsprechendem Adapter? Und wie
ist das vom "internen USB to UART controller" entkoppelt?
Stefan E. schrieb:> Das Manual sagt:>> The reader communicates with host (MCU，MPU，Controller) using serial>> communication interface RS232/ RS485 or TCPIP>> Du sagst:>> Der Reader hat einen internen USB to UART controller. Also USB an den>> Windows PC und uebere diese Delphi Anwendung die baudrate gaendert.>> Also wie genau hängt da jetzt der Controller dran?> Am RS232? Einfach dran gehängt, oder mit entsprechendem Adapter? Und wie> ist das vom "internen USB to UART controller" entkoppelt?
Mein Controller, also der STM32F1, haengt direkt an RS232. Ich habe das
Geraet noch nicht aufgeschraubt. Ich denke aber nicht, dass das
entkoppelt sein wird. Mhmm, interessante Frage. Wenn das der Fall ist,
koennte ich ja direkt am RS232 schauen was da so gesendet wird, wenn ich
das per USB dran habe.
Philipp B. schrieb:> Ich habe allerdings daran gedacht, ob das was mit active low oder high> zu tun hat. Also ob man das umdrehen muss. Aber das waere ja nicht mehr> 8N1 standard, oder?
Standard ist, dass ein RS232-Wandler die Pegel gegenüber dem UART
invertiert.
Mit den Schnittstellen scheint es bei dir noch munter durcheinander zu
gehen. Im Manual zum Reader ist angegeben RS232/RS485, du sprichst von
"internen USB to UART controller" im Reader, was dann gegenüber RS232
invertiert wäre und sagst "STM32F1, haengt direkt an RS232". Was meinst
du mit der letzten Aussage? Ist da nun ein UART-RS232 Wandler drin oder
hast du den UART direkt an die RS232-Leitung gehängt?
Das, was du da vom RFID Leser empfängst kann unmöglich eine Antwort auf
dein Kommando sein, weil es zu früh kommt und ausserdem kein gültiges
Paket-Format hat.
Da erste Byte gibt nämlich die Größe Paketes (abzüglich 1) an. Bei Dir
hat es den Wert 1. Also müsste noch ein Byte folgen, was aber nicht der
Fall ist.
Die Baudrate scheint zu passen.
Nach dem Einschalten der Stromversorgung wartest du vermutlich nicht
lange genug. Warte mal 10 Sekunden oder schalte die Stromversorgung gar
nicht aus.
Stefanus F. schrieb:> Die Baudrate scheint zu passen.
Nö, bislang gibt es keinerlei Hinweise darauf, dass der Reader etwas
'verstanden' oder eine eigene Antwort auf tx gesendet hätte. Die
Baudrate passt vermutlich wg. der Einstellung trotzdem, aber bislang
gibt es messtechnisch keinerlei Schein dafür ;-)
Philipp B. schrieb:> Mein Controller, also der STM32F1, haengt direkt an RS232.
Das ist bislang nur eine Theorie:
das Gerät hat 4 potentielle Datenleitungen + DIP-Schalter
1
-3 TXD RS-232 serial data output (keinerlei Reaktion)
2
-4 RXD RS-232 serial data input (Reaktion: übersprechen auf 3 mit ? ms low)
3
-6 GPIO1 GPIO1 or Wiegand Data 0 (nicht getestet)
4
-7 GPIO2 GPIO2 or Wiegand Data 1 (nicht getestet)
zumindest einmal alle 4 Leitungen mit einem Datenpaket durchprobieren
(auch mit unterschiedlichen DIP-Positionen) und alle 4 messen.
NB.:der USB-UART dürfte reine Software sein und keinen prüfbaren
Anschluss haben
Philipp B. schrieb:> Danke erst einmal fuer eure Antworten. Ich schaue mir das> demnachst mal> an.
Wenn du die Kraft gehabt hättest DIP-Schalter zu betätigen, dann
müsstest du jetzt nicht dein Treiber-Projekt auf unbestimmtes sog.
"demnächst" verschieben.
> Ich denke aber ich weiss schon was ich total falsch gemacht habe. :)
Sicherlich hast du Angst vor der Konkurrenz und willst keine
Informationen preisgeben die evtl. auch der Konkurrenz helfen könnten,
aber im Nachhinein ist klar, dass nur eine RS232-Schnittstelle zur
Zeit aktiv sein kann, da ansonsten mixed 'Commandos' aus beiden und
ähnliche Effekte passieren könnten. DIP-Schalter für den TTL-Rs232 wären
bei möglichem Dual-Betrieb auch sinnlos, da ein Nichtanschluss
äquivalent wäre.
Anschluss an eine nicht aktive Schnittstelle/vergessen von Vcc/ ... und
ähnliche Klassiker sind einfach nur etwas falsch. "total falsch" wäre es
wegen solcher Fehler(chen) in den Verdrängungsmodus zu springen und die
Korrektur auf irgendwann demnächst zu verschieben. Gut dass bei dir wohl
nur einfache Missgunst gegenüber der Konkurrenz zur
Geheimhaltung/Verdrängung geführt hat.
NB.: das undokumentierte Feature bei Belegung durch den USB-Rs232 ein
Break am TTL-Rs232 zu senden, falls dort ein Signal detektiert wird,
könnte ein guter Treiber mit entsprechender Meldung "please disable
other Rs233 Interfaces" behandeln.
Dirk B. schrieb:> Philipp B. schrieb:>> Danke erst einmal fuer eure Antworten. Ich schaue mir das>> demnachst mal>> an.> Wenn du die Kraft gehabt hättest DIP-Schalter zu betätigen, dann> müsstest du jetzt nicht dein Treiber-Projekt auf unbestimmtes sog.> "demnächst" verschieben.
Der DIP Schalter war gesetzt und ist bestimmt auch gar nicht das Thema
:)
>>> Ich denke aber ich weiss schon was ich total falsch gemacht habe. :)> Sicherlich hast du Angst vor der Konkurrenz und willst keine> Informationen preisgeben die evtl. auch der Konkurrenz helfen könnten,> aber im Nachhinein ist klar, dass nur eine RS232-Schnittstelle zur> Zeit aktiv sein kann, da ansonsten mixed 'Commandos' aus beiden und> ähnliche Effekte passieren könnten. DIP-Schalter für den TTL-Rs232 wären> bei möglichem Dual-Betrieb auch sinnlos, da ein Nichtanschluss> äquivalent wäre.
Das ist nicht der Grund. Die Motivation war vielmehr, dass es mir
einfach peinlich ist, es nicht besser gewusst zu haben. Das ist einfach
so ein richtiger Noob-Fehler. Ich hatte nach RFID UART module gesucht.
Gefunden und bekommen habe ich ein RS232 RFID Reader. Was mir nicht klar
war, dass UART nicht RS232 ist und das es nicht reicht 5v/3.3v fuer HIGH
und 0v fuer LOW zu modulieren.
Dirk B. schrieb:> NB.: das undokumentierte Feature bei Belegung durch den USB-Rs232 ein> Break am TTL-Rs232 zu senden, falls dort ein Signal detektiert wird,> könnte ein guter Treiber mit entsprechender Meldung "please disable> other Rs233 Interfaces" behandeln.
Guter Punkt. Danke fuer den Tipp :)
Philipp B. schrieb:> Der DIP Schalter war gesetzt und ist bestimmt auch gar nicht das Thema> :)
hätte aber u.U. vom Fehlerbild passen können (zumindest theoretisch) und
manchmal übersieht man wirklich die allereinfachsten Punkte. Vergessener
Vcc kann ganz witzig sein: sporadische Abstürze --> zum testen eine
Kontroll-Led angeschlossen --> der µC hing sich sicher mit Einschalten
der LED auf, aber da der µC eigentlich grob funktionierte ist so ein
trivialer Fehler tw. schwer auffindbar.
Die Reaktion die keine Antwort sein konnte hat mich etwas daran erinnert
;-
>Die Motivation war vielmehr, dass es mir
einfach peinlich ist, es nicht besser gewusst zu haben.
Meine (interne)Spekulation, dass dir der vergessene Schalter peinlich
wäre ging schon in die Richtung. Die Formulierte war eigentlich eher die
Aussage dass Rätsel ohne Auflösung (wenn diese bekannt ist) etwas
unhöflich sind (u.U. etwas schwer herauszulesen)
"Rs232" wird so häufig als Synonym für UART benutzt, dass wenn kein
(i.A.9-pol) Rs232 Norm-Stecker für 'echtes' Rs232 spricht der Verdacht
auf TTL-Rs232 mMn nicht ganz fern liegt.
Wen peinlich dann eher das überlesen der Frage von Rufus (und wohl noch
jemanden) nach Pegelwandlern.
Der Automodus des Logikanalyzers ohne Anzeige im ersten Bild
rx-idle(1):-3..-15V tx-idle(1):+3..+5V dürfte auch nicht ganz optimal
für den Fall gewesen sein.
Break könnte trotzdem hinkommen, aber als Reaktion auf ... hmm...häufige
ungewöhnliche Pegel(?) Vor der Berücksichtigung lieber noch mal
überprüfen auf was das Gerät eigentlich reagiert hat.
Aus Neugier: was passiert wenn die Schnittstelle deaktiviert ist
(DIP-Schalter)?
Nachtrag: nach der neuen Lage hast du im ersten Versuch ein Dauerbreak
gesendet, dass durch die Nachricht kurz unterbrochen wurde und mit ??? +
break beantwortet wurde, hmm
rfid_overview.png
(91 KB)
tx_details.png
(97 KB)
