Hallo, ich möchte in einem Projekt 512 Sensoren auslesen. Die Sensoren werden über SPI angesprochen und liefern jeweils 16 Byte Daten. Nun möchte ich die Sensoren 25 mal in der Sekunde abfragen und die Daten an einen Computer weiterleiten. Bisher habe ich mir das so vorgestellt, dass ich ich jeweils die Daten von 16 Sensoren mit einem uC(I) zusammenfasse (insgeamt also 32uCs für die Sensoren) und diese dann an einen weiteren uC(II) über SPI weiterleite. Dieser fast dann die Daten aller uCs zusammen und sendet diese via USB/Ethernet an den Computer an dem die Daten weiter verarbeitet werden. Vorgestellt habe ich mir einen ATmega 32u4 für die Sensoren. Als Mastermikrocontroller für die Kommunikation über USB/Ethernet suche ich noch einen Controller. Jetzt bin ich mir unschlüssig, ob das so funktionieren könnte. Denn insgesamt kommt ja doch einiges an Daten zusammen (die kleineren Controller schicken an den Master 6400 Byte/s (bei einer Auswertung von 25mal pro Sekunde)) und der Master schickt an den Computer letztlich 204500 Byte/s. Gibt es vllt jemand, der ein ähnliches Projekt schonmal durchgeführt hat, oder andere Möglichkeiten dies zu realisieren Gruß
Hallo, hat den niemand eine Idee bisher? Ich habe jetzt auch noch FTDI-Chips gefunden, die High-Speed USB beherrschen. Vielleicht wäre dies ja auch eine Alternative für den Master-Mikrocontroller.
Hartmuth schrieb: > Jetzt bin ich mir unschlüssig, ob das so funktionieren könnte. > Denn insgesamt kommt ja doch einiges an Daten zusammen (die kleineren > Controller schicken an den Master 6400 Byte/s (bei einer Auswertung von > 25mal pro Sekunde)) und der Master schickt an den Computer letztlich > 204500 Byte/s. ?? Da komme ich jetzt nicht mit: 512 25 2 = 25600 Bytes/s Wie kommst du dann auf 204500? Du meinst wohl eher 204500 Bits/s Das ist absolut kein Problem, "fast" jeder uC kann heute schon mit 460800 Baud über RS232 arbeiten. Bei den besseren sind schon 921600 Standart. Wenn du jetzt ein FTDI-Chip dazwischen schaltest, dann musst du dich nicht um die Übertragung kümmern, sondern kannst normal über UART senden und empfangen. Auf dem PC brauchst du nur noch ein Terminal oder ein eigenes Programm. Ob das mit den Sensoren klappt steht auf einem anderen Stern. Wie sind die angeschlossen? Daisy-Chain? Welches Umfeld (Strörungen...)? Wie lange sind die Leitungen? Werden Treiber verwendet? ...
Erstmal vielen Dank für die Antwort! Patrick B. schrieb: > ?? Da komme ich jetzt nicht mit: > 512 25 2 = 25600 Bytes/s > > Wie kommst du dann auf 204500? Du meinst wohl eher 204500 Bits/s 16 Byte Daten pro Sensor, 512 Sensoren, 25Hz -> 16Byte 512 25(1/s) = 204800Byte/s (hab mich wohl vertippt) Patrick B. schrieb: > Das ist absolut kein Problem, "fast" jeder uC kann heute schon mit > 460800 Baud über RS232 arbeiten. Bei den besseren sind schon 921600 > Standart. Wenn du jetzt ein FTDI-Chip dazwischen schaltest, dann musst > du dich nicht um die Übertragung kümmern, sondern kannst normal über > UART senden und empfangen. Auf dem PC brauchst du nur noch ein Terminal > oder ein eigenes Programm. Also kann ich zum Beispiel den FT232H verwenden und dann geh ich direkt an die 32 uC's für die Sensoren. Soweit ich gesehen habe, kann ich mir dann raussuchen, ob ich SPI oder USART nutzen will. Erfordert aber quasi einen größeren Controller als der geplante ATmega32u4, da dieser ja nur bis 16MHz spezifiziert ist. Wäre die Frage welchen Controller ich dann benutze. An sich wäre mir ein Controller von Atmel am liebsten. Bisher versucht die Software mit der Arduino-Umgebung umzusetzen. Dies kann ich aber wenn ich das richtig sehe nun doch eher vergessen. Patrick B. schrieb: > b das mit den Sensoren klappt steht auf einem anderen Stern. Wie sind > die angeschlossen? Daisy-Chain? Welches Umfeld (Strörungen...)? Wie > lange sind die Leitungen? Werden Treiber verwendet? > ... Die Sensoren schaffen bis zu 16MHz. Sollte also funktionieren, da die meisten Controller ja einen Clockdivider haben. Ansonsten ist der Aufbau der Sensoren erstmal unwichtig, da es im Moment nur um die reine Datenübertragung geht. Das wird dann nochmal ein größeres Kapitel...
Ich würde als Master einen UC3B nehmen, der hat USB gleich onboard. Programmierung ist eigentlich total simple. Auf PC-Seite gibt es auch einfache USB-Treiber, so dass du das Perfekt anpassen kannst.
Hallo, also ich habe mir jetzt das Testboard von FTDI geholt mit dem Chip FT232H (Board: UM232H). Jetzt sende ich mit einem Arduino Leonardo-Board über UART mit einer Baudrate von 2MBaud Daten an den Chip. Die Daten empfange ich dann mit dem Chip und werte sie am Computer mit dem Realterm (Hyperterminal) aus. Bei diesem kann man angeben, dass die Software die empfangenen Daten speichert und nach einer bestimmten Byteanzahl abbrechen soll. Dies habe ich so auch getestet und der Zeitstempel in der Datei zeigt mir, dass ca. 5s gebraucht werden, bis 204.800Byte empfangen wurden. Mit einem Oszilloskop habe ich verifiziert, dass auch mit der angegeben Baudrate gesendet wird. Aber eigentlich müssten die Daten doch in einer Sekunde übertragen werden oder? Außerdem habe ich noch einen weiteren Test gemacht: Ich habe eine Datei erzeugt (ASCII) mit 204.800Byte Inhalt. Diese sende ich über den Realterm und verifzieren, wie lang dies dauert. Auch hier werden die Daten bei einer eingestellten Baudrate von 2Mbaud nicht innerhalb der gewünschten Zeit übertragen. Also habe ich im Realterm die Baudrate weiter erhöht auf 12Mbaud. Meines erachtens nach brauch die Übertragung aber genauso lang wie bei 2MBaud. Mit dem Oszilloskop sehe ich (soweit dies möglich ist), dass öfters eine Pause von ca. 200us ist. Woran kann dies liegen?
Hallo, also ich habe jetzt gehört, dass es von Windows her wohl eine Begrenzung in dieser Richtung gibt. Es soll wohl so sein, dass zwischen den Sendevorgängen Windows teilweise den Vorgang unterbricht für eine bestimmte Zeit. Kann mir jemand mehr dazu sagen?
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.