Hallo zusammen, Ich bin auf der Suche nach einer Möglichkeit, bis zu 50 UARTs an der TX Leitung zuzuhören. Die Baudrate kann bis 9600 runter gehen und die Packete werden max 100 Byte lang sein und jede 1s gesendet. Allerdings sind die Sender nicht synchron zusammen. Da ich n riesen USB-Hub und voll viele USB-Serial_Wandler unhandlich finde, dacht ich an sowas wie SPI-UART Expander und STM32F4Disco der je nach Interrupt die FIFOs abholt und alles sortiert in n logview schreibt. Könnt das gehn, oder gibt's ne praktikablere Lösung? Für die aufkommende Frage nach dem Sinn: Ich suche einen sehr sporadisch auftretenden bösen Fehler und will durch die Anzahl einfach die Auftrittswarscheinlichkeit erhöhen. Die Pakete über UART enthalten nur lfd Nr und Zustandsdaten, so das sich im Fehlerfall nachvollziehen lässt, was vor dem Fehler war. MfG Hans
Ein Mega64 hat 4 UARTs, das waeren dann 16 stueck zusammengeschaltet...
@ Hans M. (Gast) >Ich bin auf der Suche nach einer Möglichkeit, bis zu 50 UARTs an der TX >Leitung zuzuhören. Die Baudrate kann bis 9600 runter gehen Und was ist die OBERE Grenze? >und die >Packete werden max 100 Byte lang sein und jede 1s gesendet. >Allerdings sind die Sender nicht synchron zusammen. >Da ich n riesen USB-Hub und voll viele USB-Serial_Wandler unhandlich >finde, Ist aber eine sehr schnelle Lösung! > dacht ich an sowas wie SPI-UART Expander und STM32F4Disco der je >nach Interrupt die FIFOs abholt und alles sortiert in n logview >schreibt. Könnt das gehn, oder gibt's ne praktikablere Lösung? Kann man machen, aber für 50(!) nicht so der Bringer. Da würde ich eher 50 UARTs in ein kleines FPGA pressen wollen. Ist aber auch nicht in 3 Stunden gemacht. >Ich suche einen sehr sporadisch auftretenden bösen Fehler und will durch >die Anzahl einfach die Auftrittswarscheinlichkeit erhöhen. Naja, ich würde vielleicht 10 nehmen und das einfach 24/7 laufen lassen. Denn das aufzubauen ist schon ein ordentlicher Aufwand und 50 USB-UART Converter kosten auch ein paar Euro. Aber die würde ich hier bevorzugen, denn es geht um ein Tool, keine industrielle Massenlösung. D.h. Entwicklungszeit und Aufwand minimieren bringt mehr als Materialkosten senken.
Das ging ja schnell ;) @hacky Ja kann man machen, aber ich würd 1 Zentrale Stelle vorziehen. @Falk Obergrenze kann auch 115kBaud sein, denk mal das "Abholtiming" wird damit besser. Weiß nicht, ob das die schnellere Lösung wär, wenn meine beiden USBee RX am 4Port USB-Hub aktiv sind bricht die Datenrate vom USB-Stick und U-Link massiv ein. Was soll das dann erst bei 50 USB-Serial werden?! ;) Das mit dem FPGA wär "für mich" die interessanter Lösung ( hab noch n schönes Xilinx Board in der Schublade liegen, aber das KnowHow, um das umzusetzen, lern ich nich in ner Woche ;) 24/7 a 10 ist auch mein Plan, aber gleich 5 verschiedene gleichzeitig. Die ElmChan SD-Lib beschädig sporadisch die FAT, 1x im Monat bei 500 Geräten. Der Fehler geht aber hin, bis zu SD-Karten, die elektrisch zerstört werden ( die Karten gehn gar nicht mehr und im Hexeditor wird wird als erster lesbarer sector der CID angezeigt ;-) ) Deshalb will ich verschiedene Tests fahren, z.B. nur lesen, nur schreiben, lesen und schreiben, in Kombination mit geringer und hoher Interruptlast und mit verschiedenen Herstellern. Damit erfahr ich erst mal wann geht's schief, dann kann ich an der Stelle weiter bohren.
Mit mit x Evalkits vom http://www.mouser.com/ds/2/256/MAX14830-277477.pdf#page26 Für 13€ und nem stm32f4nucleo halt ich die Kosten und Aufwand recht gering noch n Arduinoshield für SD karte drauf und mit Keil RTE is SPI und Filesystem an einem Tag fertig. Is für mich einfacher, als auch noch ne WindowsApp zu schreiben. MfG Hans
@ Hans M. (Gast) >Obergrenze kann auch 115kBaud sein, denk mal das "Abholtiming" wird >damit besser. Eher nicht. >Weiß nicht, ob das die schnellere Lösung wär, wenn meine beiden USBee RX Was ist das? Ein Billigadapter als IGOR-USB? >am 4Port USB-Hub aktiv sind bricht die Datenrate vom USB-Stick und >U-Link massiv ein. Was soll das dann erst bei 50 USB-Serial werden?! ;) Nimm was Gescheites ala FT232. >Die ElmChan SD-Lib beschädig sporadisch die FAT, 1x im Monat bei 500 >Geräten. Der Fehler geht aber hin, bis zu SD-Karten, die elektrisch >zerstört werden ( die Karten gehn gar nicht mehr und im Hexeditor wird >wird als erster lesbarer sector der CID angezeigt ;-) ) Sowas kriegt man per Software doch gar nicht hin, oder? > Deshalb will ich verschiedene Tests fahren, z.B. nur lesen, nur >schreiben, lesen und schreiben, in Kombination mit geringer und hoher >Interruptlast und mit verschiedenen Herstellern. Damit erfahr ich erst >mal wann geht's schief, dann kann ich an der Stelle weiter bohren. Naja, Brute Fore ist ein Ansatz. Vielleicht kriegt man es mit etwas Köpfchen auch mit deutlich weniger Materialeinsatz hin?
>Allerdings sind die Sender nicht synchron zusammen.
Das reicht, im Normalfall, für ein KO in der ersten Runde.
Entweder hat jeder Quatscher seinen eigenen Zuhörer oder sie müssen sich
einig werden, wer das Sagen hat.
Selbst ein UART im Megaherzbereich nutzt hier nicht.
Denn die Preisfrage bleibt: Zu wem gehört denn das Bit/Byte/Datenpaket
das gerade ankommt, wenn jeder dazwischen reden kann?
Sowas kriegt man per Software doch gar nicht hin, oder? Doch scheinbar ist es möglich, nach Umstellung auf ElmChan sind in 2 Wochen gleich 6 SD-Karten auf die gleiche Weise ausgefallen... Transcent schweigt sich zu dem Fehlerbild leider aus :( Knapp 2000 Dollar sind eigentlich nix billiges ;) BruteForce ist normal auch nur mein letztes Mittel, aber so langsam ist mit gutem Rat zu Ende ;) oder kennst den Silicon Bug bei den STM32 der sich wie folgt äußert: ST-Lib >> SDIO mit DMA und die sdio_read bleibt in ner while schleife hängen obwohl die Karte alles richtig übertragen hat und der Controller einfach nicht weiter macht, obwohl im fifo noch Daten sind ?! :-D Genau so nen Geist auch ich grad
@Amateur Separate UARTs Jedes Gerät überträgt seinen eigenen Status separat.
Bei separaten UARTs ist im Normalfall bei 6 Stück Schluss. Je nach Leistung (Interrupts und MHz) und Anschlussanzahl (!!!) können noch ein paar mittels Software simuliert werden. Dann ist aber Schluss. Da ich mich mit FPGAs nicht auskenne, kann ich Dir nicht sagen, ob man 100 unabhängige UARTs reinbrutzeln kann und den Output auch noch gesittet herausbekommt. Von der Geschwindigkeit her sollte es kein Problem sein, da diese ja parallel Arbeiten können.
@Amateur (Gast) >Da ich mich mit FPGAs nicht auskenne, kann ich Dir nicht sagen, ob man >100 unabhängige UARTs reinbrutzeln kann Kann man. > und den Output auch noch >gesittet herausbekommt. Mit ein paar kleinen FIFOs kein Problem. > Von der Geschwindigkeit her sollte es kein >Problem sein, da diese ja parallel Arbeiten können. Eben.
Es soll was einfaches sein: und da klingt die Lösung mit EvalBoards vom Maxim und nem STM32fxEval für mich am einfachsten ;-)
Ein halber Blick auf das STM32fxEval ergab: 2 UARTs - ein bissel dünn. 48 MHz Tackt reichen bei weitem nicht aus um so viele UARTs mit Software zu emulieren. Ob genügend Eingänge nach "Draußen" geführt wurden konnte ich auf die Schnelle nicht feststellen. Ob die sonst die richtigen Eigenschaften haben, auch nicht. Der Speicher aber sollte ausreichen.
@Amateur : son STM32F429discovery is mt 180MHZ unterwegs, damit sollten mehr als 10 max14830 evaluation kit über 24mMHZ locker verwaltbar sein ;-)
Hallo, Ich kann grade keinen Firmenvorschlag machen, der Suchwort und meine Lösung dazu lautet "rs23 portserver". Wir haben sowas mehrfach und sogar LAN-Redundant in der Firma im Einsatz, und das ist sehr zuverlässig und es würde wohl in deinem Fall das Problem recht einfach und vorallem schnell und geordnet lösen. Unser Modell in der Fima hat in der Front rj45 Ausgänge. Wenn du nen Typ wissen willst, bitte PN. Gute Nacht. Jan /edit: grade bisschen gegoogelt und nach dem Bild haben wir "DIGI PortServer TS 16". Ob es günstigere Alternativen gibts, und dass du UART«»rs232 noch machen musst, ist natürlich klar. Aber prüfeeinfach mal, was der Markt so hergibt.
:
Bearbeitet durch User
Amateur schrieb: > Tackt Was ist das? Hans M. schrieb: > bis zu 50 UARTs > ... > Packete werden max 100 Byte lang sein und jede 1s gesendet. Also mal nachrechnen: das wären dann 50*100Byte = 5kByte/sec. Mit 50kBit/sec liessen sich die Daten zusammenpacken und über einen einzigen Kanal mit 115kBit/sec z.B. auf einen zentralen Logger übertragen... Amateur schrieb: > Da ich mich mit FPGAs nicht auskenne, kann ich Dir nicht sagen, ob man > 100 unabhängige UARTs reinbrutzeln Warum jetzt 100? Egal, kann man (wie schon gesagt) trotzdem. Und ich würde dann gleich noch ein Autobaud-Feature reinpacken, damit man nicht für jeden Kanal die Baudrate extra einstellen muss. Das geht natürlich nur, wenn das Protokoll bekannt ist...
Die einfache Lösung wäre natürlich einen PC mit 50 seriellen Schnittstellen (z.Bsp mit 4 16-Port Karten) zu verwenden. Ansonsten sollten ein AtMega durchaus eine kleine 2-stellige Anzahl von seriellen Schnittstellen in Software machen können. Das ist halt schwierig und setzt spezialisierte Software voraus. Immerhin, so habe ich gerade gelesen, gibts Vorstellungen was da eigentlich gemultiplext werden soll. Da die Pakete 100 Bytes lang sind muss man natürlich im schlimmsten Falle ein Paket pro Port speichern können, streng genommen sogar 2. Das dürfte bei kleinen Mikrocontrollern der begrenzende Faktor sein. Die Software selbst würde wahrscheinlich so aussehen. Man hat eine ISR die per Timer mit >3*Baudrate aufgerufen wird. Darin führt man für jeden Port einen Zähler der zählt wie weit man im Rahmen (wahrscheinlich hier ein Byte) ist. Dieser Zähler wird am Anfang des Start-Bits auf 0 gesetzt und bei jedem ISR-Aufruf um f erhöht. F ist proportional zur gewünschten Baudrate. Jetzt weiß man durch diesen Zähler bei welchem Bit man ist und kann in der Mitte des Bits den Wert abgreifen. Das macht man für alle Kanäle die man braucht. Ein zweckmäßiger Wert für f ist zum Beispiel Baudrate/ISR-Frequenz*256. Damit hat man die Mitte der Bits immer dann wenn der Rest beim durch 256 teilen 128 ergibt.
:
Bearbeitet durch User
9600 Baud? µC mit vielen I/Os nehmen und Bitbanging betreiben. Du machst an den zugehörigen Ports entsprechendes Oversampling (z.B. 4fach) und erschlägst alles Weitere per Polling und Zustandsmaschine. Timergesteuerte Routine schreibt die aktuellen Werte in 50 Ringpuffer. Dein Main Loop wertet die Ringpuffer aus und schreibt die daraus ermittelten Werte in den Ausgangspuffer. Den wiederum schiebst du dann mit DMA und UART raus. Um jetzt nicht gerade eine Cortex-A zu brauchen, solltest du allerdings die Auswertung intelligent gestalten, d.h. mit Bitoperationen immer gleich acht Kanäle zusammen auswerten. Max
Hans M. schrieb: > Ich bin auf der Suche nach einer Möglichkeit, bis zu 50 UARTs an der TX > Leitung zuzuhören. Die Baudrate kann bis 9600 runter gehen und die > Packete werden max 100 Byte lang sein und jede 1s gesendet. > Allerdings sind die Sender nicht synchron zusammen. Mein Vorschlag: 50 kleine Pics/Tinys/etc nehmen, die Daten zwischenspeichern und mittels Zeitmultiplex oder LIN zur Sammelstelle schicken.
Wenn Deine Systeme in der Lage sind im Fehlerfall noch Daren über die serielle Schnittstelle zu senden, dann können diese Systeme die Daten auch noch selbst speichern. Insofern ist der gesamte Ansatz schwachsinnig.
Hm. Vielleicht doch eher in ein anständiges Entwicklungssystem mit vernünftigem Emulator/Debugger investieren. Denn 50 Testsysteme gleichzeitig laufen zu lassen, nur um einen Programmfehler zu finden, klingt doch eher nach Murks. Oliver
Wie wäre es denn mit einer Lösung in dieser Richtung: http://www.pctestinstruments.com/ Ginge RatzFatz und man hat (fast) alle Geräte synchron im PC und kann die Daten analysieren.
Der ATxmega64A1U hat 8 UARTs und einen USB-Device-Controller. Mit LUFA sollte es relativ einfach sein, daraus ein 8fach CDC-Device zu machen. Davon sieben Stück an einen entsprechenden USB-Hub und Du bist fertig.
So wieder da und danke allen, die sich die Mühe gemacht haben alles zu lesen und darauf hin sachlich Vorschläge brachten ;) Ich fass mal zusammen: Es sind müssen nicht 50 werden, gedacht sind Sets a 10 mit gleicher Konfiguration um ein gezieltes Verdachtsmoment zu bestätigen oder auch nicht. Hardwareaufwand sollte sich in Grenzen halten, also fallen RS232 Portserver mit levelshiftern leider aus. Der Faktor Zeit für die Umsetzung spielt auch eine Rolle, Daher fällt FPGA leider auch aus. Genau wie die Lösungen mit xMCs für xSoft/HardwareUARTs. Wie lange würde es dauern um das zu coden? Vor allem, wenn jede Zeile Code um etwas zu testen, muss selbst auch getestet werden ;) Denk mal es werden die 4x UARTs von Maxim, die Kosten soviel wie 2h coden und STM32discovery zum abholen der FIFOs und schreiben in logfile ist auch in nur 2h gemacht. Bedeutet 1AT und es steht... An die "Murks und Schwachsinn Poster ": Was würdet ihr machen, wenn eure Vorschläge schon versucht wurden und kein Ergebnis geliefert hätten? Wie sprechen hier von einem sporadischem Fehler, welcher beim ersten Auftreten, nicht mal eine Fehlfunktion bewirkt ( auf die man triggern könnte ). Daher die statusdaten um eine Art Verlauf zu bekommen... Bei embedded gibt's leider nicht immer schwarz und weiß :-P @Lothar Iwann hab ich genug Luft um mir die VHDL Geschichte anzuschauen, nehm ich mir schon seit 10Jahren vor :( @Max Seit dem Oben beschrieben Silicon Bug trau ich keinem DMA mehr übern weg ;) Greatings Hans
Die "Murks und Schwachsinn" Poster hätten das Problem schon längst kausal gelöst und sich nicht mit Symptomen und Geisterjagd wie die Ghost Buster beschäftigt. Aber für viele ist ja bekanntlich der Weg das Ziel. Von solchen Mitarbeitern muss man sich irgendwann halt trennen, auch wenn Sie es gut gemeint haben. Das ist die Realität.
Ich verstehe das Vorgehen auch nicht so ganz. Wenn der gesuchte Fehler nicht so schwer ist, dass die Systeme sich komplett aufhängen (sie konnen ja noch per UART was schicken), kannst du dann nicht in jedem System autark erkennen, dass ein Fehler aufgetreten ist, dann z.B. eine LED anknipsen und somit signalisieren, dass auf diesem Gerät der Fehler aufgetreten ist. Im Gerät selbst wird ständig ein Log aufgezeichnet, den du dann von den Gerät mit der leuchtenden LED per UART abholst. Du brauchst dann nur eine Schnittstelle und steckst einfach das Kabel am betreffenden Gerät ein. Also mir erscheint dein Vorgehen etwas aufgeblasen, aber ich kenne auch nicht alle Rahmenbedingungen
Gut wie schon geschrieben, eure Vorschläge zur kausalen Lösung, wurden schon lange erfolglos versucht und noch viele mehr! Es geht nicht nur um Fehlersuche, sondern auch um eine Methode um den Fehler reproduzierbar zu machen. Denn nur dann kann man auch beweisen das die Abstellmaßnahme erfolgreich war. Aber gut es, es gibt leider immer noch arrogante Entwickler, die ihren TestIng nicht zu schätzen wissen... Sein Job is ja die eigenen Unzulänglichkeiten aufzudecken... Aber Hey, das ist nichts persönliches, es hilft allen beteiligten ;) Egal, is OT! Schönes WE zusammen Hans
R. Max schrieb: > Der ATxmega64A1U hat 8 UARTs und einen USB-Device-Controller. 8 UARTs oder 7 UARTs plus einen USB.
Schau hier: http://www.visionsystems.de/produkte/650.html Die Firma hat das auch als 8-Port Version und bietet auch PCI/PCIe Seriell-Karten und Ethernet-seriell-Karten an. Deine Arbeitszeit kostet auch Geld, und das Zeugs hier funktioniert einfach. Auch wenn es einige 100 € sind, ist das vermutlich summa summarum noch die billigste Lösung. fchk
Moxxabox, die hat auch unmengen serieller schnittstellen, einige auch mit linuxtreibern :P
Um auch noch was guenstiges Fertiges ins Spiel zu bringen: Lantronix XPort einfach oder Lantronix Xport AR (Erinnerungspreis AR: Groessenordnung ~35E einzeln) Da bei mir auch Security wichtig ist, stehe ich auf den AR, im Testlabor koennte man ggf. drauf verzichten. Wenn Xport einfach reicht, eine XPort Platine auf Ebay: EUR 17,99 http://www.ebay.de/itm/Lantronix-XPORT-Serial-over-Ethernet-Adapter-/140672265790?pt=DE_Computing_Interne_Netzwerkkarten (Nope, keine privaten oder geschaeftlichen Verbindungen zu dieser Firma!) Wenn man 1-2 Manntage Rumstochern im Nebel vermeiden kann, ist IMHO diese Investition "finanziert". Den notwengigen 10er/48er (Ethernet-)Switch wird die interne IT bestimmt leihweise zur Verfuegung stellen koennen.
>die Karten gehn gar nicht mehr und im Hexeditor wird >wird als erster lesbarer sector der CID angezeigt Ich weiss zu wenig ueber Deine HW/SW, aber der Denkanstoss, "ob das ist SW moeglich sei" wuerde mich ggf. dazu verleiten, die Spannungsversortung direkt an der SD Karte genauer anzusehen.
Wie wärs damit? http://www.ebay.de/itm/16-PORT-USB-AUF-SERIELL-ADAPTE-/380895954113?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item58af2b04c1 http://www.ebay.de/itm/Digi-Ports-16EM-Erweiterung-16-serielle-Ports-1907-/350225757557?pt=DE_Computing_Server&hash=item518b14f575 http://www.ebay.de/itm/Digi-Etherlite-32-Terminal-Server-Serial-Concentrator-32-Ports-GREAT-CONDITION-/121342707566?pt=US_Terminal_Servers&hash=item1c4096c76e
:
Bearbeitet durch User
@Hans M. Kannst du etwas mehr darüber schreiben, wie du mit seriellen Ports den Bug auf der SD-Karte finden willst? Werden dabei Debug-Informationen auf dem seriellen Port raus geschrieben? Vielleicht die SPI-Pakete, die ausgetauscht werden? Ich hätte vermutet, dass ihr vielleicht die Schnittstelle uC <-> SD-Karte genauer unter die Lupe nehmen wollt? Sollen auf der PC-Seite dann alle ankommenden Daten einfach geloggt werden oder wird mit den Daten gleich etwas unternommen? Oder gar das Gerät am seriellen Port gestartet oder gesteuert?
Hallo, also die SPI-to-UART Chips (z.B. von Maxim) sind bzgl. Interruptfägigkeit nicht so einfach zu handhaben. Wenn der µC nur die Aufgabe hat, mehrere UART zu überwachen, dann wäre sowas in der Art vielleicht eine Möglichkeit: http://www.microchip.com/forums/m361004.aspx
Hans M. schrieb: > Doch scheinbar ist es möglich, nach Umstellung auf ElmChan sind in 2 > Wochen gleich 6 SD-Karten auf die gleiche Weise ausgefallen... > Transcent schweigt sich zu dem Fehlerbild leider aus :( Und mit SD-Karten anderer Hersteller tritt das selbe Problem auf?
Bitte 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.