Hallo, ich möchte gerne 4 UART Kanäle auf eine gewisse Stringfolge prüfen, dafür hatte ich erst 4 einzelne Attinys eingeplant, aber heute bin ich über den Atmega640 gestolpert. Der Baustein bietet 4 HW UARTS und würde ideal dafür passen, aber etwas unschlüssig bin ich mir, ob der Baustein wirklich 4 Uart sniffen kann ohne Datenverlust. Die Sender senden kontinuerlich mit 115200Baud Daten über die UART Schnittstelle und der ATMega soll mit 7,3728MHz arbeiten, die Programmiersprache wäre C (AVR GCC). Ich würde in den 4 auftretenen UART Interrupts jeweils ein Zeichen in einen eignen FIFO schreiben und in der Mainschleife die Stringfolge in dem Fifo suchen und nach positiver Auswertung ein paar Outputs toggeln. Was meint Ihr ist das zu schaffen ohne Datenverlust oder lieber auf Nummer sicher gehen und jeweils einen eigenen AVR pro Teilnehmer einplanen? Ein Protokoll zwischen AVR und Teilnehmer scheidet aus.
PS.: Der nächste riesenvorteil bei dem ATMega wäre die Updatemöglichkeit über UART Bootloader. Klar funktioniert es auch bei 4 einzelnen Attinys, aber wäre mit mehr HW Aufwand nur lösbar.
Torben schrieb: > Was meint Ihr ist das zu schaffen ohne Datenverlust oder lieber auf > Nummer sicher gehen und jeweils einen eigenen AVR pro Teilnehmer > einplanen? Hallo, da bleiben für jedes neu eintreffende Zeichen ca 25 µs für die komplette Verarbeitung einschliesslich Vergleich, Entscheidung und ev. Weitermeldung. Ich denke, mit optimierter Assembler-Software wäre das möglich, in C eher nicht. Gruss Reinhard
Möglich, das ich mich verrechnet habe oder einen Denkfehler mache, aber ich komme auf viel weniger Zeit. 115200 Baud an vier Schnittstellen sind 460800 Baud insgsamt. Das wäre alle 2,1us ein Byte. Das sind demnach 16 Takte pro Zeichen für den Vergleich. Schon ziemlich sportlich.
Andererseits kannst Du den Mega auch mit 14.7456Mhz takten, dann hast Du doppelt so viel Zeit. Huch schrieb: > 115200 Baud an vier Schnittstellen sind 460800 Baud insgsamt. Das wäre > alle 2,1us ein Byte. Das sind demnach 16 Takte pro Zeichen für den > Vergleich. Das kann man so nicht sagen. Je nachdem, wann die Bytes eintreffen, kann es Überschneidungen geben, zu denen alle 4 RXC-Interrupte gleichzeitig feuern. Das abzuarbeiten, könnte schwierig werden. Alternativ gibt es den XMEGA, einige Bauformen bieten bis zu 8 UARTs. Das Abhohlen kann hier mit DMA erfolgen und das ist absolut zuverlässig. Die Taktrate des Controllers kann hier auch bei 29.xxxxMhz liegen, was zusätzlich Luft verschafft.
Hallo, wenn ich das nachrechne komme ich auf andere Werte: 115200 Baud * 4 = 460800 Bit / s macht inklusive Start und Stoppbit 46080 Byte / s 7,328 MHz macht 7328000 Takte / s macht 159 Takte pro Byte. Sollte also reichen. Gruß Olaf
Was ? Die Zeiten sind ganz falsch. 115200baud sind 10kbyte pro sekunde. Macht 100us/byte. Da wir vier haben sind es noch 25us. Mit einem 14.xxMHz getakteten Mega64 sind das immerhin fast 300 Befehle pro empfangenes Byte. Die Frage ist eher, was macht man dann damit. Muss der Trigger dynamisch veraenderbar sein ? Wie wird der Trigger der Aussenwelt mitgeteilt? Dann wuerde sich ein externes 4 fach UART, zb ein 16C754 anbieten. Das hat dann noch je 64byte buffer, falls es mal etwas eng wird. Die Frage nach der Reaktionszeit auf den Trigger stellt sich auch noch.
Ich würde auch zum 14,7456MHz Quarz greifen. Dann hast Du 320 Zyklen pro Byte, das sollte auch in C dicke reichen. Peter
Danke an alle für die Hilfe! >8MHz geht leider nicht, weil das komplette Sniffer und Teilnehmersystem mit 3,3V VCC arbeitet. ATXMega kommt leider wegen Einarbeitungszeit nicht in Frage oder wie hoch war euer Umstieg von ATMega zum ATXMega? TL16C754B sieht sehr interessant aus wegen dem 64Byte Fifo. >Die Frage nach der Reaktionszeit auf den Trigger stellt sich >auch noch. Reaktionszeiten von 5-10Sekunden auf den Trigger sind akzeptabel. Was passiert, wenn alle 4 Interrupts zur gleichen Zeit zuschlagen? Kommt es dann zum Datenverlust?
Das alle vier RX-Interrupts gleichzeitig ausgelöst werden kann natürlich vorkommen. Aber das ist aus meiner Sicht keine Problem. Denn die Interrupts werden ja gespeichert, es geht keiner verloren.
Torben schrieb: > ATXMega kommt leider wegen Einarbeitungszeit nicht in Frage oder wie > hoch war euer Umstieg von ATMega zum ATXMega? Datenblatt und Manual lesen ist Pflicht. Die Befehle sind weitestgehend kompatibel, das Verhalten der XMega-Peripherie ist gleich bis sehr ähnlich zu vergleichbarer Mega-Peripherie. Die Init ist komplexer, aber verständlich. Ich würde sagen, ein paar Stunden Einarbeitungszeit, wenn man nicht tief in´s Detail geht und praktisch Mega-Code nach XMega portiert. Bei Nutzung aller Features ist die Einarbeitung in einigen Tagen bis Wochen zu schaffen. Inszwischen gibt es auch einige XMega-Projekte im Netz.
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.