Hallo, auf der Suche nach einem interessanten Nebenbei-Projekt, bin ich auf die Idee gekommen, einen JTAG/SWD Debugger zu entwickeln, der über Bluetooth LE kommuniziert. Die Idee dabei ist, dass der Debugger so wenig Strom verbraucht, dass er bequem durch die Zielhardware mit Strom versorgt werden kann. Vorteile, die mir dabei einfallen wären: - einsetzbar auf rotierenden Teilen - galvanisch getrennt / Isoliert von Hochspannung - Benutzung im geschlossenen Gehäuse möglich - kann auf der Zielhardware verbleiben um diese nachträglich um Over The Air updates zu erweitern. Nachteil wäre die vermutlich lange upload-Zeit beim flashen über BLE. Findet das hier jemand von euch interessant / nützlich? mfg Torsten
Torsten R. schrieb: > Findet das hier jemand von euch interessant / nützlich? Praktisch wäre das schon. Allerdings auch nicht problemfrei: Versorgung: Wenn der Adapter auch den DUT versorgen soll, dann kann das eng werden (mit der Lebensdauer des Akkus) Driver: Wie schwierig wird es, den Adapter an die IDE zu hängen? /regards
Hallo Andreas, Andreas H. schrieb: > Versorgung: Wenn der Adapter auch den DUT versorgen soll, dann kann das > eng werden (mit der Lebensdauer des Akkus) die Idee war anders herum: der Adapter bekommt seinen Strom aus der Zielhardware. > Driver: Wie schwierig wird es, den Adapter an die IDE zu hängen? Der jetzige Plan geht davon aus, einen GDB-Server zu schreiben. Damit sollte es sich in die gängigen IDEs einhängen lassen.
Torsten R. schrieb: > - Benutzung im geschlossenen Gehäuse möglich Aber nicht in Metall Gehäusen. Nur so als Hinweis. Andreas H. schrieb: > Driver: Wie schwierig wird es, den Adapter an die IDE zu hängen? Das sehe ich auch als Problem an, falls der OP das nicht direkt in OppenOCD rein hackt. Bluetooth LE kennt leider keine COM Ports mehr... Torsten R. schrieb: > Nachteil wäre die vermutlich lange upload-Zeit beim flashen über BLE. Implementiere auf dem BLE Peripherial den HID Service. Der muss nix tun, alleine die Präsenz schaltet bei allen mir bekannten OS die schnellen Connection Intervalle frei, d.h. Du hast ~10ms statt 50ms Intervalle und kommst so auf ca. 10kByte/sec netto (bei NRF51 Modul). Ich hatte mal das versaloon Protokoll für die R0ket mit 32k Flash / 8k RAM portiert: https://github.com/turboj/versaloon-r0ket Da müsste man nur noch einen BLE Transport für stricken und in OpenOCD rein hacken. Übrigens: Die derzeit billigsten NRF51 boards sind AFAIK die BBC microbit.
Jim M. schrieb: > Torsten R. schrieb: >> - Benutzung im geschlossenen Gehäuse möglich > > Aber nicht in Metall Gehäusen. Nur so als Hinweis. Ja, gut, das wird jeder einsehen und verstehen. Wenn es den Bedarf gibt, müsste man die Antenne dann halt nach aussen verlegen. > Implementiere auf dem BLE Peripherial den HID Service. Der muss nix tun, > alleine die Präsenz schaltet bei allen mir bekannten OS die schnellen > Connection Intervalle frei, d.h. Du hast ~10ms statt 50ms Intervalle und > kommst so auf ca. 10kByte/sec netto (bei NRF51 Modul). Ich hatte schon vor, da ein richtiges Produkt draus zu machen. Das Projekt wäre eh, vor allen Software-lastig und würde dann ein auf den Anwendungsfall zugeschnittenes Protokoll bekommen. Das connection interval zu weit runter zu setzen, verringert zwar die Latenz, aber höhere Bandbreiten lassen sich eigentlich besser mit größerer MTU erzielen. Das wird aber kein Problem, da kenne ich mich ganz gut aus :-) > > Übrigens: Die derzeit billigsten NRF51 boards sind AFAIK die BBC > microbit. Die Hardware wird nicht teuer werden, der Aufwand steck dann vor allem in der Software. Das bedeutet dann, Hardware für einen Preis, der deutlich über den sichtbaren Herstellungskosten liegt => Da fühlt sich dann wieder jeder über'n Tisch gezogen und meint, dass beim Chinesen günstiger zu bekommen.
Einen vergleichbaren (wenngleich nur auf MSP430 fixierten) Ansatz gab es schon mal: https://www.olimex.com/Products/MSP430/JTAG/MSP430-JTAG-RF/
Rufus Τ. F. schrieb: > Einen vergleichbaren (wenngleich nur auf MSP430 fixierten) Ansatz gab es > schon mal: > > https://www.olimex.com/Products/MSP430/JTAG/MSP430-JTAG-RF/ Ja, über den bin ich auch gestolpert und über noch einen anderen Ansatz. Beide werden nicht mehr produziert. Das kann natürlich bedeuten, dass es dafür keinen Bedarf gibt, oder dass die Zeit noch nicht bereit war. Heute hat ja fast jeder PC BLE onboard und damit würde auf jeden Fall schon mal das Gegenstück auf der PC-Seite entfallen.
Torsten R. schrieb: > Die Hardware wird nicht teuer werden, der Aufwand steck dann vor allem > in der Software. Das bedeutet dann, Hardware für einen Preis, der > deutlich über den sichtbaren Herstellungskosten liegt => Da fühlt sich > dann wieder jeder über'n Tisch gezogen und meint, dass beim Chinesen > günstiger zu bekommen. Diese Pöbler wird man natürlich sofort auf den Plan rufen, Du Kapitalist, der dem kleinen Mann nichts gönnen will. :-) Sicherlich wäre ein Preis wie für einen Lauterbach nur bei sehr wenigen Kunden durchsetzbar. Aber wenn man sich anschaut, wie vergleichweise teuer ein Xilinx Platform Cable oder ein Altera USB Blaster über den Tisch geht, sollte es durchaus möglich sein, sich preislich in diesem Bereich (~ 200,- EUR) zu platzieren. Leider hat man damit aber den allergrößten Teil der Bastler (Neudeutsch: Maker) abgehängt. Dann gibt es auch noch die Frage, ob irgendeine Art von technischem Nachbauschutz eingesetzt werden kann, um die ganzen chinesischen Nachahmer abzuhalten. Das, worauf man heute als zahlender Kunde aber berechtigterweise sehr empfindlichen reagiert, sind Kopierschutzmaßnahmen, die einen bei der Arbeit unnötig behindern, z.B. separate Dongle. Wenn die Donglefunktion jedoch schon im Gerät selbst steckt, ohne dass man sie wirklich wahrnimmt, wäre es okay. Lauterbach hatte früher z.B. ein einfaches EEPROM für Lizenzschlüssel verwendet, was sich aber leicht kopieren ließ, und zwar nicht nur von Chinesen, die das ganze Gerät klonen wollten, sondern auch als regulärer Kunde, der zusätzliche Prozessorplattformen freischalten wollte. Seit einigen Jahren verwendet Lauterbach daher ein Krypto-EEPROM. Die Implementierung solch einer Absicherung sollte aber auch nicht so zeitaufwändig werden, dass dadurch die Markteinführung des gesamten Produktes allzu sehr verzögert wird, denn sonst verpasst man das Zeitfenster, in dem das Produkt verkaufsfähig ist.
Was für Stecker packt Ihr den so auf eure Schaltungen, um da später einen JTAG Adapter anzuschließen?
gibt's doch schon: http://www.isystem.com/products/hardware/cortex-debugger/ione-bt-wireless-debugger
Ruediger A. schrieb: > gibt's doch schon: > > http://www.isystem.com/products/hardware/cortex-debugger/ione-bt-wireless-debugger Danke, den hatte ich nicht entdeckt. Das geht schon in die Richtung, die ich mir vorstelle, aber ist viel zu groß.
Torsten R. schrieb: > Was für Stecker packt Ihr den so auf eure Schaltungen, um da > später > einen JTAG Adapter anzuschließen? tagconnect :-) Die Idee ist ansich gut, und einen JTAG-TAP-Stack bekommst du z.B. auf einen cc430 in Daumennagelgrösse. Die Frage ist, für welche Targets du den Support machen willst. Ein guter Trick ist z.B. eine virtuelle libftdi, damit funktioniert dann die bisherige Software. Nur die Kunden kannst Du vermutlich an der Hand abzählen.. Grüsse, - Strubi
Torsten R. schrieb: > Was für Stecker packt Ihr den so auf eure Schaltungen, um da später > einen JTAG Adapter anzuschließen? ARM 10-pin 1.27mm Raster http://www.keil.com/support/man/docs/ulink2/ulink2_hw_connectors.htm Und vergiss nicht, SWD/SWO zu implementieren. fchk
Frank K. schrieb: > Torsten R. schrieb: >> Was für Stecker packt Ihr den so auf eure Schaltungen, um da später >> einen JTAG Adapter anzuschließen? > > ARM 10-pin 1.27mm Raster > http://www.keil.com/support/man/docs/ulink2/ulink2_hw_connectors.htm Ja, das wäre jetzt auch mein Favorit. > Und vergiss nicht, SWD/SWO zu implementieren. Wird gemacht, sollte kein zu großer Mehraufwand sein.
Torsten R. schrieb: > Das connection > interval zu weit runter zu setzen, verringert zwar die Latenz, aber > höhere Bandbreiten lassen sich eigentlich besser mit größerer MTU > erzielen. Das wird aber kein Problem, da kenne ich mich ganz gut aus :-) Dann muste Du aber wohl auch den BLE Dongel vorgeben. Ich habe MTU >23 weder bei Windoof 10 noch bei Android hinbekommen, da gab es nur Disconnects. Allerdings war das jedesmal nur Bluetooth 4.0 Hardware, MTU change ist IIRC erst ab BT 4.2 in der Spec drin. Hat jemand schon BT 4.2 USB Dongels gesehen...?
>> ARM 10-pin 1.27mm Raster > >Ja, das wäre jetzt auch mein Favorit. Würde ich nicht nehmen. Komplett bastleruntauglich. Passt nicht in die billigen China Module. Dann wird wieder ein wackliger Adapter fällig. Bei Kabelbruch macht man sich nicht mal eben ein neues billiges Flachbandkabel und mehr.
holger schrieb: >>> ARM 10-pin 1.27mm Raster > Bei Kabelbruch macht man sich nicht mal eben ein neues > billiges Flachbandkabel und mehr. Entsprechende Pfostenstecker und Flachbandkabel sind doch sogar in der Bastlerspotheke Conrad erhältlich: https://www.conrad.de/de/buchsenleiste-rastermass-127-mm-polzahl-gesamt-10-bkl-electronic-1-st-741344.html?sc.ref=Product%20Details https://www.conrad.de/de/flachbandkabel-rastermass-0635-mm-10-x-005-mm-grau-bkl-electronic-1505050-meterware-605418.html Mit etwas Fummelarbeit vereinzelt man dann auf einer Seite des Flachbandkabels die Adern und quetscht sie in einen normalen 2,54mm-Pfostenstecker. Das ist doch wirklich bastlertauglich.
>Entsprechende Pfostenstecker und Flachbandkabel sind doch sogar in der >Bastlerspotheke Conrad erhältlich: Im RM2,54mm kostet der Kram aber nur ein Zehntel;)
Jim M. schrieb: > Dann muste Du aber wohl auch den BLE Dongel vorgeben. Ich habe MTU >23 > weder bei Windoof 10 noch bei Android hinbekommen, da gab es nur > Disconnects. Das Problem könnte sein, das relativ wenige BLE stacks auf Peripheral-Seite in der Vergangenheit mehr als 23 Bytes konnten. Das gibt sich aber gerade. Die meisten Controller können mehr als 23. > Allerdings war das jedesmal nur Bluetooth 4.0 Hardware, MTU change ist > IIRC erst ab BT 4.2 in der Spec drin. MTU exchange ist ATT und auch schon in BT 4.0 vorhanden. > Hat jemand schon BT 4.2 USB > Dongels gesehen...? Ich denke mal, die meisten PCs haben eh schon BLE integriert, oder?
holger schrieb: > Würde ich nicht nehmen. Komplett bastleruntauglich. > Passt nicht in die billigen China Module. Dann wird > wieder ein wackliger Adapter fällig. Bei Kabelbruch macht > man sich nicht mal eben ein neues billiges Flachbandkabel > und mehr. Solange mein Vermieter und der Bäcker keine Yuan nimmt, kann ich preislich nicht mit den Chinesen mithalten ;-)
Torsten R. schrieb: > Andreas H. schrieb: >> Versorgung: Wenn der Adapter auch den DUT versorgen soll, dann kann das >> eng werden (mit der Lebensdauer des Akkus) > > die Idee war anders herum: der Adapter bekommt seinen Strom aus der > Zielhardware. > Umpf, sry. My fault. Hattest Du ja auch so geschrieben. /regards
Ich bin gerade bei der Umsetzung und arbeite am Support für Windows. Jetzt frage ich mich gerade, wie weit ist die Verbreitung von Windows 8.1 unter meinen potentiellen Kunden noch? Wie viele von euch nutzen Windows 8.1. noch? mfg Torsten
Angehängte Dateien:
-
IMG_1833.JPG
240 KB
Das Projekt wird immer konkreter. Die ersten Prototypen sind fertig. Jetzt muss "nur noch" die Software fertig werden :-)
Wenn das BT Modul nur eine Verlängerung wäre? CPU->BT-Modul ---- BT-Modul->JTAG-Adapter (herkömmlicher wie gehabt) Damit wäre das Modul unabhängig von den Treibern und jeder könnte seinen "Wunschadapter" weiter verwenden. ... nur mal so als Idee.
Markus M. schrieb: > Wenn das BT Modul nur eine Verlängerung wäre? > > CPU->BT-Modul ---- BT-Modul->JTAG-Adapter (herkömmlicher wie gehabt) > > Damit wäre das Modul unabhängig von den Treibern und jeder könnte seinen > "Wunschadapter" weiter verwenden. Naja, die meisten "Wunschadapter" funktionieren ja wahrscheinlich über USB. Damit würde es auf einen USB über BLE Adapter hinaus laufen. Könnte man auch machen (?), wäre dann aber ein anderes Produkt. Ich finde die Kompaktheit, die wir erreicht haben schon sehr schön. Der gesammte Adapter ist ja kleiner als ein USB-Stecker :-)
Harlekin schrieb: > Wozu dienen die Stiftleisten in der Mitte? Da sind die SWD-Leitungen der einzelnden Controller (nrf52) auf dem Nutzen zusammen geführt, um Initial den Bootloader und Firmware drauf zu spielen.
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.