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
@ 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
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.
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.
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.
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.
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
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
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.
@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?
