PicoProbe mit SWD-Verlängerung

[Harald P. (haraldp)]

Der Microprozesser RP2040 (Pico) lässt sich - wie wohl alle 
ARM-basierten Prozessoren über 2 Leitungen programmieren:
SWCLK - unidirektional und SWDIO - bidirektional.

Zum Programmieren kan man einen zweiten Pico benutzen, der mit dem 
Programm "PicoProbe" oder auch "DebugProbe" versehen ist.
Das Programm "PicoProbe" ist z.B. unter 
https://github.com/raspberrypi/debugprobe abrufbar. Dort stehen auch die 
Quellprogramme.
Als Verbindung zwischen PicoProbe und dem zu programmierenden Prozessor 
reicht im Prinzip eine 3-adrige Leitung. Bei meinen Versuchen hat sich 
herausgestellt, dass die Länge der SWD-Leitung nicht mehr als 10..15m 
sein darf. Da hilft auch keine Verringerung der Baudrate.
Bei meiner Anwendung befindet sich das Zielsystem im Gartenhaus, zu dem 
auch eine bisher ungenutzte LAN-Leitung liegt; Entfernung ca. 20m.
Um die Signale zu verstärken braucht man Treiberbausteine, die aber 
nicht direkt bidirektional verfügbar sind. Man braucht mindestens einen 
Richtungsausgang, um das bidirektionale Signal aufzusplitten. Der ist im 
Originalprogramm nicht enthalten.
Jedoch kann man das Programm so projekieren, dass es ein 
Output-Enable-Signal zur Verfügung stellt.
Meines Erachtens ist das schlecht dokumentiert. Wer das gleiche Problem 
wie ich hat, kommt mit der hier vorgestellten Unterstützung sicher 
schneller zum Ziel.
Das eigentliche Programm habe ich gar nicht verändert. Lediglich habe 
ich die Konfiguration angepasst.
In der Bastellkiste lagen noch ungenutzte 74HC240, die allerdings die 
Signale invertieren. Der 74HC240 enthält 2x4 Treiber, die jeweils in den 
Tristate geschaltet werden können. Andere Treiberbausteine würden auch 
gehen. Eine uf2-Datei befindet sich mit allen dazugehörigen Dateien in 
der zip-Datei.
Bis das PC-Programmm "VS-Code" diese Datei überhaupt erstellt hat, 
musste ich mich tief einlesen und auch viel probieren. Die cmake-Orgie, 
die RaspberryPi veranstaltet, ist nicht nach meinem Geschmack.
Getestet habe ich das System mit eienm 40m Kabel. Eine längere Leitung 
stand mir nicht zur Verfügung. Allerdings musste ich die 
Adapter-Geschwindigkeit auf 2000kHz reduzieren, damit alles fehlerfrei 
durchlief.


Harald

[Gerd E. (robberknight)]

Ich will nicht Deine Arbeit schlecht machen, aber SWD ist konzipiert 
fürs Debuggen und Programmieren über eine Entfernung von vielleicht 15 
cm. Es mag natürlich unter guten Umständen (und Reduktion der 
Geschwindigkeit) auch über längere Kabel funktionieren, aber das ist 
nicht Ziel der Sache.

Bei Deinen Entfernungen mit 20 m und mehr musst Du daher schon harte 
Kompromisse eingehen und ob es dann so wirklich dauerhaft stabil läuft 
oder halt nur meistens ist auch nicht klar. Durch die langen Kabel ohne 
Treiber und Schutzbausteine wird das ganze auch empfindlich für Schäden 
durch entferntes Gewitter. Probleme durch Masseverschiebung sind 
natürlich auch zu befürchten.

Ich würde daher ganz klar empfehlen anders vorzugehen: nimm ein 
differentiell getriebenes Übertragungsmedium, z.B. einen RS485-Bus. Und 
dann pack einen Bootloader auf den Microcontroller den Du über das RS485 
ansteuern kannst und damit dann neue Firmware laden kannst.

Ist wesentlich stabiler. Außerdem kannst Du den Bus natürlich auch für 
die Übertragung von Nutzdaten, zum Anbinden mehrerer Mikrocontroller 
etc. verwenden.

[Harald P. (haraldp)]

Gerd E. schrieb:
> Ich will nicht Deine Arbeit schlecht machen..
Hallo Gerd, ich gebe dir in allen Punkten recht. Es ist eine 
Bastellosung und kein professionelles Projekt. Tatsächlich brauche ich 
das System nur für die Inbetriebnahme. Wenn alles läuft, wird es 
abgebaut und das Zielsystem nicht wieder angefasst.
Hier noch die versprochene zip-Datei.

[Dieter S. (ds1)]

Wenn eine Netzwerkverbindung möglich ist: OpenOCD, das kann übers 
Netzwerk bedient werden und zum Debuggen/Programmieren verwendet werden. 
Das Zielsystem und ein kleiner Rechner (z.B. Raspberry Pi) kann dann 
fast beliebig weit weg stehen.

[Harald K. (kirnbichler)]

Wenn Netzwerk möglich ist, man aber die verwendete Software nicht ändern 
will: USB-Deviceserver verwenden.

Ist mit einem Raspberry Pi und virtualhere auch ohne Geldeinwurf 
möglich. Auf dem Programmier-PC installiert man den Devicetreiber 
(https://www.virtualhere.com/usb_client_software) als "virtuelle 
USB-Schnittstelle", auf dem Raspberry Pi läuft "VirtualHere USB Server 
for Linux (ARM) <-- Raspberry Pi 0, ... "

https://www.virtualhere.com/usb_server_software

Den SWD-Pico schließt man an diesen Raspberry Pi an.

[Harald P. (haraldp)]

Danke Dieter S. und Harald K.
die Vorschläge sind hilfreich. Ich bin doch sehr hardwarelastig geprägt 
und löte lieber etwas schnell zusammen (immer auf Lötrasterplatine) als 
Scripte  und Programme zu schreiben.

[Alexander (alxc)]

Ich verstehe das Problem nicht. Du setzt deinen RPi neben die MCU im 
Gartenhaus und kommunizierst damit per LAN. OpenOCD musst du eh auf dem 
RPi starten. Jetzt arbeitest du über SSH entweder direkt mit dem OpenOCD 
CLI oder du verbindest dich mit dem gdb Client von deinem 
Entwicklungsrechner aus mit gdb Server (OpenOCD) auf dem RPi. Dafür 
musst du 0 scripten. Das ist der ganz normale Anwendungsfall. Welchen 
Vorteil hat es wenn das RPi im Haus steht?

[Alexander (alxc)]

Achso: den RPi gibts ja bisher gar nicht sondern nur den Pico den du 
wahrscheinlich an deinen PC anschließen willst.