OpenTX - Multiplex MLINK Konverter
- Ersteller Donaufisch66
- Erstellt am
Super, freut mich zu hören. Vielen Dank für die Hilfe und Mühen.
Sobald, das funktionierende Modul von kalle habe, werde ich gleich berichten. Gut zu wissen, dass es bei anderen mit gleicher Fernsteuerung intern und extern einwandfrei geht.
Schönen Sonntag allen und Grüße Andreas
Sobald, das funktionierende Modul von kalle habe, werde ich gleich berichten. Gut zu wissen, dass es bei anderen mit gleicher Fernsteuerung intern und extern einwandfrei geht.
Schönen Sonntag allen und Grüße Andreas
Reinhardt Werbik
User
Extern ( D Cable Option) geht bei der 2019er Taranis nicht mehr, da dort ein permanenter S-Port im Batterieschacht sitzt.
(Companion suggeriert da leider was anderes, da nicht mit dem Sender übereinstimmend in diesem Punkt.)
Mit meinem Adapter habe ich die drei benötigten Modulschacht-Pins mit dem M-Link Modul verbunden und den S-Port Pin separat herausgeführt.
Ich stelle später noch die Bilder hier ein, die ich gemacht habe.
Jetzt aber erst mal ein schöner Winterspaziergang, und zwar dort, wo nicht die ganzen Wahnsinnigen alles überlaufen.
(Companion suggeriert da leider was anderes, da nicht mit dem Sender übereinstimmend in diesem Punkt.)
Mit meinem Adapter habe ich die drei benötigten Modulschacht-Pins mit dem M-Link Modul verbunden und den S-Port Pin separat herausgeführt.
Ich stelle später noch die Bilder hier ein, die ich gemacht habe.
Jetzt aber erst mal ein schöner Winterspaziergang, und zwar dort, wo nicht die ganzen Wahnsinnigen alles überlaufen.
Reinhardt Werbik
User
So, nach einem ausgedehnten Spaziergang durch den Schnee hier nun die versprochenen Bilder.
Mit diesem Adapter habe ich die Modulschacht-Pins nach draußen verlegt.
Kleine Anekdote dazu:
Die normalen Pfostenleisten sind zu kurz, um das M-Link Modul zu kontaktieren.
Ich wollte schon entnervt aufgeben, bis mir einfiel, dass ich doch da ein paar lange Pfostenverbinder rumliegen habe.
Diese habe ich noch als Gymnasiast bei einer Elektronica Messe abgestaubt, sprich vor über 40 Jahren.
Man sieht also, es lohnt sich, auch die kleinsten Dinge aufzuheben, irgendwann braucht man sie.
So schaut der gesamte Versuchsaufbau aus.
Der Konverter läuft auf einem 8 MHz Wattuino Board und ist mit Pfostenleisten bestückt, damit er auf einem Steckboard platziert werden kann.
Er wird vom M-Link Modul mit 3,3 V versorgt.
Und das hier sieht man auf dem Display der Taranis nach der Sensorsuche.
A1 ist die Empfängerspannung und ist mit einem Skalierungsfaktor von 25,5 versehen, damit der angezeigte Wert stimmt.
Ich habe noch einen Strom- und einen Spannungssensor angesteckt, damit man ein paar Werte mehr sieht.
000F sind die Alarm Flags, der Wert 4 bedeutet, dass das Alarm-Flag der MSB Adresse 2 gesetzt ist (Bit 2 -> Wert 4).
Das kommt vom Spannungssensor, der natürlich 0 V liefert, wenn nichts weiter angeschlossen ist.
Also nur Mut Andreas, es besteht Hoffnung.
Mit diesem Adapter habe ich die Modulschacht-Pins nach draußen verlegt.
Kleine Anekdote dazu:
Die normalen Pfostenleisten sind zu kurz, um das M-Link Modul zu kontaktieren.
Ich wollte schon entnervt aufgeben, bis mir einfiel, dass ich doch da ein paar lange Pfostenverbinder rumliegen habe.
Diese habe ich noch als Gymnasiast bei einer Elektronica Messe abgestaubt, sprich vor über 40 Jahren.
Man sieht also, es lohnt sich, auch die kleinsten Dinge aufzuheben, irgendwann braucht man sie.
So schaut der gesamte Versuchsaufbau aus.
Der Konverter läuft auf einem 8 MHz Wattuino Board und ist mit Pfostenleisten bestückt, damit er auf einem Steckboard platziert werden kann.
Er wird vom M-Link Modul mit 3,3 V versorgt.
Und das hier sieht man auf dem Display der Taranis nach der Sensorsuche.
A1 ist die Empfängerspannung und ist mit einem Skalierungsfaktor von 25,5 versehen, damit der angezeigte Wert stimmt.
Ich habe noch einen Strom- und einen Spannungssensor angesteckt, damit man ein paar Werte mehr sieht.
000F sind die Alarm Flags, der Wert 4 bedeutet, dass das Alarm-Flag der MSB Adresse 2 gesetzt ist (Bit 2 -> Wert 4).
Das kommt vom Spannungssensor, der natürlich 0 V liefert, wenn nichts weiter angeschlossen ist.
Also nur Mut Andreas, es besteht Hoffnung.
Hallo zusammen,
Hallo Kalle und Reinhardt.
Heute ist Post gekommen (herzlichen Dank nochmals) und super Nachrichten: Der Konverter von Kalle funktioniert bei mir einandfrei *voll cool.
Fernsteuerung und mein HFMG3-Modul sind somit zum Glück OK
Jetzt kann ich beruhigt auf Fehlersuche gehen.
Danke und Schöne Grüße Andreas
Hallo Kalle und Reinhardt.
Heute ist Post gekommen (herzlichen Dank nochmals) und super Nachrichten: Der Konverter von Kalle funktioniert bei mir einandfrei *voll cool.
Fernsteuerung und mein HFMG3-Modul sind somit zum Glück OK
Jetzt kann ich beruhigt auf Fehlersuche gehen.
Danke und Schöne Grüße Andreas
Reinhardt Werbik
User
Hallo zusammen,
na da bin ich ja froh, dass unser Motto gerettet ist.
Super, dass es jetzt endlich läuft.
Die Frage ist natürlich, wo vorher das Problem lag, vielleicht einfach ein defektes Controller-Board?
@kalle:
Ich habe auch gute Nachrichten, das Portieren des Codes auf den ATtiny 841 ist deutlich weniger Aufwand als befürchtet.
Die Verwendung des Pin Change Interrupts statt des externen Interrupts (wegen dem Pull-Up auf dem Nanite Board) ist kein großes Problem.
Den Rest hatte ich ja schon mehr oder weniger fertig.
Ich denke, es wird in absehbarer Zeit ein HEX File zum Testen geben (deutlich vor dem Ende meines Arbeitslebens).
na da bin ich ja froh, dass unser Motto gerettet ist.
Super, dass es jetzt endlich läuft.
Die Frage ist natürlich, wo vorher das Problem lag, vielleicht einfach ein defektes Controller-Board?
@kalle:
Ich habe auch gute Nachrichten, das Portieren des Codes auf den ATtiny 841 ist deutlich weniger Aufwand als befürchtet.
Die Verwendung des Pin Change Interrupts statt des externen Interrupts (wegen dem Pull-Up auf dem Nanite Board) ist kein großes Problem.
Den Rest hatte ich ja schon mehr oder weniger fertig.
Ich denke, es wird in absehbarer Zeit ein HEX File zum Testen geben (deutlich vor dem Ende meines Arbeitslebens).
Eher unwahrscheinlich. Das würde heißen, dass meine beiden Arduino-Boards 8 Mhz und 16 Mhz defekt wären.
Eher klappt bei mir das Flashen nicht. Oder am Bootloader ist was faul. Dachte ich hätte im Thread etwas bei den Pro Minis gelesen. Muss mich damit mal näher beschäftigen, vllt mal mit einem anderen Programm als der Arduino IDE versuchen...
Oder mein Ground auf dem Arduino vertauschen und beide anschließen? Das wäre das einzige was mir noch einfällt, mit Ausnahme eben neuen und anderen Arduino versuchen...
Eher klappt bei mir das Flashen nicht. Oder am Bootloader ist was faul. Dachte ich hätte im Thread etwas bei den Pro Minis gelesen. Muss mich damit mal näher beschäftigen, vllt mal mit einem anderen Programm als der Arduino IDE versuchen...
Oder mein Ground auf dem Arduino vertauschen und beide anschließen? Das wäre das einzige was mir noch einfällt, mit Ausnahme eben neuen und anderen Arduino versuchen...
Kurze Zwischenfrage. Das flashen der Hex-Datei mit der Arduino IDE funktioniert doch nicht, oder?
kalle123
User
So, dann hat sich das ja gelohnt, das ich mich am Samstag noch mit dem Brief aufs Rad und zur Post begeben hab 
.
@Claus Eckert.
Das ist eine alte Methode
https://forum.arduino.cc/index.php?topic=410618.0
Ich flash momentan aber sowohl die Pro minis als auch den ATTiny über die Kommandozeile aus der IDE per USBasp ISP Progger ohne bootloader auf die Dinger. Ob ich jetzt vier Strippen für nen FTDI oder CP2102 an den Pro mini dran hänge oder die sechs vom Progger ....
Geht dann hierüber
und dann zuerst 'BLINK' und dann auch 'Anpassung der Kommandozeile' mit den gewünschten hex Code.
Aber zu den Pro minis noch mal. Hab letztens welche auf den Tisch bekommen, sahen genau so aus, nur verhielten die sich etwas sonderbar .... Stellte sich dann raus, da waren keine ATMEL 328P drauf, sondern LGT8F328P.
cu KH
.@Claus Eckert.
Das ist eine alte Methode
https://forum.arduino.cc/index.php?topic=410618.0
Ich flash momentan aber sowohl die Pro minis als auch den ATTiny über die Kommandozeile aus der IDE per USBasp ISP Progger ohne bootloader auf die Dinger. Ob ich jetzt vier Strippen für nen FTDI oder CP2102 an den Pro mini dran hänge oder die sechs vom Progger ....
Geht dann hierüber
und dann zuerst 'BLINK' und dann auch 'Anpassung der Kommandozeile' mit den gewünschten hex Code.
Aber zu den Pro minis noch mal. Hab letztens welche auf den Tisch bekommen, sahen genau so aus, nur verhielten die sich etwas sonderbar .... Stellte sich dann raus, da waren keine ATMEL 328P drauf, sondern LGT8F328P.
cu KH
Hallo zusammen,
gerade erst gesehen, das wieder viel neues kam (warum bekomme ich manchmal keine Nachricht über neue Threads....).
Wie versprochen anbei eine Zip Datei mit den Sourcen, unterschieden für 8MHz/16Mhz, mit/ohne ID's und ATtiny nur über 3 Defines. Das geht aus dem .ini File (für PlatformIO) hervor bzw. aus den Files.
Kalle,
ein Hex-File für den ATtiny mit FRSky ID's hänge ich auch noch an.
Viele Grüße
Ralf
gerade erst gesehen, das wieder viel neues kam (warum bekomme ich manchmal keine Nachricht über neue Threads....).
Wie versprochen anbei eine Zip Datei mit den Sourcen, unterschieden für 8MHz/16Mhz, mit/ohne ID's und ATtiny nur über 3 Defines. Das geht aus dem .ini File (für PlatformIO) hervor bzw. aus den Files.
Kalle,
ein Hex-File für den ATtiny mit FRSky ID's hänge ich auch noch an.
Viele Grüße
Ralf
kalle123
User
Hi Ralf.
Was hast du denn in https://www.rc-network.de/account/preferences gesetzt?
Danke dir für die hex Files. Reinhardt schaut sich die sicher auch an.
@Claus Eckert
Noch ein Punkt zum Flashen über die Arduino IDE. Da brauchst du dich als Einsteiger nicht mit solchen Dingen wie Fuses zu beschäftigen. Da kümmert sich die IDE drum.
@Alle.
Nur, was da bei Andreas falsch gelaufen ist ???? Beißt sich Reinhardts Code mit dem bootloader?
Zumindest sind Sender und die beiden HFMG3 Module ok.
cu KH
Was hast du denn in https://www.rc-network.de/account/preferences gesetzt?
Danke dir für die hex Files. Reinhardt schaut sich die sicher auch an.
@Claus Eckert
Noch ein Punkt zum Flashen über die Arduino IDE. Da brauchst du dich als Einsteiger nicht mit solchen Dingen wie Fuses zu beschäftigen. Da kümmert sich die IDE drum.
@Alle.
Nur, was da bei Andreas falsch gelaufen ist ???? Beißt sich Reinhardts Code mit dem bootloader?
Zumindest sind Sender und die beiden HFMG3 Module ok.
cu KH
Zuletzt bearbeitet:
Reinhardt Werbik
User
Hallo zusmmen,
ich habe bisher nur einen kurzen Blick auf Ralf's Source Code geworfen, hier ein paar Anmerkungen dazu.
Ich werde im Gegensatz zu ihm erstmal die t841 Version in separaten Source Files halten (ausgenommen natürlich die Files, die gleich sind).
Die Unterscheidung zwischen 8/16 MHz, mit/ohne FrSky IDs, und evtl. andere mache ich bereits in meinem Master-Projekt per #define Optionen.
Ob ich da dann auch unterschiedliche Controller abdecke, kann ich jetzt noch nicht sagen.
Generell bin ich keine großer Fan davon, da es den Code leicht unübersichtlich macht.
Wenn am Ende die Unterschiede gering genug sind, werde ich das vielleicht in Betracht ziehen.
Einige Änderungen kann ich auf die schnelle nicht nachvollziehen, ich habe den Eindruck, dass ich bei mir mit weniger Unterschieden auskomme.
Das mag aber teilweise auch eine persönliche Präferenz sein.
@Ralf:
Ich würde vorschlagen, dass Du nicht einfach meine Versionsnummern weiterzählst.
Das kann irgendwann zu Verwirrung führen, da ich natürlich Deine Nummerierung in meinem Master Projekt nicht übernehmen werde.
Es sind ja andere Änderungen als die, die ich mache.
Du solltest entweder Deine Versionsnummern ganz anders gestalten, oder Du gibst den Dateien einen anderen Namen bzw. Namenszusatz.
Dann kratzen wir uns in zwei Jahren nicht den Kopf darüber, warum unterschiedliche Dateien dieselbe Versionsnummer haben.
Zum Problem von Andreas:
Das einzige Problem, das ich bisher mit Bootloadern hatte, besteht darin, dass die Übergabe an die Applikation nicht funktioniert hat.
Der Konverter hat dann gar nichts gemacht, obwohl das Programm korrekt geladen war.
Aber bei Andreas blinkt der Konverter ja richtig, ein sicheres Zeichen, dass das Programm läuft.
Soviel zunächst, jetzt habe ich leider eine längliche Telecon (Home Office).
ich habe bisher nur einen kurzen Blick auf Ralf's Source Code geworfen, hier ein paar Anmerkungen dazu.
Ich werde im Gegensatz zu ihm erstmal die t841 Version in separaten Source Files halten (ausgenommen natürlich die Files, die gleich sind).
Die Unterscheidung zwischen 8/16 MHz, mit/ohne FrSky IDs, und evtl. andere mache ich bereits in meinem Master-Projekt per #define Optionen.
Ob ich da dann auch unterschiedliche Controller abdecke, kann ich jetzt noch nicht sagen.
Generell bin ich keine großer Fan davon, da es den Code leicht unübersichtlich macht.
Wenn am Ende die Unterschiede gering genug sind, werde ich das vielleicht in Betracht ziehen.
Einige Änderungen kann ich auf die schnelle nicht nachvollziehen, ich habe den Eindruck, dass ich bei mir mit weniger Unterschieden auskomme.
Das mag aber teilweise auch eine persönliche Präferenz sein.
@Ralf:
Ich würde vorschlagen, dass Du nicht einfach meine Versionsnummern weiterzählst.
Das kann irgendwann zu Verwirrung führen, da ich natürlich Deine Nummerierung in meinem Master Projekt nicht übernehmen werde.
Es sind ja andere Änderungen als die, die ich mache.
Du solltest entweder Deine Versionsnummern ganz anders gestalten, oder Du gibst den Dateien einen anderen Namen bzw. Namenszusatz.
Dann kratzen wir uns in zwei Jahren nicht den Kopf darüber, warum unterschiedliche Dateien dieselbe Versionsnummer haben.
Zum Problem von Andreas:
Das einzige Problem, das ich bisher mit Bootloadern hatte, besteht darin, dass die Übergabe an die Applikation nicht funktioniert hat.
Der Konverter hat dann gar nichts gemacht, obwohl das Programm korrekt geladen war.
Aber bei Andreas blinkt der Konverter ja richtig, ein sicheres Zeichen, dass das Programm läuft.
Soviel zunächst, jetzt habe ich leider eine längliche Telecon (Home Office).
kalle123
User
@AndreasN
Dass es bei dir nicht hin gehauen hat, geht mir nicht aus dem Kopf.
Ein paar Punkte sind mir da eingefallen.
- Ich schreib, vier Kabel zwischen USB Uart und Pro mini (Vcc, Gnd, RX und TX). Das kann funktionieren, muss aber nicht.
Korrekt ist das hier https://www.google.com/search?q=arduino+pro+mini+programmieren&tbm=isch&source=iu&ictx=1&fir=K9ph8UHRFL8eRM%2C8JWpFYbe88ktlM%2C_&vet=1&usg=AI4_-kREHoRNfPBr9qcddQtvGrIAFUkXVQ&sa=X&ved=2ahUKEwi1yJ-9vpjuAhV7DWMBHZd1CJkQ9QF6BAgFEAE&biw=1181&bih=728#imgrc=K9ph8UHRFL8eRM
Die Pinauslegung bei den Uarts ist sehr unterschiedlich und auch bei den Pro minis unterscheidet sich die 6 Schnittstellenkontakte in Reihenfolge und Belegung teils ziemlich. Ich kenne das und denke da nicht mehr groß drüber nach.
Hab die Situation Uart <> Pro mini gestern und heute morgen durchgespielt.
Sauber angeschlossen und das Aufspielen des hex Files per geänderter Kommandozeile kein Problem.
- Jetzt weiß ich nicht, wie viel du schon vorher mit Arduinos zu tun hattest?
Drum schreibe ich, nimm einen UNO (kostet bei ebay ~6€) oder zumindest einen Nano. Du hast da die o.a. Problematik nicht. Und schließe EXTERN an, also über das Batteriefach. Du hast schnell ein Erfolgserlebnis und schaffst bei dir Vertrauen.
- Wenn du da angelangt bist, dann kannst du auf nen Pro mini gehen. Je nach Gusto dann 5V/16MHz oder 3V/8Mhz für 'Mutige'
. Aber möglichst auch erst extern.
- Und danach, dann mach den HFMG3 auf, wenn es denn so sein soll.
Aber ich glaube, wir mache auf das Andreas Phänomen/Problem einfach mal 'den Deckel drauf'!
Nix für ungut - KH
PS. Seh gerade, Reinhardt hat geschrieben.
Ich hatte vor dem Cut 1½ Jahre Homeoffice und schon mal 'vorsichtshalber' getestet.
Bis jetzt geht es gut!
Dass es bei dir nicht hin gehauen hat, geht mir nicht aus dem Kopf.
Ein paar Punkte sind mir da eingefallen.
- Ich schreib, vier Kabel zwischen USB Uart und Pro mini (Vcc, Gnd, RX und TX). Das kann funktionieren, muss aber nicht.
Korrekt ist das hier https://www.google.com/search?q=arduino+pro+mini+programmieren&tbm=isch&source=iu&ictx=1&fir=K9ph8UHRFL8eRM%2C8JWpFYbe88ktlM%2C_&vet=1&usg=AI4_-kREHoRNfPBr9qcddQtvGrIAFUkXVQ&sa=X&ved=2ahUKEwi1yJ-9vpjuAhV7DWMBHZd1CJkQ9QF6BAgFEAE&biw=1181&bih=728#imgrc=K9ph8UHRFL8eRM
Die Pinauslegung bei den Uarts ist sehr unterschiedlich und auch bei den Pro minis unterscheidet sich die 6 Schnittstellenkontakte in Reihenfolge und Belegung teils ziemlich. Ich kenne das und denke da nicht mehr groß drüber nach.
Hab die Situation Uart <> Pro mini gestern und heute morgen durchgespielt.
Sauber angeschlossen und das Aufspielen des hex Files per geänderter Kommandozeile kein Problem.
- Jetzt weiß ich nicht, wie viel du schon vorher mit Arduinos zu tun hattest?
Drum schreibe ich, nimm einen UNO (kostet bei ebay ~6€) oder zumindest einen Nano. Du hast da die o.a. Problematik nicht. Und schließe EXTERN an, also über das Batteriefach. Du hast schnell ein Erfolgserlebnis und schaffst bei dir Vertrauen.
- Wenn du da angelangt bist, dann kannst du auf nen Pro mini gehen. Je nach Gusto dann 5V/16MHz oder 3V/8Mhz für 'Mutige'
. Aber möglichst auch erst extern.- Und danach, dann mach den HFMG3 auf, wenn es denn so sein soll.
Aber ich glaube, wir mache auf das Andreas Phänomen/Problem einfach mal 'den Deckel drauf'!
Nix für ungut - KH
PS. Seh gerade, Reinhardt hat geschrieben.
Ich hatte vor dem Cut 1½ Jahre Homeoffice und schon mal 'vorsichtshalber' getestet.
Bis jetzt geht es gut!
Zuletzt bearbeitet:
Reinhardt Werbik
User
Hallo zusammen,
jetzt habe ich doch glatt beim Anschauen von Ralfs Code einen Fehler in meiner t841er Version gefunden.
Jetzt ist der Code aber erstmal komplett, kompiliert und auf das Nanite Board geladen.
Das hat ein paar Anläufe gebraucht, da das alles schon Jahre her ist mit dem Nanite Board.
Der Micronucleus Bootloader hat die Eigenschaft, dass er nicht automatisch startet, sondern per Reset aktiviert werden muss.
Wer soll denn das nach Jahren noch wissen, aber Gottseidank gibt es ja heute das Internet.
Aber jetzt ist der Konverter drauf und blinkt fröhlich die Startsequenz.
Ich muss dann als nächstes mal den Oszi auspacken, um den Vorladewert für den SW UART Timer des M-Link Interfaces zu ermitteln.
Mal schauen, ob ich das am Wochenende hinkriege.
jetzt habe ich doch glatt beim Anschauen von Ralfs Code einen Fehler in meiner t841er Version gefunden.
Jetzt ist der Code aber erstmal komplett, kompiliert und auf das Nanite Board geladen.
Das hat ein paar Anläufe gebraucht, da das alles schon Jahre her ist mit dem Nanite Board.
Der Micronucleus Bootloader hat die Eigenschaft, dass er nicht automatisch startet, sondern per Reset aktiviert werden muss.
Wer soll denn das nach Jahren noch wissen, aber Gottseidank gibt es ja heute das Internet.
Aber jetzt ist der Konverter drauf und blinkt fröhlich die Startsequenz.
Ich muss dann als nächstes mal den Oszi auspacken, um den Vorladewert für den SW UART Timer des M-Link Interfaces zu ermitteln.
Mal schauen, ob ich das am Wochenende hinkriege.
Reinhardt Werbik
User
A0 für MPX und A1 für FrSky habe ich auch so vorgesehen und werde ich auch so lassen.
Der LED Ausgang liegt natürlich auf dem Port, wo auf dem Nanite Board die Status LED angeschlossen ist (Pin B2).
Da Du keine Status LED auf Deinem Board hast, kannst Du B2 für eine externe LED verwenden.
Wenn noch ein zweiter LED Ausgang gebraucht wird, würde ich wahrscheinlich A7 nehmen, aber momentan sehe ich keinen Grund dafür.
Der LED Ausgang liegt natürlich auf dem Port, wo auf dem Nanite Board die Status LED angeschlossen ist (Pin B2).
Da Du keine Status LED auf Deinem Board hast, kannst Du B2 für eine externe LED verwenden.
Wenn noch ein zweiter LED Ausgang gebraucht wird, würde ich wahrscheinlich A7 nehmen, aber momentan sehe ich keinen Grund dafür.
Hallo,
ich hätte da mal eine Frage rein theoretischer Natur.
Der Adapter in Form des µC ist doch nur ein reiner Protokoll-Konverter - oder?
So wie ich das sehe, bringt das MLink-Modul die Daten ja als Onewire, S-Port ist das aber auch (bei den anderen weiß ich es nicht).
Somit wäre es doch auch möglich die µC Hardware einzusparen und die Konvertierung als Fork oder so in OTX direkt zu implementioeren.
Oder hab ich da was übersehen?
S-Port ist sicher eine feine Sache (FrSky bringt ja schon den Nachfolger). Vielleicht finden sich ja noch Mitstreiter (ich bin da leider raus weil Löter und kein Programmierer) damit eingangsseitig auch noch andere Protokolle (z.B. Jeti EX - kommt ja auch über Onewire) mit verarztet werden können. Quasi eine Art Babbelfisch für OTX.
Die zusätzliche Hardware bringt also hauptsächlich so eine Art "Codehoheit" bzw. Unabhängigkeit von OTX?
Gruß
Onki
ich hätte da mal eine Frage rein theoretischer Natur.
Der Adapter in Form des µC ist doch nur ein reiner Protokoll-Konverter - oder?
So wie ich das sehe, bringt das MLink-Modul die Daten ja als Onewire, S-Port ist das aber auch (bei den anderen weiß ich es nicht).
Somit wäre es doch auch möglich die µC Hardware einzusparen und die Konvertierung als Fork oder so in OTX direkt zu implementioeren.
Oder hab ich da was übersehen?
S-Port ist sicher eine feine Sache (FrSky bringt ja schon den Nachfolger). Vielleicht finden sich ja noch Mitstreiter (ich bin da leider raus weil Löter und kein Programmierer) damit eingangsseitig auch noch andere Protokolle (z.B. Jeti EX - kommt ja auch über Onewire) mit verarztet werden können. Quasi eine Art Babbelfisch für OTX.
Die zusätzliche Hardware bringt also hauptsächlich so eine Art "Codehoheit" bzw. Unabhängigkeit von OTX?
Gruß
Onki
Reinhardt Werbik
User
@Ralf:
Du verwendest zur initialen Synchronisierung den Bitzähler, das spart zwar eine zusätzliche Variable, ist aber m.E. nicht wirklich intuitiv.
Ich verwende hier eine boolesche Variable, um die Idle Line zu signalisieren, auch um die Anzahl der Befehle in der ISR für den PC Interrupt zu minimieren.
Die If Abfrage einer Integer Variablen muss ja mehr Befehle brauchen als die einer booleschen Variablen.
Es wäre interessant, mal zu vergleichen, wie sich das genau auf den Code auswirkt.
Wenn Du magst, kannst Du ja mal den entsprechenden Abschnitt des LSS Files hier posten (oder mir per PM oder E-Mail schicken).
Du verwendest zur initialen Synchronisierung den Bitzähler, das spart zwar eine zusätzliche Variable, ist aber m.E. nicht wirklich intuitiv.
Ich verwende hier eine boolesche Variable, um die Idle Line zu signalisieren, auch um die Anzahl der Befehle in der ISR für den PC Interrupt zu minimieren.
Die If Abfrage einer Integer Variablen muss ja mehr Befehle brauchen als die einer booleschen Variablen.
Es wäre interessant, mal zu vergleichen, wie sich das genau auf den Code auswirkt.
Wenn Du magst, kannst Du ja mal den entsprechenden Abschnitt des LSS Files hier posten (oder mir per PM oder E-Mail schicken).
Reinhardt Werbik
User
Hi Onki,
das Problem ist, dass das M-Link Modul die Telemetriedaten an einem separaten Ausgang ausgibt, nicht an den Modulschacht-Pins.
Der Sende bräuchte also eine entsprechende Schnittstelle, wo man die M-Link Daten einspeisen kann.
Die alten X9D+ und X9E Sender hatten sowas, die neueren nicht mehr.
Der Konverter speist übrigens die Telemetriedaten im alten D-Format ein.
Das ist vollkommen ausreichend, da der M-Link Rückkanal hier das Nadelöhr ist.
Außerdem ist das D-Protokoll, im Gegensatz zum S-Port Format, von FrSky offengelegt.
Was die Programmiererei angeht, da bin ich genauso außen vor wie Du.
OpenTx ist in C++ programmiert, und da bin ich raus, da kein gelernter Programmierer.
Meine AVR Projekte mache ich in C (früher auch mal in Assembler
)