Orientierung im Raum mit RFID

[PICture]

Hallo!

Noch fehlende Daten u.a. Leseabstand: http://www.fiscard.de/plastikkarten/...e_objectID=116 von o.g. RFID Antenne: http://www.produktinfo.conrad.com/da..._C_CONTROL.pdf .

[i_make_it]

Bitte nicht vergessen das Funkwellen im Gegensatz zu Licht auch durch Wände gehen. Im Gegensatz zu IR Baken heist " Ich empfange ein Signal" nicht zwingend "Ich bin im selben Raum".

[efb]

Hallo,

vielen Dank für die schnellen Antworten!

Was die Reichweite betrifft, wird bei den kleinen Empfangsmodulen oft von etwa 5 cm gesprochen, ich richte mich erst einmal darauf ein, das es nicht viel mehr werden kann. (auch weil der Robi bei der Fahrt ggf. den Empfang durch elektromagnetische Störungen beeinträchtigen könnte). Das hat nun den Nachteil, das er länger suchen muss, um eine Marke zu finden, aber auch den Vorteil, das die Position dann genauer ist und auch nichts durch Wände geht. Am ehesten wird der RP6 wahrscheinlich eine Marke finden, wenn er sich an Wänden fortbewegt und Transponder z.B. an der Sockelleiste befestigt sind.

Was die Hardware betrifft: stimmt ja, UART ist eine vorhandene serielle Schnittstelle. Ich glaube aber, sie eignet sich in meinem Fall nicht so gut. Über den UART gibt der RP6 bei mir schon während der Fahrt Terminal-Daten an das BT Modul aus und wird über dieses Modul auch geflasht. Ich denke, besser wäre eher eine serielle Datenübertragungs "Simulation" mit I/O Pins und einer Softwarelösung, so wie es auch bei I2C gemacht ist.

Die Frage ist halt "nur" ob es so etwas ähnliches für den RP6 schon gibt?

Viiele Grüsse

Ernst

[Peter(TOO)]

Hallo Ernst,

Was die Hardware betrifft: stimmt ja, UART ist eine vorhandene serielle Schnittstelle. Ich glaube aber, sie eignet sich in meinem Fall nicht so gut. Über den UART gibt der RP6 bei mir schon während der Fahrt Terminal-Daten an das BT Modul aus und wird über dieses Modul auch geflasht. Ich denke, besser wäre eher eine serielle Datenübertragungs "Simulation" mit I/O Pins und einer Softwarelösung, so wie es auch bei I2C gemacht ist.

Das kannst du nicht vergleichen!
I2C ist synchron, d.h. der Master erzeugt einen Clock und der Slave verändert seine Datenleitung dann mit den Flanken des Clocks. Dabei kann die CPU ach mal ein Nickerchen machen (Interrupts bedienen), wenn sich der Clock nicht ändert ist alles eingefrohren.

RS232 ist asynchron. Da wird einfach nach dem festgelegten Timing gedendet, egal ob der Empfänger gerade mithört oder nicht. Kommst du zu spät ist das Bit schon durch! Wann das Startbit kommt, weiss du auch nicht. Du musst den Pin also dauernd abfragen um das Startbit zu erkennen. Dann musst du die Mitte des Startbits finden und von dort aus alle 104µs (bei 9'600, Bit/s) abfragen. Dazu brauchst du einen Timerinterrupt und dieser darf nie durch eine andere Interruptroutine verzögert werden.

MfG Peter(TOO)

[oberallgeier]

... den Pin also dauernd abfragen um das Startbit zu erkennen ... Mitte des Startbits finden ... darf nie durch eine andere Interruptroutine verzögert ...

Klar, fast unnötig Dir beizupflichten. Aber es geht natürlich auch anders.

Mein UART läuft (eigentlich bei allen Lösungen) auf Interrupt und schreibt in einen FIFO-Ringspeicher. Dann schaue ich im Vorbeigehen nach

if ( ! ukbhit0 () ) continue;

und WENN etwas im FIFO steht wird es abgeholt

zeichen_aus_fifo = ugetchar0();

und auf einen signifikanten Telegramm-Anfang abgefragt, der aus einem, einzigen ASCII-Zeichen besteht, das aber so in den Telegrammen natürlich nicht vorkommen darf (Buchstabe/n, oft natürlich #, * oder so)

      if (zeichen_aus_fifo == KOMMANDO_APPS)   // Fahre Anwendungsprogramme
        telegrammlaenge = KOMMANDO_APPS_LEN;   //   mit und ohne Parameter

       if (zeichen_aus_fifo == KOMMANDO_DATS)   // Servo Daten von allen
         telegrammlaenge = KOMMANDO_DATS_LEN;   //   Servos anzeigen

       if (zeichen_aus_fifo == KOMMANDO_NORM)   // Servo Normposition
         telegrammlaenge = KOMMANDO_NORM_LEN;   //   anfahren

Dieses "Schlüsselzeichen" wiederum ergibt die Telegrammlänge. Die kann, z.B. im Beispiel "KOMMANDO_NORM" 1 sein und das ist das Kommandobyte alleine. Das Telegramm wird, wieder im Vorbeigehen, ausgelesen (in voller, aber eben nur für DIESES Telegramm festgelegten Länge) und ausgewertet. Dazwischen laufen mehrere andere Interrupts, die so wenig stören, dass ich im Standardfall Controller<->PC mit lesen und schreiben über UART-USB-Wandler locker 115k2 Bd schaffe, bei Controller-Controller-Kommunikation sogar die vollen Kanne mit 1,2 MBd (da beide Controller mit 20 MHz laufen, haben die den gleichen "Rechen-/Zeitfehler" beim UBRR. Zusätzlicher Vorteil natürlich zwei Kommunikationsrichtungen. Nachteil: Es ist KEIN Busverfahren.

[Peter(TOO)]

Hallo Geier,

Klar, fast unnötig Dir beizupflichten. Aber es geht natürlich auch anders.

MIT UART ist das alles kein Problem!

Aber er will das UART per Software an einem beliebigen GPIO-Pin simulieren, weil seines schon belegt ist!
Das Argument war: Bei I2C geht das ja auch.

MfG Peter(TOO)

[oberallgeier]

... MIT UART ist das alles kein Problem! ... Aber er will das UART per Software an einem beliebigen GPIO-Pin ...

Aua - da hab ich schon wieder mal zuuu wenig gelesen/raufgescrollt. Danke.