Vor einigen Jahren lernte ich russische Mikrocontroller von Milandr kennen. Es war 2013, als Ingenieure die ersten Ergebnisse des Föderalen Zielprogramms „Entwicklung der elektronischen Komponentenbasis und der Funkelektronik“ für 2008–2015 heiß diskutierten. Zu diesem Zeitpunkt war der Controller K1986BE9x (Cortex-M3-Kern) bereits erschienen, und der Controller 1986BE1T (Cortex-M1-Kern) war gerade erschienen. Im LQFP-144-Kunststoffgehäuse trug er in der Dokumentation die Bezeichnung K1986BE1QI (Luftfahrt) und auf dem Chip selbst die Bezeichnung MDR32F1QI. Auf der Website des Herstellers trägt er den Zusatz „Luftfahrt“, da er über flugzeugspezifische Schnittstellen (ARINC 429, MIL_STD_1553) verfügt.
Überraschenderweise hatte Milandr zum Zeitpunkt der Veröffentlichung dieser Controller Debug-Kits und eine Bibliothek mit Routinen für die Arbeit mit der Peripherie vorbereitet, „jedoch ohne zusätzliche Garantien und Verpflichtungen hinsichtlich der Korrektheit der Bibliothek“. Die Bibliothek ähnelt der Standard Peripheral Library von STMicroelectronics. Generell haben alle auf dem Cortex-M-Kern basierenden ARM-Controller vieles gemeinsam. Daher verlief die Einarbeitung in die neuen russischen Controller schnell. Und wer Marken-Debug-Kits kaufte, erhielt während der Nutzung technischen Support.
Debug-Kit für Mikrocontroller 1986BE1T, © Milandr
Mit der Zeit traten jedoch die Kinderkrankheiten neuer Chips und Bibliotheken auf. Testbeispiele der Firmware funktionierten ohne sichtbare Probleme, doch mit erheblichen Änderungen traten Ausfälle und Fehler auf. Die ersten „Babyschwalben“ in meiner Praxis waren unerklärliche Ausfälle im Betrieb des CAN-Controllers. Ein Jahr später wurde ein Problem mit dem Modul auf dem 1986BE1T (avia) Controller der frühen Revision entdeckt . Im Allgemeinen waren alle Revisionen dieser Mikrocontroller bis 2016 nur von begrenztem Nutzen. Es wurde viel Zeit und Nerven darauf verwendet, diese Probleme zu identifizieren, deren Bestätigung nun in .
Unangenehm war, dass die Arbeiten und die Fehlersuche nicht auf Debug-Boards, sondern auf Prototyp-Boards von Geräten durchgeführt werden mussten, die für die Serienproduktion vorgesehen waren. Außer dem JTAG-Anschluss gab es dort meist nichts. Der Anschluss an einen Logikanalysator war schwierig und umständlich, und LEDs oder Bildschirme waren meist nicht vorhanden. Aus diesem Grund kam mir die Idee, ein eigenes Debug-Board zu entwickeln.
Einerseits gab es Marken-Debug-Kits auf dem Markt sowie wunderbare Boards von LDM-Systems aus Zelenograd. Andererseits sind die Preise für diese Produkte unerschwinglich, und die Grundfunktionalität ohne Erweiterungskarten entspricht nicht den Erwartungen. Eine Platine mit einem verlöteten Controller und einem Pin-Anschluss interessiert mich nicht. Und interessantere Boards sind teuer.
Debug-Board MILANDR LDM-HELPER-K1986BE1QI-FULL, © LDM Systems
Milandr verfolgt eine einzigartige Preis- und Marketingpolitik. Beispielsweise ist es möglich, kostenlose Muster einiger Mikroschaltungen zu erhalten, dies ist jedoch nur juristischen Personen vorbehalten und mit einem bürokratischen Aufwand verbunden. Generell sind Mikroschaltungen in einem Metall-Keramik-Gehäuse im wahrsten Sinne des Wortes Gold wert. Beispielsweise kostet der Controller 1986BE1T in Moskau zwischen 14 und 24 Rubel. Der statische Speicherchip 1645RU6U kostet ab 15000 Rubel. Und diese Preise gelten für alle Produkte. Infolgedessen sparen selbst spezialisierte Forschungsinstitute mit staatlichen Aufträgen und scheuen solche Preise. Mikroschaltungen in einem Kunststoffgehäuse für den zivilen Gebrauch sind deutlich günstiger, aber bei gängigen Anbietern nicht erhältlich. Zudem ist die Qualität von Mikroschaltungen in einem Kunststoffgehäuse meiner Meinung nach schlechter als die der „goldenen“. Beispielsweise konnte ich den Controller K1986BE1QI nicht mit einer Frequenz von 128 MHz starten, ohne die Flash-Latenz zu erhöhen. Gleichzeitig stieg die Temperatur dieses Controllers auf 40–50 °C. Der 1986BE1T („goldener“) Controller startete jedoch ohne zusätzliche Einstellungen mit 128 MHz und blieb kühl. Er ist wirklich gut.
"Goldener" Mikrocontroller 1986BE1T, (c) Milandr
Ich hatte Glück, dass der Mikrocontroller im Kunststoffgehäuse noch im Einzelhandel bei LDM Systems erhältlich ist und alle Platinendiagramme frei verfügbar sind. Das Schlimme ist, dass auf der Website auf dem Foto des Controllers die Markierung zu sehen ist, die besagt, dass es sich um die 4. Revision von 2014 handelt, also mit Mängeln. Ich habe lange überlegt – kaufen oder nicht kaufen. So vergingen mehrere Jahre ...
Die Idee, ein Debug-Board zu entwickeln, ließ mich nie los. Nach und nach entwickelte ich alle Anforderungen und überlegte, wie ich das alles kompakt und kostengünstig auf einem Board unterbringen könnte. Gleichzeitig bestellte ich die fehlenden Komponenten bei den Chinesen. Ich hatte es nicht eilig – ich habe alles selbst gemacht. Chinesische Lieferanten sind bekannt für ihre Schlamperei – ich musste dasselbe bei verschiedenen Anbietern bestellen, um alles zu bekommen, was ich brauchte. Außerdem stellte sich heraus, dass einige der Speicherchips gebraucht waren – offensichtlich aus defekten Geräten gelötet. Das quälte mich später.
Der Kauf eines Milandr K1986BE1QI (Flugzeug-)Mikrocontrollers ist keine leichte Aufgabe. Im selben Chip and Dip Store fand ich in der Rubrik „Bestellartikel“ nur den K1986BE92QI für 740 Rubel, aber der passte mir nicht. Die einzige Möglichkeit war, eine nicht aktuelle Revision von LDM-Systems für 2000 Rubel zu kaufen. Da ich nirgendwo anders einen Ersatz finden konnte, entschied ich mich für den Kauf des verfügbaren. Zu meiner angenehmen Überraschung verkauften sie mir einen brandneuen Controller, Baujahr Dezember 2018, Revision 6+ (1820). Auf der Site befindet sich noch ein altes Foto, und zum Zeitpunkt des Schreibens ist der Controller nicht verfügbar ...
Mikrocontroller K1986BE1QI (Luftfahrt) in technologischer Verpackung, (c) Foto des Autors
Wichtigste technische Merkmale meines Entwicklungsboards MDB1986 wie folgt vor:
- integrierter Debugger-Programmierer, kompatibel mit J-Link und CMSIS-DAP;
- statischer Speicher 4 Mbit (256 k x 16, 10 ns);
- 64-Mbit-Flash-Speicherchip, Winbond 25Q64FVSIG;
- RS-232-Schnittstellentransceiver mit RTS- und CTS-Leitungen;
- Schnittstellen und Anschlüsse für Ethernet, USB, CAN;
- 7-Segment-Anzeige-Controller MAX7221;
- Stiftstecker für die Arbeit mit MICO (MIL_STD_1553) und ARINC429;
- Fototransistor Everlight PT17-21C;
- fünf farbige LEDs, Reset-Taste und zwei Benutzertasten;
- die Stromversorgung vom USB-Anschluss beträgt 5 Volt;
- Leiterplattenabmessungen 100 x 80 mm
Mir gefielen die Boards der STM-Discovery-Serie, weil sie über einen integrierten Programmierer-Debugger – ST-Link – verfügen. Der proprietäre ST-Link funktioniert nur mit STMicroelectronics-Controllern. Seit einigen Jahren ist es jedoch möglich, die Firmware im ST-Link zu aktualisieren und den Segger J-Link OB (On-Board) Debugger zu erhalten. Rechtlich ist die Verwendung eines solchen Debuggers nur mit STMicroelectronics-Boards beschränkt, das Potenzial ist jedoch unbegrenzt. Mit J-Link OB können Sie also einen integrierten Programmierer-Debugger auf dem Debug-Board nutzen. Beachten Sie, dass die Produkte von „LDM-Systems“ den CP2102 (USB2UART)-Konverter verwenden, der nur flashen kann.
STM32F103C8T6 Mikrocontroller, real und nicht real, (c) Foto vom Autor
Daher musste ich den originalen STM32F103C8T6 kaufen, da die proprietäre Firmware mit dem Klon nicht korrekt funktioniert. Ich bezweifelte diese These und entschied mich, den CS32F103C8T6-Controller der chinesischen Firma CKS auszuprobieren. Am Controller selbst habe ich nichts auszusetzen, aber die proprietäre ST-Link-Firmware funktionierte darin nicht. J-Link funktionierte teilweise – das USB-Gerät wurde erkannt, aber der Programmierer führte seine Funktionen nicht aus und erinnerte ständig daran, dass es „defekt“ sei.
Fehler beim Ausführen des Debuggers auf einem nicht originalen Controller
Ich habe es nicht dabei belassen und zunächst eine Firmware für das Blinken der LED geschrieben und anschließend die IDCODE-Anforderung über das JTAG-Protokoll implementiert. Der ST-Link-Programmierer, den ich auf der Discovery-Karte installiert hatte, und das ST-Link-Dienstprogramm flashten den CS32F103C8T6 problemlos. Dadurch war ich überzeugt, dass meine Karte funktioniert. Zu meiner Freude gab der Zielcontroller K1986BE1QI (Luftfahrt) seinen IDCODE freudig über die TDO-Leitung aus.
Oszillogramm der TDO-Signalleitung mit codierter IDCODE-Antwort, (c) Foto des Autors
Der SWD-Port war also praktisch, um den Debugger selbst zu debuggen und IDCODE zu überprüfen
Die einzige verbleibende Option war ein Debugger. . Ein Projekt aus ARM-Quellen zu erstellen ist keine leichte Aufgabe. Ich habe das Projekt von , und dann habe ich DAP42 ausprobiert. Leider fror Keil uVision ein und wollte nicht mit ihnen arbeiten. Daher habe ich den Debugger-Chip durch einen proprietären STM32F103C8T6 ersetzt und dieses Problem trat nicht mehr auf.
Erfolgreicher Betrieb des integrierten Debuggers J-Link STLink V2
Als alle Schlüsselkomponenten des zukünftigen Debug-Boards verfügbar waren, öffnete ich Eagle CAD und stellte fest, dass sie nicht in der Elementbibliothek vorhanden waren. Es gab keinen Ausweg – ich musste sie selbst zeichnen. Gleichzeitig erstellte ich Footprints für den Speicher, einen HanRun-Anschluss für Ethernet und fügte Frames für Widerstände und Kondensatoren hinzu. Die Projektdatei und die Komponentenbibliothek finden Sie hier .
Schematische Darstellung der MDB1986-Debug-Platine
Die Stromversorgung der Karte erfolgt über eine 5-Volt-Gleichstromquelle, die vom USB-Anschluss bereitgestellt wird. Auf der Karte befinden sich zwei USB-Typ-B-Anschlüsse. Einer ist für den Programmierer, der andere für den K1986BE1QI-Controller. Die Karte kann mit beiden Quellen oder beiden gleichzeitig betrieben werden. Die einfachste Lastregelung und der Schutz der Stromleitung werden durch Schottky-Dioden im Diagramm D2 und D3 (SS24) realisiert. Das Diagramm zeigt außerdem die selbstheilenden Sicherungen F1 und F2 für 500 mA. Die Signalleitungen des USB-Anschlusses sind durch eine Diodenbaugruppe USBLC6-2SC6 geschützt.
Die ST-Link-Debugger-Programmierschaltung ist vielen bekannt und findet sich in der Dokumentation zu den STM32-Discovery-Boards und anderen Quellen. Für die initiale Firmware des ST-Link/J-Link-OB/DAP-Klons (optional) habe ich die Leitungen SWDIO (PA13), SWCLK (PA14) und GND herausgeführt. Viele verwenden UART für die Firmware und müssen die BOOT-Jumper ziehen. SWD ist für mich jedoch praktischer, und dieses Protokoll ermöglicht auch Debugging.
Fast alle Komponenten der Platine werden mit 3.3 Volt versorgt, die vom Spannungsregler AMS1117-3.3 kommen. Zur Unterdrückung elektromagnetischer Störungen und Stromstöße werden LC-Filter aus Kondensatoren und Drosseln der Serie BLM31PG verwendet.
Der 7-Segment-Anzeigetreiber MAX7221 verdient besondere Erwähnung. Gemäß der Spezifikation beträgt die empfohlene Versorgungsspannung 4 bis 5.5 Volt, und der hohe Signalpegel (logisch Eins) beträgt mindestens 3.5 V (0.7 x VCC) bei einer Versorgungsspannung von 5 V. Der Controller K1986BE1QI (Luftfahrt) hat einen logischen Ausgang, der einer Spannung von 2.8 bis 3.3 V entspricht. Offensichtlich liegt eine Nichtübereinstimmung der Signalpegel vor, die den normalen Betrieb stören kann. Ich habe beschlossen, den MAX7221 mit 4 V zu versorgen und die Signalpegel auf 2.8 V (0.7 x 4 = 2.8) zu reduzieren. Dazu wird eine Diode D4 (RS1A oder FR103) in Reihe in den Treiberversorgungskreis geschaltet. Der Gesamtspannungsabfall beträgt 0.9 V (Schottky-Diode 0.3 V und Diode 0.6 V), und alles funktioniert.
Die meisten Ports des Mikrocontrollers K1986BE1QI (Luftfahrt) sind mit Signalen bis zu 5 V kompatibel. Daher ist die Verwendung des CAN-Transceivers MCP2551, der ebenfalls mit 5 V betrieben wird, problemlos möglich. Der MAX232-Chip ist im Diagramm als RS-3232-Transceiver angegeben, ich habe jedoch den SN65C3232D von Texas Instruments verwendet, da dieser mit 3.3 V betrieben wird und Geschwindigkeiten von bis zu 1 Mbit/s bietet.
Auf der Platine befinden sich vier Quarzresonatoren – einer für den Debugger (4 MHz) und drei für den Ziel-Mikrocontroller K8BE1986QI (Luftfahrt) mit den Nennwerten 1 kHz, 32.768 MHz und 16 MHz. Dies sind notwendige Komponenten, da die Parameter des eingebauten RC-Generators in einem weiten Bereich von 25 bis 6 MHz liegen. Die Frequenz von 10 MHz ist für den Betrieb des eingebauten Ethernet-Controllers erforderlich. Auf der Milandr-Website wird (möglicherweise versehentlich) aus irgendeinem Grund angegeben, dass im Kunststoffgehäuse kein Ethernet-Anschluss vorhanden sei. Wir verlassen uns jedoch auf die Spezifikationen und Fakten.
Ein wichtiger Anreiz für die Entwicklung meines eigenen Debug-Boards war die Möglichkeit, mit dem externen Systembus EBC (External Bus Controller) zu arbeiten, der im Wesentlichen ein paralleler Port ist. Der Mikrocontroller K1986BE1QI (avia) ermöglicht den Anschluss und die Arbeit mit externen Speicherchips und Peripheriegeräten wie ADC, FPGA usw. Die Fähigkeiten des externen Systembusses sind recht umfangreich – Sie können mit statischem 8-Bit-, 16-Bit- und 32-Bit-RAM, ROM und NAND-Flash arbeiten. Zum Lesen/Schreiben von 32-Bit-Daten kann der Controller automatisch 2 entsprechende Operationen für 16-Bit-Chips und 8 Operationen für 4-Bit-Chips ausführen. Offensichtlich wird eine 32-Bit-Ein-/Ausgabeoperation mit einem 32-Bit-Datenbus am schnellsten ausgeführt. Zu den Nachteilen gehört, dass das Programm mit 32-Bit-Daten arbeiten muss und 32 Spuren auf der Platine verlegt werden müssen.
Gebrauchte statische RAM-Chips (raten Sie, welcher defekt ist)
Eine ausgewogene Lösung ist die Verwendung von 16-Bit-Speicherchips. Ich hatte Chips von Integrated Silicon Solutions Inc. (ISSI IS61LV25616AL, 16 x 256k, 10 ns, 3.3 V). Milandr verfügt natürlich über eigene statische Speicherchips. , aber sie sind zu teuer und nicht erhältlich. Alternativ gibt es den pinkompatiblen Samsung K6R4016V1D. Ich habe bereits erwähnt, dass die Chips gebraucht waren und die von mir installierte Kopie zunächst Fehler und chaotische Werte in der 15. Datenleitung lieferte. Es dauerte mehrere Tage, bis ich die Hardwarefehler fand, und umso zufriedener war ich, als ich den beschädigten Chip durch einen funktionierenden ersetzte. Wie dem auch sei, die Geschwindigkeit beim Arbeiten mit externem Speicher lässt zu wünschen übrig.
Externer Bus und StandAlone-ModusDer Mikrocontroller K1986BE1QI (Luftfahrt) verfügt über einen einzigartigen Standalone-Modus, der für den direkten externen Zugriff auf Ethernet- und MKI-Controller (MIL_STD_1553) über einen externen Bus ausgelegt ist. Der Kern befindet sich dabei im Reset-Zustand, d. h. er wird nicht verwendet. Dieser Modus eignet sich für Prozessoren und FPGAs ohne Ethernet und/oder MKI.
Das Anschlussdiagramm sieht wie folgt aus:
- MCU-Datenbus (D0-D15) => SRAM (I/O0-I/O15),
- Adressbus MCU(A1-A18) => SRAM(A0-A17),
- Steuer-MCU(nWR,nRD,PortC2) => SRAM (WE,OE,CE),
- SRAM(UB,LB) werden über einen Widerstand mit Masse verbunden bzw. auf Masse gezogen.
Die CE-Leitung wird über einen Widerstand zur Stromversorgung hochgezogen, die Pins zur Auswahl des MCU-Bytes (BE0-BE3) bleiben unbenutzt. Unter dem Spoiler stelle ich den Initialisierungscode für die Ports und den externen Buscontroller bereit.
Initialisierung der Ports und des EBC (externer Buscontroller)
void SRAM_Init (void)
{
EBC_InitTypeDef EBC_InitStruct = { 0 };
EBC_MemRegionInitTypeDef EBC_MemRegionInitStruct = { 0 };
PORT_InitTypeDef initStruct = { 0 };
RST_CLK_PCLKcmd (RST_CLK_PCLK_EBC, ENABLE);
PORT_StructInit (&initStruct);
//--------------------------------------------//
// DATA PA0..PA15 (D0..D15) //
//--------------------------------------------//
initStruct.PORT_MODE = PORT_MODE_DIGITAL;
initStruct.PORT_PD_SHM = PORT_PD_SHM_ON;
initStruct.PORT_SPEED = PORT_SPEED_FAST;
initStruct.PORT_FUNC = PORT_FUNC_MAIN;
initStruct.PORT_Pin = PORT_Pin_All;
PORT_Init (MDR_PORTA, &initStruct);
//--------------------------------------------//
// Address PF3-PF15 (A0..A12), A0 - not used. //
//--------------------------------------------//
initStruct.PORT_FUNC = PORT_FUNC_ALTER;
initStruct.PORT_Pin = PORT_Pin_4 | PORT_Pin_5 |
PORT_Pin_6 | PORT_Pin_7 |
PORT_Pin_8 | PORT_Pin_9 |
PORT_Pin_10 | PORT_Pin_11 |
PORT_Pin_12 | PORT_Pin_13 |
PORT_Pin_14 | PORT_Pin_15;
PORT_Init (MDR_PORTF, &initStruct);
//--------------------------------------------//
// Address PD3..PD0 (A13..A16) //
//--------------------------------------------//
initStruct.PORT_FUNC = PORT_FUNC_OVERRID;
initStruct.PORT_Pin = PORT_Pin_0 | PORT_Pin_1 |
PORT_Pin_2 | PORT_Pin_3;
PORT_Init (MDR_PORTD, &initStruct);
//--------------------------------------------//
// Address PE3, PE4 (A17, A18) //
//--------------------------------------------//
initStruct.PORT_FUNC = PORT_FUNC_ALTER;
initStruct.PORT_Pin = PORT_Pin_3 | PORT_Pin_4;
PORT_Init (MDR_PORTE, &initStruct);
//--------------------------------------------//
// Control PC0,PC1 (nWE,nOE) //
//--------------------------------------------//
initStruct.PORT_FUNC = PORT_FUNC_MAIN;
initStruct.PORT_Pin = PORT_Pin_0 | PORT_Pin_1;
PORT_Init (MDR_PORTC, &initStruct);
//--------------------------------------------//
// Control PC2 (nCE) //
//--------------------------------------------//
initStruct.PORT_PD = PORT_PD_DRIVER;
initStruct.PORT_OE = PORT_OE_OUT;
initStruct.PORT_FUNC = PORT_FUNC_PORT;
initStruct.PORT_Pin = MDB_SRAM_CE;
PORT_Init (MDR_PORTC, &initStruct);
//--------------------------------------------//
// Initialize EBC controler //
//--------------------------------------------//
EBC_DeInit();
EBC_StructInit(&EBC_InitStruct);
EBC_InitStruct.EBC_Mode = EBC_MODE_RAM;
EBC_InitStruct.EBC_WaitState = EBC_WAIT_STATE_3HCLK;
EBC_InitStruct.EBC_DataAlignment = EBC_EBC_DATA_ALIGNMENT_16;
EBC_Init(&EBC_InitStruct);
EBC_MemRegionStructInit(&EBC_MemRegionInitStruct);
EBC_MemRegionInitStruct.WS_Active = 2;
EBC_MemRegionInitStruct.WS_Setup = EBC_WS_SETUP_CYCLE_1HCLK;
EBC_MemRegionInitStruct.WS_Hold = EBC_WS_HOLD_CYCLE_1HCLK;
EBC_MemRegionInitStruct.Enable_Tune = ENABLE;
EBC_MemRegionInit (&EBC_MemRegionInitStruct, EBC_MEM_REGION_60000000);
EBC_MemRegionCMD(EBC_MEM_REGION_60000000, ENABLE);
// Turn ON RAM (nCE)
PORT_ResetBits (MDR_PORTC, MDB_SRAM_CE);
}
Der Mikrocontroller im LQFP-144-Gehäuse und der Speicher im TSOP-44-Gehäuse haben viele angeschlossene Pins und beanspruchen viel Platz auf der Leiterplatte. Da ich Erfahrung mit der Lösung von Optimierungsproblemen im Bereich der Wirtschaftswissenschaften habe, war mir klar, dass diese Chips zuerst auf der Platine platziert werden sollten. In verschiedenen Quellen stieß ich auf lobende Kritiken über Ich habe die Testversion heruntergeladen und konnte mein Projekt erst aus Eagle CAD exportieren, nachdem ich fast alle Komponenten gelöscht hatte. Leider half mir TopoR nicht, auch nur 10 Elemente auf der Platine zu platzieren. Zuerst wurden alle Komponenten in der Ecke und dann entlang der Kante platziert. Ich war mit dieser Option nicht zufrieden und habe die Platine lange Zeit manuell in der gewohnten Eagle CAD-Umgebung nachgezeichnet.
Ein wichtiges Element der Leiterplatte ist der Siebdruck. Die Debug-Platine sollte nicht nur Signaturen für die elektronischen Komponenten enthalten, sondern auch alle Anschlüsse beschriftet sein. Auf der Rückseite der Platine habe ich Tabellen-Memos mit den Funktionen der Controller-Ports (Haupt-, Alternativ-, Neudefinitions- und aktuelle Ports) platziert. Ich habe die Leiterplattenproduktion in China bei der bekannten Firma PCBWay in Auftrag gegeben. Ich werde sie nicht loben, denn die Qualität ist gut. Sie können es besser machen, mit kleineren Toleranzen, aber .
Hergestellte Leiterplatten MDB1986, (c) Foto vom Autor
Ich musste die Komponenten „auf dem Knie“ mit einem 40-Watt-Lötkolben und POS-61-Lot auslöten, da ich selten löte, 1-2 Mal im Jahr, und die Lötpaste eingetrocknet war. Außerdem musste ich den chinesischen CS32F103-Controller durch den originalen STM32F103 ersetzen und anschließend den Speicher austauschen. Insgesamt bin ich mit dem Ergebnis jetzt vollkommen zufrieden, obwohl ich die Funktion von RS-232 und CAN noch nicht überprüft habe.
Das MDB1986-Debugboard im Betrieb – es leuchtet und heizt, (c) Foto vom Autor
Auf der Milandra-Website finden Sie eine ganze Menge 1986BE9-Serie (Cortex-M3-Kern), aber ich sehe dort nichts zum Mikrocontroller K1986BE1QI (Luftfahrt). Nach Durchsicht der dort veröffentlichten Materialien, Handbücher und Laborarbeiten für Universitäten freue ich mich, dass landesweit Personal für die Arbeit mit russischen Controllern geschult wird. Die meisten Schulungsmaterialien sind auf die Arbeit mit Ein-/Ausgabeports, Timern, ADC, DAC, SPI und UART ausgelegt. Es werden verschiedene IDE-Entwicklungsumgebungen verwendet (Keil, IAR, CodeMaster). Mal wird mit CMSIS-Registern programmiert, mal mit der MDR-Bibliothek. Erwähnenswert ist die Ressource , das viele Artikel von praktizierenden Programmierern enthält. Und natürlich sollten wir nicht vergessen .
Gedanken zu MilandraDie Mikroelektronik entwickelt sich in Russland, und Milandr spielt dabei eine bedeutende Rolle. Es erscheinen neue interessante Mikrocontroller, zum Beispiel 1986BE81T und Electrosila mit SpaceWire- und MKIO-Schnittstellen (die gleichen wie 1986BE1 und möglicherweise mit den gleichen Problemen) usw. Für normale Studenten, Lehrer und Bauingenieure ist es jedoch unrealistisch, solche Mikroschaltungen zu kaufen. Dies bedeutet, dass die Ingenieurgemeinschaft Fehler und Probleme dieser Mikroschaltung nicht schnell erkennen kann. Meiner Ansicht nach ist es notwendig, zunächst Mikroschaltungen in einem Kunststoffgehäuse herzustellen, sie an alle interessierten Parteien zu verteilen und erst nach der Prüfung (lateinisch approbatio – Genehmigung, Anerkennung) durch Spezialisten eine Revision in einem Metall-Keramik-Gehäuse vorzubereiten, das vor allen schädlichen Einflüssen geschützt ist. Ich hoffe, dass wir in naher Zukunft ALLE mit den auf Messen angekündigten neuen Projekten zufrieden sein werden.
Das von mir entwickelte Debug-Board kann von jedem reproduziert, modifiziert und im Bildungsprozess verwendet werden. Zunächst habe ich das Board für mich selbst gebaut, aber es ist so gut geworden, dass .
K1986BE1QI (avia) ist ein sehr interessanter Controller mit einzigartigen Schnittstellen, der an Universitäten zur Ausbildung von Studenten eingesetzt werden kann. Ich denke, dass der Controller nach der Behebung der im Controller gefundenen Fehler und dem Bestehen der Zertifizierungstests im wahrsten Sinne des Wortes fliegen wird!
Source: habr.com
