Guten Abend an alle, ich bin neu im Forum und stelle folgendes zur Debatte... Ich habe ein älteres Gerät mit RS422 Schnittstelle, Schrittgeschwindigkeit: 3.2MBit/s alle 45kHz wird ein 16bit-Wort gesendet Vorhanden sind Takt, DatenübernahmePuls und die seriellen Daten als Steuerleitung. Ich möchte die 16bit-Werte an einen Rechner senden, wobei als Schnittstelle USB oder Netzwerk zur Verfügung steht. Frage: Kommt zum einlesen, bearbeiten und versenden ein ATmega mit 16MHz in Frage? Was könnte alternativ zum Einsatz kommen? Vielen Dank für ein paar Tipps Peter
Bei USB müsste das Gerät als Slave laufen, der PC als Host. Das Gerät müßte dann die Daten bis zum nächsten Transfer-Request des PCs zwischenpuffern. Ob da so ein ATMega genug Speicher für hat? Das müßte man man durchspielen mit allen Puffern, die benötigt werden. Ich würde ein Gerät mit mehr Hauptspeicher wählen.
3.2 MBaud wirst Du nicht mit dem Avr erreichen, ebenso nicht mit Full Speed USB Seriell Konvertern. Evt geht ein USB 2.0 High Speed Konverter wie der FT2232H.
Hallo, die Sache mit einem AVR zu erledigen läßt mir keine Ruhe... Wenn alle 45kHz 16bit in einem externen Schieberegister landen, sollte ich doch genug Zeit haben um die mit einem AVR zu bearbeiten. Wäre dann eine Seriell-Parallel-Wandlung. Ich habe den Takt, die Daten und den ÜbernahmePuls, sollte zum takten eines Schieberegister reichen. Die eigentliche Datenrate der Nutzdaten (16bit) liegt doch bei einem Bruchteil der 3.2MBit/s, irgendwo im kBit/s - Bereich? Denke ich da falsch? Peter
Peter L. schrieb: > Die eigentliche Datenrate der Nutzdaten (16bit) liegt doch bei einem > Bruchteil der 3.2MBit/s, irgendwo im kBit/s - Bereich? > Denke ich da falsch? Das kann man doch ausrechnen. Bei 45kHz erhält man etwa 22us zwischen den 16 Bit Werten. -> 1.375us pro Bit. Das ergibt ca. 720kBit/s. Wenn du unbedingt einen AVR nehmen willst, dann nimm doch einen Xmega mit DMA und USB.
Peter L. schrieb: > Vorhanden sind Takt, DatenübernahmePuls und die seriellen Daten als > Steuerleitung. Dann ist es kein RS422, denn RS422 ist AFAIK asynchron. Peter L. schrieb: > Die eigentliche Datenrate der Nutzdaten (16bit) liegt doch bei einem > Bruchteil der 3.2MBit/s, irgendwo im kBit/s - Bereich? > Denke ich da falsch? 16x 45kHz = 720.000 bit/sec. Ich wüsste nicht wie man die aus einem 16 MHz AVR schnell genug rauslassen kann, außer man nimmt eine dicke USB Variante mit vieeeel RAM.
Ein Blick ins Datenblatt unter "Absolute Maximum Ratings" hilft: z.B. beim mega328p: - max SPI-Clock bestenfalls F_OSC/6 - oder F_XCK <= F_OSC/4 beim USART. Deine 3.2MBaud sind damit gerade noch im Rahmen, ansonsten kann man sich da mit einem externen Schieberegister und parallelem Einlesen behelfen. Aber: 16bit@45kHz heißt über den dicken Daumen: ca alle 20µs ein neues 16bit-Datum. Dh. du hast bei 16MHz ca. 320 Clock cycles für: Einlesen, Verarbeiten, Ausgeben. Kommt drauf an, wie komplex dein "Verarbeiten, Ausgeben" ist. Einlesen allein sollte gehen. Aber das ist ja gerade mal ein Drittel der Task.
Jim M. schrieb: > 16x 45kHz = 720.000 bit/sec. Ich wüsste nicht wie man die aus einem 16 > MHz AVR schnell genug rauslassen kann, So langsam sind die AVR auch nicht, bei 16MHz kann man den UART auf 2MBit/s einstellen und durch das zusätzliche Puffer-Byte in Sende-Richtung bekommt man das auch kontinuierlich raus geschoben. Viel mehr macht der dann nicht mehr, okay, muss der aber auch nicht unbedingt. :-) 45kHz = 22µs 16 Bit bei 2 MBit/s -> 10µs Wären also mindestens 12µs um die Daten einzulesen, effektiv kann man aber auch noch die 10µs Übertragungs-Zeit quasi voll nutzen, da man ja quasi direkt nacheinander 2 Bytes in den UART schreiben kann und der dann erst beschäftigt ist. Also seriell einlesen mit 3,2 MBit/s geht nicht, aber seriell ausgeben geht schon noch mehr als hier benötigt wird. Wenn das 8 Bit wären, könnte man noch den SPI zum einlesen benutzen.
Rudolph R. schrieb: > Wenn das 8 Bit wären, könnte man noch den SPI zum einlesen benutzen. Leider brauche ich die 16bit komplett, keine Datensicherung oder anderer Overhead vorhanden.
Jim M. schrieb: > Dann ist es kein RS422, denn RS422 ist AFAIK asynchron. Die Schnittstelle entspricht der RS422, alle Ausgänge sind invertiert bzw. nicht invertiert vorhanden.
Rainer B. schrieb: > Kommt drauf an, wie komplex dein "Verarbeiten, Ausgeben" ist. > Einlesen allein sollte gehen. Aber das ist ja gerade mal ein Drittel der > Task. Ziel ist die 16bit direkt an einen Rechner auszugeben, der kümmert sich um den Rest. Wenn ich die parallel über 16 Pins verteilt abfragen muss dann vorher noch (ein wenig) Bit-Manipulation um alles in die richtige Reihenfolge zu bringen. Der AVR muss also nichts weiter machen, nur ausgeben ;-)
Moin, von solcher AVR-Frickelei würde ich die Finger lassen, das so hinzukriegen (wenn überhaupt) kostet eine Menge mehr Ach und Krach als einen passenden RS485-Konverter zu nehmen. Entweder fertig kaufen, oder Uwes Rat befolgen: FT2232H (wichtig das 'H'). Gibt da auch fertige Appnotes zu. Habe damit schon gut RS422/485 ersniffen können, 3MBit liegen problemlos drin, das Problem könnte höchstens hostseitig (insbesondere Windows) auftreten. Also wenn Echtzeit nötig und absolut kein Datenverlust auftreten darf, dann muss man zu anderen Lösungen greifen. Gruss, - Strubi
Angehängte Dateien:
-
scope_1.png
51 KB
Zuerst ein gesundes neues Jahr... um mal einen Zwischenstand zu geben, die seriell/parallel Wandlung mit Schieberegistern konnte ich heute mal testen. siehe Anhang... (1) orange LSB (2) grün MSB (3) lila? serielle Daten 3.2MBit/s (4) rot Datenübernahme Takt Jetzt werde ich mich an den Softwareteil machen. 1) AVR -> USART 2) AVR -> SPI -> LAN 3) EZ-USB Versuch macht klu(ch)g. Peter
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.