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.
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.
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.
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.
Lange Pham
Lange Pham
Oldtimer
Oldtimer
Oldtimer
Ahorn
Oldtimer
Oldtimer
Hasman404