Hallo,
ich bin in der Entwurfsphase für ein Projekt bei dem die
GPS-Koordinaten, zwei Winkelwerte (von einem Kompassmodul) und noch 1-2
wertere Werte für verschiedene Wegpunkte gespeichert werden müssen.
Die Geräte (GPS-Empfänger, Kompass-Modul, Entfernungsmesser, Gyro)
liefern ihre Daten über RS232 Schnittstellen.
Ich würde jetzt am liebsten an je einem URAT pro Gerät auf Daten warten,
diese mit einem Zeitstempel versehen und abspeichern. Für den
Zeitstempel könnte man ja einen Timer mit den Signal vom GPS
"syncronisieren".
Viel mehr müsste das ganzte Ding dann nicht machen, alle
Datenverarbeitung soll dann im PC geschehen.
Nun mein Problem: Ich suche einen µC mit dem ich drei oder vier RS232
Schnittstellen abfragen kann. Er soll aber auch möglichst einfach zu
handhaben sein (muss auch auch sonst nicht viel können).
Könnt Ihr mir das etwas empfehlen?
MfG Steffen
>> Der Atmega2560 sollte ... 4 UARTs haben.
Ja, hat er. Aber das ist doch ein ziemlicher Brocken. Dort bracht es
einiges an Investitionen (Zeit und Geld) bis man was am laufen hat. Und
da das ganze Ding ansonsten nicht viel machen soll (siehe oben) suche
ich nach einer enfachen Lösung.
MfG Steffen
>Dort bracht es>einiges an Investitionen (Zeit und Geld) bis man was am laufen hat.
???
Außerdem sind da noch ATMEGA1280, ATXMEGA128A1.
Software UART ist bei 9600Baud überhaupt kein Problem und kann z.B. mit
timergesteuertem Polling betrieben werden.
Man könnte auch per I²C mehrere I²C-Doppel-UARTs à la SC16IS752
anschließen.
Die sind registerkompatibel zum "Industriestandard" 16450 und enthalten
Sende- und EmpfangsFIFOs mit je 64 Byte Größe.
Sofern es nicht auf allzuhohe Baudraten ankommt, ist das eine gar nicht
so unpraktische Lösung - wenn denn der Host-µC I²C in Hardware
unterstützt.
Moin,
wenn das GPS seine Daten im NMEA Protokoll ausgibt, sind es sogar nur
4800 Baud, was ein Software UART nochmal leichter macht.
Man muss es ja nichtmal im Fullduplex betreiben da ein Empfang völlig
ausreichend ist. Viele (alle?) GPS-Geräte plappern einfach vor sich hin
und Senden die Daten ohne Anfrage ständig nach außen.
Es könnte also auch ein Atmel mit 2 UART + USI reichen.
mfg Emperor_L0ser
LPC2364 = 4 UARTs
Gute Unterstützung im Netz (siehe auch großer Bruder LPC2378), breites
Spektrum an Entwicklungstools (kostenlos bis sauteuer)
Software-UARTs sind ja beim Senden ja noch halbwegs annehmbar, beim
Empfang finde ich es sehr sehr bastelig und unprofessionell.
Steffen wrote:
>>> Der Atmega2560 sollte ... 4 UARTs haben.>> Ja, hat er. Aber das ist doch ein ziemlicher Brocken. Dort bracht es> einiges an Investitionen (Zeit und Geld) bis man was am laufen hat.
Nö, Zeit und Geld sind außer den Kosten für den MC die gleichen, wie bei
einem kleinen AVR.
Ein kleines Programm zu entwickeln dauert darauf exakt genau so lange,
wie auf einem ATtiny.
Es bleiben eben nur viele Ressorcen ungenutzt.
Man kann aber auch nen ATMega48 nehmen und 3 weitere UARTs in SW machen,
ist bei nur 9600Baud spielend zu schaffen.
Peter
Falls Interesse besteht, habe ich eine fertige Platine (Layout, Muster)
mit 4 mal RS232 (TX und RX belegt) mit einem Mega2560. Ursprünglich für
ein Projekt im Medizinbereich verwendet. Poste doch mal Deine Email,
wenn Du möchtest, Steffen.
Maxim-SPI-UARTs --> Mal 'nen Blick auf die Preise geworfen?
Hinzu kommt noch die Inbetriebnahme, das würde ich mir nicht antun.
Was ist eigentlich mit dieser Software-UART-Lösung per Polling, wird da
jedes Bit auch 3x gepollt und anschliessend einem 2-aus-3 Entscheider
zugeführt? So wie das bei einer Hardware-UART gemacht wird, um die
Übertragungssicherheit zu erhöhen?
Anstatt die Super Duper Alleskönnerlösung mit viel Firepower zu
erzwingen, sollte man vielleicht mal drüber nachdenken, ob man die
einzelnen Module vielleicht NACHEINANDER abfragen kann. Dann reicht ein
simpler Multiplexer für 20 Cent und ein kleiner AVR.
MFG
Falk
Moin,
@Falk
beim hintereinander Abfragen könnte allerdings das Problem entstehen,
dass die Geräte nicht auf ne Aufforderung warten, sondern ihre Werte
zyklisch ausspucken.
@Harald
Beim Software UART werden die meisten Implementationen wohl so aussehen,
dass man nur einmal liest. Grundsätzlich obliegt es aber dort dem
Software Entwickler, ob er ein mehrfaches Abfragen benötigt. Bei nem
Einsatz in EMV unkritischen Umgebungen und bei 4800 bis 9600 Baud sollte
ein einzelnes Abfragen keine Probleme bereiten.
mfg Emperor_L0ser
Ich arbeite im Moment gerade an etwas ähnlichen.
Ich muss die Werte von mehreren Sensoren zyklisch abfragen. Dazu brauche
ich eine UART womit ich auf ein RS-485 Driver gehe. Mit dem RS-485 kann
ich die Sensoren alle an das gleiche Kabel hängen => Bus. Danach frage
ich die Sensoren zyklisch ab, indem ich zuerst die Adresse des
gewünschten Sensors auf die Leitung gebe, und dieser mir dan die Daten
zurück gibt. Mit dem 9 Bit, welches oft als Parity-Bit verwendet wird,
kann man zwischen Adresse und Daten unterscheiden.
Sollte auch auf die Anwendung von Steffen übertragbar sein.
Gruss
@ pq (Gast)
>>Duper Alleskönnerlösung>die S12X µCs kosten 8€>da würde ich nicht mit Multiplexern anfangen.
Ein Mega8 kostet 1,20 EUR, ein MUX 25 Cent. Aber Nachdenken liegt ja
nicht im Trend . . .
> Aber Nachdenken liegt ja nicht im Trend . . .
ein unnötiger Kommentar
Eine Lösung mit µC mit 4 Uarts erleichtert das Programmieren und hat
weniger Einschränkungen. So dass sich die 6,80€ recht schnell
amortisieren. Im Professionellen Bereich bereits nach 5-10 Minuten. Im
Hobbybereich gehts etwas länger.
pq
@ pq (Gast)
>Eine Lösung mit µC mit 4 Uarts erleichtert das Programmieren
Wer als Programmierer mit ner MUX Probleme hat, sollte mal nen VHS Kurs
machen.
> und hat weniger Einschränkungen.
Ja, aber man baut nicht die SuperSonderAlleskönnerlösung sondern was
benötigt wird.
> So dass sich die 6,80€ recht schnell>amortisieren. Im Professionellen Bereich bereits nach 5-10 Minuten.
Nicht bei 10.000 Stück ;-)
> Im Hobbybereich gehts etwas länger.
Eben, da muss man mit einem neuen Prozessor, Compiler Tollchain
anfangen. Weil ne kleine MUX zu "aufwändig" ist . . .
MFG
Falk
