Ist SWD mit FTDI-Chip eine universelle Programmierlösung?

Ich habe hoch und tief gesucht (tatsächlich habe ich die letzten Monate hin und wieder damit verbracht, eine Antwort zu finden). Vielleicht stelle ich nicht die richtigen Fragen oder starre der Antwort ins Gesicht, ich bin mir nicht sicher. Ich war zu nervös, um zu fragen, aber ich bin mit meinem Latein am Ende, also los.

Ich erstelle ein Projekt, das aufgrund von Größenbeschränkungen sehr klein sein muss. Das bedeutet kleine MCU und kleine Programmierschnittstelle. Es ist auch Open Source, daher möchte ich die Programmierschnittstelle so günstig und einfach wie möglich halten (auch als Student möchte ich nicht viel ausgeben, wenn ich nicht muss).

Dieser Artikel, den ich gefunden habe, scheint mir die Möglichkeit einer universellen Lösung aufzuzeigen. Diese FTDI-Chips sind viel billiger als jeder andere (legitime) JTAG-Programmierer. Werden sie im Großen und Ganzen (für die Nachwelt) in der Lage sein, mit jeder ARM-MCU, die eine SWD-Schnittstelle enthält, zu kommunizieren und sie zu programmieren?

Insbesondere (falls relevant) möchte ich das SiP-Modul SiLabs BGM121 in mein Projekt integrieren und versuche herauszufinden, wie ich es programmieren würde. Ich interessiere mich an dieser Stelle nicht einmal unbedingt für das Debuggen, sondern versuche nur, eine billige Lösung zu finden. Auch zwischen dem SiLabs CP2102 und dem FTDI FT2232H, was funktioniert eher?

Die meisten Hardwarelösungen mit geeigneter Spannung können funktionieren, wenn Sie die entsprechende Software dahinter haben, was oft bedeutet, etwas wie OpenOCD zu patchen (oder darauf zu warten, dass jemand anderes es patcht), um ein bestimmtes Ziel zu unterstützen. Einige Hardware-Ansätze arbeiten lediglich schneller als andere oder kommen besser mit extremen Spannungen zurecht. Der FT2232H ist für grundlegende Siliziumlösungen ziemlich teuer - Sie können den CMSIS-DAP-Code beispielsweise auf jede Low-End-ARM-Cortex-MCU mit USB portieren, aber er wird viel langsamer sein.
Das trifft auf den FT2232H zu. Irgendwo auf dem Weg habe ich die Grenzen zwischen dem FT232h verwischt, der billiger, aber vielleicht älter ist? Ich werde Open-OCD herunterladen und installieren und versuchen, das zu lernen und zu sehen, was die Einfachheitsstudios von SiLabs zu bieten haben. Haben Sie einen Vorschlag für eine günstige Hardwarelösung? Ich entschuldige mich für meine Unwissenheit, ich fange gerade an, die Armprogrammierung zu lernen, das Datenblatt für den BGM121 war ziemlich unscheinbar, aber ich habe eine App-Notiz gefunden, die ich von ihnen durchlese. Vielen Dank für Ihre Antwort!
Ihre Bearbeitung der Frage macht im Kontext dieser Site nicht viel Sinn. Sie hätten es möglicherweise als Antwort posten können - dann hätten zumindest die ursprünglichen Fragen / Antworten Sinn gemacht. Am besten warten Sie, bis Sie eine neue Frage zur Firmware haben, und stellen Sie dann etwas Neues.
Ja, ich weiß nicht wirklich, wie diese Seite funktioniert, um 100% ehrlich zu sein. Ich dachte, es wäre die klare Verbreitung von Informationen für die Nachwelt? Ich habe meine eigene Frage beantwortet und die Frage bearbeitet, um dies widerzuspiegeln und jedem zu helfen, der sich in der gleichen Position wie ich befand, auf (IMHO) klare Weise. Die Informationen sind jetzt in Sichtweite. Ich mache nicht das ganze Händeringen, wenn ich Informationen finde, die mir fehlen, bin ich nur für die Informationen dankbar, nicht für das Format. Aber auf jeden Fall werde ich meinen Beitrag bearbeiten, Sie haben hier um viele Größenordnungen mehr Erfahrung als ich.
und jetzt hast du den doppelten Ruf, den du vorher hattest...

Antworten (2)

Die ARM-SWD-Schnittstelle ist insofern „generisch“, als das Schnittstellenprotokoll sich nicht um die Zielhardware kümmert. Angenommen, Ihr Programmiergerät arbeitet mit der richtigen Spannung, ja, es kann mit jeder Hardware funktionieren.

Hinter der SWD-Schnittstelle sind die Register, die das Debuggen im SoC steuern, speicherabgebildet. Obwohl diese in gewissem Sinne standardisiert sind, ist für jede Debug-Toolkette häufig ein gewisses Maß an Anpassung erforderlich (auf der Softwareseite). Beispielsweise wird eine neue CPU einen neuen ID-Code-Wert und möglicherweise einige zusätzliche architekturdefinierte Steuerregister haben.

Grundsätzlich haben Sie die Wahl, das SWD-Protokoll in Software auf Ihrem PC zu implementieren und eine USB-to-Pins-Schnittstelle zu verwenden oder das Protokoll in einem Mikrocontroller zu implementieren und einen USB-Endpunkt zu präsentieren, der „debuggt“. Letzteres tun fast alle Entwicklungsboards mit eingebauter Debug-Schnittstelle, ähnlich wie SWDAP und die DAPLink- Software. Häufig sind diese Entwicklungsboards so konfiguriert, dass Sie die SWD-Signale herausbrechen und zum Debuggen Ihrer eigenen Zielhardware in einem Endproduktdesign verwenden können.

Wenn Sie sich gegen die Implementierung von DAPLink entschieden haben, sind Sie möglicherweise in den Toolchains, die Ihre Schnittstelle unterstützen, eingeschränkter.

In der Vergangenheit war es schwierig, auf die SWD-Protokolldokumentation zuzugreifen, und dies scheint zu einer gewissen Verwirrung geführt zu haben, wenn es um generische Sonden geht. Die alten Pre-CoreSight-JTAG-Schnittstellen waren auch viel gerätespezifischer, mit einem in der CPU implementierten TAP-Controller.

Danke für die Antwort. Auf jeden Fall hilfreich, ich denke, der Weg zu gehen könnte darin bestehen, ein stm32-Entwicklungsboard mit eingebautem st-Link zu bekommen, das dann mit Segger-Firmware geflasht werden kann, um es auf ein J-Link zu aktualisieren. Ich glaube, sie halten es für den J-Link Lite. Es gelten natürlich die gleichen Lizenzbeschränkungen, aber ich kann es verwenden, um meine Füße nass zu machen, und wenn ich am Ende versuche, ein Projekt zu verkaufen, kann ich es von dort aus nicht herausfinden. Um es zusammenzubinden, ist dies möglicherweise die beste Option für einen billigen universellen Programmierer / Debugger. Bitte korrigieren Sie mich, wenn ich falsch liege.
Sie beziehen sich auf Einschränkungen für die zu debuggende Hardware oder auf Toolchain-Einschränkungen? Das mbed cmsis-dap ist unbelastet (soweit ich weiß) und kann auf vielen Entwicklungsboards geflasht werden (wahrscheinlich billiger als der Kauf von dip-dap, einem eigenständigen NXP-Teil, das für das Prototyping entwickelt wurde). Mir sind keine zusätzlichen Funktionen in Firmware anderer Anbieter bekannt (aber ich musste nie nachsehen).
Entschuldigung, ich bezog mich auf Einschränkungen, die Segger für ihre jlink edu-Firmware auferlegt hat. Was Sie sagen, ist interessant. Wenn ich also ein stm32-Entwicklungsboard kaufe, kann ich cmsis-dap auf den st-link-Teil des Boards flashen? Oder ist cmsis-dap nur eine Softwareschicht? Das kann ich in jedem Fall tun. Danke schön!

Okay, nach mehr Recherche glaube ich, dass ich eine relativ billige Lösung gefunden habe, ein stm32-Entwicklungsboard kann mit DAPLINK-Firmware geflasht werden, aber ich glaube nicht, dass die offizielle Github-Firmware nativ funktionieren wird. Aber ich habe festgestellt, dass auf dem daplink_usb-Board, das im readbear mk20 enthalten ist, ein stm32-Chip läuft, sie haben die Firmware veröffentlicht, die eine Zeile ändern muss, um sie mit dem 8-MHz-Kristall kompatibel zu machen (detailliert im unten verlinkten Forumsbeitrag). Sonst den Quarz gegen einen 16 MHz tauschen.

GITHUB-REPO

Gute Forum-Ressource hier .

Redbear Github-Fork

Beachten Sie, dass ein CMSIS-DAP, das mit einer Full-Speed-MCU gebaut wurde, relativ langsam ist, was auf Kosten des für die Portabilität verwendeten Modus geht. Kommerzielle Versionen mit anständiger Geschwindigkeit sind USB-Hochgeschwindigkeitsgeräte, weniger wegen der Übertragungsgeschwindigkeit, als weil dann eine größere Paketgröße erlaubt ist. Das ST-LINK-Protokoll ermöglicht eine effizientere Nutzung von USB mit voller Geschwindigkeit, sodass Sie für ein STM32-Ziel wahrscheinlich nicht die ST-LINK-Firmware ersetzen möchten. Es ist auch möglich, zumindest einige andere Marken über einen unveränderten ST-LINK mit OpenOCD zu flashen, zum Beispiel alle drei Generationen von Nordic BLE-Chips.
Ist SWD mit FTDI-Chip eine universelle Programmierlösung?
AntwortenHierDatenschutz-Bestimmungen1y, 0v