OpenTX - Multiplex MLINK Konverter
- Ersteller Donaufisch66
- Erstellt am
Reinhardt Werbik
User
Hallo Wolfram,
ich habe nochmal im Datenblatt des t841 geschmökert. Die Angabe von 16MHz Clock bei Reichelt muss sich auf den Betrieb mit einem externen Quarz beziehen, denn der kalibrierte interne Oszillator arbeitet immer mit 8MHz. Da man durch das Setzen der entsprechenden Fuse Bits auswählen kann, welcher Oszillator benutzt wird, sollten auch die Teile von Reichelt gehen.
ich habe nochmal im Datenblatt des t841 geschmökert. Die Angabe von 16MHz Clock bei Reichelt muss sich auf den Betrieb mit einem externen Quarz beziehen, denn der kalibrierte interne Oszillator arbeitet immer mit 8MHz. Da man durch das Setzen der entsprechenden Fuse Bits auswählen kann, welcher Oszillator benutzt wird, sollten auch die Teile von Reichelt gehen.
kalle123
User
Hi Renhardt.
Unterstützt auch den MysmartUSB light von Wolfram. Würde ihn ja gerne überreden, sich doch noch mal mit dem ATTiny zu beschäftigen.
Es braucht dann halt den ATTiny und möglichst so was hier fürs Handling.
Ich mach dann hier vor mit AVRdudess und USBasp und Wolfram macht nach ....
Grüße KH
PS. AVRdudess gefällt mir auch sehr, nur benötigt das unter Linux halt mono, und wine und etc. kommen mir nicht auf meine System. Und mit USBasp unter WIN in einer VM bin ich schon mal auf den Bauch gefallen. Dann lieber dualboot Linux <> WIN.
Seh gerade ihr habt beide geschrieben.
Zu den xx MHz beim ATTiny841
Schaut mal auf der Seite https://github.com/SpenceKonde/ATTinyCore nach unten durch.
SpenceKonde geht da sehr ausführlich auf diese Sache ein.
Kann das nicht beurteilen, dazu hätte ich was Anderes studieren müssen.
Nur es fängt dort ja schon so an
'On top of that, if you tune the internal oscillator to nearly the maximum, 90+% of these will run at 16 MHz.'
Und da kommt noch ne Masse mehr zu xxMHz.
Und was hab ich hier? 8MHz oder was? Und da laufen 4 von ohne Probleme ...
Unterstützt auch den MysmartUSB light von Wolfram. Würde ihn ja gerne überreden, sich doch noch mal mit dem ATTiny zu beschäftigen.
Es braucht dann halt den ATTiny und möglichst so was hier fürs Handling.
5x Breakout Board für SO14 / SOP14 / SO-14 | Adapter Platine, SOIC, DIL, SMD | eBay
Breakout Board für SO14/SOP14.
www.ebay.de
Ich mach dann hier vor mit AVRdudess und USBasp und Wolfram macht nach ....
Grüße KH
PS. AVRdudess gefällt mir auch sehr, nur benötigt das unter Linux halt mono, und wine und etc. kommen mir nicht auf meine System. Und mit USBasp unter WIN in einer VM bin ich schon mal auf den Bauch gefallen. Dann lieber dualboot Linux <> WIN.
Seh gerade ihr habt beide geschrieben.
Zu den xx MHz beim ATTiny841
Schaut mal auf der Seite https://github.com/SpenceKonde/ATTinyCore nach unten durch.
SpenceKonde geht da sehr ausführlich auf diese Sache ein.
Kann das nicht beurteilen, dazu hätte ich was Anderes studieren müssen.
Nur es fängt dort ja schon so an
'On top of that, if you tune the internal oscillator to nearly the maximum, 90+% of these will run at 16 MHz.'
Und da kommt noch ne Masse mehr zu xxMHz.
Und was hab ich hier? 8MHz oder was? Und da laufen 4 von ohne Probleme ...
Reinhardt Werbik
User
Hallo Kalle,
der Chip wird ab Werk so ausgeliefert, dass der interne 8MHz Oszillator aktiviert ist (durch die entsprechenden Fuse Bits), und in dieser Konfiguration läuft er für unsere Zwecke ohne Probleme, wie Du richtig schreibst. Daher sollten wir nicht mal dran denken, am internen Oszillator rumzumachen.
Wenn man die Taktfrequenz hochsetzt, z.B. durch die Verwendung eines externen 16MHz Quarzes, braucht das Teil auch eine höhere Versorgungsspannung, und dann reichen die 3,3V, die das M-Link Modul liefert, wahrscheinlich nicht mehr. Das war ja seinerzeit der Auslöser, überhaupt eine 8MHz Variante zu machen, zwecks direkter Versorgung am COM-Port des M-Link Moduls.
der Chip wird ab Werk so ausgeliefert, dass der interne 8MHz Oszillator aktiviert ist (durch die entsprechenden Fuse Bits), und in dieser Konfiguration läuft er für unsere Zwecke ohne Probleme, wie Du richtig schreibst. Daher sollten wir nicht mal dran denken, am internen Oszillator rumzumachen.
Wenn man die Taktfrequenz hochsetzt, z.B. durch die Verwendung eines externen 16MHz Quarzes, braucht das Teil auch eine höhere Versorgungsspannung, und dann reichen die 3,3V, die das M-Link Modul liefert, wahrscheinlich nicht mehr. Das war ja seinerzeit der Auslöser, überhaupt eine 8MHz Variante zu machen, zwecks direkter Versorgung am COM-Port des M-Link Moduls.
@ Kalle: ja hatte ich kurz vorher auch gesehen, dass mein MysmartUSB light den 841 supporten sollte.
Insofern sollte es gehen. Hab aber gerade andere Baustellen insofern kann es dauern...
Ich würde aber zum Proggen und für den Betrieb nicht unbedingt löten, sondern so etwas verwenden.
@ Reinhardt: danke, ich werde mal bei Reichelt paar ATTiny841 bestellen und ausprobieren, kostet ja nicht die Welt....
Viele Grüße
Wolfram
Insofern sollte es gehen. Hab aber gerade andere Baustellen insofern kann es dauern...
Ich würde aber zum Proggen und für den Betrieb nicht unbedingt löten, sondern so etwas verwenden.
@ Reinhardt: danke, ich werde mal bei Reichelt paar ATTiny841 bestellen und ausprobieren, kostet ja nicht die Welt....
Viele Grüße
Wolfram
kalle123
User
Hi Wolfram, bist du sicher dass sich das Ding da für den ATTiny 841 eignet?
Das sind die beiden Bauformen, die es lt. Datenblatt von dem 841er gibt.
Denn 1. 841 hab ich ja auf einer Lochrasterplatine so verdrahtet (face hugger). Bild gibt es hier irgendwo im thread, aber die Dinger sind recht klein.
Dann hab ich mir das Teil rechts besorgt, der geht super für den 841 und zum löten hab ich mir ne Wäscheklammer modifiziert, der den 841er auf der Platine fixiert. Feine Lötspitze, 0.5 mm Bleilot und viel Flux. Gibt dann so Lötungen wie im Bild oben in #1563. Und ich bin schon einige Jahre im Ruhestand. Mein exaktes Alter möchte ich in dieser Runde lieber nicht nennen
Gruß KH
DIL DIP-14-Pin Zig Zag IC Chip Carrier PCB Socket Adapter / Sockel 14-polig THT | eBay
Power Supplies / Netzteile. Cables & Adapters / Kabel. HDDs / Hard Disk Drives. Drives / Laufwerke. Laptop Parts. Type IC Socket. Sound Cards. Des Weiteren geben wir aufNeuware 24 Monate und aufGebrauchtware 12 Monate Gewährleistung.
www.ebay.de
Das sind die beiden Bauformen, die es lt. Datenblatt von dem 841er gibt.
Denn 1. 841 hab ich ja auf einer Lochrasterplatine so verdrahtet (face hugger). Bild gibt es hier irgendwo im thread, aber die Dinger sind recht klein.
Dann hab ich mir das Teil rechts besorgt, der geht super für den 841 und zum löten hab ich mir ne Wäscheklammer modifiziert, der den 841er auf der Platine fixiert. Feine Lötspitze, 0.5 mm Bleilot und viel Flux. Gibt dann so Lötungen wie im Bild oben in #1563. Und ich bin schon einige Jahre im Ruhestand. Mein exaktes Alter möchte ich in dieser Runde lieber nicht nennen
Gruß KH
Hallo Kalle, Du hast natürlich schon Recht, ich meinte im Prinzip ein passendes zum einclipsen, so wie auf Deinem Bild rechts. War nur auf die Schnelle aus der Bucht noch ohne Prüfung.
Alternativ frage ich mal bei unseren Luftfahrt Elektronikern nach, ob die mir schnell mal paar Stk . quasi als Azubi Lötübung auf ne Adapterplatine löten lassen. Respekt an Deine Lötkünste , scheint einen jung zu halten !!! Beim AVRdudess download für Windows habe ich allerdings noch nichts gefunden, was keine Malicius Warnung ausgibt, möchte mein Win System nicht verseuchen und mein Linux System ist zur Zeit leider immer noch down. Aber es sollte ja mit meinem MysmartUSB light auch gehen.. Für meine zwei HFMG3 brauche ich eh nix mehr, in meinen sind ein Nano und ein Pro Mini integriert und laufen und laufen....
Viele Grüße
Wolfram
Alternativ frage ich mal bei unseren Luftfahrt Elektronikern nach, ob die mir schnell mal paar Stk . quasi als Azubi Lötübung auf ne Adapterplatine löten lassen. Respekt an Deine Lötkünste , scheint einen jung zu halten !!! Beim AVRdudess download für Windows habe ich allerdings noch nichts gefunden, was keine Malicius Warnung ausgibt, möchte mein Win System nicht verseuchen und mein Linux System ist zur Zeit leider immer noch down. Aber es sollte ja mit meinem MysmartUSB light auch gehen.. Für meine zwei HFMG3 brauche ich eh nix mehr, in meinen sind ein Nano und ein Pro Mini integriert und laufen und laufen....
Viele Grüße
Wolfram
kalle123
User
Verstehe ich Wolfram, vielleicht kann Reinhardt dazu was sagen?
Ich mache NULL sicherheitsrelevante Sachen über WIN, alles, was relevant ist, mach ich über Linux.
Danke für die Blumen wegen meiner 'Lötkünste'. Ich bin der Auffassung, eine gute Lötung sollte auch gut aussehen.
Im nächsten Leben werde ich dann Uhrmacher, jetzt ist es wohl etwas spät mit einem Berufswechsel.
Gruß KH
Reinhardt Werbik
User
Herzlichen Dank Reinhardt,
hab da die portable Version genommen, die hat schon mal perfekt gepasst !
Jedenfalls auch ohne die vorherigen Virenscanner Complains :-)
Es scheinen da halt leider einige dubiose Versionen im Netz zu kursieren.
Jetzt geht es erst mal ans Bestellen bei Reichelt
Viele Grüße
Wolfram
hab da die portable Version genommen, die hat schon mal perfekt gepasst !
Jedenfalls auch ohne die vorherigen Virenscanner Complains :-)
Es scheinen da halt leider einige dubiose Versionen im Netz zu kursieren.
Jetzt geht es erst mal ans Bestellen bei Reichelt
Viele Grüße
Wolfram
kalle123
User
Ich will hier noch mal was zum Flashen insbesondere des ATTiny841 in Zusammenhang mit Windows unter Avrdudess schreiben. Irgendwie hatte ich da in Erinnerung, dass es bei meinem Equipment da schon mal hakte.
Meine bisher immer zuverlässige 'Methode Arduino IDE, USBasp und Linux'.
Also hab ich noch mal aufgebaut.
Meine beiden USBasps, ein ATTiny im Wechseladapter und LED mit Vorwiderstand an Pin 5 (Code beim Start von Reinhardts Programm)
Die beiden USBasps haben die letzte Fischl Firmware drauf. Einer war fest auf 5V gestellt, den 2. musste ich auf 5V setzen, damit er bereit war, mit dem ATTiny zu funktionieren.
NUR, es zeigte sich folgender Effekt
Ich musste nach jedem ausgeführten Befehl den USB Anschluss kurz abziehen, dann erst ging es weiter ....
Ein Spannungslos machen des ATTinys reichte da nicht. Crosscheck mit einem Arduino als Flashobjekt zeigte diesen Effekt nicht.
Liegt das jetzt am USBasp, am ATTiny oder?
Ich bin dann mal auf einen Arduino UNO als ISP Programmierer ausgewichen.
Infos zum Arduino ISP ist zwar sehr gut im Netz dokumentiert, aber was die Einstellungen unter Avrdudess betrifft, da geht es ziemlich durcheinander ....
Mit den Einstellungen im Bild geht es super auch hier in WIN 10 in einer VM unter Linux.
AVRdudess ist in der Oberfläche sehr übersichtlich, Arduino als ISP super simple (wer den BLINK sketch aufspielen kann, kann einen Arduino UNO oder Nano auch in einen ISP Programmer umwandeln!) und die Verdrahtung auch recht einfach (5 Strippen und noch einen 10µF Elko).
Gruß KH
Meine bisher immer zuverlässige 'Methode Arduino IDE, USBasp und Linux'.
Also hab ich noch mal aufgebaut.
Meine beiden USBasps, ein ATTiny im Wechseladapter und LED mit Vorwiderstand an Pin 5 (Code beim Start von Reinhardts Programm)
Die beiden USBasps haben die letzte Fischl Firmware drauf. Einer war fest auf 5V gestellt, den 2. musste ich auf 5V setzen, damit er bereit war, mit dem ATTiny zu funktionieren.
NUR, es zeigte sich folgender Effekt
Ich musste nach jedem ausgeführten Befehl den USB Anschluss kurz abziehen, dann erst ging es weiter ....
Ein Spannungslos machen des ATTinys reichte da nicht. Crosscheck mit einem Arduino als Flashobjekt zeigte diesen Effekt nicht.
Liegt das jetzt am USBasp, am ATTiny oder?
Ich bin dann mal auf einen Arduino UNO als ISP Programmierer ausgewichen.
Infos zum Arduino ISP ist zwar sehr gut im Netz dokumentiert, aber was die Einstellungen unter Avrdudess betrifft, da geht es ziemlich durcheinander ....
Mit den Einstellungen im Bild geht es super auch hier in WIN 10 in einer VM unter Linux.
AVRdudess ist in der Oberfläche sehr übersichtlich, Arduino als ISP super simple (wer den BLINK sketch aufspielen kann, kann einen Arduino UNO oder Nano auch in einen ISP Programmer umwandeln!) und die Verdrahtung auch recht einfach (5 Strippen und noch einen 10µF Elko).
Gruß KH
Reinhardt Werbik
User
Hallo zusammen,
wegen des neuen S-Port Konverters ist es hier im Thread naturgemäß still geworden, aber keine Sorge, der alte Konverter lebt noch. Durch die Arbeit am neuen S-Port Konverter ist sozusagen als Nebenprodukt ein neuer Release des alten D-Konverters entstanden, da die Code Files ja teilweise identisch sind. Für den "alten" Konverter hat sich zwar funktional nichts geändert, aber die Implementierung speziell der Interfaces ist doch wesentlich verbessert worden.
Ich habe heute zwei Versionen des D-Konverters getestet, und zwar die Version ohne FrSky IDs auf einem 8MHz Pro Mini Board, sowie die Version mit FrSky IDs auf einem Nanite 841 Board. Beide haben einwandfrei funktioniert, wobei ich den Test mit EdgeTx 2.8.4 auf meiner Taranis X9D+ 2019 gemacht haben. Das sollte aber auch mit OpenTx einwandfrei funktionieren.
Da das Modul mit der eigentlichen Daten-Konvertierung HW unabhängig ist, und die Unterschiede zwischen den 8MHz und 16MHz Pro Mini Versionen sehr gering sind, bin ich mir ziemlich sicher, dass auch die anderen Konverter-Versionen funktionieren (insgesamt 6 wie im letzten Release). Ich werde daher wie versprochen, den neuen Release hier einstellen. Momentan bin ich noch dabei, die Anleitung ein wenig aufzupeppeln, aber das wird nicht sehr lange dauern.
Watch this space...
wegen des neuen S-Port Konverters ist es hier im Thread naturgemäß still geworden, aber keine Sorge, der alte Konverter lebt noch. Durch die Arbeit am neuen S-Port Konverter ist sozusagen als Nebenprodukt ein neuer Release des alten D-Konverters entstanden, da die Code Files ja teilweise identisch sind. Für den "alten" Konverter hat sich zwar funktional nichts geändert, aber die Implementierung speziell der Interfaces ist doch wesentlich verbessert worden.
Ich habe heute zwei Versionen des D-Konverters getestet, und zwar die Version ohne FrSky IDs auf einem 8MHz Pro Mini Board, sowie die Version mit FrSky IDs auf einem Nanite 841 Board. Beide haben einwandfrei funktioniert, wobei ich den Test mit EdgeTx 2.8.4 auf meiner Taranis X9D+ 2019 gemacht haben. Das sollte aber auch mit OpenTx einwandfrei funktionieren.
Da das Modul mit der eigentlichen Daten-Konvertierung HW unabhängig ist, und die Unterschiede zwischen den 8MHz und 16MHz Pro Mini Versionen sehr gering sind, bin ich mir ziemlich sicher, dass auch die anderen Konverter-Versionen funktionieren (insgesamt 6 wie im letzten Release). Ich werde daher wie versprochen, den neuen Release hier einstellen. Momentan bin ich noch dabei, die Anleitung ein wenig aufzupeppeln, aber das wird nicht sehr lange dauern.
Watch this space...
Reinhardt Werbik
User
Guten Morgen,
jetzt ist es soweit, hier ist das ZIP-Archiv mit den HEX Files (Version 1.30) für folgende HW Varianten:
- ATmega328 8MHz
- ATmega328 16MHz
- ATtiny841 8MHz
Für jede dieser drei HW Standards gibt es wieder je eine Variante mit und ohne vordefinierte FrSky IDs, was dann insgesamt 6 Varianten ergibt. Die Alarm Flags sind wie gehabt überall deaktiviert, da sie für OpenTx/EdgeTx überflüssig sind. (Wenn sie jemand unbedingt braucht, kann ich aber leicht eine entsprechende Version kompilieren.)
Wie bereits gesagt hat sich funktional am Konverter nichts geändert. Wer die vorherige Version am Laufen hat, muss nicht unbedingt updaten, kann es aber tun ohne dass an den Modell Setups etwas geändert werden muss. Nur wer eine ganz alte Version mit Alarm Flags hat, muss bedenken, dass diese jetzt nicht mehr übertragen werden.
Die angehängte ZIP-Datei enthält die HEX Files für die 6 Varianten des Konverters, sowie die aktuelle Anleitung, wie üblich mit der Endung .txt zwecks Hochladen.
Damit ist das Konverter-Projekt mit dem alten D-Protokoll wohl endgültig abgeschlossen, zumal mit EdgeTx 2.9 die Konverter-Funktionalität als integrierter Bestandteil kommen wird. Sollten aber Fehler auftauchen, werde ich diese natürlich auch weiterhin korrigieren.
jetzt ist es soweit, hier ist das ZIP-Archiv mit den HEX Files (Version 1.30) für folgende HW Varianten:
- ATmega328 8MHz
- ATmega328 16MHz
- ATtiny841 8MHz
Für jede dieser drei HW Standards gibt es wieder je eine Variante mit und ohne vordefinierte FrSky IDs, was dann insgesamt 6 Varianten ergibt. Die Alarm Flags sind wie gehabt überall deaktiviert, da sie für OpenTx/EdgeTx überflüssig sind. (Wenn sie jemand unbedingt braucht, kann ich aber leicht eine entsprechende Version kompilieren.)
Wie bereits gesagt hat sich funktional am Konverter nichts geändert. Wer die vorherige Version am Laufen hat, muss nicht unbedingt updaten, kann es aber tun ohne dass an den Modell Setups etwas geändert werden muss. Nur wer eine ganz alte Version mit Alarm Flags hat, muss bedenken, dass diese jetzt nicht mehr übertragen werden.
Die angehängte ZIP-Datei enthält die HEX Files für die 6 Varianten des Konverters, sowie die aktuelle Anleitung, wie üblich mit der Endung .txt zwecks Hochladen.
Damit ist das Konverter-Projekt mit dem alten D-Protokoll wohl endgültig abgeschlossen, zumal mit EdgeTx 2.9 die Konverter-Funktionalität als integrierter Bestandteil kommen wird. Sollten aber Fehler auftauchen, werde ich diese natürlich auch weiterhin korrigieren.
Reinhardt Werbik
User
Hallo zusammen,
die Konverter Funktion ist jetzt mit EdgeTx 2.9.0 RC1 verfügbar (Telemetrie-Eingang muss auf SPort stehen).
die Konverter Funktion ist jetzt mit EdgeTx 2.9.0 RC1 verfügbar (Telemetrie-Eingang muss auf SPort stehen).
Hallo Reinhardt,
klingt toll !!
Ich möchte Dir einen ganz großen Dank für Dein perfektes Engagement aussprechen, wir haben so die letzten Jahre deine Konverter Software mit unseren M-Link / HFMG3 in diversen FrSky und Radiomaster Sendern perfekt mit MPX Telemetriedaten betreiben können ! War ne traumhafte Sache und bleibt sie bestimmt auch zukünftig für den einen oder anderen, der nicht zu EdgeTX wechselt.....
Und bei den Tests für die MPX Telemetrie Implementierung in EdgeTX warst Du ja auch professionell dabei, sonst gäbe es das in EdgeTX 2.9.0 RC1 sicherlich nicht !
Für mich nebenbei noch ein super Einstieg in die Arduino Welt, von der ich vorher absolut keine Ahnung hatte.
In diesem Sinne nochmals einfach: DANKE......
VG
Wolfram
klingt toll !!
Ich möchte Dir einen ganz großen Dank für Dein perfektes Engagement aussprechen, wir haben so die letzten Jahre deine Konverter Software mit unseren M-Link / HFMG3 in diversen FrSky und Radiomaster Sendern perfekt mit MPX Telemetriedaten betreiben können ! War ne traumhafte Sache und bleibt sie bestimmt auch zukünftig für den einen oder anderen, der nicht zu EdgeTX wechselt.....
Und bei den Tests für die MPX Telemetrie Implementierung in EdgeTX warst Du ja auch professionell dabei, sonst gäbe es das in EdgeTX 2.9.0 RC1 sicherlich nicht !
Für mich nebenbei noch ein super Einstieg in die Arduino Welt, von der ich vorher absolut keine Ahnung hatte.
In diesem Sinne nochmals einfach: DANKE......
VG
Wolfram
Reinhardt Werbik
User
Ich vermute mal, dass bei Verwendung der in Edge integrierten Konvertierung, die Auswahl des Telemetrieprotokolls unerheblich ist. SPort ist aber auf jeden Fall die Default-Einstellung.
Reinhardt Werbik
User
Hier noch eine kleine Klarstellung:
EdgeTx konvertiert natürlich die M-Link Telemetriedaten nicht in das SPort Protokoll, sondern dekodiert sie direkt und verarbeitet sie intern weiter.
Die Einstellmöglichkeit für das Telemetrieprotokoll ist ein Relikt, das in EdgeTx keine Funktion mehr hat und demnächst aus der Benutzeroberfläche verschwinden wird. Daher funktioniert auch der Konverter mit EdgeTx nicht mehr, was aber belanglos ist, da ja die M-Link Telemetrie jetzt direkt dekodiert wird.
EdgeTx konvertiert natürlich die M-Link Telemetriedaten nicht in das SPort Protokoll, sondern dekodiert sie direkt und verarbeitet sie intern weiter.
Die Einstellmöglichkeit für das Telemetrieprotokoll ist ein Relikt, das in EdgeTx keine Funktion mehr hat und demnächst aus der Benutzeroberfläche verschwinden wird. Daher funktioniert auch der Konverter mit EdgeTx nicht mehr, was aber belanglos ist, da ja die M-Link Telemetrie jetzt direkt dekodiert wird.
Ähnliche Themen
