GPS aber UART belegt

[Uwe H. (uweham)]

Hi Leute.

[Offtopic Note:
Ich hatte urspünglich meinen Beitrag hier: 
Beitrag "I2C GPS" gestartet, nun 
übernehme ich meine Inhalte hierher.]

Zum Thema: Ich suche einen I2C GPS Empfänger. Ziel ist es die 
GPS-Positionsdaten auf meinem uC-Atmega328p zur Verfügung zu haben. 
Leider ist die UART Schnittstelle schon belegt, daher I2C. Die 
Versorgungsspannung ist 3.3V.

[Edit:
Das GPS wird zu einem bestehenden Gesamtsystem (Studentenprojekt, 1uC, 
4Sensoren, 2Servos, Xbee, EEPROM) hinzugefügt. Dieses Gesamtsystem ist 
fertig dimensioniert, "geEaglet", geätzt, gelötet und die Software ist 
ebenfalls quasi fertig. Da es sich bei dem GPS um ein AddOn handelt, 
sollte es idealerweise gar keinen Einfluss auf die bereits bestehenden 
Komponenten haben. Daher schien mir I2C sinnvoll und Optionen wie 'uC 
wechseln' sind nicht realisierbar.
Weiterhin gibt es gewisse Platzprobleme bei neuen Komponenten, sodass 
fertige, kleine Komponenten vorteilhaft sind. Daher und aus der Hoffnung 
Zeit zu sparen, habe ich zunächst nach fertigen I2C-GPS-Subsystemen 
gesucht.]

Da ich nur wenige Tage Zeit habe, suche ich eine simple Lösung. In 
meiner Vorstellung lese ich idealerweise einfach ein paar Register des 
GPS mit I2C aus.

Allerdings finde ich bisher keine I2C GPS Empfänger mit aussagekräftigem 
Datasheet, welches das Registerauslesen dokumentiert.


Meine bisherige Recherche:

(1) I2C-GPS NAV Module
http://www.drotek.fr/shop/en/home/335-i2c-gps-nav-module.html
Ich vermute, es macht was ich brauche, aber ich habe keine Doku dazu 
gefunden. Lediglich eine r33-documentation. Hier wäre die Frage, wie 
aufwendig es ist die GPS-Daten auf meinen uC zu bekommen.


(2) maestro GPS Receiver A2035-H
http://www.farnell.com/datasheets/1794015.pdf
Bei dem steht zwar I2C als Modul-Schnittstelle, allerdings finde ich in 
der Doku keinen Hinweis zur I2C Kommunikation. Irgendwie ist die I2C 
Schnittstelle nur für MEMS?


(3) Arexx I²C GPS Empfänger JM3-GPS
http://www.conrad.biz/ce/de/product/1082385/Arexx-IC-GPS-Empfaenger-JM3-GPS?ref=searchDetail 
Auch hierzu finde ich leider kein Datasheet.



Zusammengefasst, 'könnten' aus meiner Sicht alle Optionen zielführend 
sein. Welche Option ist die beste, und warum? Welche weiteren 
Alternativen habe ich? Hat jemand Erfahrungen auf dem Thema und kann 
mich beratend unterstützen?


Schöne Grüße
Uwe

[Uwe H. (uweham)]

[Offtopic Note:
Ich hatte urspünglich meinen Beitrag hier: 
Beitrag "GPS Modul an µC anbinden" gestartet, nun übernehme ich 
die Antworten hierher.]


______________________________________________________________________

Autor: André C. (clausi)
Datum: 19.02.2014 06:40


Hallo,

vielleicht kommst du einfacher, wenn du einen zweiten Controller nimmst
an den du ein GPS-Modul (zu dem du viel Infos hast) über UART dranhängst
und dann die Daten über I2C an deinen "Hauptcontroller" gibst.

Das schränkt dich nicht so ein und die Teile sollten schnell beschaffbar
sein.

Nur so ne Idee :-)

Gruß

André



______________________________________________________________________

Autor: Max H. (hartl192)
Datum: 19.02.2014 06:53

Du könntest falls möglich die Rx und Tx Leitungen mit einem Multiplexer
(z.B. 74HC405x) umschalten.
Pull Up an den Ausgängen nicht vergessen.



______________________________________________________________________

Autor: Stefan Wagner (dl6dx)
Datum: 19.02.2014 09:30

André C. schrieb:
> wenn du einen zweiten Controller nimmst
> an den du ein GPS-Modul (zu dem du viel Infos hast) über UART dranhängst
> und dann die Daten über I2C an deinen "Hauptcontroller" gibst

An den TO: Schau mal hier:
http://www.mikrocontroller.net/articles/I2C-slave_USART

Grüße

Stefan



______________________________________________________________________

Autor: Aehh (Gast)
Datum: 19.02.2014 09:41

Was spricht denn gegen einen anderen Controller, zB den Mega 644, der
hat 2 Uarts.



______________________________________________________________________

Autor: Axel Schwenke (a-za-z0-9)
Datum: 19.02.2014 10:17

Uwe Ham schrieb:
> Zum Thema: Ich suche ein I2C GPS Empfänger. Ziel ist es die
> GPS-Positionsdaten auf meinem uC-Atmega328p zur Verfügung zu haben.
> Leider ist die UART Schnittstelle schon belegt, daher I2C.

<seufz>

GPS liefert Daten im Schneckentempo (und das sind extra langsame
Schnecken). Die typisch 9600Bd kann man auch per Software-UART machen.


XL

[Uwe H. (uweham)]

Vielen Dank für die schnellen, konstruktiven Antworten. 
Mikrocontroller.net scheint ein guter Platz für effizientes 
Brainstorming zu sein. Entschuldigt wenn ich zum Antworten etwas 
brauche. Ich muss mich erst in die verschiedenen Themen einarbeiten.

Als Grundidee höre ich raus: "Kauf dir ein normales UART GPS, und mach 
den Rest selbst!"


@André C.
Ich habe mir zunächst das 'Very small PA6C GPS breakout board 
(FGPMMOPA6C)' bestellt und werde es ersten Schritt das UART GPS 
auslesen.
http://www.drotek.fr/shop/en/home/146-pa6c-gps-llc.html


@Max H.
Multiplexer ist schwierig, wegen nötigen Änderungen am Gesamtsystem. 
(siehe Edit im ersten Beitrag)

@Stefan Wagner
Der I2C-slave USART Artikel ist interessant, mein erster Eindruck ist 
eventuell aufwändig, muss es aber erst noch im Detail anschauen und 
verstehen.

@Aeh
Ich möchte möglichst nichts am bestehenden Gesamtsystem ändern. (siehe 
Edit im ersten Beitrag)

@Axel Schwenke
Den Software UART schaue ich mir genauer an. Ich habe den 8bit-Timer2 
noch frei. Zwei freie Pins gibts auch. Weiterhin gibt es die Software 
schon, von Peter Dannegger (Beitrag "Software UART") 
Er schreibt, dass sich 16bit-Timer1 anbietet, damit keine Jitter 
Probleme entstehen. Als erster Eindruck, frage ich mich ob Probleme 
entstehen wenn ich Timer2 verwende? Und ob die Code Änderungen von T1 
auf T2 aufwändig sind.

[Frank K. (fchk)]

Schau hier:

http://www.nxp.com/products/interface_and_connectivity/bridges/i2c_spi_slave_to_uart_irda_gpio_bridges/#products
http://www.nxp.com/products/interface_and_connectivity/bridges/i2c_spi_slave_to_uart_irda_gpio_bridges/series/SC16IS752_SC16IS762.html

Ist auch gar nicht so teuer. Damit hast Du zwei zusätzliche serielle 
Ports.

http://de.farnell.com/nxp/sc16is752ipw-112/ic-dual-uart-fifo-5mbps-3-6v-tssop28/dp/2101309?ref=lookahead

fchk

[c-hater (Gast)]

Uwe Ham schrieb:

> Leider ist die UART Schnittstelle schon belegt, daher I2C.

Warum? Das bissel Scheiß, was so ein GPS-Teil zu übermitteln hat, kann 
man auch mit einer Soft-UART empfangen, denn eben weil es so wenig ist, 
wird nämlich typisch eine recht geringe Bitrate dafür benutzt.

Wenn du auf I2C abzielst, sind also mindestens zwei Pins des Controllers 
frei und auch etwas, was man ziemlich problemlos als primitiven, aber 
immerhin interruptfähigen "Timer" zweckentfremden kann.

Damit steht der minimalinvasiven Soft-UART nichts mehr im Wege. Außer 
eventuell der Unfähigkeit des Programmierers. Da es aber eventuell 
leichter ist, einen unfähigen Programmierer zu ersetzen, als ein GPS mit 
I2C zu auch nur annähernd dem Preis eines GPS mit UART zu finden, wird 
dein Problem wohl in naher Zukunft möglicherweise wie durch ein Wunder 
gelöst werden, wenn auch in einer für dich unerwarteter Art...

[Uwe H. (uweham)]

@Frank K.
Sehr cool, vielen dank, der SC16IS740 scheint mir eine noch bessere 
Lösung als der Software-UART zu sein. Verstehe ich es richtig, dass das 
GPS dann die NMEA 0183 strings in die Register schreibt und mein uC 
diese Register via I2C auslesen kann? -> Ich lese mal data sheet.

[Frank K. (fchk)]

Uwe Ham schrieb:
> @Frank K.
> Sehr cool, vielen dank, der SC16IS740 scheint mir eine noch bessere
> Lösung als der Software-UART zu sein. Verstehe ich es richtig, dass das
> GPS dann die NMEA 0183 strings in die Register schreibt und mein uC
> diese Register via I2C auslesen kann? -> Ich lese mal data sheet.

Etwas komplexer ist das schon. Das ist in Prinzip ein 16550, wie er in 
PCs als USART verwendet wird, aber mit I2C Interface. Die GPS-Strings 
musst Du Byte für Byte abholen - entweder per Polling oder 
(sinnvollerweise) interruptgesteuert.

Vorteil dieser Lösung: Du kannst die Zahl der Ports ganz leicht erhöhen, 
falls Du noch weitere brauchst. Und das Timing ist völlig unkritisch, 
weil der Chip FIFOs hat.

fchk