Liebe Bastler, ich bin Mechatronik-Student und soll im Rahmen eines kleinen Jobs ein Datenbussystem für ein kleineres (~3Kg), unbemanntes Flugzeug aufbauen. Ich bin dabei, ein möglichst robustes, einfaches und idiotensicheres Datenbussystem aufzubauen, mit dem noch viele Leute nach mir weiterarbeiten sollen. Ich bin dabei zu dem Entschluss gekommen, dass ich aufgrund der geringen Übertragungswege, Robustheit, Einfachheit und der ausreichenden Geschwindigkeit den I2C-Datenbus benutzen möchte. Ein Master bildet das zentrale Element und mehrere Slaves (es ist davon auszugehen, das es bis zu 40 werden) sind an diesem angeschlossen. Die Slaves sind wieder einzelne Platinen, auf denen ein oder mehrere Sensoren sitzen. Diese Sensoren könnten zum Beispiel analoge, kapaizitive Sensoren für die Feuchtigkeitsmessung sein. Diese Sensorwerte sollen mit bis zu 100 Hz erfasst werden. Der Master soll sich mit Hilfe eines GPS-Moduls und einem PPS-Signal auf die genaue Sekunde synchronisieren. Danach soll er dann die Daten der Slaves mit der gewünschten Frequenz abfragen. Die große Anforderung ist: Man soll so genau wie möglich sagen können, dass zu diesem definierten Zeitpunkt der Sensorwert gemessen wurde. Und genau da liegt mein Problem.. : Wie kriege ich es hin, möglichst zu einem definierten Zeitpunkt den Sensorwert erfassen zu lassen? Wenn ich den Sensorwert erst bei der Anfrage über I2C erfassen lasse, dann ist es für manche Sensoren wahrscheinlich nicht mehr Präzise genug, denn es kommt das Delay des Masters, bis er die Anfrage stellt und das Delay des Slaves, bis er die Daten empfangen und verarbeitet hat, zusammen. Am elegantesten wäre es ja, wenn die Slaves selber wüssten, wann sie Messen sollen und der Master kurz nach der Messung einfach nur die Werte "aberntet". Das würde ja zum Beispiel gehen, wenn man ein PPS-Signal auf einen weiteren Busstrang legen würde. Nur irgendwie erscheint mir das unglaublich unelegant. Ich würde gerne eine Standard, "Keep it simple and stupid" methode verwenden, nur ich finde dazu nichts passendes, vielleicht fehlen mir aber auch noch die passenden Suchbegriffe. Kennt ihr Anwendungen, wo das Problem gelöst wurde? Irgendwelche Inspirationen und Ideen? Vielen Dank bereits im Voraus! Liebe Grüße, Endy
Sende doch einfach eine Nachricht an alle Slaves ("Genral Call ")dass
sie jetzt messen sollen, und hole dann nacheinander die Daten ab.
PS: hat das Flugzeug einen Elektromotor? Dann würde ich dringend von I2C
abraten wegen der geringen Störsicheheit und völlig fehlenden
Fehlererkennung. CAN z.B. ist da viel sicherer, schneller und auch
einfacher anzuwenden.
Moin, Nimm nicht I2C. Mit bis zu 40 Teilnehmern und Leitungen zwischen Platinen ist der voellig ungeeignet dafuer. Gruss WK
Endy schrieb: > Ich bin dabei zu dem Entschluss gekommen, dass > ich aufgrund der geringen Übertragungswege, Robustheit, Einfachheit und > der ausreichenden Geschwindigkeit den I2C-Datenbus benutzen möchte. > > Ein Master bildet das zentrale Element und mehrere Slaves (es ist davon > auszugehen, das es bis zu 40 werden) sind an diesem angeschlossen. I2C auf Grund der Robustheit? Da würde ich jetzt gerade NICHT I2C verwenden - das ist nicht gerade für seine Störsicherheit (erst recht bei langen Leitungen) bekannt. Ein hängender Slave der den Bus nach Masse zieht und dein ganzer Bus ist tot - nicht unbedingt das, was man haben möchte. Ich würde eher auf RS485 oder gleich CAN mit richtigen CAN-Chips setzen, die Wahrscheinlichkeit, dass sich ein solcher Chip aufhängt ist deutlich geringer. Oder direkt MIL-STD-1553 auch wenn das für dich vermutlich overkill ist. > genau wie möglich Das ist eine verdammt unpräzisie Aussage. So genau wie möglich? Nimm eine Rauchzeichenverbindung und "so genau wie möglich" ist +-10 Sekunden. Nimm I2C und es ist vielleicht +-100ms. Wie genau brauchst du es denn wirklich? Im worst-case würde ich ebenfalls das PPS-Signal an alle Slaves verteilen, der Master kann dann innerhalb einer Sekunde alle Werte sammeln und weiß genau, dass sie bei der letzten 1PPS-Flanke gesampelt wurden. Aber bei > genau wie möglich muss man dann natürlich darauf achten, dass die Leitungen alle gleich lang sind, sonst kommen die Pulse unterschiedlich verzögert bei den Slaves an. Und auf die Interruptlatzen musst du dann auch achten... Aber zumindest die Leitungslänge ist wohl irrelephant, daher solltest du > genau wie möglich spezifizieren.
> Das würde ja zum Beispiel gehen, wenn man ein PPS-Signal auf einen > weiteren Busstrang legen würde. Wen man das verallgemeinert, dann landet man bei: die Slaves müssen über die Systemzeit Bescheid wissen. Wie das dann genau aussieht, ist eine andere Sache. Eine eigene PPS Leitung ist sicherlich eine Möglichkeit. Eine andere wäre, dass der Master die Systemzeit übermittelt und die Slaves eigenständig zumindest kurzfristig eine Uhrzeit mitführen. Natürlich hat man auch hier einen kleinen Delay. Die Frage ist allerdings auch, wie gross der ist und damit auch wie relevant er ist. Ich kann mir nicht vorstellen, dass es systemrelevant ist, die aktuelle Uhrzeit auf die Zehntel Nanosekunde genau zu kennen. Aus dem Bauch raus würde ich mal sagen, Millisekunden sind genau genug. Die sollten sich aber relativ leicht in den Griff kriegen lassen. > Nur irgendwie erscheint mir das > unglaublich unelegant. Irgend einen Mechanismus wirst du aber vorsehen müssen. Allerdings: Nicht überteiben! Leg erst mal fest, wie exakt die Timestamps sein müssen. Daran orientierst du dich. Und nicht daran, was cool klingt. Je genauer die Dinge sein müssen, desto mehr Aufwand muss man treiben. Mit unnötigem Mehraufwand ist aber auch wieder keinem geholfen. Der kostet nur Geld für nichts.
:
Bearbeitet durch User
Genau, das Flugzeug hat auch Elektro-Motoren. Man kann aber I2C, soweit ich weiß, auch mit den richtigen Bausteinen differentiell übertragen und ich würde das bei zu großen Störquellen machen. Was mich stört ist, dass der CAN-Bus für Multi-Master ausgelegt ist, das heißt, dass ich das möglichst simple Protokoll nicht nur auf dem einen Master realisieren müsste, sondern noch mehr Intelligenz in jeden Slave auslagern müsste. Das ganze verkompliziert sich so etwas.
Endy schrieb: > Was mich stört ist, dass der CAN-Bus für Multi-Master ausgelegt ist, das > heißt, dass ich das möglichst simple Protokoll nicht nur auf dem einen > Master realisieren müsste Um die Abwicklung von CAN brauchst du dich nicht gross kümmern, das machen die CAN-Chips von alleine. > sondern noch mehr Intelligenz in jeden Slave > auslagern müsste. Das ganze verkompliziert sich so etwas. Im Slave brauchst du sowieso Intelligenz. Aber das Prinzip von CAN ist ein komplett anderes. Die Idee hinter CAN ist es nicht Master und SLave zu haben. Die Idee hinter CAN ist es, dass jeder der einen Messwert hat (etwas mitteilen will), das einfach in die Welt hinausposaunt. Und derjenige, der sich für diesen Wert interessiert, der holt sich den Wert aus der Message raus. Bei CAN steht die Nachricht im Vordergrund und nicht wer wem etwas mitzuteilen hat. CAN ist gedacht als eine Art elektronische Pinwand, an der jeder seine Ergüsse veröffentlichen kann und wer sich für etwas interessiert, der wertet dann neben der Überschrift auch noch die Details aus. Klar kann man das auch auf ein Master Slave Prinzip umbauen. Aber eigentlich ist das eine Pervertierung des CAN-Prinzips.
:
Bearbeitet durch User
Wegen dem "genau wie möglich". Ich habe im Rahmen meiner letzten Abschlussarbeit an einem Bussystem mit einer RS485 Schnittstelle mitgewirkt, das ganze soll im Nanosekundenbereich genau sein (ja ich weiß, je nach Leitungslänge), dass heißt, es gab jede Sekunde einen Synchronisationspuls und die Slaves haben ihre Schwingung des Oszillators mittels DAC auf die genaue Sekunde aufgeregelt. Mit diesem System "konkurrier" ich gerade. Es ist auch echt super, nur nicht für diese Anwendung, da es einfach zu kompliziert dafür ist und ich weiß, sobald nicht mehr die Leute da sind, die sich mit dem System auskennen, das ganze noch einmal neu gemacht werden muss. Deswegen bin ich auf der ultimativen "so einfach wie möglich" Methode mit möglichst wenig eigenem Protokoll und Bastelpotenzial.
Moin, Endy schrieb: > Deswegen bin ich auf der ultimativen "so einfach wie möglich" Methode > mit möglichst wenig eigenem Protokoll und Bastelpotenzial. Ethernet mit PTP(IEEE1588)? Aber nicht ueber die Preise fuer Switche meckern, wenn's auf die Nanosekunde genau sein soll... Gruss WK
Endy schrieb: > Ich habe im Rahmen meiner letzten Abschlussarbeit an einem Bussystem mit > einer RS485 Schnittstelle mitgewirkt, das ganze soll im > Nanosekundenbereich genau sein (ja ich weiß, je nach Leitungslänge), > dass heißt, es gab jede Sekunde einen Synchronisationspuls und die > Slaves haben ihre Schwingung des Oszillators mittels DAC auf die genaue > Sekunde aufgeregelt. Mit diesem System "konkurrier" ich gerade. Nanosekundenbereich? Kleiner Job? => Schwachsinn. Endy schrieb: > ich bin Mechatronik-Student Schuster bleib bei deinen Leisten!
Ich würde auch nicht I2C benutzen. Wenn Du es differentiell machst, dann hast Du gleich 4 Leitungen und trotzdem noch nicht alle I2C-Fallstricke behoben. Für mich wäre es jedenfalls de Horror, in einem 40-Teilnehmer-System denjenigen zu finden, der das System aktuell blockiert. RS485 ist in einem Single-Master-System eine sehr gute Wahl. CAN ist auch nicht schlecht, da die Multimasterfähigkeit bereits von der Hardware unterstützt wird, verkompliziert sich Dein System damit nicht wirklich. Dein Timing-Problem würde ich mit einer Systemzeit-Msg lösen, die der Master zyklisch sendet. In dieser überträgst Du den aktuellen Systemzeit-Counter des Masters an alle Slaves. Diese können ihren eigenen Systemzeit-Counter damit auf den des Masters synchronisieren. Damit können dann alle Slaves autonom fast zeitgleich Messung starten und danach warten, bis der Master irgendwann diese Werte abholt. Fast zeitgleich bedeutet: Du hast einen Timelag im Master vom Auslesen der Systemzeit bis zum Ausgeben auf die Schnittstelle. Dann kommt die Zeitdauer für die Msg-Übertragung dazu. Und am Schluß müssen Deine Slaves die Zeit-msg (per Interrupt) empfangen und mit der eigenen Systemzeit synchronisieren. Teilweise sind diese Verzögerungszeiten konstant (msg-Übertragungs-Dauer) und Du kannst sie bei der Syncronisierung mit einberechnen. Deshalb ist es wichtig: Ändere Deine Spec von "möglichst genau" in eine definierte Zeitangabe, z.B. +- 1ms (+-100us).... Erst damit kannst Du ernsthaft mit Entwickeln anfangen. Gruß, Stefan
Ich bedanke mich an der Stelle erstmal für die vielen Antworten! Das ist grade sehr hilfreich für mich! derguteweka schrieb: > Ethernet mit PTP(IEEE1588) ..und nicht zu vergessen, möglichst leicht, aber danke für den Tipp! Ihr habt mir den CAN-Bus doch etwas schmackhaft gemacht. Die Lizensgebühren fallen nur für die Chiphersteller an, oder? Ich muss mich mit dem Prinzip etwas anfreunden, dass es nicht so deterministisch ist und das sich die Teilnehmer in die quere kommen können und der eine Teilnehmer verzögert noch einmal senden muss, was aber bei einer geringen Auslastung wahrscheinlich egal ist?! Es bleibt aber immer noch das Kernproblem mit der Synchronisation, beim CAN-Bus müssten ja auch tatsächlich alle Slaves über die genaue Zeit bescheid wissen. Gibt es beim CAN Ansätze, wie das gelöst wird? Mit zeitgenauen Broadcast-Nachrichten? Gibt es sowas?
m.n. schrieb: > Nanosekundenbereich? Kleiner Job? => Schwachsinn. Nein, Abschlussarbeit m.n. schrieb: > Schuster bleib bei deinen Leisten! https://de.wikipedia.org/wiki/Mechatronik
Endy schrieb: > Liebe Bastler, > > ich bin Mechatronik-Student und soll im Rahmen eines kleinen Jobs ein > Datenbussystem für ein kleineres (~3Kg), unbemanntes Flugzeug aufbauen. > Ich bin dabei, ein möglichst robustes, einfaches und idiotensicheres > Datenbussystem aufzubauen, mit dem noch viele Leute nach mir > weiterarbeiten sollen. Ich würde sagen, die haben den falschen für den Job genommen ;-) Deine Einschätzung zu I2C unter den gegebenen Bedingungen ist grundfalsch. Für so eine Job braucht schon sowohl elektrotechnische als auch informationstechnische Kenntnisse. Ein Mechatroniker scheint die beste Wahl gewesen zu sein. Ich würde alles an einen RS232 (besser RS485) hängen. Das ist einfacher und günstiger als CAN, aber wahrscheinlich ausreichend. Natürlich muss man sich für die Adressierung ein eigenes Protokoll ausdenken. Aber das ist sehr einfach. Auch eine Triggerung für eine gemeinsame Messung lässt sich so ohne Zusatzaufwand an alle Teilnehmer gleichzeitig senden. Die Ergebnisse kann man dann nach und nach abholen. Es benötigt wenige Leitungen, ist aber relativ robust. Sogar wenn man "nur" RS232 mit ordentlichen Pegeln (+-10V) nimmt.
:
Bearbeitet durch User
Cyblord ---- schrieb: > Ich würde sagen, die haben den falschen für den Job genommen ;-) > > Deine Einschätzung zu I2C unter den gegebenen Bedingungen ist > grundfalsch. Für so eine Job braucht schon sowohl elektrotechnische als > auch informationstechnische Kenntnisse. Ein Mechatroniker scheint die > beste Wahl gewesen zu sein. Es ist mir eigentlich ziemlich egal, was dazu denkst ;) Wenn Du meinst, an den Beiträgen komplett festzustellen, dass ich ungeeignet bin, auch in informationstechnischer Weise, dann herzlichen Glückwunsch für deine schnelle Auffassungsgabe! Ansonsten wäre es geil, wenn wir zu dem Thema zurückkommen würden :)
Ok, es kam anscheinend noch etwas nach deiner Aussage. Ich kann leider nicht editieren, also ein danke im zweiten Post hinterher.
Bei CAN gibt es sowas, das läuft unter TTCAN. Damit sollte eine Synchronisation im Bereich der CAN-Baudrate möglich sein. Welche mc willst Du verwenden? Und welche genaue Zeitauflösung strebst Du jetzt an? Gruß, Stefan
Cyblord ---- schrieb: > Natürlich muss > man sich für die Adressierung ein eigenes Protokoll ausdenken. Aber das > ist sehr einfach. Wie oft habe ich das schön gehört: "Q931, TCP/IP, WasAuchImmer ..., alles für diese Anwendung zu kompliziert, da mach ich schnell was eigenes, viel einfacheres ..." Und zum Schluß wurde etwas genauso kompliziertes aber schlecht dokumentiertes und im Prinzip unwartbares Trümmerfeld daraus. Da hätte man besser was fertiges nehmen sollen, das auch von vielen Anwendern schon debugged worden ist. MfG Klaus
Klaus schrieb: > Cyblord ---- schrieb: >> Natürlich muss >> man sich für die Adressierung ein eigenes Protokoll ausdenken. Aber das >> ist sehr einfach. > > Wie oft habe ich das schön gehört: > > "Q931, TCP/IP, WasAuchImmer ..., alles für diese Anwendung zu > kompliziert, da mach ich schnell was eigenes, viel einfacheres ..." Quatsch. Das "Protokoll" besteht aus einem Paket mit ein paar Feldern. Eines davon ist eine Adresse. Danach noch Länge und Payload und CRC. Das ist schnell gemacht. Auch in der Praxis habe ich so was schon öfters erfolgreich umgesetzt. In so einem dezidierten einfachen Fall gibt's da keine Probleme und jede Portierung einer bestehenden Lösung wäre schon aufwändiger. Welches bestehende Protokoll würdest DU denn nehmen? CAN ist a.) wie Karl Heinz schon sagte, eher nicht geeignet. Und benötigt trotzdem noch eine Protokollschicht auf höherer Ebene. Man muss sich ID, Adressen und Messages ja auch überlegen und festlegen. Der Einwand wegen Debuggtem Code ist auch Humbug, da man wohl kaum wirklich portiert, sondern nachimplementiert. Aber auch beim portieren können sich Fehler einschleichen. Und gerade dein Beispiel TCP ist ein Paradebeispiel für ein extrem komplexes Protokoll. Für die Anwendung des TO absolut Overkill und führt nur zu Fehlern. Am ehesten noch reine Ethernetframes via RS232/RS485.
:
Bearbeitet durch User
Cyblord ---- schrieb: > Ich würde alles an einen RS232 (besser RS485) hängen. Das ist einfacher > und günstiger als CAN Vielleicht minimal günstiger, aber auf keinen Fall einfacher. Bei CAN mußt Du Dich um nix kümmern, macht alles die Hardware. Der Sender schreibt was in einen Sendepuffer und kriegt nen Interrupt, wenn das fehlerfrei gesendet wurde. Und der Empfänger kriegt nen Interrupt, wenn was in einem Empfangspuffer steht. Der Master kann also senden, wann er lustig ist, ohne Rücksicht auf Fehler, Retries, CRC, Bus frei usw. Dito der Slave. Und zusätzlich kriegen Sender und Empfänger nen Timestamp des Paketes. D.h. der Slave kann in der Antwort mitteilen, wann vorher oder nachher er den Sensor gelesen hat. Diese Zeitdifferenz muß dann nur noch der Master zu seinem Timestamp der Anfrage addieren. Das ist bei 20MHz CPU-Takt auf 50ns genau, sollte wohl reichen.
@Peter: Hast Du das mit dem Timestamp schon einmal ausprobiert? Mit welchem Controller? Beim STM32Fxxx habe ich das Thema nur in den Errata gefunden. Beim Durchlesen des STM32Fxxx CAN-Manuals hatte ich den Eindruck, daß ein Zugriff auf den entsprechenden CAN-Timer vergessen wurde ... Gruß, Stefan
Habe dies schon mal implementiert. Für gewisse Systeme ist der lin bus vorteilhaft, Einfache UC, kein Quarz nötig, deterministisches timing.
Stefan schrieb: > Hast Du das mit dem Timestamp schon einmal ausprobiert? Mit welchem > Controller? Wir benutzen den AT90CAN128: "The capture of the timer value is done in the MOb which receives or sends the frame. All managed MOb are stamped, the stamping of a received (sent) frame occurs on RxOk (TXOK)." Der kleinste Vorteiler ist 8, d.h. bei 16MHz erreicht man 0,5µs Auflösung und 30ms Zählweite. Sinnvoll ist aber nur eine Auflösung >=Baudrate, d.h. bei 500kBit 2µs (= 130ms Zählweite).
:
Bearbeitet durch User
Da du, Endy, ja auch auf der Suche nach Inspirationen und Ideen bist folgender Beitrag: Wähle ein differentiell getriebener Bus (RS485), verzichte auf aufwändige Fehlererkennung oder gar Korrektur und nutze die Paritätsprüfung des U(S)ARTs als minimale Absicherung. Dein Protokoll sollte als Anfrage (1 Byte) die Adresse und als Antwort lediglich den Wert (vielleicht 1 bis 4 Byte) vorsehen. Die adressierbaren Slaves behandeln ihre UART-Kommunikation interrupt-getrieben, während die Messwerte im Polling-Betrieb ermittelt werden (Der Fokus liegt also darauf die Daten nach einer Anfrage schnellstmöglich zu senden, lässt sich sicherlich auch mit Interrupt Prioritäten lösen). Dieses einfache Konzept für Slaves dürfte auch für spätere Dritte verständlich sein. Die Anforderung der Zeitgenauigkeit wird vollständig in deinen Master verlagert in dem du darauf ein Echtzeitbetriebssystem laufen lässt (nicht vom Begriff Echtzeitbetriebssystem erschlagen fühlen). Da gibt es z.B. das freie und bereits auf eine Vielzahl von Plattformen portierte FreeRTOS. Ein solches Echtzeitbetriebssystem schafft zusätzlich Struktur (für spätere Dritte). Für jede Sensorabfrage wird ein Task definiert mit einer harten (oder weichen) Bedingung. Diese Bedingung ist dann dein (festes) Delta für deine genaue Systemzeit bzw. Timestamp zum Messwert. Dieses Delta zu ermitteln ist zugegebenermaßen nicht einfach. Eine Plausibilitätsprüfung der Messwerte in den einzelen Tasks ist ebenfalls möglich. Auch wenn der Vorschlag nicht das Gesuchte ist (ist schwierig Anforderungen abzuleiten mit "so zeitgenau wie möglich") lohnt es sich sicherlich darüber nachzudenken wohin man die geforderten Komplexitäten packen möchte.
Endy schrieb: > Ich habe im Rahmen meiner letzten Abschlussarbeit an einem Bussystem mit > einer RS485 Schnittstelle mitgewirkt, das ganze soll im > Nanosekundenbereich genau sein 1GHz RS485 klingt recht sportlich. Erzähl mal, wie das gehen soll.
Hallo Endy, die Laufzeiten der verschiedenen Bussysteme sind immer vom Takt abhängig. Je höher der Takt, so sensibler wird er. Natürlich mit entsprechender Hardware kann sehr viel abgefangen werden. Ist halt eine Kostenfrage und natürlich auch die entsprechende Software muss stimmen. Nach vielen Test habe ich mich für I²C entschieden. Sind die Leitungen SDA /SCL nicht größer 2 Meter, benötigt man auch kein Bustreiber IC, mit sind auch 100 Meter kein Problem. Was aber oft nicht beachtet wird sind die „Einschwingzeiten“ für Analogsensoren. Wo ist der Sinn, die Sensoren alle µs abzufragen, wenn diese 10 µs oder bis 100 ms benötigen um diese als Digitalwerte bereit zu stellen. Die mir bekannten, Analogsensoren, benötigen immer ein Start für Neumessung. Haben ja meist ein kleinen RAM der die letzte Messung speichert. Meine Testplatine mit 40 I²C Teilnehmer. 16x Digital IC, 8x Analog IC, 8x Digital Poti IC und 4x Eeprom IC. Benötigen mit Bustakt 100kHz ca. 2ms um Daten sauber auf dem Bus zu legen um die Daten für Auswertungen zu speichern. Mit Takt 400kHz natürlich schneller. Aber einige meiner IC sind überfordert. Auch nach viele Softwareoptimierungen, muss ich sagen irgendwo ist es Schluss für den Amateur. Mein Rat: Las dich nicht Entmutigen. Somit folge den Rat der Profis, wenn Du einer dieser werden möchtest. Mit freundlichen Grüßen fredlich
Cyblord ---- schrieb: > Quatsch. ... Wie oft habe ich das schon gehört, und eigentlich immer hat es sich am Ende des Tages als falsch herausgestellt. Zum Schluß mussten dann alle Funktionen eines "richtigen" Protokolls nachimplementiert werden, wie Handshake, Resynchronisation, Timeouts etc. Und aus "schnell gemacht" wurde dann ein großes Projekt. Die von mir genannten Protokolle waren nur als Beispiel gedacht und nicht als Vorschlag für den TO. Und hier Cyblord ---- schrieb: > Der Einwand wegen Debuggtem Code ist auch Humbug hast du mich missverstanden. Es ging mir nicht um Debuggten Code, sondern um ein Debuggtes Protokoll, dokumentiert und getestet von anderen als dem Entwickler selbst. MfG Klaus
ähm... du hast als Beispiel einen Feuchtesensor genannt. Wieviele Sekunden Ansprechzeit hat der denn? Oder sind es Minuten? Welche Sensoren werden denn verbaut werden, die weniger als ein paar 100ms Ansprechzeit haben? Vielleicht musst du ja nicht mit deinem früheren Echtzeitsystemen "konkurrieren", sondern machst es so genau wie nötig / sinnvoll? DAS ist die Kunst des Ingenieurs...
Für einen Modellflieger (?) finde ich ein Bussystem eingetlich unpassend. Ein Board pro Bereich, z.B. eines hinten und eins vorn, das alle notwendigen Sensoren plus Reserve ansprechen können, wäre denke ich einfacher und vor allem gewichtstechnisch leichter zu realisieren. Statt jeweils ein Sensorknoten mit Controller, Busanbindung, eventuell Spannungsversorgung hättest du dann nur die Verdrahtung vom Sensor zur Hauptplatine. Die Software wäre dann auch überschaubarer, da der Prozessor dann genau ein Timing für die direkt angeschlossenen Sensoren einhalten könnte.
Servus, ich kenne das Problem nur mit einer geringfügig höheren Datenrate der "Sensoren" da ich mit ~2Gsps Abtasten muss. Die Messzeitpunke müssen halt zu einander passen. zu "so genau wie möglich" wäre im low cost Bereich sowas: http://www.spectratime.com/products/isync/ zu haben. 10Mhz Referenz zu den "Slaves"verteilen, OCVCXO auf die 10Mhz referenziert zur Systemtakt Generierung für einen FPGA her nehmen. Vom FPGA differentiell und parallel die Daten von den Slaves holen. So könnte das relativ kohärent laufen. Wenn du alle Komponenten auf die 10Mhz Referenz gelockt sind und einen Trigger für alle nutzt, kannst du den statischen Fehler der durch die unterschiedlichen Messzeiten entsteht raus rechnen. Relativ simpel: Trigger an -> alle messen -> nach der definierten zeit t werden alle werte abgeholt. Vom Zeitpunkt t die vorher vermessene post processing time abziehen und du hast deine Messzeitpunkte. Timestamp vom GPS dran und fertig. Über Sinn oder Unsinn der Lösung brauchen wir nicht zu diskutieren solange wir nicht mal die Frage kennen.
Klaus schrieb: > Cyblord ---- schrieb: > Die von mir genannten Protokolle waren nur als Beispiel gedacht und > nicht als Vorschlag für den TO. Und hier Das hilft dem TO aber nicht. Und Offtopic ist es somit auch. Du willst hier nur den Oberlehrer raushängen. Eine Lösung bringst du nicht. Und deine Argumente sind eher dürftig. Mehr als "Habe ich schon tausend mal gesehen", "ist immer so" kommt von dir ja nicht. Glaub mir, ich habe auch schon genug gesehen und genug solcher Einfachst-Protokolle erfolgreich umgesetzt. Also Beweis durch Alter zieht nicht. > hast du mich missverstanden. Es ging mir nicht um Debuggten Code, > sondern um ein Debuggtes Protokoll, dokumentiert und getestet von > anderen als dem Entwickler selbst. Das mag ja sein, bei einfachen Protokollen ist aber schnell überschaubar ob es korrekt arbeitet. Und ein sehr einfaches Protokoll reicht dem TO hier. Außerdem führst du deine eigene Argumentation ad absurdum, wenn du auf ein bekanntes Protokoll zurückgreifen willst, aber nicht ein passendes nennen kannst. Gerade im hier angesprochenen Modellbaubereich, beim eigentlichen Funk, aber mehr noch bei internen Bussen für Telemetriesensoren, kocht jeder Hersteller auch sein Süppchen. Und die funktionieren tadellos. Aber natürlich Wissen die Hersteller es nicht so gut wie du.
:
Bearbeitet durch User
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.