Programmieren von Mikrocontrollern mit UART

Ich versuche, ein Entwicklungsboard mit einem Dialogmikro zu entwerfen. Ich versuche, die Notwendigkeit eines Programmierers auf diesem Board zu beseitigen. Damit der Benutzer einfach ein USB-Kabel einstecken und mit dem Chip kommunizieren und booten kann. Ich habe gesehen, dass das Arduino ein zusätzliches Mikro (ATMEGA16U2) verwendet, um USB zu UART zu machen, und dies wird in das eigentliche Mikro des Arduino (ATMEGA328P-PU) eingespeist. Entschuldigung, wenn das Folgende sehr dumm rüberkommt, aber für meine eigenen Klarstellungen habe ich 2 Fragen:

Erstens, wie wird das erste Mikro am Anfang programmiert? Ich würde mir vorstellen, dass der Chip leer ist. Wenn ich also zuerst einen USB-Anschluss anschließe, würde er nichts sehen?

Zweitens könnte ich einen FTDI-USB-zu-Seriell-Chip verwenden, um dasselbe zu tun? Wäre das nicht eine einfachere Lösung gewesen?

Ich vermute, sobald die Kommunikation zwischen meinem Laptop über USB und meinem Mikro über UART initiiert ist, könnte ich dann jede IDE verwenden, um diesen Chip zu programmieren.

Ich habe sehr grundlegende Vorkenntnisse in der Arbeit mit Mikros und möchte diese Gelegenheit nutzen, um diese zu verbessern.

Kleine Anpassung: Sie sind Mikrocontroller, kein Mikroprozessor
IIRC, ATMEGA16U2 wird verwendet, um den teureren FTDI-Chip zu emulieren.
Ja, es gibt viele Open- und wahrscheinlich Closed-Source-Beispiele für die Verwendung von FTDI-Chips mit den verschiedenen Protokollen, die von dieser und anderen MCUs (dieser Marke und anderen) unterstützt werden. Sie können einige preiswerte Programmierer bekommen, die oft auf einem FTDI-Chip basieren, wo jemand die Software für Sie gemacht hat. Aber wenn Sie in MCUs einsteigen möchten, gehört dies dazu. Das Programmieren des MCU-Codes selbst macht 5% der Arbeit zwischen dem Lesen, dem Beherrschen der Toolchain, dem Lösen der vorprogrammierten oder Feldprogrammierung usw. aus, um den Rest abzudecken der Arbeit.
Wenn es darauf ankommt, kaufen Sie ein Arduino oder ein Nucleo oder Mbed oder unzählige andere Tools, die auf Sandbox-Lösungen basieren, und erstellen Sie Ihren eigenen Programmierer. Es gibt auch andere Produkte, die werkseitig so programmiert sind, dass sie beispielsweise dfu unterstützen. Verkabeln Sie sie, stellen Sie den Riemenstift richtig ein, schalten Sie sie ein oder setzen Sie sie zurück, und Sie können sie über USB programmieren, entfernen / ändern Sie den Riemen-Reset und los geht's. Andere haben UART-Bootloader eingebaut, um eine nette Verbindung mit einem FTDI oder einem anderen Teil in einem UART-Modus herzustellen.
hört sich so an, als wollten Sie den Schritt von einem 50-Dollar-Arduino-Board machen, in dem Sie sich in einer Sandbox befinden, in der alles andere, einschließlich 90% der Programmierung der Peripheriegeräte des Teils, für Sie erledigt wurde, und in den Kauf des 2-Dollar-Teils ausbrechen möchten sich selbst und es verwenden. Die Mühe wert, aber es gibt Mühe, beginnend mit dem Lesen der systeminternen Programmierschnittstellen, auch nichts darüber, dass die Xmegas vs. Megas und kleinere Geräte nicht immer die gleichen Protokolle in der AVR-Welt teilen. Studieren Sie die Datenblätter und App-Hinweise.
@old_timer Irgendwie hat jeder das winzige Detail übersehen - es ist kein Atmega- Chip, nach dem das OP fragt. Es ist eine Cortex-M0-Variante mit einer sehr spezifischen Startsequenz. Ich habe einige Details gefunden (Links in meiner Antwort), aber nicht viel.
"Studieren Sie die Datenblätter und App-Notizen", was in den Chip eingebaut ist, sei es Hardware oder werkseitig programmierte Roms, ist sehr spezifisch für dieses Produkt oder diese Produktlinie. Es gibt also keine allgemeine Antwort. Ja, es gibt definitiv Cortex-m0-Produkte von mindestens ein paar Anbietern, die uart-basierte Lösungen haben, die mit einem ftdi-USB-to-Whatever-Breakout trivial sind. Ebenso haben die Cortex-ms eine SWD-Zweidrahtschnittstelle, die mit einem USB-zu-FTDI-Breakout-Board (mpsse) ebenfalls trivial ist.
Eine Reihe der Eval-/Demo-Boards, die Nucleos und Discoverys und Launchpads und dergleichen haben eine USB-seitige Debug-MCU, die Sie nicht kontrollieren, und eine MCU, die wir testen, und die eine USB-Schnittstelle für den Chiphersteller bereitstellt, für die er ein Tool erstellen kann und dann verwendet dieser chip eines der unterstützten protokolle für die ziel-mcu, von denen viele keinen direkten usb haben. es ist keine ungewöhnliche Praxis.
Mir wurde mitgeteilt, dass die Herstellung eines Boards, das direkt mit einem USB-Anschluss und ohne Programmierer programmiert werden kann, ein großes Projekt für sich wäre. Er sagte auch, dass die meisten Evaluierungsboards mit 2 MCUs geliefert werden, wobei 1 der MCU der Programmierer mit etwas schwerem Code ist, um den Ziel-Bootloader zu programmieren. Er sagte, Unternehmen widmen sich solchen Dingen, wenn sie ihre Programmierer herstellen, die auf sehr schwerer Software basieren. Und auch, dass UART allein über ein FTDI Ihnen nichts Nützliches bringt, und ich sollte einfach einen Anschluss hinzufügen, der das JTAG ausbricht und UART.

Antworten (3)

Erstens, wie wird das erste Mikro am Anfang programmiert?

In der Fabrik mit einem Programmierer.

Zweitens könnte ich einen FTDI-USB-zu-Seriell-Chip verwenden, um dasselbe zu tun?

Der Atmega328 kann mit dem SPI-Protokoll programmiert werden. Um einen SPI-Stream aus einem FTDI-Chip herauszuholen, ist eine geschickte Programmierung erforderlich.

Die meisten „selbstprogrammierenden“ Entwicklungskits haben ein grundlegendes Boot-Programm in einem geschützten Abschnitt ihres FLASH-Speichers. Es wird dort in der Fabrik platziert. Es verfügt über SW, um eine Schnittstelle (UART, USB) zu verwenden, mit der Sie Daten in den Rest des FLASH hochladen und dorthin springen können. Das Protokoll ist proprietär, wird aber manchmal offengelegt.

Ich könnte dann jede IDE verwenden, um diesen Chip zu programmieren.

Nein, Ihre IDE müsste wissen, welche Schnittstelle und welches Protokoll verwendet werden soll. Auch das Arbeiten mit Haltepunkten und das schrittweise Durchlaufen des Codes wird wahrscheinlich nicht funktionieren. Aus diesem Grund ist es jeden Cent wert, etwas Geld für einen anständigen (ICE) Programmierer auszugeben.

Das Entwerfen eines selbstprogrammierenden Kits wird also schwieriger als ich dachte. Jemand erwähnte, ich könnte den Bootloader zunächst mit JTAG-Tools laden und dann die gesamte nachfolgende Programmierung per Kommunikation über uart mit einem FTDI-Chip durchführen. Werden FTDI-Chips also nicht für Mikro- und Comp-Kommunikation verwendet?
Ich nehme an, was noch wichtiger ist, gibt es keine einfache Lösung, um ein „Selbstprogrammierungskit“ zu entwerfen? Eines, bei dem der Entwickler nur seine Laptops über USB an das Kit anschließt?
Ja, Sie können Ihren eigenen 'Bootloader' schreiben und diesen mit einem dedizierten Programmierer schreiben. Verwenden Sie dann den FTDI/UART, um Bilder hochzuladen. Sie müssen auch SW auf dem PC schreiben, um ein Bild an einen (virtuellen) COM-Port zu senden. Ich dachte, Sie suchen nach einer Komplettlösung ohne Programmierer.
ftdi-Chips können verwendet werden, um verschiedene Protokolle zu generieren: spi, uart, jtag, i2c, benutzerdefiniert. Diejenigen, die mpsse unterstützen, machen das glatter, aber die anderen können etwas verprügelt werden.
Diese Antwort verfehlt den Punkt - die Frage bezieht sich nicht auf ein ATmega-Ziel.

Beim Kauf von Arduino ist der Chip (Atmega8U2/16U) bereits mit Firmware programmiert. Es kann mit dem DFU-Protokoll aktualisiert werden, das üblicherweise von vielen USB-Geräten unterstützt wird. Wenn Sie nur den Chip kaufen, müssen Sie dieselbe Firmware beim ersten Mal mit dem regulären ISP-Mechanismus hochladen.

Allerdings ist die Firmware in Atmega8U2/16U eine einfache USB-zu-UART-Brücke, sodass Sie sie definitiv durch eine FTDI- oder Silicon Labs-Hardwarebrücke ersetzen können.

Ich vermute, sobald die Kommunikation zwischen meinem Laptop über USB und meinem Mikro über UART initiiert ist, könnte ich dann jede IDE verwenden, um diesen Chip zu programmieren

Die elektrische Verbindung zwischen USB und UART unter Verwendung eines Bridge-Chips bedeutet keine Kommunikation. Sie benötigen eine Software, die auf einem Mikrocontroller läuft und UART hört. Die Software heißt "Bootloader" und muss beim ersten Mal mit einer alternativen Methode hochgeladen werden.

Für ATMega328P ist diese alternative Methode derselbe ISP, der zum Programmieren von Firmware in die ATmega8U-USB-Bridge verwendet wird.

Sie verwenden jedoch einen Dialog-Mikrocontroller, bei dem es sich anscheinend um eine Cortex-M0-Variante handelt. Die Dokumentation auf der Dialog-Site erfordert eine Registrierung, daher kann ich sie nicht sehen. Aus diesem Dokument geht hervor, dass Dialog-MCUs einen komplexen Mechanismus mit zwei Bootloadern verwenden, von denen einer durch Ihren eigenen ersetzt werden kann, ein anderer scheint werkseitig in den OTP-Speicher (One-Time Programmable) eingebrannt zu sein.

Wenn dies der Fall ist, reicht das Anschließen von USB an den UART-Port mit FTDI aus, um mit der Entwicklung zu beginnen. Alternativ können Sie JTAG verwenden, um Ihre Anwendung direkt in den Arbeitsspeicher hochzuladen (so genannter Entwicklungsmodus in der Dokumentation).

Sie müssen es selbst herausfinden, wenn Sie Zugang zu Dokumentation haben. Hier gibt es einige Informationen

Damit der Benutzer einfach ein USB-Kabel einstecken und mit dem Chip kommunizieren und booten kann

Hier gibt es ein Problem mit der Terminologie. Wenn Sie „der Benutzer“ sagen, meinen Sie sich selbst oder den „Endbenutzer“? Da Endbenutzer den Chip nicht "booten", schließen sie das Gerät an den USB-Anschluss an (oder versorgen es auf andere Weise mit Strom) und es bootet von selbst.

Ob sie damit kommunizieren können oder nicht, hängt ganz von der Software ab, die Sie hochladen. Ohne diese Software können sie (oder Sie) möglicherweise mit dem vorhandenen Bootloader kommunizieren und ihre eigenen Programme hochladen, wie oben beschrieben.

Wenn Sie unter "Kommunizieren" etwas anderes meinen als das Hochladen der Anwendung von IDE, hilft Ihnen der FTDI-Chip nicht. Wenn Sie beispielsweise das DFU-Protokoll unterstützen möchten (damit Endbenutzer die Software einfach aktualisieren können) oder wenn Sie möchten, dass Ihr Gerät auf dem PC als etwas anderes angezeigt wird (z. B. Eingabe- oder Speichergerät), müssen Sie die USB-Geräteklasse ändern. Mit dem FTDI-Chip ist dies nicht möglich.

AKTUALISIEREN

Wie @chris-stratton in den Kommentaren unten feststellte, ist es sehr ratsam , zumindest einen Platzhalter für SWD (10-Pin Cortex Debug Connector) hinzuzufügen, auch wenn andere Programmiermethoden verfügbar sind. Das erspart Ihnen auf lange Sicht viel Kopfzerbrechen.

Für ein Cortex M0-Target wäre es ein bedauerlicher Fehler, ein Board zu entwerfen, das die SWD-Signale nicht ausbricht, unabhängig davon, ob eine andere Methode wie ein USB- oder UART-Bootloader unterstützt wird. Die meisten Discovery- und Nucleo-Evaluierungsboards von ST haben beispielsweise ein zweites Mikro an Bord, das als USB-SDW-Programmier- und Debug-Adapter fungiert und in einigen Fällen auch eine Laufzeit-UART-Schnittstelle zum Ziel bereitstellt.
"Die Firmware in Atmega8U2 / 16U ist eine einfache USB-zu-UART-Brücke, sodass Sie sie definitiv durch eine FTDI- oder Silicon Labs-Hardwarebrücke ersetzen können" - es sollte vielleicht angemerkt werden, dass die meisten geklonten Arduinos (insbesondere die von Chinesen verkauften kostengünstigeren Boards) sind Lieferanten) nehmen diese Ersetzung vor. Und normalerweise auch nicht mit einem echten FTDI-Chip, was oft bedeutet, dass es eine Weile dauert, einen geeigneten Treiber zu finden, bevor Sie ihn verwenden können.
@ChrisStratton "Schwerer Fehler beim Entwerfen eines Boards, das die SWD nicht durchbrochen hat" - Stimme dem zu 100% zu. Verstehe nicht, warum Sie die obige Aussage gleich mit dem Hinweis auf das zweite Mikro unterlaufen. Das OP-Ziel besteht, wie gesagt, darin, das Design zu vereinfachen und eine spezielle Programmierschnittstelle zu vermeiden. Ein SWD-Header und ein FTDI-Chip sind für die meisten Aufgaben ausreichend, mit Ausnahme derjenigen, die eine Änderung der Geräteklasse erfordern.
@Jules Viele Arduino-Klone kommen tatsächlich nur mit ISP-Header aus. DIY- und Steckbrett-Arduinos folgen sicherlich dem gleichen Weg.
@Maple - weil das Einsetzen der SWD- und USB-Seriell in ein integriertes Mikro theoretisch bedeutet, dass sie auch für Neulinge verfügbar sind. Obwohl nichts mit USB sogar einfach endet ...
@ChrisStratton Verstehe immer noch nicht, warum du dafür ein zweites Mikro brauchst. Die Verwendung der FTDI-Bridge ist sicherlich eine einfachere Lösung, insbesondere für "Neulinge".
@Maple - Arduino fand den ATmega8u2 oder 16u2 vorteilhaft, selbst wenn seine Funktionalität nur einen FTDI widerspiegelte. Aber eine MCU kann auch so programmiert werden, dass sie mehr kann, zum Beispiel eine SWD-Schnittstelle, etwas, worin die billigen FTDI-Teile wie der FT2232RL schlecht sind (Sie brauchen wirklich die High-End-Teile wie den 2232H).

Sowohl Arduino als auch NodeMCU verwenden einen USB-zu-UART-Brückenchip wie FTDI, und beide verwenden zusätzliche Steuerleitungen (CTS RTS), um das Zurücksetzen und/oder die Startauswahlpins des Ziel-uC zu steuern. Auf diese Weise können Sie das Ziel-uC und auch zurücksetzen Versetzen Sie es in den Bootloader-Modus, in dem eine spezielle Software im uC dafür verantwortlich ist, den neuen Code über die serielle Schnittstelle zu empfangen und in den Flash zu brennen. Im Fall von Arduino muss dieser Bootloader-Code, wie bereits erwähnt, zuvor über eine Standard-Programmierschnittstelle in den uC gebrannt werden

Aber im Fall von NodeMCU (ESP8266) ist der Bootloader bereits im ROM-Speicher vorhanden (und wird immer dort sein, es ist nicht möglich, ihn zu löschen), sodass die PC-Software das Zurücksetzen des ESP8266 erzwingt (über CTS) und das RTS-Signal verwendet (an ein anderes IO angeschlossen) um den Start des ROM-Bootloaders zu erzwingen, dann verwendet die Anwendung das Bootloader-Protokoll, um den neuen Code zu senden, der geflasht werden soll.

Ich habe bereits mit STM32 Cortex-M3-Mikrocontrollern gearbeitet, und sie haben auch einen ROM-Bootloader, der zur Rücksetzzeit durch ein Signal in einem der IOs ausgewählt werden kann, sodass es theoretisch durchaus möglich ist, ein STM32-"Arduino-Board" zu bauen, das genau darin funktioniert auf die gleiche Weise wie ein NodeMCU-ESP8266, der keinen vorgeflashten Bootloader benötigt und auch nicht "brickable" ist, da der Bootloader immer zugänglich ist.