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.
Angehängte Dateien:
-
rfid_overview.png
91 KB -
tx_details.png
97 KB
:
Bearbeitet durch User
Worauf läuft Dein Programm? Gibts das Manual auch in etwas sinnvollerem als *.doc?
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Lt. Fotos sendest du mit 9,6k lt. Doku versucht der Reader 57,6k ... vielleicht gibt das Missverständnisse??
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?
:
Bearbeitet durch User
... 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!
:
Bearbeitet durch User
Misst du mit dem Logic analyzer am ein oder Ausgang des Solid State Relais?
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.
:
Bearbeitet durch User
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?
.... vielleicht vorher zum testen tx/rx beim Ansprechen über den internen usb-wandler messen
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?
Zeichne einen Schaltplan vom Aufbau und messen an den Signal-Leitungen die Ruhespannung. Schreibe sie an die Leitungen im Schaltplan.
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
Der Befehl
1 | 8.3.10 Get Reader Serial number |
wäre eine Kommunikation, für die kein Transponder benötigt wird. Kommt da ein sinnvolles Ergebnis zurück?
Danke erst einmal fuer eure Antworten. Ich schaue mir das demnachst mal an. Ich denke aber ich weiss schon was ich total falsch gemacht habe. :)
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
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.