Philipp E. schrieb: > Ne, das wollte ich aber noch tun. Wollte aber vorher fragen, ob die > Traces soweit vollständig sind. Wie war der Status als das Logging > gestartet wurde und wie als es Endete? Also für das File: SPI traffic > during binding.txt > Vorher: Copter und RC angeschaltet, nichts gedrückt? > Nachehr: Binding abgeschlossen? Das Log fängt direkt mit dem Einschalten der FB an. Im ersten Teil sieht man daher schön, wie die Register des BK2423 initialisiert werden. Die Aufzeichnung endet noch während der Binding-Phase.
Tim schrieb: > Wir sollten uns tatsächlich mal Gedanken > machen, wie man das ganze strukturiert angeht. +1 Finde die Aufteilung sinnvoll. Wobei vermutlich jeder etwas unterschiedliche Prioritäten hat. Aber das macht ja nix, jeder kann sich das Schnappen worauf er Lust hat. Ich bin sehr an Punkt 2) bis 4) interessiert, wenn denn mein Copter endlich mal ankäme. @Torsten: Gibt es eigentlich schon neues von den China Händlern bzgl. Mengenrabatt? Tim schrieb: > 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal > angekommen) Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu bestellen, auf der anderen Seite wäre es für die Community sicher genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt den LA dran und schickst uns nen Trace vom Unlocken ;-) Tim schrieb: > Wenn man einige Optionen nicht > mitcompiliert passt die Firmware bereits jetzt in 16kb. Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche Optionen hast du ausgeschaltet? Tim schrieb: > Die Aufzeichnung endet noch während der Binding-Phase. Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding Phase abdeckt? Ach ja, ich habe noch eine Frage zur IDE. Ihr verwendet alle Keil, oder? Damit kann man dann den SWD Port vom Discovery Board direkt mit dem Copter verbinden und Debuggen und Flashen (wenn er denn nicht mehr gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich dazu als korrekt rausgestellt? Und welche Keil Version? Ist das, was in https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS liegt als Grundlage (also vom Keil-Projekt her) geeignet?
Philipp E. schrieb: > Tim schrieb: >> Wenn man einige Optionen nicht >> mitcompiliert passt die Firmware bereits jetzt in 16kb. > > Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche > Optionen hast du ausgeschaltet? https://github.com/trollcop/bradwii Habe in den Defines alles deaktiviert, was sowieso nicht unterstützt wird und anschließend manuell das Konfigurationsinterface ausgebaut (Checkboxes, EEPROM code usw.). Philipp E. schrieb: > Tim schrieb: >> Die Aufzeichnung endet noch während der Binding-Phase. > > Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding > Phase abdeckt? Habe die Verbindungen leider schon wieder entfernt. Ich gehe aber davon aus, dass es da keine Überraschung gibt. Es wird einfach vom Binding in den normalen Modus umgeschaltet. Philipp E. schrieb: > Tim schrieb: >> 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal >> angekommen) > > Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu > bestellen, auf der anderen Seite wäre es für die Community sicher > genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt > den LA dran und schickst uns nen Trace vom Unlocken ;-) Das wird das Allererste sein :) Philipp E. schrieb: > gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich > dazu als korrekt rausgestellt? Und welche Keil Version? µVision5 mit legacy device support. > Ist das, was in > https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS > liegt als Grundlage (also vom Keil-Projekt her) geeignet? Ich denke schon. Das sind die Einstellungen vom Beispielprojekt für den MINI54.
Philipp E. schrieb: > Gibt es eigentlich schon neues von den China Händlern bzgl. > Mengenrabatt? Das Problem ist, dass bei einer Einfuhr von mehr als einem Stück in jedem Fall Einfuhrumsatzsteuer fällig wird. Dann muss der Händler mindestens 20% Rabatt einräumen, damit es pari ausgeht. Das Porto innerhalb Deutschlands ist auch nicht zu vernachlässigen (Warensendung € 1.90). Und Torsten muss die Dinger auch einzeln neu verpacken (Karton € 0.50). Nun sind wir schon bei weiteren gut 10% die der Händler nachlassen muss. Und Torsten hat noch immer keine Entschädigung für seine Arbeit. Wenn dann auch nur ein Copter defekt ankommt... ich will gar nicht weiter rechnen... aber ich freue mich, wenn es noch klappt (ich könnte direkt bei Torsten abholen, 15km Entfernung).
Neben den Daten auf den 16 Hopping-Kanälen schickt die Fernbedienung das Gleiche nochmal auf vielen anderen Kanälen. Lauscht man nur an einem Kanal erhält man in unregelmäßigen Abständen einen Datensatz (hier Channel 2):
1 | 125 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
2 | 261 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
3 | 130 2F 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 29 |
4 | 512 C1 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 BB |
5 | 1813 DB 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 D5 |
6 | 774 1A 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 14 |
7 | 129 03 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FD |
8 | 126 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
9 | 649 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
Dann weiß der Empfänger einen Hopping-Kanal und ist schnell in Sync. Es gibt aber auch Kanäle (z.B. 0x1f) auf denen kommt nichts. Wenn die Fernbedienung noch nicht gebunden(?) hat, gibts auf vielen Kanälen (auch 0x1f) etwa alle 125ms einen Datensatz:
1 | 125 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
2 | 133 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
3 | 125 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
4 | 129 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
Auch hier kann der Empfänger dann die Kanäle ermitteln. https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber auch wenn [14]==0 ist. NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als über die Fernbedienung :-)
Fernbedienung: Für den N79E814 gibt es die Header Files für Keil&Co auf der Nuvoton Seite. Man muss aber nach "Demo Code" suchen, nicht nach "Header". Die sind in dem Zip versteckt. Falls der 814 ohne Bootlader in der FB ist (wovon ich ausgehe, auf den Pads ist ICP herausgeführt), brauchen wir den Stick von Nuvoton zum Programmieren (geschätzt € 30.-). Ich frage bei Nuvoton mal an, ob sie das ICP Protokoll herausrücken. Die Hardware wäre simpel.
Tim schrieb: > Hast Du eigentlich auch mal mein Dump nach dem Einschalten durch Deinen > Parser geschickt? Dadurch könnte man in Erfahrung bringe, welche Kanäle > beim Binding verwendet werden. Für das Binding werden keine besonderen Kanäle verwendet. Die Fernbedienung sendet einfach in ihrem 16 Kanalraster die Pakete. Das Binding wird beendet sobald der Speedstick einmal hin- und wieder zurück bewegt wurde. Die Pakete haben als Besonderheit 2 Flags gesetzt und die Werte für die Sticks sind auf 0x00 gesetzt. Coptersoftware: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
Georg G. schrieb: > Das Problem ist... Stimmt. Sehe ich ähnlich. Allerdings wollen die meisten von uns vermutlich mehr als einen Copter (damit werden die Versandkosten pro Stück schon einmal geringer). Außerdem könnte ja die Fernbedienung und der Lader weggelassen werden, dürfte auch noch mal ein klein bisschen was bringen. Abschließend kann ich das nicht beurteilen. Aber wenn es tatsächlich 100 Stück für 900 € inkl. Versand geben sollte, dann ergibt sich bei Abnahme von 5 Stück pro Person: 9 € * 1,25 (Zoll + Ust.) = 11,25 € + 0,75 € (Versand und Verpackung [3,75 € / 5]) = 12,00 € pro Stück. Das wäre schon Attraktiv. Wenn Torsten jetzt noch 2 € als Profit / Puffer draufschlägt ist es immer noch 10 € billiger als bei eBay und damit wären locker 15 Defekte Copter abgedeckt. Weiterhin sollte klar sein, dass Torsten nicht dafür verantwortlich ist, wenn die Dinger defekt sind. Auf der anderen Seite ist das natürlich alles mit Aufwand und Risiko für Torsten verbunden. Auch weiß ich nicht, ob sich wirklich 9 € pro Stück erzielen lassen. Und ob hier wirklich so viel Nachfrage besteht ist auch fraglich. Vielleicht kann Torsten kurz mal schreiben, wie seine Pläne diesbezüglich sind, andernfalls würde ich mir einfach 5 von den Dingern direkt bei eBay klicken.
Bei 100 Stück könnte man vielleicht auch direkt beim Hersteller anfragen: http://www.jxdtoys.com/en/aboutus.asp
Jetzt wird der BU-Link plötzlich nicht mehr angeboten: http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die Chip-Erase von einem original Nu-Link zu grabben.
Tim schrieb: > von einem original Nu-Link zu grabben Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider kenne ich niemanden, der deren ICs kommerziell einsetzt.
Georg G. schrieb: > Tim schrieb: >> von einem original Nu-Link zu grabben > > Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider > kenne ich niemanden, der deren ICs kommerziell einsetzt. Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das Nuvoton-Forum, die leider abgelehnt wurden.
Tim schrieb: > Langsam > bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die > Chip-Erase von einem original Nu-Link zu grabben. Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen einen "gemeinsam". Davis schrieb: > Für das Binding werden keine besonderen Kanäle verwendet. Die > Fernbedienung sendet einfach in ihrem 16 Kanalraster die Pakete. Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt geparst, aber nach ein paar ms geht es los mit immer dem gleichen Packet:
1 | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0xC0 0x38 |
Also alles wie zu erwarten. Nun bin ich etwas verwirrt (mangels Copter) wie genau die "Bedienung" ist. Also RC Einschalten und dann Stick nach ganz oben? Damit sendet sie das Binding Packet solange bis der Stick auf 0 geschoben wird? Und am Copter? Schaut der einfach nach dem Einschalten nach dem ersten binding packet oder speichert er an welchen Sender er gebindet ist und es gibt am Copter ne Taste o. Ä. um das Binding zu starten?
Philipp E. schrieb: > Also alles wie zu erwarten. Nun bin ich etwas verwirrt (mangels Copter) > wie genau die "Bedienung" ist. Also RC Einschalten und dann Stick nach > ganz oben? Damit sendet sie das Binding Packet solange bis der Stick auf > 0 geschoben wird? Sobald der Speedstick, nachdem er oben war (0xFF), wieder unten ist (0x00), wird das Binding beendet und die Fernbedienung sendet "normale" Pakete. > Und am Copter? Schaut der einfach nach dem Einschalten nach dem ersten > binding packet oder speichert er an welchen Sender er gebindet ist und > es gibt am Copter ne Taste o. Ä. um das Binding zu starten? Keine Taste. Der Copter schaut nur auf die Pakete die da kommen. Die Bindung an die Fernbedienung erfolgt über die drei Bytes der Unique-ID.
Davis schrieb: > Keine Taste. Der Copter schaut nur auf die Pakete die da kommen. Ah verstehe. Also muss der Copter bei jedem Akku wechsel neu gebindet werden?
Philipp E. schrieb: > Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool > minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert > ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt > geparst, aber nach ein paar ms geht es los mit immer dem gleichen > Packet: > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 > 0xC0 0x38 Interessant! Auf welchen Kanälen sendet er?
Tim schrieb: > Philipp E. schrieb: >> Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool >> minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert >> ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt >> geparst, aber nach ein paar ms geht es los mit immer dem gleichen >> Packet: >> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 >> 0xC0 0x38 > > Interessant! Auf welchen Kanälen sendet er? Auf den 16 Kanälen, die aus der Unique-ID generiert werden. Dabei ist immer ein Kanal zwischen 24 und 31. Die könnte der Copter "abhören", um an die ID zu kommen und dann seinerseits die 16 Hopping Kanäle zu bestimmen.
1 | Kanaele zu obiger Unique-ID: |
2 | |
3 | 5, 33, 63, 46, 42, 40, 52, 60, 31, 39, 47, 26, 36, 24, 51, 30 |
Davis schrieb: > Auf den 16 Kanälen, die aus der Unique-ID generiert werden. Also um das hier nochmal heraus zu stellen. Das Channel Hopping ist immer gleich egal ob in der "Bind" Phase oder bei der eigentlichen Steuerung. Die Sequenz hängt nur von der ID des Senders ab und ist daher immer gleich. Die Bind Phase zeichnet sich nur durch die spezielle Struktur der Pakete aus. Damit kann der Copter dann discovern welcher Sender sich binden will und kennt dann dessen ID und damit die Hopping Sequenz.
Philipp E. schrieb: > Die Sequenz hängt nur von der ID des Senders ab und ist daher > immer gleich. Also bezogen auf die ID. Die variiert natürlich von Sender zu Sender.
Philipp E. schrieb: > Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob > ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original > hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir > sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen > einen "gemeinsam". Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da ist, davor hat es keinen Sinn > Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das > Nuvoton-Forum, die leider abgelehnt wurden. Jop, leider.
Manuel Steiner schrieb: > Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da > ist, davor hat es keinen Sinn Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-)
Philipp E. schrieb: > Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-) Klaro, Robert hat das zwar schon gemacht, aber vielleicht kann man da ja noch mehr rausholen. nosilent hat so einen Saleae Clone, und ich habe einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz funktionieren, aber leider nur One Shot und nicht kontinuierlich wie de saleae Teile, die den PC als Buffer verwenden. Ich hoffe es dauert nicht mehr all zu lange.
Manuel Steiner schrieb: > Robert hat das zwar schon gemacht Ich dachte irgendwie, der Trace war unvollständig. Habe ich mir das falsch gemerkt? Manuel Steiner schrieb: > Saleae Clone, und ich habe > einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz Das ist ja super. Damit müsste sicher ein guter Trace rauskommen.
Philipp E. schrieb: > Hier gab es doch jemanden, der das Original > hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir > sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen > einen "gemeinsam". Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir nur wo ich ihn hin schicken soll.
Robert Knipp schrieb: > Klar, kein Ding. Hatte ich ja eh schon angeboten. Wahnsinn. Danke! Klasse Sache!!! Da mein Copter noch nicht da ist, nützt mir das gute Stück leider im Moment nichts. Ich denke Tim wäre ein guter Ansprechpartner, falls er Zeit und Lust hat. Die Sache mit dem BuLink ist ja etwas ungewiss atm ;-) Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung, die dieses unlock + erase vollständig auf allen relevanten Leitungen Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden, dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat. Danke schonmal für deine Mühe!
Philipp E. schrieb: > Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal > eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann > mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung, > die dieses unlock + erase vollständig auf allen relevanten Leitungen > Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden, > dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat. Genau, der hat die Aufzeichnung selbstständig abgebrochen. Keine Ahnung warum. Ist auch das erste mal dass ich mit nem LA etwas mache. Daher fehlt mir da noch etwas die Erfahrung. Daher verleihe ich auch gern den NuLink. Ihr könnt damit wohl erstmal mehr anfangen als ich.
Haben will schrieb: > Ist das der richtige? Ja. Viel billiger als "PayPal" ist "Kredietkarte" nach wie vor nicht: http://www.aliexpress.com/item//1082441152.html Haben will schrieb: > Will mir so 3 bis 5 von den Dingern shoppen. Der übliche Hinweis: Einen nach dem anderen kaufen. Erst wenn der eine auf "versendet" steht, den nächsten. Alles was am gleichen Tag aus China abgeschickt wird, kann vom Zoll zusammen addiert werden, und dann zahlst Du drauf! Haben will schrieb: > Aber eine Sammelbestellung gibt es jetzt nicht, oder? Kann noch kommen, dann aber ohne Fernbedienung. Das Problem: Einzeln_ohne_Zoll mit Fernbedienung ist vielleicht billiger als eine Sammelbestellung mit_Zoll und ohne Fernbedienung.
Robert Knipp schrieb: > Philipp E. schrieb: >> Hier gab es doch jemanden, der das Original >> hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir >> sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen >> einen "gemeinsam". > > Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den > Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir > nur wo ich ihn hin schicken soll. Hallo Robert, vielen Dank für das Angebot. Ich würde gerne mein Glück versuchen. Du bekommst eine PM von mir.
Tim schrieb: > Jetzt wird der BU-Link plötzlich nicht mehr angeboten: > > http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html > > Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam Oh! Habe neulich auch einen geordert. Wurden soviel bestellt das die schon ausverkauft sind? Der Anbieter hat etliche Programmier-Interface im Angebot. Mal nachhaken.
So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja weiter.
> Wurden soviel bestellt das die schon ausverkauft sind? Es sieht so aus, dass die Firma nicht mehr existiert. Die Webseite ist ist nicht erreichbar: http://www.betemcu.cn
Robert Knipp schrieb: > So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja > weiter. Ich bin schon gespannt! Davis schrieb: >> Wurden soviel bestellt das die schon ausverkauft sind? > > Es sieht so aus, dass die Firma nicht mehr existiert. > Die Webseite ist ist nicht erreichbar: http://www.betemcu.cn Die Website ging schon vorher nicht. Den Aliexpress-shop gibt es aber noch. Nur bietet man das Produkt nicht mehr an.
Hi, das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach den Seiten ab, auch wenn ich versuche zu trimmen.... Habe mir besseres erwartet :-(
Kalle S. schrieb: > das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug > auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach > den Seiten ab, auch wenn ich versuche zu trimmen.... Meiner ist ziemlich stabil. Schaue mal hier: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere...
Meine beiden sind da ich musste 9euro zoll zahlen :) geht ja noch 50€ die kopter
Tim schrieb: > Kalle S. schrieb: >> das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug >> auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach >> den Seiten ab, auch wenn ich versuche zu trimmen.... > > Meiner ist ziemlich stabil. Schaue mal hier: > Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere... Danke Werde ich mal probieren. Frage : habe schon jemand ein anderes Netzteil fündig Akkus probiert?
Turbonator schrieb: > Meine beiden sind da ich musste 9euro zoll zahlen :) Dann hast Du wohl beide zusammen bestellt? > geht ja noch 50€ > die kopter War aber nicht nötig, der einzelne Copter wäre ganz legal ohne Kosten durchgegangen. Bei Käufen aus Fernost (oder Fernwest) immer die 22€-Grenze (bzw. 5€-Grenze für Gebühren) für EUst im Auge behalten. Sammelbestellungen lohnen sich da fast nie. Lieber zwischen den Bestellungen ein paar Tage oder Wochen warten. Ansonsten frisst die fällig werdende EUst den Preisvorteil auf. ...
Angehängte Dateien:
-
LED_Links_Dsc_6233.jpg
9,6 KB
Hannes Lux schrieb: > Lieber zwischen den Bestellungen ein paar Tage oder Wochen warten. Wie lange denn nun? ;) Torsten C. schrieb: > Einen nach dem anderen kaufen. Erst wenn der eine > auf "versendet" steht, den nächsten. @Hannes: Nicht gelesen oder anderer Meinung? Disclaimer: Es geht nicht ums "Recht haben", sondern darum, was später im Wiki steht. PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade "gestorben", siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI" Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden: 1. Meine Familie will, dass die LED-Leiste an der Wohnzimmerdecke endlich fertig wird (rechte Hälfte, Bild). 2. Ich muss endlich das Lochraster-Layout fertig machen, siehe Beitrag "Gitter-Drill (Trennstellen)" 3. Das Aquariumforum quengelt wegen eines LED-Strip-PWM-Dimmers: http://www.aquariumforum.de/threads/350068-sammelpost-rigid-stripes-test-fragen-beckenvorstellungen/page11?p=2346959&viewfull=1#post2346959 Das muss nun erstmal erledigt werden. Sorry.
Angehängte Dateien:
-
Nu-Link-PCB-fs.jpg
250 KB -
Nu-Link-PCB-rs.jpg
220 KB -
log.png
23 KB
Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten gefunden. Das ging ja wirklich schnnell! Viel dran ist nicht. Ich habe mal Bilder der Platine gemacht. Der Prozessor wurde erkannt. Auch wurde sofort gefragt, ob ich einen Chip erase durchführen will. Der Chip erase selbst dauert sehr lange, wobei eine sehr große Menge Daten über SWD geschaufelt werden, wie auf dem Screenshot zu sehen. Anbei ein Log des Datenaustausches zur Identifikation des Chips. Das Log des Erase-Vorgangs ist >100mb gezippt. Wo könnte ich das hochloaden? Ich muss jetzt erst einmal schlafen. Evtl. finde ich morgen noch etwas Zeit.
Hm, was wird da wohl in dem Flash drin stehen? Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt. Achso das File geht das nicht auch bei github rein?
Torsten C. schrieb: > @Hannes: Nicht gelesen oder anderer Meinung? Gelesen sicher, aber wieder vergessen, denn ich lese die Threads nicht in einem Stück, sondern immer mal wieder die neuesten Beiträge. Da gerät sowas schon mal in Vergessenheit. Anderer Meinung bin ich diesbezüglich nicht. Nur kann oder will man nicht immer warten, bis der erste Artikel da ist. Dazu ist die Ware einfach zu lange unterwegs. ...
Hannes Lux schrieb: > Nur kann oder will man > nicht immer warten, bis der erste Artikel da ist. Nee, da würde man ja kirre werden. Das hat m.E. auch niemand vorgeschlagen.
Tim schrieb: > Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten > gefunden. Das ging ja wirklich schnnell! Super. Nochmal vielen vielen Dank an Robert! Tim schrieb: > Anbei ein Log... Klasse, auch dir tausend Dank, das du direkt den LA dran gehängt hast! Tim schrieb: > Wo könnte ich das hochloaden? Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log vom Erase... Tim schrieb: > Erase-Vorgangs ist >100mb Mhhh, damit wird das ganze vermutlich etwas komplexer als gedacht. Was könnten das wohl alles für Daten sein. Vielleicht ist es erst einmal das eigentliche unlocking und danach wird dann wie bei Keil ein Erase Tool in den Flash / Ram vom uC geschaufelt? Könnte es weiterhin sein, dass der Erase vlt. so lange braucht weil es viel zu löschen gibt? Kannst du den Chip noch einmal locken (aber sonst leer lassen) und noch mal das Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem nicht gelockten (und ebenfalls leeren) Chip interessant. Ach ja, eine Frage noch: Kommt eigentlich auch was vom Chip zurück? Oder sendet der ICP nur? Torsten C. schrieb: > Im Moment muss ich erstmal etwas pausieren. Mach dir keinen Stress. Soll doch alles Hobby und Spaß bleiben. Und der Wiki Artikel kann ja über die Zeit wachsen. Außerdem muss er ja nicht jedes Detail dokumentieren. Je mehr dort steht, umso besser, aber wenn etwas dort nicht dokumentiert ist, kann das ja über die Zeit wachsen. Der Artikel ist in meinen Augen für den "frühen" Projekt Status schon auf einem super weg, ich denke das wird so weiter gehen. Jeder trägt bei, was er hat bzw. möchte bzw. kann und dann wird das schon.
Philipp E. schrieb: > Tim schrieb: >> Wo könnte ich das hochloaden? > > Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell > angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log > vom Erase... Guter Punkt. Einen Account habe ich dort eh. Hier ist das File: https://www.dropbox.com/s/l4xuxvaw1ielv19/connect%20and%20chip%20erase.zip Der Rest liegt im GitHub-Repository https://github.com/hackocopter/Documentation/tree/master/Nu-Link
Angehängte Dateien:
-
log.png
23 KB -
erase-preamble.png
41 KB -
grosser-signalblock.png
22 KB
Hier noch einmal ein paar Details zum Datenverkehr auf dem SWD-Interface. Das SWD-Intarface besteht aus zwei Leitungen: SWDCLK und SWDIO. SWDIO ist bidirektional. Die Datenrichtung wird dabei vom Master festgelegt. Der Chip-ERase Vorgang wird durch eine sehr kurze Sequenz eingeleitet, wie auf dem mittleren Bild zu sehen (3). Dann kommt für 25ms nicht. Diese Zeit kann eigentlich nur zum Chip-Erase reichen, wenn wirklich das ganze Flash gleichzeitig gelöscht wird. Diesen Teil hatte Robert auch oben schon einmal gepostet. Anschließend wird für eine sehr lange Zeit (20s) immer wieder die gleiche Sequenz gesendet. Bei mir kam dieser Vorgang immer erst zum erliegen, wenn ich auf "disconnect" in der ICP-Software geklickt habe. Der Controller war danach trotzdem entsperrt. Daher kann es sein, dass die lange Sequenz nicht unbedingt notwendig ist. p.s. die logfiles kann man mit Saleae Logic öffnen. Die Software ist für Testzwecke frei herunterladbar: http://www.saleae.com/downloads
Torsten C. schrieb: > PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade > "gestorben", > siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI" > > Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein > hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden: Hi Torsten, ich denke das Wiki wird sich von ganz alleine weiterentwickeln. Du hast ja schon einen sehr guten ersten Schritt gemacht. Man sollte nur häufiger darauf hinweisen dass es den Eintrag auch gibt. Daher hier noch einmal der Link auf den Artikel: http://www.mikrocontroller.net/articles/Hack-O-Copter Das wichtigste ist dass die Leute zum Artikel beitragen wenn sie Lust haben. Wenn vorher zu viele Regeln festgelegt werden schreckt das nur ab. Aufräumen kann man später immer noch.
Informationen zu SWD und freie Implementierungen sind immer noch recht spärlich. Hier einmal das, was ich bisher gefunden habe: Im MCHCK-Projekt gibt es eine SWD bit-bang Minimalimplementierung. Leider alles ziemlich wenig dokumentiert: https://mchck.org/ https://www.evernote.com/shard/s13/sh/2557f123-e1fd-4d04-b053-0adac1945c74/6343ffac964a01863d817690f27bbfb5 https://github.com/mchck/mchck/tree/master/bootloader/swd-adapter/swduino Dann natürlich Versaloon: http://www.versaloon.com/ Black Magic probe: http://www.blacksphere.co.nz/main/blackmagic https://github.com/gsmcmullin/blackmagic SWD Einführung http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one Hier noch Links von Manuel Steiner (Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter") damit alles an einem Platz ist: Ich hab letztens mal libswd gefunden: http://sourceforge.net/apps/trac/libswd Das ist eine SWD Library. Auf dieser Seite waren unter anderem folgende Dokumente zu SWD verlinkt: http://www.arm.com/products/system-ip/debug-trace/... http://www.arm.com/files/pdf/Low_Pin-Count_Debug_I... An die genaue Spezifikation kommt man wahrscheinlich nur als ARM Partner :/ Edit: Die ARM Debug Interface Architecture Specification könnte noch interessant sein. (Kapitel 5.2) http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
Die Frage ist, ob es ausreicht einen Mikrocontroller so zu programmieren, dass er die Sequenzen aus "erase-preamble.png (3)" und 1x den Wiederholer aus "grosser-signalblock.png" zum Löschen sendet? Reicht das zum Löschen? Wenn nicht, was ist noch wichtig? Der Abschnitt ID-Device?
Ohne genaue Kenntnis des SWD Protokolls wird es fast unmöglich sein, die gesuchten Befehle zu finden. SWD ist bidirectional, wie soll man aus dem Mitschnitt erkennen, was der Nulink gesagt hat und was die Antwort war?
> Bei Käufen aus Fernost (oder Fernwest) immer die 22€-Grenze (bzw. > 5€-Grenze für Gebühren) für EUst im Auge behalten. Sammelbestellungen > lohnen sich da fast nie. Lieber zwischen den Bestellungen ein paar Tage > oder Wochen warten. Ansonsten frisst die fällig werdende EUst den > Preisvorteil auf. > > ... Artikel Standort Frankfurt. ?.......war angegeben
ist es mòglich die Daten binàr zu bekommen, also in definiertem Interval ein byte ist ein Sampling. Ev mit Sigrok, da geht es das Sampling als raw abzuspeichern. Hintergrund, damit kann ich dann das SWD Protokoll aufdòseln, zumindest nach Cortex M3 Docs.
Tim schrieb: > Edit: Die ARM Debug Interface Architecture Specification Genau das hat mir gefehlt! Super. Nun den Mitschnitt als Folge von Nullen und Einsen (positive Flanke von SCK ist Abtastzeitpunkt) und mit ein paar Zeilen Code kann man es grob aufdröseln.
Anbei die Daten von oben als Binary dump. Jedes Byte ist ein Sample bei 16MHz Abtastfrequenz. Bit0 =SWData Bit1=SWCLK. Man kann die Daten auch nur Abschnittsweise oder in anderen Formaten aus Logic exportieren. Ich hatte noch nicht so viel Zeit, mich mit der Interpretation zu beschäftigen. Was mir bisher aufgefallen ist: - Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der Richtung des Datentransfers ab: Host->Target steigende Flank von Clk Target->Host fallende Flanks von Clk Das sieht man auch gut in dem SWD Bitbanging Source, der oben verlinkt ist.
1 | static void |
2 | write_bits(uint8_t buf, size_t bits) |
3 | {
|
4 | pin_configure(SWD_DIO_PIN, SWD_MODE_OUTPUT); |
5 | for (; bits > 0; --bits, buf >>= 1) { |
6 | pin_write(SWD_CLK_PIN, 0); |
7 | pin_write(SWD_DIO_PIN, buf & 1); |
8 | pin_write(SWD_CLK_PIN, 1); |
9 | }
|
10 | }
|
11 | |
12 | static void |
13 | read_bits(size_t bits, int silent) |
14 | {
|
15 | uint8_t val = 0; |
16 | |
17 | pin_configure(SWD_DIO_PIN, SWD_MODE_INPUT); |
18 | size_t bit; |
19 | for (bit = 0; bit < bits; ++bit) { |
20 | pin_write(SWD_CLK_PIN, 0); |
21 | val |= !!pin_read(SWD_DIO_PIN) << bit; |
22 | pin_write(SWD_CLK_PIN, 1); |
23 | }
|
24 | if (!silent) |
25 | reply_write(&val, 1); |
26 | }
|
Hi, Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den SWD um eine Statusmedllung zu erhalten Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte Flash, das dauert eben etwas. Versuche zu identifizieren was in der langen Leer Phase passiert und teile die ganze Übertragung in drei Teile. Unlock -> Status polling -> Antwort. Gruß Martin
Tim schrieb: > - Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der > Richtung des Datentransfers ab: > Host->Target steigende Flank von Clk > Target->Host fallende Flanks von Clk Bild 6 in "LPC Debug Interfaces" sagt, dass die Daten immer mit der steigenden Flanke gültig sind, egal, wer sendet. Bild 5-1 in der ARM Debug Spec sagt, dass es immer die fallende Flanke ist, egal, wer sendet. Nun darfst du dir aussuchen, was richtig ist :-) (Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer die steigende Flanke, das Target legt nach der fallenden Flanke die Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man gelesen hat und Target bitte das nächste Bit bereit stellen möge.)
Angehängte Dateien:
-
line_reset.png
47 KB
> Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis > der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den > SWD um eine Statusmedllung zu erhalten > Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte > Flash, das dauert eben etwas. > > Versuche zu identifizieren was in der langen Leer Phase passiert und > teile die ganze Übertragung in drei Teile. Unlock -> Status polling -> > Antwort. Hi Martin, das kann gut sein. Es Großteil des Datenverkehrs scheint nur aus der "line reset sequence" (50x CLK während IO high ist) zu bestehen. Wahrscheinlich wartet der Adapater einfach nur darauf, dass das Target eine gültige Antwort zurück sendet. Siehe auch 5.4.1 http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf Direkt am Anfang macht er bereits 4x einen Line-Reset, ohne dass eine Antwort zu kommen scheint.
Georg G. schrieb: > (Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer > die steigende Flanke, das Target legt nach der fallenden Flanke die > Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man > gelesen hat und Target bitte das nächste Bit bereit stellen möge.) Ja, aber dadurch ändern sich die Daten auf/nach der steigenden Flanke und sind damit dort nicht gültig. Im LA Log kann das durchaus zu Glitches führen, wie man an ein paar Stellen sehen kann.
So morgend werde ich dem Zoll die Rechnung schicken und dann ist das Teil hoffentlich auch bald hier und dann brauch ich keinen "Blindflug" bezüglich der Hardware mehr zu machen.
Interessanter Link: Beitrag "Re: Flash im Cortex-M0 durch Codeinjektion ins SRAM auslesen" Es sieht so aus, dass der "Frankfurter"-Copter nicht gelockt ist.
Ich habe den Bitstream extrahiert und das vorlàufige Ergebnis ist dieses. Warscheinlich sollte die binary noch gefiltert werden. Morgen kann ich mehr berichten. x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 data parity error SWD(2) DAP Write = 0xf3181132 ack = 7 data parity error SWD(1) AP Write = 0xf0981032 parity error header x ack = 4 fault parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc28048c
Nur zur schnellen Erklàrung:
parity error header -- discard bit and repeat header parsing.
Ack error -- Protocol error, no answer from target
data parity error -- parity error on 32bit data field.
Unter umstànden ist die Pause nach dem Protokoll Fehler. Wenn dem so
ist,
dann ist es nicht die gesuchte Sequenz.
Im Header wird neben Parity auch getestet, ob Stop bit 0 ist.
Dies gibt einen eigenen Fehler, welcher hier nie aufgetreten ist.
Wenn mehrere parity error header hintereinander auftreten, stimmt was
nicht.
Ich will noch einen Filter fuer die Raw Daten reinmachen,
und dann anstelle oder zusàtzlich zum derzeitigen Debug Ausgabe
ein Replay C File generieren damit man dann testen kann, ob man dies
mit irgendeiner CPU raufspielen kann, ungeachtet aller Timings.
Hier mein derzeitiger Code , der Rueckgabewert ist die Anzahl der bits
to discard, data ist 64bit bitstream Variable als einziges Argument der
Funktion.
header = data>>(64-8);
write = lsb(1,2,data);
addr = lsb(2,3,data);
ack = lsb(3,8+1,data);
dat = lsb(32,8+4+write,data);
par = lsb(1,8+4+write+32,data);
if(header&2) return puts("stop error"),1; // test stop bit
if(parity(header&0x7c)) return printf("parity error header "),1;
if(!ack) return printf("Ack error "),9;
printf(" ack = %d ",ack);
if(ack==2) return puts(" wait "),8+4+1; // wait
if(ack==4) return puts(" fault "),8+4+1; // fault
if(parity(dat)!=par) puts("data parity error");
printf(" SWD(%d) %s %s = %#x\n",addr,
header&0x40?"AP":"DAP",header&0x20?"Read":"Write", dat);
return 14+32;
}
Chris
No y. schrieb: > was wird da wohl in dem Flash drin stehen? > > Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man > dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt. Das ist ein 16mbit Device. Da wird wohl etwas mehr drin gespeichert sein als nur VID/PID. Nur was? Auslesen will ich es lieber nicht, ich will den NU-Link nicht beschädigen.
Angehängte Dateien:
-
glitch.png
38 KB
chris schrieb: > x > parity error header x > ack = 1 SWD(1) DAP Write = 0x997dec09 > ack = 1 data parity error > SWD(1) DAP Write = 0x197ccc09 > ack = 7 SWD(2) DAP Write = 0xf3181332 Ich habe mir inzwischen noch einmal einige Stellen das Protokolls per Hand angeschaut. Es wird sehr lange einfach nur "Line Reset" und "Read IDCODE" gesendet, worauf das Target nicht zu antworten scheint. Erst ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt. Übrigens musste ich zur Auswertung des Anwort des Targets tatsächlich die fallende Flanke auswerten, da es manchmal am Übergang Glitches gab. Evtl. müsstest Du das in Deinem Code auch berücksichtigen. Der Screenshot zeigt ein "READ"-Feld, in dem das Target sendet. Manchmal hat der LA einen Übergang auf der steigenden Flanke gesampled, machmal danach.
chris schrieb: > Nur zur schnellen Erklàrung: > parity error header -- discard bit and repeat header parsing. > Ack error -- Protocol error, no answer from target > data parity error -- parity error on 32bit data field. Also wenn ich das richtig verstehe, ist das Log auf dem Post oben aus einem Bereich wo das Target nicht antwortet. t. > Ich will noch einen Filter fuer die Raw Daten reinmachen, > und dann anstelle oder zusàtzlich zum derzeitigen Debug Ausgabe > ein Replay C File generieren damit man dann testen kann, ob man dies Ich fürchte ja fast, dass es nicht ausreicht, einfach nur die Signalsequenz zu wiederholen. Es ist wohl notwendig, die Registerzugriffe zu extrahieren und mit einem simplemen SWD-Treiber wieder abzuspielen. Aber zum Glück ist das Low-Lowevel Protokoll ja relativ einfach. > mit irgendeiner CPU raufspielen kann, ungeachtet aller Timings. > Hier mein derzeitiger Code , der Rueckgabewert ist die Anzahl der bits > to discard, data ist 64bit bitstream Variable als einziges Argument der > Funktion. Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? P.s.: Ich habe per Hand den IDCODE 0x0BB11477 ermittelt. Dabei stimmt die Vendor Id in [11:] = 0x23B, allerdings ist die Device ID in [27:12] mit 0xBB11 evtl. nicht richtig.
Tim schrieb: > ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation > statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt.
Tim schrieb: > ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation > statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt. Hier ist auch die Datei.
> Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das > evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? > Vom binary dump durch das Programm swd_dat generiere ich eine Datei, welche den Bitstream enthàlt, bei steigender Flanke von clk. Ich lese diesen Bitstream dann in der Variable data ein, Msb first. Aus diesem Grunde gibt es die Funktion lsb(len,offset,data) welche den lsb first Wert aus data zurueckgibt. Parity gibt das parity bit zurueck. > P.s.: Ich habe per Hand den IDCODE 0x0BB11477 ermittelt. Dabei stimmt > die Vendor Id in [11:] = 0x23B, allerdings ist die Device ID in [27:12] > mit 0xBB11 evtl. nicht richtig. Ich habe den Verdacht, dass die Turnaround time veràndert wird und es dadurch dann zu Timingverschiebung kommt. Gibt es eine Mòglichkeit die Geschwindigkeit runterzusetzen, kònnte ein Workaround sein, damit die Turnaround Zeit nicht raufgesetzt wird. Zum Programm, sind einfach gemacht, Daten werden als stdin eingelesen, und ueber stdout ausgegeben, also cmd Umleitung verwenden. dump -- was àhnliches wie hexdump, wenn man ein x-beliebiges Argument dazugibt, dann werden gleiche Daten ignoriert. swd_dat -- convertiert das Binary in einen gueltigen Datenstream, eine Art spi protokoll decoder. swd_dump -- dump der Kommunikation. Derzeit rudimentàr. -v als Argument gibt mehr verbosity info, man sollte dies mal probieren, derzeit max drei mal hintereinander.
Tim schrieb: > Informationen zu SWD und freie Implementierungen sind immer noch recht > spärlich. Hier einmal das, was ich bisher gefunden habe: Vor kurzem war in einem Thread: Beitrag "Logic analyzer HP, Tek - Protokollauswertung" von einem Zeroplus Logic Analyzer die Rede bei welchem der Käufer aus einer Reihe von Protokollanalyseoptionen wählen kann. Einer davon war der SWD. Eventuell hat den einer oder weiss von jemanden der einen hat?
Mein Sourcecode basiert auf diesen Link: http://theesan1688.wordpress.com/2012/11/10/implementation-of-serial-wire-jtag-flash-programming-in-arm-cortex-m3-processors/
Zum Thema "Daten erfassen": SWD ist bis 50MHz Takt spezifiziert. Das sind 20ns. Da wird es also keine langen Haltezeiten geben. Unmittelbar nach der gültigen Flanke ist das Signal schon wieder weg. Eine asynchrone Aufzeichnung müsste also mit 100MHz erfolgen. Das ist unrealistisch und ergibt einen Wust an Daten. Der Saleae kann auf Flanke triggern. Also warum nicht die Datenerfassung auf der positiven Clock Flanke machen? Eventuell zusätzlich zwei Inverter zwischen Nulink-Takt-Ausgang und Board-Takt-Eingang schalten, den Saleae mit seinem Trigger Kanal am Nulink. Das könnte 10ns Sicherheit geben (in der Hoffnung, dass der Nulink etwas Haltezeit für die Daten hat). Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen Stellen aber nicht sicher.
Hat jemand eigentlich schonmal die arduino Software von https://bitbucket.org/rivig/v202/src/c2142a790c463abff9004b761e013cff6735f50b/V202_arduino/?at=default mit dem copter ans laufen bekommen? Ich hab da jetzt mal ein bisschen mit rumgespielt (atmega328p + nrf24l01) aber bei mir bindet der copter nicht mit der Software. :-\ Gruss, Simon
Simon schrieb: > Hat jemand eigentlich schonmal die arduino Software von > https://bitbucket.org/rivig/v202/src/c2142a790c463abff9004b761e013cff6735f50b/V202_arduino/?at=default > mit dem copter ans laufen bekommen? > Ich hab da jetzt mal ein bisschen mit rumgespielt (atmega328p + > nrf24l01) aber bei > mir bindet der copter nicht mit der Software. :-\ Ich glaube Helmut hat das hinbekommen, wenn ich seine Bemerkung richtig interpretiere. Helmut H. schrieb: > https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit > byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber > auch wenn [14]==0 ist. > > NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als > über die Fernbedienung :-) Magst Du uns verraten, was Du hier gemacht hast? :)
Georg G. schrieb: > Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae > Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI > etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen > Stellen aber nicht sicher. Ist nicht 1.1.15 die neuste Version?
Tim schrieb: > Ist nicht 1.1.15 die neuste Version? Das ist richtig. Aber ich suche den alten User Guide.
Habs mit dem Original nicht probiert, aber müsste eigentlich wenn man
einen der #if 0 für die Definition der txid's zu #if 1 macht
Mit dem angehängten Testprogramm, das davon geklaut ist, gehts mit
uint8_t txid[3] = { 0xcd, 0x31, 0x71 } bei meinen beiden Helis.
* Stromlosen Heli mittels handelsüblichen Nähgarns(z.B. "Sternzwirn
hohreißfest") so an einer Unterlage befestigen, so dass er sich zwar
bewegen, aber nicht entkommen kann
* Software auf Arduino starten (benutze 8 für CE und 9 für CSN)
* Terminal mit 115200
* tippe H für Hopping-Kanäle aus der o.a. txid berechnen
* tippe s für senden, man sieht die gesendeten Werte von buf[0] bis
buf[3]
* Heli stromversorgen
* Warten bis er langsam blinkt
* tippe b für Binden, das schickt einfach 50 bind-Sätze.
* Heli LEDs bleiben an
* Üben mit +, -, i,j,k,m. Das ändert throt um 10 (von 0-255), roll und
pitch um 4 (von 0x19 ..0 oder ox80 ..0x9f)
* Leertaste setzt alle Werte wieder auf 0 zurück.
* Nähgarn durchschneiden
Mit anderen txids funktioniert das Binden nur manchmal, habe mich aber
nicht weiter darum gekümmert.
N.B: Interessante Erfahrung, wenn Programmier- oder Bedienungsfehler
sofort mit Schmerzen bestraft werden. Beabsichtige dies als "Taktile
Feedback Driven Super Agile Software Development" zu vermarkten.
Nabend Leute, Interessanter Thread! Cooles Projekt. Wie oben schon mal angefragt, hätte ich hier einen LA von Zeroplus, der kann das SWD Protokol analysieren. Ich weiß nicht genau wie weit ihr seid und ob das noch was helfen könnte? Gruß Daniel
Hmm irgendwas stimmt mit meiner atmega nrf24l01 connection nicht.
Prinzipiell sieht die Verbindung wohl gut aus, beim init bekomme ich
das:
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0x8686866688 0x6868688866
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0x8686866688
RX_PW_P0-6 = 0x10 0x10 0x00 0x00 0x00 0x00
EN_AA = 0x00
EN_RXADDR = 0x03
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGH
Ich sehe mit dem LA auch auf MOSI/MISO die geschriebenen und gelesenen
Werte.
Aber wenn ich auf senden gehe (mit debugflags) dann bekomme ich:
*** CHANGING TO SEND ROLE -- PRESS 'r' TO SWITCH BACK
write_register(11,10)
write_register(12,10)
write_register(02,03)
Writing Pipe
write_register(00,0e)
write_register(07,70)
...OK.write_register(00,0c)
00 00 00 00
write_register(05,1f)
write_register(00,0e)
write_register(07,70)
...Failedwrite_register(00,0c)
00 00 00 00
write_register(00,0e)
write_register(07,70)
...Failedwrite_register(00,0c)
00 00 00 00
write_register(05,3d)
write_register(00,0e)
write_register(07,70)
...Failedwrite_register(00,0c)
Also mal gehts mit ok durch, zu 99% endet das senden aber mit Failed.
Hat irgendjemand einen Tipp für mich?
Gruss,
Simon
Also irgendwas ist bei meiner RF24.cpp im argen, da ist schonmal beim senden CE LO und HIGH vertauscht... Helmut: könntest Du noch deine RF24.h/cpp, RF24_config.h und nRF24L01.h posten? Das wäre super. Gruss, Simon
Ok, Problem gelöst... Ich habe das mit nem chinesischen arduino nano 3 clone getestet. Das NRF24L01 (ohne pa) hab ich an den 3.3V out vom ftid (wie ich dachte) gehängt, der kann ja normalerweise bis 60mA liefern. Sollte für die 10mA vom nrf24 also reichen. Zumindest für den ohne PA, für den leistungsfähigen mit PA braucht man ja eh nen 3.3V Regler. ACHTUNG: (zumindest mein) Clone hat nen PL2303, der liefert wenn überhaupt nur 19mA für PL2303 + NRF24. Das führte dazu dass sich mein NRF24 immer geresettet hat. Lösung: 3.3V Regler für den NRF24. Gruss, Simon
@Simon: schön dass es funktioniert. Simon schrieb: > Helmut: könntest Du noch deine RF24.h/cpp, RF24_config.h und nRF24L01.h > posten? Das wäre super. Nur der Vollständigkeit halber: Erforderlich sind die aktuellen Dateien von https://github.com/maniacbug/RF24 nach libraries/RF24. Habe nichts daran geändert.
Gibt es mittlerweile etwas neues vom Bu-Link? Oder von den analysierten Unlock Sequenzen?
Das neue über den von mir bestellten Bulink ist, dass er noch nicht da ist :-(
Hi ich will die Reichweite erhöhen sender/Empfänger wo bring ich die antenne am besten an ? Hat jemand schonmal die reichweite getestet. Bei mir sind 80 meter möglich, 200-500m wären gut .
Turbonator schrieb: > Bei mir sind 80 meter möglich, 200-500m wären gut . Ich habe es bisher noch nicht geschafft die Reichweite zu überschreiten. Wie denn auch? Wenn er so weit weg ist sieht man ihn sowieso nicht mehr, das einzige was man damit erreichen würde wäre, dass er unkontrollierbar (da fast nicht mehr sichtbar) irgendwo abstürzt.
Ich Bestelle mir ne funk Kamera diese woche noch und da wäre es schön auf dem feld etwas weiter fliegen zu können ich seh das teil auch noch auf 500m
Heute hat mir der Postmann Flattermaxe Nummer 3 gebracht, aber vom Bulink noch keine Spur :-(
Ich habe leider in den letzten Tagen keine Zeit gefunden, mich weiter mit dem copter zu beschäftigen. Das wird sich aber hoffentlich wieder ändern. Nur kurz ein paar Kleinigkeiten: - Das Bu-Link ist immer noch nicht da. - Programmieren mit dem Nu-Link funktioniert wunderbar. Das CMSIS-Blinky ist jetzt auch auf richtiger Hardware erprobt. Auch die Ausgabe über die serielle Schnittstelle funktioniert: https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS -Die Platinen für den LiPO-Charger sind angekommen. Leider konnte ich ihn noch nicht testen, da mir das IC noch fehlt. Aus einem mir unerfindlichen Grund hat OSH-Park mir sogar die doppelte Anzahl an Platinen geschickt. Daher würde ich an die ersten drei, die mir ihre Adresse per PM schicken, eine abgeben. Bitte nur anfragen, wenn ihr später auch hier über euren Aufbau berichtet :) https://github.com/hackocopter/LiPoCharger -Bezüglich der Chip-Erase Sequenz habe ich mir überlegt, eine Low-Level SWD Implementierung zu programmieren. Mit den Beispielen und der Dokumentation ist das nicht sonderlich kompliziert, hilft aber auch das Protokoll besser zu verstehen. Außerdem ist dann die Software zum Unlocken gleich mit fertig.
bezueglich Unlock. Es geht definitiv nicht ueber normales SWD. Teilweise waren logs da, wo SWD waehren Reset gemacht wurde, andererseits existieren Logs mit speziellen High Waveforms welche definitiv nicht das SWD Protokoll sind. Es waere hilfreich, zwei komplette Logs zu haben, einmal von einem ungesperrten Baustein, und einmal von einem welcher looked ist und testen, ob es da differenzen gibt.
Philipp E. schrieb: > Kannst du > den Chip noch einmal locken (aber sonst leer lassen) und noch mal das > Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem > nicht gelockten (und ebenfalls leeren) Chip interessant. chris schrieb: > Es waere hilfreich, zwei komplette Logs zu haben, einmal von einem > ungesperrten Baustein, und einmal von einem welcher looked ist und > testen, > ob es da differenzen gibt. Glaube auch das die beiden Logs zusammen sehr hilfreich wären. Dann könnte man das SWD darin parsen und schauen was dann noch für Waveforms übrig bleiben.
chris schrieb: > Es waere hilfreich, zwei komplette Logs zu haben Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive Flanke getriggert.
Philipp E. schrieb: > kann mir jemand sagen, was das für ein Connector Im "nRF24LU1 Reference Design" (was anscheinend die 2.4G NRF24lu1p china dongle ist) http://www.freqchina.com/en/down.asp?ID=102 ist ein adapter kabel gezeigt "nRF24LU1 USB Dongle Programming adapter cable", die passende buchse ist in der BOM als "JST BM05B-SRSS-TB" gelistet. Der stecker ist also JST SH familie, 5pin, 1mm pitch.
Ok, weiter gehts. Hier sind ein paar neue Logs: ->connect__protected_device_-disconnect Verbinden und Verbindung wieder trennen. Read protect ist gesetzt. ->connect-chip_erase-disconnect Verbinden, Chip erase und disconnect. Read protect war gesetzt. ->connect-program_fuses_to_protect-erase-disconnect Verbinden, Read protect fuse setzen und disconnt. Read protect war nicht gesetzt. Bit 0- SWDIO Bit 1- SWDCLK Bit 2- Reset (wird nie ausgelöst)
Georg G. schrieb: > chris schrieb: >> Es waere hilfreich, zwei komplette Logs zu haben > > Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive > Flanke getriggert. Das kann der LA leider nicht. Das Triggering bezieht sich wirklich nur auf den Startzeitpunkt der Aufzeichnung. Danach wird einfach nur gesampled. Dafür haben die ganzen "professionellen" LA nicht die Speichertiefe. Letztendlich bin ich aber immer noch davon überzeugt, dass das Protokoll nicht darauf angewiesen ist, innerhalb eines sehr kleinen Zeitfensters zu samplen. Für so etwas wäre auf der Host-seite dedizierte Hardware notwendig. Das Nu-Link, und wahrscheinlich die meisten anderen SWD-Adapter auch, nutzt anscheinend die GPIO Pins an einem normalen Mikrocontroller per "Bit-Banging" Daher ist es gar nicht möglich, ein Clock-Signal auszugeben und gleichzeitig auf einer Flanke zu sampeln.
Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ...
chris schrieb: >> Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das >> evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? >> > Vom binary dump durch das Programm swd_dat generiere ich eine Datei, > welche > den Bitstream enthàlt, bei steigender Flanke von clk. > Ich lese diesen Bitstream dann in der Variable data ein, Msb first. > Aus diesem Grunde gibt es die Funktion lsb(len,offset,data) welche den > lsb first Wert aus data zurueckgibt. Parity gibt das parity bit zurueck. Wie schon oben geschrieben, ich denke hier liegt m.E. das Problem. Daten, die vom Target gesendet werden, müssten auf der nachfolgenden fallenden Flanke ausgelesen werden. Das Einlesen der Daten und der Protokollanalyzer lassen sich demnach nicht trennen. Torsten C. schrieb: > Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die > Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ... Damit würden sich bestimmt einfach binärdaten abfangen lassen. Aber der Befehl, den der Computer an das NU-Link zum Löschen sendet kann ziemlich beliebig sein. 42? 請刪除該芯片? "kill them all"?
Tim schrieb: > Das kann der LA leider nicht Dann muss man mit einem Flipflop zwischen Nulink-Daten und Analyser-Daten nachhelfen, damit die Daten immer zur Flanke passen. Mit freilaufendemTakt kommt es schnell zu Schmutzeffekten. Aber vielleicht haben wir ja Glück.
Ich habe den SWD-Analyzer von Chris etwas erweitert. Aktueller Stand anbei. - Bug: Read und Write waren verwechselt - Bug: lsb(...) wurde bei mir nicht richtig compiliert, da Maskierung nicht long long war - Neu: rising udn falling edge werden ausgewertet - Neu: Analyse in einem Durchgang Leider ergeben die Logs immer noch nicht so recht viel Sinn. Sie sind voll von erfolglosen versuchen, den SWD-Port zu resetten. Ich werde später weiter machen, vermute aber langsam, dass es doch einfacher ist, sich über eine SWD-Implementierung heranzutasten. Welche Sequenz für Chip-Erase verantwortlich ist, lässt sich ja einkreisen.
Tim schrieb: > Ich habe den SWD-Analyzer von Chris etwas erweitert. Bitte noch etwas mehr erweitern: <string.h> mit dazu. Funktionen, die nichts zurück geben als void definieren. Dann meckert LCC32 auch nicht mehr :-)
Georg G. schrieb: > Ich habe den SWD-Analyzer von Chris etwas erweitert. > > Bitte noch etwas mehr erweitern: > <string.h> mit dazu. > Funktionen, die nichts zurück geben als void definieren. Du meinst, ich sollte den Source lieber in das Repository laden? :) Ist schon geschehen: https://github.com/hackocopter/SWD-Hacking mingw-gcc ist übrigens ziemlich schmerzfrei.
Tim schrieb: > mingw-gcc Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man seit mehr als 10 Jahren problemlos arbeitet. Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also nicht z.B. short int sondern int16_t. Ist defensiver. Und immer noch kein Copter gekommen...
Georg G. schrieb: > Tim schrieb: >> mingw-gcc > > Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man > seit mehr als 10 Jahren problemlos arbeitet. > > Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also > nicht z.B. short int sondern int16_t. Ist defensiver. chris scheint K&R C zu programmieren, ich halte mich eher an Ansi-C90/C95. Was Du siehst ist eben der resultierende Mischmasch. Einige casts mit long long haben mir auch ziemliche Probleme bereitet. Werde ggf. den Source noch aufräumen, aber im Moment ist mir die Funktion wichtiger. Die int-typen sind wahrscheinlich C99?
Angehängte Dateien:
-
bulink.jpg
61 KB -
bulink-inside.jpg
190 KB -
Bulink-MCU.jpg
140 KB -
bulink-stecker.jpg
28 KB
Sensation! Obiges lag gerade in der Post. Die Nuvoton-Tools haben es als Nu-Link erkannt und die Software auf den neusten Stand gebracht. Es scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es nur wieder lieferbar sein... Ich bin mit dem Entschlüsseln des Protokolls auch entscheidend weiter gekommen. Später mehr.
Angehängte Dateien:
-
reset_Nu-Link.png
47 KB -
reset_ST-LINK.png
51 KB
Der SWD-Analyzer ist jetzt in der Lage, die meisten Logs komplett fehlerfrei zu interpretieren. Das heisst dass Reset- und Idle Sequenzen, sowie fehlerhafte Pakete (Start/Stop bit, Parity) korrekt identifiziert werden. Dabei hat sich übrigens auch herausgestellt, dass die vermutete Erase-Sequenz von oben in Wirklichkeit eine abgebrochene Reset-Sequenz ist. Die Reset-Sequenz des Nuvotons hat gegenüber der Spezifikation allerdings einen zusätzlichen Low-Zyklus auf der Datenleitung. Oben zum Vergleich ein Reset vom Nu-Link und ST-Link. Ob das einfach nur ein Bug, oder doch relevant ist, lässt sich noch nicht sagen. Die meisten der bisher geposteten Logs werden mit 0 erkannten Fehlern geparsed. Dieses ist recht beeindruckend, da das bedeutet dass das Log der Host-Kommunikation fast frei von Bitfehlern ist. Bei teilw. >8e8 Samples schons bemerkenswert. Leider gilt das nicht für die Rückmeldungen vom Target, die etliche Übertragungs- und Paritätsfehler enthalten. Ich werde hier wohl doch noch einmal an die HW müssen... Aktueller Stand hier: https://github.com/hackocopter/SWD-Hacking/tree/master/SWD-Analyzer
Tim schrieb: > s > scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es > nur wieder lieferbar sein... Wow, das hört sich ja wirklich toll an. Aber schade, dass der jetzt nicht mehr lieferbar ist. Ich glaube die Post wollte mir heute meinen Quad auch endlich bringen, bin gespannt auf morgen.
Angehängte Dateien:
-
SWD-register.png
35 KB
So, jetzt funktioniert der SWD-Analyzer. Es wird der komplette Datenverkehr ohne Bit- und Paritätsfehler geparsed. Erstaunlicherweise funktioniert das mit 16M Samplerate sogar noch bei 4Mhz SWD-Clock. https://github.com/hackocopter/SWD-Hacking/tree/master/SWD-Analyzer Ein nerviges Problem war die Gültigkeit der Daten vom Target. Es stimmt natürlich, dass diese bei der steigenden CLK-Flanke herausgeclocked werden. Durch die Gatterlaufzeit im Target, erscheinen die Daten natürlich verzögert am Ausgang, was im LA zu glitches führt. Was mich am Anfang verwirrt hat, ist dass die Daten bereits im vorhergehenden Taktzyklus herausgeclocked werden. Dafür gibt es die Turnaround cycles. Ich habe das Problem jetzt gelöst, in dem ich die Daten an der vorhergehenden fallenden Flanke einlese. Aus dem Timing sieht man, dass das Nu-link selbst wohl genau das gleiche macht. Ein Flip-Flop hätte auch funktioniert, wie Georg oben schon angemerkt hat. So, die Herausforderung besteht jetzt natürlich darin, die Chip-Erase Sequenz zu isolieren. Falls jemand mitpuzzeln will - ich habe hier ein paar Logs als Rohdaten und nach dem Parsen abgelegt: https://github.com/hackocopter/SWD-Hacking/tree/master/Nulink-Logs Ich habe bereits einen heißen Kandidaten für die Chip-Erase Sequenz identifiziert. Direkt nach dieser Sequenz ist der Chip nämlich für 140ms "tot" und wird über einen Registerzugriff und die Resetsequenz gepollt. Die Sequenz beginnt mit einem Reset. Möglicherweise handelt es sich daher also um den Relevanten Teil. Die höheren Ebenen des SWD-Protokolls wirken auf mich ziemlich wirr. Einen Masterplan scheint es beim Design nicht gegeben zu haben. Ich frage mich, welche Randbedingungen hier relevant waren. Der Zugriff auf die tatsächlichen Funktionsregister erfolgt zweifach indirekt, wie im Bild. Dies sind die besten SWD-Referenzen: http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=Main_Page#SWD_Packet_Construction http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
Geschafft! Ich habe die Chip-Erase Sequenz extrahieren können. Damit ist es jetzt möglich, den Microcontroller ohne Bu-Link/Bu-Link zu programmieren. Noch einmal vielen Dank an Robert für das zur Verfügung stellen des NU-Links. Und an chris, georg und die anderen für die Hilfe. Das ganze ist aber noch aufwändiger geworden als gedacht. Um mit der Datenflut etwas anfangen zu können, habe ich auch noch die derüber liegende Ebene, nämlich die Speicherzugriffe, geparsed. Der aktuelle Source ist hier: https://github.com/hackocopter/SWD-Hacking Durch den Vergleich von unterschiedlichen Logs habe ich die Chip-Erase-Sequenz finden können. Anbei das kommentierte Log der Sequenz. Der Relevante Teil ist unten. Eigentlich ist es recht einfach. Die Chip-Erase Sequenz wird natürlich über die Flash-Register kontrolliert. Es gibt anscheinend ein undokumentiertes Enable-Register (0x5000C01C) und einen Undokumentierten Befehl (0x26) für das ISP Command register.
1 | @3315.698313ms:Read Buf(0x5000c000)=0x00000032 ; ISP control |
2 | @3315.738438ms:Write BD (0x5000c000)=0x00000033 ; ISP Control=0x33 Set bit 1= Enable ISP function... really? |
3 | @3315.767938ms:Read Buf(0x5000c000)=0x00000000 |
4 | @3315.927375ms:Read Buf(0x5000c01c)=0x00000000 |
5 | @3315.967688ms:Write BD (0x5000c01c)=0x00000001 ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller |
6 | @3315.997188ms:Read Buf(0x5000c01c)=0x04770021 ; Buffer after write - "unpredictable" |
7 | |
8 | @3316.156188ms:Read Buf(0x5000c000)=0x00000033 |
9 | @3316.232000ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
10 | @3316.400563ms:Read Buf(0x5000c010)=0x00000000 ; ISP not busy? |
11 | @3316.527437ms:Write BD (0x5000c00c)=0x00000026 ; ISP Command=0x26. Undocumented combination. Enable page erase and program |
12 | @3316.556938ms:Read Buf(0x5000c00c)=0x04770021 ; Buffer after write - "unpredictable" |
13 | @3316.595000ms:Write BD (0x5000c004)=0x00000000 ; ISP Address=0x00000000 Start of APROM |
14 | @3316.624500ms:Read Buf(0x5000c004)=0x00000000 |
15 | @3316.748562ms:Write BD (0x5000c010)=0x00000001 ; ISP Trigger=1 -> Start ISP Operation |
16 | @3316.778125ms:Read Buf(0x5000c010)=0x00000000 ; First read is invalid? better replicate or trouble looms |
17 | @3316.852250ms:Read Buf(0x5000c010)=0x00000001 ; Operation is ongoing during ISP Trigger reads |
18 | |
19 | ... poll poll poll ... |
20 | |
21 | @3326.586938ms:Read Buf(0x5000c010)=0x00000001 |
22 | @3326.664813ms:Read Buf(0x5000c010)=0x00000001 |
23 | @3326.742625ms:Read Buf(0x5000c010)=0x00000001 |
24 | @3326.820500ms:Read Buf(0x5000c010)=0x00000001 |
25 | @3326.898375ms:Read Buf(0x5000c010)=0x00000000 ; and done. After ~10ms |
26 | @3327.060438ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
Die große Frage ist jetzt natürlich wie man das am besten Umsetzt. Weiss jemand, ob sich die Befehlssequenz z.B. über ein Script in Keil/OpenOCD/etc. abbilden liesse? Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem Microcontroller, die nichts anderes tut als zu überprüfen ob das richtige Device angeschlossen ist und ein chip erase durchzuführen. Im Vergleich zum parsen des Logs erscheint das fast trivial, aber diese Woche nicht mehr... :)
SWD ist übrigens ein ganz schreckliches Protokoll. Und das Nu-Link ist eine noch schlimmere Umsetzung davon -> Glitches, übles Timing und redundante Zugriffe.
Tim, könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC einigermaßen auskennt aber nicht mit Protokollanalyse, wären super.
Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay, Write/Read Register usw... Da die ST-Link ja abgespeckte J-Links sind denke ich mal es geht.. Was mich jetzt mal interessieren würde ist was sonst noch so in dem "versteckten" Register für Bits gesetzt werden können..!? Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Edit: Würde mich auch mal interessieren..
Den Bu-Link scheint es ja auch hier noch zu geben. Ich versteh nur das Kauderwelsch nicht. Meiner von aliexpress ist leider noch nicht da :-( Für 13 Euro http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html Für 9 € http://de.imendit.com/item/the-the-bu-link-compatible-nu-link-emulator-full-version-offline-download-new-don-the-numicro-m0-16901419914.html
@Tim: Womit hast Du den ChipErase jetzt durchgeführt, mit Nu-Link oder mit Bu-Link?
Antwort auf eine Anfrage an den Hersteller via AliExpress: "SUSAN LIU: Hi, yes, the bulink will be avaiable after Christmas holiday, the main IC is out of stcok now." ----- @ Oliver Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" Das ist wirklich preiswert! Die Preise sind in Dollar.
No y. schrieb: > Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Wann bestellt? Ich warte auch auf Post von denen.
Georg G. schrieb: > No y. schrieb: >> Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! > > Wann bestellt? Ich warte auch auf Post von denen. und gut drei Stunden nach dieser Mail war er auch hier. Und er fliegt sogar :-) Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen (sie ist aktiv).
So mein Quad ist heute auch von der Post geholt worden. Ich werde also nun auch etwas aktiver sein, hoffentlich :) Aber zu fliegen ist das Teil am Anfang ja wirklich schwer
Mal ne andere Frage: Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt. Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss?
Ich frag mich nur, was an dem Teil jetzt so doll sein soll, daß man so lange darauf wartet. Fliegt das Spielzeug jetzt nicht so schnell in die Ecke, wie die anderen Mini-Helis? Bei Aldi gibts jetzt einen für 24,95, sieht besser aus man kann ihn sogar gleich mitnehmen. Für ein paar Euro mehr gibts dann die 4-kanaligen, die dann genauso oder besser fliegen wie sonn Quad.
Quadrocopter weder im Süden noch im Norden: https://www.aldi-sued.de/de/angebote/technik-aktuell-im-verkauf/ http://www.aldi-nord.de/aldi_multimedia_aktuell_im_verkauf_5_1453.html
Erstmal ganz großes Lob und vielen vielen Dank für die tolle Arbeit!!! Tim schrieb: > Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem > Microcontroller, die nichts anderes tut als zu überprüfen ob das > richtige Device angeschlossen ist und ein chip erase durchzuführen. Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? Könnte eventuell als Grundlage dienen... https://github.com/mchck/mchck
Philipp E. schrieb: > Erstmal ganz großes Lob und vielen vielen Dank für die tolle Arbeit!!! > > Tim schrieb: >> Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem >> Microcontroller, die nichts anderes tut als zu überprüfen ob das >> richtige Device angeschlossen ist und ein chip erase durchzuführen. > > Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? > Könnte eventuell als Grundlage dienen... > https://github.com/mchck/mchck Es hindert dich niemand den Link von dir und die Infos von Tim zusammenzuführen.
Davis schrieb: > Es hindert dich niemand den Link von dir und die Infos von Tim > zusammenzuführen. Doch. Noch nicht angekommener Copter. Frau. Kinder. Job. Zeit...
Ich habe den SWD-Analyzer noch einmal etwas überarbeitet. -C99 Datentypen eingeführt, Source aufgeräumt. -Verbose level lassen sich jetzt von der Commandozeile auswählen. -Parsing der AHB-Registerzugriffe verbessert. Dummy-Lesezugriffe werden jetzt nicht mehr angezeigt. https://github.com/hackocopter/SWD-Hacking Hier sind nach dem Parsing mit der neusten Version die notwendigen Zugriffe zum Chip-Erase:
1 | @3310.553875ms:Write BD (0xe000edf0)=0xa05f0003 <- Debug Halting Control Reg STOPRead Powercon. Oscillators enabled? |
2 | @3315.189313ms:Write BD (0x50000100)=0x00000059 ; Unlock registers with magic sequence |
3 | @3315.256750ms:Write BD (0x50000100)=0x00000016 |
4 | @3315.324187ms:Write BD (0x50000100)=0x00000088 |
5 | @3315.512938ms:Read Buf(0x50000200)=0x0000001c ; Read Powercon |
6 | |
7 | Erase sequence |
8 | @3315.698313ms:Read Buf(0x5000c000)=0x00000032 ; ISP control |
9 | @3315.738438ms:Write BD (0x5000c000)=0x00000033 ; ISP Control=0x33 Set bit 1= Enable ISP function... really? |
10 | @3315.927375ms:Read Buf(0x5000c01c)=0x00000000 |
11 | @3315.967688ms:Write BD (0x5000c01c)=0x00000001 ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller |
12 | |
13 | @3316.156188ms:Read Buf(0x5000c000)=0x00000033 |
14 | @3316.232000ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
15 | @3316.400563ms:Read Buf(0x5000c010)=0x00000000 ; ISP not busy? |
16 | @3316.527437ms:Write BD (0x5000c00c)=0x00000026 ; ISP Command=0x26. Undocumented combination. Enable page erase and program |
17 | @3316.595000ms:Write BD (0x5000c004)=0x00000000 ; ISP Address=0x00000000 Start of APROM |
18 | @3316.748562ms:Write BD (0x5000c010)=0x00000001 ; ISP Trigger=1 -> Start ISP Operation |
19 | @3316.852250ms:Read Buf(0x5000c010)=0x00000001 ; Operation is ongoing while ISP Trigger reads |
20 | |
21 | ... poll poll poll ... |
22 | @3326.742625ms:Read Buf(0x5000c010)=0x00000001 |
23 | @3326.820500ms:Read Buf(0x5000c010)=0x00000001 |
24 | @3326.898375ms:Read Buf(0x5000c010)=0x00000000 ; and done. After ~10ms |
25 | @3327.060438ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
26 | |
27 | @3329.989687ms:Write BD (0x5000c000)=0x00000032 ; Disable ISP |
28 | @3330.178625ms:Read Buf(0x5000c01c)=0x00000001 |
29 | @3330.218938ms:Write BD (0x5000c01c)=0x00000000 ; Write 0 to undocumented register |
Dann will ich mich auch mal melden, meiner ist nun auch endlich angekommen. Bestellt hatte ich am 22.10.2013. Danke an den Threadstarter! Ich wäre auch noch an 1-3 stück interressiert, falls es eine Sammelbestellung gibt.
Angehängte Dateien:
-
SWD_Write_valid.png
18 KB -
SWD-register.png
35 KB
Robert Knipp schrieb: > könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den > Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du > das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste > Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC > einigermaßen auskennt aber nicht mit Protokollanalyse, wären super. Prinzipiell sind solche Protokolle ja wie eine Zwiebel in mehreren Schichten aufgebaut. Ich habe mich dabei von der niedrigsten Protokollebene, dem Hardwarelevel immer weiter nach oben gehangelt. (Bzw. Chris hat den Anfang gemacht). Am besten schaust Du Dir den Source an: https://github.com/hackocopter/SWD-Hacking/blob/master/SWD-Analyzer/swd_analyzer.c 1) Konvertieren der Samplingdaten in einen Bitstream, der nur Daten auf steigenden und fallenden Flanken enthält. (macht getnextperiod()) 2) Einteilen des Bitstreams in interpretierbare Dateneinheiten. Dazu habe ich zunächst nur geschaut, ob sich gültige Befehle (Reset-Sequenz oder Read/write) im Bitsream befinden und wie lang diese sind. Das geschieht in der Hauptschleife. Dazu wird bei SWD- Lese- und Schreibzugriffen der Header ausgewertet (Bild). Wenn er gültig ist, werden die Daten interpretiert, sonst verforfen. 3) Interpretieren und übersetzten der SWD-Befehle (macht swd()). 4) Nachbilden des Memory Access Ports (Bild), um die SWD-Befehle in Schreib- und Lesezugriffe auf die Peripherie des Prozesseres zu übersetzen. Denn per SWD wird im Grunde nichts anderes gemacht, als den Prozessor anzuhalten und auf den Addressraum zuzugreifen. Leider geschieht das auf eine extrem umständliche Art. Es gibt z.B. drei unterschiedliche Möglichkeiten eine Speicherzelle auszulsen. Die Daten die auf den unteren Protokollebenen Interpreitert werden, kann der Analyzer auch ausgeben. (Kann mit mit -v x einstellen. --help zeigt eine Hilfe an).
No y. schrieb: > Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay, > Write/Read Register usw... Hast Du dazu eine Referenz, oder kennst Du selbst damit aus? Das wäre natürlich die beste Lösung, da Keil mit vielen SWD-Adaptern zurecht kommt. No y. schrieb: > Was mich jetzt mal interessieren würde ist was sonst noch so in dem > "versteckten" Register für Bits gesetzt werden können..!? Wahrscheinlich nur das eine, aber Du kannst damit ja mal herumspielen. > Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Habe heute auch gerade einen von denen bekommen. Komisch, da ist wohl ein Container angekommen? Oliver Stellebaum schrieb: > Kauderwelsch nicht. > Meiner von aliexpress ist leider noch nicht da :-( > > Für 13 Euro > http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html Das ist ein Taobao-Agent, der sie für Dich von www.taobao.com kauft und Dir zusendet. Dort werden auch einige Bu-Links angeboten. Auf den Preis kommen noch erhebliche Zusatzgebühren. Manuel Steiner schrieb: > Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt. > Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss? Eigentlich alle? "Nach fest kommt ab" usw. :) Philipp E. schrieb: > Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? > Könnte eventuell als Grundlage dienen... > https://github.com/mchck/mchck Hatte ich oben auch schon gepostet. Leider haben die nur die allerunterste Ebene im client implementiert, den Rest macht der PC. Prinzipiell würde es gar nicht so lange dauern, ein kleines Bitbang-SWD-Programm zum programmieren welches Chip-Erase macht - auf jeden Fall ist das weniger aufwändig als der Analyzer. Allerdings benötigt man sowieso noch einen Keil-kompatiblen SWD-Adapter für die Programmierung. Da wäre es einfacher, diesen über ein Script anzusteuern.
Georg G. schrieb: > Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen > (sie ist aktiv). Es wäre natürlich praktischen, wenn man nur ein LCD anschließen müsste.
Entschuldigung ich muss mich korrigieren. Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!! Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht hatte. Bringt also nichts. Ich glaub selbst mit nem J-Link Edu bringt es nichts da keine J-Flash Lizenz dabei ist. Weiß daher nicht ob die Scripts ausgeführt werden oder ob zuerst der Lizenzfehler kommt. Werde ich demnächst mal ausprobieren.
No y. schrieb: > Entschuldigung ich muss mich korrigieren. > > Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!! > Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht > hatte. Also für mich sieht es aus, als wenn es mit den Debug Function im Menu Debug->Function Editor funktionieren könnte. Man kann damit functionen definieren, die Befehle wie _WWORD (0x20000, 123); beinhalten, mit denen man den Speicher des Targets beschreiben kann. Oder verstehe ich hier etwas falsch?
Angehängte Dateien:
-
mini51flashtools.png
56 KB
Es hat sich herausgestellt, dass es wirklich sehr einfach ist, mit "Functions" im KEIL Debugmodus eigene SWD-Sequenzen zu definieren. Mit dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es wunderbar. Leider gibt es noch ein paar Probleme mit ST-Link und Keil. Mann kann programme Downloaden, aber nicht debuggen und ausführen. Woran es liegt weiss ich nicht. Evtl. hilft hier Versaloon usw. Kennt sich hier jemand aus? https://github.com/hackocopter/SWD-Hacking/tree/master/KEIL-Flashtools Hier nur kurz: -Es wird Keil µVision5 mit Legacy Device support benötigt. -Die Treiber für den SWD-Adapter sollten installisert sein. -Projekt im Anhang öffnen -Den richtigen SWD-Adapter auswählen. -In den Debug-modus gehen (1) -In der Command Zeile "INCLUDE Mini51flashtools.ini"+<enter> eingeben (2) -Jetzt erscheint ein Tool-Menu mit einigen neuen Funktionen. (3) _Mini51 ShowConfig_: Zeigt aktuelle configuration des controllers an. Hier am besten zuerst mal draufklicken. _Mini51 ChipErase_: Führt ein Chip-Erase durch, wenn der Chip gesperrt war. *ACHTUNG:* Dieser Befehl löscht die original Firmware ohne Sicherheitabfrage _Mini51 WriteStdConfig_: Beschreibt die Configurationsregister mit Standardwerten. Sollte nach dem Chip-Erase immer gemacht werden. _Mini51 Reset_: Selbsterklärend
Tim schrieb: > Mit ST-Link funktioniert es > wunderbar. Na das kommt doch genau zum richtigen Zeitpunkt. Da mein Quad so lange auf sich warten hat lassen ist ja jetzt wirklich zu überlegen, ob sich die Anschaffung eines Nulinks noch lohnt. Eigentlich hab ich nicht vor, irgendwo anders Nuvoton MCUs zu verwenden. Ich denke Tim, aber auch allen die dabei geholfen haben, das möglich zu machen, gebührt mal wirklich ein Dankeschön.
Tim schrieb: > Mit > dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem > beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es > wunderbar. Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis! Tausend Dank!!! (PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant)
Gute Arbeit cpldcpu! Nach einem chip-erase (mit dem magic register) konnte ich meine alte Firmware wieder aufspielen und das Gerät läuft wieder!!! Besten Dank!
Jog3k schrieb: > Gute Arbeit cpldcpu! Nach einem chip-erase (mit dem magic register) > konnte ich meine alte Firmware wieder aufspielen und das Gerät läuft > wieder!!! Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch nicht so gut. Philipp E. schrieb: > > Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis! > Tausend Dank!!! > (PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks > zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant) Danke! :) Habe auch schon über einen Artikel nachgedacht, aber dafür muss ich auch erstmal die Zeit finden. Der Hackocopter hat mir diese Woche schon sehr viel davon gekostet...
Tim schrieb: > Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du > für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch > nicht so gut. Genau, MouldKing (in der Anleitung als X6 betitelt, auf dem Gehäuse steht M-1). Ich habe ein eigenes Programm geschrieben bzw. erweitert und verwende den stlink-v1 vom ersten Discovery. Ich werde den Code bei Gelegenheit gerne veröffentlichen. In meinem code.google.com repo habe ich auch ein script für openocd (allerdings habe ich nicht getestet ob das Programmieren damit funktioniert). Welche Probleme hast Du mit dem stlink? Beste Grüße!
>> Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du >> für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch >> nicht so gut. > > Genau, MouldKing (in der Anleitung als X6 betitelt, auf dem Gehäuse > steht M-1). Ich habe ein eigenes Programm geschrieben bzw. erweitert und > verwende den stlink-v1 vom ersten Discovery. Ich werde den Code bei > Gelegenheit gerne veröffentlichen. In meinem code.google.com repo habe > ich auch ein script für openocd (allerdings habe ich nicht getestet ob > das Programmieren damit funktioniert). > Welche Probleme hast Du mit dem stlink? > > Beste Grüße! Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. Verwendest Du die normale ST-Link Firmware und OpenOCD zum programmieren? Dein Programm wäre sicherlich für andere auch interessant.
Tim schrieb: > Verwendest Du die normale ST-Link Firmware und OpenOCD zum > programmieren? Ja, die Firmware auf dem Discovery ist unverändert. OpenOCD hatte ich ausprobiert und beispielsweise das Auslesen des PDID Registers hatte funktioniert. Die anderen Funktionen konnte ich zu dem Zeitpunkt nicht testen, da das Gerät nicht richtig funktionierte. Nach einem kompletten "Device-Erase" (Danke nochmal für die Informationen) und dem Aufspielen der alten Firmware kann ich jetzt auch wieder mein "uarttest.bin" Programm ausführen und bekomme entsprechendes Feedback über die serielle Schnittstelle. Das habe ich jetzt aber wieder mit meinem eigenen Programm gemacht und nicht mit OpenOCD. > Dein Programm wäre sicherlich für andere auch interessant. Sobald der Code ordentlich aussieht und ich einige weitere Funktionen implementiert habe lade ich das Programm auf meinem code.google repo hoch.
Tim schrieb: > Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme > hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert nicht?
Hubsy schrieb: > Tim schrieb: > >> Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme >> hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. > > Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert > nicht? Flash und Erase wird ohne Fehlermeldung durchgeführt. Nur das hochgeladene Programm (z.B. Blinky) wird anschließend nicht ausgeführt. Ebenso zeigt der Debug-Mode einen leeren Speicher. Entsperrt ist der Chip, denn das Programmieren geht mit dem Nu-Link wunderbar.
Tim schrieb: > Hubsy schrieb: >> Tim schrieb: >> >>> Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme >>> hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. >> >> Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert >> nicht? > > Flash und Erase wird ohne Fehlermeldung durchgeführt. Nur das > hochgeladene Programm (z.B. Blinky) wird anschließend nicht ausgeführt. > Ebenso zeigt der Debug-Mode einen leeren Speicher. Entsperrt ist der > Chip, denn das Programmieren geht mit dem Nu-Link wunderbar. Kannst du mit dem ST-Link und der "STM32 ST-LINK Utility" auf den Mini54ZAN zugreifen?
Hey, Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher mit der Verlustleistung des Chips. Wie sieht das bei dir aus?
Dominic A. schrieb: > Hey, > Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt > ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher > mit der Verlustleistung des Chips. Wie sieht das bei dir aus? Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit Wärmeproblemen rechne.
Hubsy schrieb: > Kannst du mit dem ST-Link und der "STM32 ST-LINK Utility" auf den > Mini54ZAN zugreifen? Das STM32 utitlity habe ich noch nicht ausprobiert. Aber da das Script von oben funktioniert, wird der genenrelle Zugriff möglich sein. Ich glaube eher, dass das ST-Linkt versucht irgendwelche Protokolleigenarten auszunutzen, die es nur auf dem STM32 gibt.
Die Bedienungsanleitung ist mir teilweise ein Buch mit 7 Siegeln. Leider sind meine Kenntnisse der chinesischen Sprache zu gering, das Original zu entziffern. Drei Punkte, die vielleicht jemand beantworten kann: - Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht? - Der letzte Punkt über "flying environment" beginnt mit "if the aircraft take-off not be vertical rise..." Was will der Autor uns sagen? Was soll die beschriebene Prozedur bewirken? - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der Stelle schwebt?
Tim schrieb: > Dominic A. schrieb: >> Hey, >> Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt >> ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher >> mit der Verlustleistung des Chips. Wie sieht das bei dir aus? > > Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar > verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an > den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich > den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit > Wärmeproblemen rechne. Alles klar, ich denke ich bestelle auch einfach mal meine PCB's. Ich werde wahrscheinlich auch noch ein paar zu viele und hier vergeben. Da werde ich mich aber wieder melden wenn ich die Platinen habe. Kann also noch dauern. Georg G. schrieb: > - Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht? Mit ihm kann scheinbar auch eine Kalibrierung durchgeführt werden. Den Knopf drücken und beide Knüppel in die Linke untere Ecke ziehen. (Hat bei mir selber aber auch noch nie funktioniert) Edit: Doch es funktioniert. Man muss beide Knüppel in die linke untere Ecke ziehen und dann den Turningbutton gedrückt halten. Georg G. schrieb: > - Der letzte Punkt über "flying environment" beginnt mit "if the > aircraft take-off not be vertical rise..." Was will der Autor uns sagen? > Was soll die beschriebene Prozedur bewirken? In meinem Handbuch kann ich diesen Satz nicht finden. Bei mir stehen unter flying environment nur so Dinge wie z.B bei warmem Wetter fliegen und nicht fliegen wenn es windet. Georg G. schrieb: > - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät > mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der > Stelle schwebt? Das habe ich mich auch schon gefragt. Jedoch habe ich dazu soeben noch etwas Interessantes im Handbuch gefunden. Scheinbar werden die Kalibierungseinstellungen in der Fernbedienung gespeichert. Den bei mir steht der Satz:"Press and Hold the speed conversation button while turning the power switch, Trimming the remote controller is reset" Also so wie ich das verstehe werden die Kalibrierungseinstellung gelöscht wenn man die Fernbedienung mit gedrücktem Speedbutton einschaltet. Vielleicht hängt das gepiepse irgendwie damit zusammen?
Zur Fernbedienung: Bei mir piepst die Fernbedienung nur kurz, wenn ich die Trimmtaster betätige. Die Trimmung bleibt auch nicht erhalten. Nach jedem Einschalten tippe ich 2x zurück und 2x links, danach lässt sich der Copter zum Schweben bringen. Es sind aber permanente Eingriffe erforderlich, um den Copter in einem Raum von ca. 50 x 50 x 50 cm³ o. s. zu halten. Hauptproblem dabei ist die vertikale Steuerung des Copters. Sie ist einfach nicht fein genug, um auf einer Höhe zu schweben. Eine winzige Hebelbewegung entscheidet darüber, ob der Copter steigt oder sinkt. Ansonsten: Laut Keil kann der ULINK2 mit dem Mini54ZAN "arbeiten"[1]. Der ULINK2 selbst liegt mit ca. 11 Euro preislich beim Nu-/BuLink[2] und ist aber auch für andere Controller-Familien geeignet. Was haltet ihr davon? [1] http://www.keil.com/dd/chip/5587.htm [2] http://www.ebay.de/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-DR-/300945296019
Für Fortgeschrittene kann ich den linken Taster sehr empfehlen! - Copter schweben lassen - linke taste 1x drücken - (linken Stick) nach rechts lenken und staunen wie agil der kleine in dem Modus ist ;) (zurück zum Anfängermodus nochmal drücken) Die Rechte Taste ist auch für Loopings gut: Copter auf >2m Höhe bringen und halten, dann gleichzeitig rechte Taste und (linken) Stick zb nach Rechts -> Copter macht ne Rolle ;) Das Höhe halten fand ich auch anfangs relativ schwer, dachte schon meiner sei kaputt... Es liegt aber am Piloten, drückt die Fernbedienung mal jemanden in die Hand der Heli fliegt... ;) Also weiter üben ;) Gruss, Simon
Kann man den linken Button nicht auch 2x hintereinander drücken und dann ist er noch agiler? Habe ich zumindest das Gefühl. Noch ein kleiner Tipp. Bei mir sind manchmal die Sticks hängen geblieben. Insbesondere in den Ecken. Das ist ziemlich mühsam. Bei mir lag es daran das die Knöpfe zu stark auf die Fernbedienung gedrückt haben. Als Lösung habe ich einfach die Fernbedienung aufgeschraubt und die 2 Schrauben in der oberen Ecke des PCB ein bisschen gelöst. Nun flutschen die Sticks zurück in die Mitte wie noch nie.
Dominic A. schrieb: > Kann man den linken Button nicht auch 2x hintereinander drücken und dann > ist er noch agiler? Habe ich zumindest das Gefühl. Stimmt schon, es sind drei Modi.
Georg G. schrieb: > - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät > mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der > Stelle schwebt? Die langen Piepser ertönen, wenn das Trimming auf 0 eingestellt ist. Das Trimming bleibt übrigens nach dem Ausschalten der FB erhalten. (EEPROM?). Am besten nutzt man es gar nicht.
Davis schrieb: > Ansonsten: > > Laut Keil kann der ULINK2 mit dem Mini54ZAN "arbeiten"[1]. Der ULINK2 > selbst liegt mit ca. 11 Euro preislich beim Nu-/BuLink[2] und ist aber > auch für andere Controller-Familien geeignet. > > Was haltet ihr davon? > > [1] > http://www.keil.com/dd/chip/5587.htm > > [2] > http://www.ebay.de/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-DR-/300945296019 Klingt gut. Chip erase wird es nicht unterstützen, aber das macht das Script oben.
Den Versuch, im FB Sender an den LCD Anschluss ein Display zu hängen werden wir beerdigen können. Es kommen - wie bereits geschrieben - abwechselnd drei Datenpakete, die sich bei Bedienung der Hebel und Taster ändern. Es ist aber kein Zusammenhang zwischen den Bytes und Bits und irgendwelchen Aktionen zu erkennen. Um weiter zu kommen, müssten wir einen Sender analysieren, der mit LCD ausgeliefert wurde.
Schade, dann ist die Datenausgabe evtl. einfach nur übrig gebliebener Code ohne richtige Funktion? Oder lässt sich zumindest erkennen dass die Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.)
Tim schrieb: > Oder lässt sich zumindest erkennen dass die > Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.) Die Ausgabe ändert sich, wenn man steuert. Es ist aber nicht so, dass eine Änderung der Betriebsspannung bestimmte Bits ändert (oder Binden oder Trimmung oder Bewegung der Knüppel). Beispiel: Drücken auf "trimmen roll rechts" ändert ein Byte permanent von 0x04 auf 0x0c. Anschließendes Drücken auf "trimm roll links" ändert es aber nicht zurück auf 0x04. Es geht zurück auf 0x04 bei "throttle 10%". Es ist alles irgendwie pseudozufällig und doch reproduzierbar.
Tim schrieb: > Schade, dann ist die Datenausgabe evtl. einfach nur übrig gebliebener > Code ohne richtige Funktion? Oder lässt sich zumindest erkennen dass die > Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.) Der "Frankfurter" Quadrocopter meldet sich bei der Fernbedienung an. Es erscheint ein "Lampensymbol" in der Anzeige. Zudem werden die Trim-Einstellungen und die Geschwindigkeit in Prozent angezeigt. Das ist beim Modell aus dem Eingangsbeitrag nicht der Fall. Hier kann das "Binding" auch ohne Copter durchgeführt werden. Ein Rückmeldung erfolgt optisch über die beiden blauen LEDs.
Auf meinen Bulink warte ich noch immer :-( Ob ich in der Zwischenzeit den Ulink2 bestelle? Was haltet ihr von diesem http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=130738049882 Magnetsensor? Könnte man damit einen autonomen Schwebeflug erzielen?
Also zum Thema ULink: Beitrag "CoLinkEX oder Segger J-Link EDU oder Ulink2" Und für ca. 11€ bekommt man auch ne 10DOF IMU in Ebay mit MS5611 die wahrscheinlich auch nicht viel größer ist als die verlinkte.
Oliver Stellebaum schrieb: > Könnte man damit einen autonomen Schwebeflug erzielen? Für die Höhe brauchst du einen Höhensensor, barometrisch oder Ultraschall oder Laser oder Radar. Für die anderen zwei Koordinaten hilft dir der Magnetsensor auch nur begrenzt, weil das Magnetfeld sich über wenige Meter nicht merkbar ändert. Du kannst nur die Richtung der Nase damit stabilisieren.
Vielleicht kann man eine optische Maus so modifizieren, daß sie den Bewegungsvektor über Boden ausgibt (statt über Mousepad)?
Für die Höhenstabilisierung bietet sich ein Drucksensor an. Ich habe mir mal einen BMP180 bestellt, der einer der besten Sensoren am Markt zu sein scheint: http://www.ebay.de/itm/1PC-BMP180-Digitale-Luftdruck-Sensor-Brett-Modul-fur-Arduino-/271336856744 Bis das mit der Software funktioniert ist es aber noch ein weiter weg .)
batman schrieb: > Vielleicht kann man eine optische Maus so modifizieren, daß sie den > Bewegungsvektor über Boden ausgibt (statt über Mousepad)? Ich glaube nicht, dass das mit mehr als wenigen mm Abstand noch funktioniert.
Stichwort: modifizieren Es gibt durchaus Linsen, die die Brennweite der Optik verändern - quasi eine Brille für die Maus.
Wenn man dem kleinen Ding dann noch eine zusätzliche Schubdüse verpasst könnte er mit der Mouse unten drunter auch abheben :-)
Und wenn man mit Kamera fliegen will, braucht man ja ne 3-stufige Rakete. ;)
Heute ist mein original Hubsan angekommen. Da ist eine Schutzschaltung mit DW01 im Ladekabel. Schaltung scheint ziemlich exakt nach Datenblatt zu sein. Ist sicherlich nicht der Weißheit letzter Schluss, aber schon besser als beim Billig-Hubsan. Allerdings ist die Steuerung der "Flips" doof gelöst. Man muss erst in eine Richtung drücken und danach schnell in die andere Wechseln um einen Flip aus zu führen. Immer wenn man keinen Flip machen will macht er einen und wenn man einen machen will funktioniert's nicht :( Außerdem sackt er nach dem Flip noch viel stärker weg als der Billig-Hubsan.
Bevor dieser Thread hier vollkommen in der Versenkung verschwindet gebe ich bekannt dass mein bestellter Bu-Link endlich angekommen ist. Erschwerend kam hinzu, das nicht mein Name sondern nur mein Aliexpress-Name auf dem Umschlag stand. Ich konnte dem Postmann aber glaubhaft versichern das ich der rechtmäßige Empfänger bin :-) So, bald sind Weihnachtsferien, hoffe ich komme dann dazu, mir eine Testumgebung aufzubauen.
Ich habe mich gerade noch einmal wieder dran gesetzt. Eine positive Sache: Das Programmieren und Debuggen mit ST-Link funktioniert. Ich weiss nicht was letztes mal schief ging. Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board entsperren und programmieren lässt. Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, ist ein serieller Bootloader einfacher in der Handhabung
Tim schrieb: > Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board > entsperren und programmieren lässt. > > Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den > Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, > ist ein serieller Bootloader einfacher in der Handhabung Nice work :) Big thx. Leider stresst die Uni in letzter Zeit ziemlich :(
Ein wenig Off-topic, aber: Weiß jemand wie die Stecker für die Akkus heisen, bzw. wo man diese Kaufen kann. Ich würde mir gerne für meinen IMAX B6 ein Ladekabel mit Balancer anschluss bastel, damit ich mehrer Akkus in einem Ladevorgang geladen bekomme. THX
Genau dasselbe habe ich auch gemacht. Bei Ebay gehen die Stecker unter "Walkera Stecker".
ARM-Fan schrieb im Beitrag #3452604: > Bei Ebay gehen die Stecker unter "Walkera Stecker". Wie alles, was nach Modellbau riecht, leider wieder völlig überteuert. Bei den Preisen ist es ja billiger, sich die Stecker von den Ladegeräten abzuschneiden?
Tim schrieb: > Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den > Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, > ist ein serieller Bootloader einfacher in der Handhabung Ich war bisher noch nicht erfolgreich, werde aber jetzt noch einmal einen anderen Ansatz probieren. Mein Ziel ist, dass man den Copter im zugeschraubten Zustand mit dem seriellen Bootloader programmieren und debuggen kann. Nur dann lässt sich bequem eine neuen Software entwickeln. Hat jemand eine gute idee, wie man einen Stecker auslegen könnte? Der serielle Port ist direkt neben einem "Auge". Darüber könnte man dünne Kabel herausführen. Dann würde man nur noch einen günstigen, beschaffbaren und kleinen Steckverbinder benötigen.
Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen Bootloader in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader oben drauf? Vorschlag: Während der Entwicklung das Oberteil des Coptergehäuses abnehmen oder ausfräsen, eine Buchse in die vorhandenen Löcher einlöten, debuggen & freuen.
Davis schrieb: > Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen > Bootloader > in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, > der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader > oben drauf? Davis, Du scheinst ja der Bootloaderfeind allgemein zu sein :) Der Mini54ZAN hat 2kb dedizierten Flash-Speicher für den Bootloader (LPROM), die sich für gar nichts anderes nutzen lassen. Es gibt von Nuvoton einen fertigen Bootloader, der auch von deren Host-Software unterstützt wird. Man verliert von den 16kb also kein einziges Byte. Clever wäre es natürlich, wenn man einen Bootloader programieren könnte, der im LDROM sitzt und Updates über den Funkchip zulässt. Ich würde da aber erst einmal auf dem Boden bleiben :)
Tim schrieb: > Davis schrieb: >> Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen >> Bootloader >> in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, >> der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader >> oben drauf? > > Davis, Du scheinst ja der Bootloaderfeind allgemein zu sein :) Jetzt hast du mich ertappt :) > Der Mini54ZAN hat 2kb dedizierten Flash-Speicher für den Bootloader > (LPROM), die sich für gar nichts anderes nutzen lassen. Es gibt von > Nuvoton einen fertigen Bootloader, der auch von deren Host-Software > unterstützt wird. Man verliert von den 16kb also kein einziges Byte. Muss mich doch ein wenig in den Chip "einlesen". > Clever wäre es natürlich, wenn man einen Bootloader programieren könnte, > der im LDROM sitzt und Updates über den Funkchip zulässt. Ich würde da > aber erst einmal auf dem Boden bleiben :) "Auf dem Boden bleiben", ist der richtige Ausdruck. Du machst einfach zu viele Baustellen auf. Nachdem es mit dem ST-Link funktioniert, spricht nichts dagegen diesen für die Entwicklung zu verwenden.
Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel wo dran kommt und welche Software man verwendet? Ich komme aus der Anwendungsprogrammierung, habe schon ein wenig Atmel gemacht aber ansonsten noch nicht viel.
Oliver Stellebaum schrieb: > Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel > wo dran kommt und welche Software man verwendet? Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" https://github.com/hackocopter/Documentation
So, dsa Programmieren des Bootloaders funktioniert, der Bootloader selbst nicht. Vermutlich liegt das daran, dass er auf die andere Konfiguration der seriellen Schnittstelle konfiguriert ist. Ich werde es erst einmal sein lassen und einen Wireless-Bootloader ganz unten auf die Prioliste setzen.
Oliver Stellebaum schrieb: > Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel > wo dran kommt und welche Software man verwendet? Leider gibt es noch keine übersichtliche Anleitung für den Einstieg. Ich werde versuchen, dass in der nächsten Zeit zu ändern und den Wiki-Artikel auf Vordermann zu bringen. Die nötigen Informationen sind im Moment über die Thread verstreut. Die wesentlichen Unterliegen liegen im Repository, wie von Davis verlinkt. 1) Du musst den SWD-Port mit deinem SWD Adapter verbinden. 2) Als Software eignet sich die freie Version von Keil µVision 5. Du musst zusätzliche den "Legacy device support" installieren. 3) Anleitung zum Freischalten des Microntrollers hier (Chip Erase): Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" 4) Beispielprojekte hier: https://github.com/hackocopter/Examples
Die guten Angebote für den JXD385 werden immer spärlicher. Hier ist noch ein relative günstiges: http://www.ebay.de/itm/Mini-6-Axis-4-Channels-2-4GHZ-Gyro-Flying-UFO-RC-Helicopter-Aircraft-Red-Black-/161119365976
Nun ja, also bei ob jetzt 21€ oder 25€. Ist immernoch verdammt günstig. Ansonsten erst nach Weihnachten kaufen, ist ja nicht mehr lange. Dann wird's sicherlich auch wieder günstiger ;)
Studentle schrieb: > Nun ja, also bei ob jetzt 21€ oder 25€. Eben nicht. Wenn Ebay 25,25 schreibt, dann errechnet PayPal um die 26,50. Und das ist nun wirklich zuviel für die Freigrenze der Einfuhr-Umsatzsteuer. Dann sind es nämlich knappe 32 Euro. Und nein, bitte keine Spenden an mich, ich brauche derzeit keinen weiteren Copter... ;-) Studentle schrieb: > Ansonsten erst nach Weihnachten kaufen, ist ja nicht mehr lange. Dann > wird's sicherlich auch wieder günstiger Damit könntest Du völlig recht haben, das sehe ich auch so. Ist mir aber momentan mangels Bedarf nicht so wichtig... ...
Ich hab gerade einen Motor wiederbelebt, in dem ich die Achse mit Gewalt und zwei Kombizangen rausgezogen hab, falls das jemand etwas hilft.
Ich wünsche hier mal allen, die so fleißig an dem Thema dran sind oder daran interessiert sind, oder auch nur einfach ab und zu mal wieder mitlesen, frohe Weihnachten und Festtage.
Tim schrieb: > ARM-Fan schrieb im Beitrag #3452604: >> Bei Ebay gehen die Stecker unter "Walkera Stecker". > > Wie alles, was nach Modellbau riecht, leider wieder völlig überteuert. > Bei den Preisen ist es ja billiger, sich die Stecker von den Ladegeräten > abzuschneiden? gibt es hier billiger http://www.ebay.com/itm/Walkera-3-7v-Walkera-lipo-battery-plug-x-6-extra-long-/321270125203?pt=Radio_Control_Parts_Accessories&hash=item4acd311293 http://www.ebay.com/itm/Walkera-Charge-Lead-for-Walkera-3-7v-Battery-plug-x-6-/221332983760?pt=Radio_Control_Parts_Accessories&hash=item3388794fd0
Für die, die nur entwickeln wollen: http://www.tmart.com/JXD-385-004-PCB-Board-Receiver-for-RC-Helicopter-Green_p192103.html
Ich habe noch einmal bei einigen chinesischen Händlern nachgebohrt. Inzwischen erscheint es mir realistisch, den Copter ohne Fernbedienung für ~10EUR pro Stück zu importieren, wenn eine entsprechende Stückzahl abgenommen wird. Unverhandelte Angebote liegen zwischen 9.6-11 USD. Dazu kommen noch Einfuhrumsatzsteuer, Zoll und Versand. Besteht an so einer Aktion noch Interesse? Dazu müsste sich eine Anzahl von Leuten finden, mehr als 5 Stück abnehmen wollen. Sonst lohnt sich der logistische Aufwand nicht. Ich wäre auch gerne Bereit, die Kontakte weiter zu geben, wenn Torsten oder jemand anderes das Thema wieder aufnehmen will.
p.s.: Ich bin im Moment am Thema Dokumentation dran. Nach Neujahr werde ich wieder etwas mehr Zeit haben.
Tim schrieb: > Ich bin im Moment am Thema Dokumentation dran. Hast du jetzt eigentlich schon mal eine neue Firmware geflasht um z.B. die LEDs blinken zu lassen oder so?
Marius S. schrieb: > Hast du jetzt eigentlich schon mal eine neue Firmware geflasht um z.B. > die LEDs blinken zu lassen oder so? Ja, diese hier: https://github.com/hackocopter/Examples
@cpldcpu Ich hätte Interesse an einem Paket. Wenn's soweit ist, einfach eine PM schicken.
Wenn hier die Entwicklung/Hackung so weitergeht würde ich auch 50€ für 5 Stück investieren um zukünftig einen Schwarm loszulassen. http://www.youtube.com/watch?v=YQIMGV5vtd4 Ist sowas utopisch oder kann man sowas mit wenig hardwareaufwand realisieren? Luftdrucksensor? Magnetometer? Viel Zuladung verkaftet der Kleine sicher nicht.
Ein Link für viel Information zum Thema Quadcopter Software und Theorie (meist AVR, aber als Anregung dennoch gut): https://github.com/googl1/therminator
Wegen Copter Bestellung, ist auch eine Fernsteuerung mitbestellbar ? Bin dabei.
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.