För några år sedan lärde jag mig känna de ryska mikrokontrollarna från företaget Milandr. Det var 2013, när ingenjörerna ivrigt diskuterade de första resultaten av det federala programmet "Utveckling av elektronisk komponentgrund och radioelektronik" för åren 2008-2015. Vid den tidpunkten hade redan kontroller K1986ВЕ9x (Cortex-M3-kärna) släppts, och kontroller 1986ВЕ1Т (Cortex-M1-kärna) hade just dykt upp. I det plastikkåpan LQFP-144 hade den i dokumentationen beteckningen K1986ВЕ1QI (flyg), medan den på själva chipet var märkt MDR32F1QI. På tillverkarens webbplats hade den suffixet "flyg", eftersom den har gränssnitt som är specifika för flygindustrin (ARINC 429, MIL_STD_1553).
Det är förvånande, men vid tiden för spridningen av dessa kontroller hade företaget "Milandr" förberett utvecklingssatser och biblioteksfunktioner för arbete med periferin, "men utan några ytterligare garantier och åtaganden om korrektheten i biblioteket". Biblioteket liknar Standard Peripheral Library från företaget STMicroelectronics. Sammanfattningsvis har alla ARM-kontroller byggda på Cortex-M-kärnan mycket gemensamt. Av denna anledning gick bekantskapen med de nya ryska kontrollerna snabbt. För de som köpte officiella utvecklingssatser erbjöds teknisk support under användningen.
Utvecklingssats för mikrokontrollern 1986ВЕ1Т, © Milandr
Men med tiden började "barnsjukdomarna" hos de nya chiparna och biblioteken visa sig. Testexemplen för firmware fungerade utan synbara problem, men vid betydande modifieringar uppstod krasch och fel. Den första "fågeln" i min praktik var oförklarliga krascher i CAN-kontrollern. Ett år senare upptäcktes ett problem med modulen på kontroller 1986ВЕ1Т (flyg) av tidig revision. . Generellt sett var alla revisioner av dessa mikrokontroller fram till 2016 begränsat användbara. Mycket tid och nerv ner gick åt för att identifiera dessa problem, som nu kan bekräftas i .
En obehaglig aspekt var att det var nödvändigt att arbeta med och hantera fel på prototypskorten av apparater som var planerade för seriell industriell tillverkning, istället för debuggningskorten. Utöver JTAG-kontakten fanns det vanligtvis ingenting. Att ansluta en logikanalysator var svårt och obekvämt, och lysdioder samt skärmar var oftast frånvarande. Av denna anledning föddes tanken om att skapa mitt eget debuggningskort.
Å ena sidan fanns det varumärkesdebuggningssatser på marknaden samt utmärkta kort från LDM-Systems i Zelenograd. Å andra sidan är priserna på dessa produkter förlamande, och den grundläggande funktionaliteten utan expansionskort motsvarar inte förväntningarna. Ett kort med en fastinstallerad mikrokontroller och kontakt är inte intressant för mig. Mer intressanta kort är dyra.
Debuggningskortet MILANDR LDM-HELPER-K1986BE1QI-FULL, © LDM Systems
Företaget "Milandr" har en speciell prissättning och marknadsföring. Det är möjligt att få gratis prover av vissa kretsar, men detta är endast tillgängligt för juridiska personer och är kopplat till en byråkratisk process. Generellt är mikrokretsar i metallkeramiska höljen dyra både i bokstavlig och överförd bemärkelse. Till exempel kostar kontroller 1986VE1T i Moskva mellan 14 000 och 24 000 rubel. Mikrokretsen för statisk minne 1645РУ6У kostar från 15 000 rubel. Det finns en sådan prissättning för hela produkten. Även forskningsinstitut med statliga beställningar sparar och drar sig undan sådana priser. Mikrokretsar i plastskal för civilt bruk är betydligt billigare, men de finns inte tillgängliga hos populära leverantörer. Dessutom verkar kvaliteten på mikrokretsarna i plastskal, enligt min åsikt, vara sämre än "guld". Till exempel kunde jag inte starta kontroller K1986BE1QI vid 128MHz utan att öka parametern flash latency. Samtidigt steg temperaturen på denna kontroller till 40-50 °C. Men kontroller 1986BE1T ("guld") startade på 128MHz utan ytterligare inställningar och förblev kall. Den är verkligen bra.
"Guld" mikrokontroller 1986BE1T, (c) Milandr
Jag hade turen att jag i alla fall kunde köpa mikrokontrollern i plastkapsling i detaljhandeln från LDM Systems, och alla säkerhetskopior av kretskort finns tillgängliga. Det dåliga är att på hemsidan, på bilden av kontrolleren, finns märkningen som säger att det är revidering 4 från 2014, det vill säga med defekter. Jag tänkte länge – skulle jag köpa den eller inte. Så gick det flera år...
Tankarna på att skapa ett utvecklingskort försvann aldrig. Gradvis formulerade jag alla krav och funderade på hur jag skulle få plats med allt på ett kort, så det blev kompakt och inte dyrt. Parallellt beställde jag de saknade komponenterna från kineserna. Jag hade ingen brådska – jag gjorde allt för mig själv. Kinesiska leverantörer är kända för sin slarvighet – jag fick beställa samma sak från olika ställen för att få allt som behövdes. Dessutom visade det sig att en del av minneskretsarna hade använts tidigare – uppenbarligen avlägsnats från trasiga apparater. Detta kom att påverka mig senare.
Att köpa mikrokontrollern Milandr K1986ВЕ1QI (aviation) är ingen enkel uppgift. I samma butik "Chip and Dip" hittade jag bara K1986BE92QI för 740 rubel i avsnittet "Positioner på beställning", men den passade mig inte. Det enda alternativet var att köpa en gammal revision från LDM-Systems för 2000 rubel. Eftersom jag inte lyckades hitta något alternativ någon annanstans beslutade jag mig för att köpa det som fanns. Till min glädje sålde de mig en helt ny kontroller som tillverkades i december 2018, revision 6+ (1820). Och på hemsidan finns fortfarande en gammal bild, och vid tidpunkten för skrivandet av artikeln fanns det inga kontrollerare i lager...
Mikrokontroller K1986ВЕ1QI (aviation) i teknologisk förpackning, (c) Foto av författaren
Huvudtekniska specifikationer för mitt utvecklingskort MDB1986 följande:
- inbyggd debugger-programmerare, kompatibel med J-Link och CMSIS-DAP;
- statisk minne 4Mbit (256k x 16, 10 ns);
- flashminneschip 64Mbit, Winbond 25Q64FVSIG;
- mottagare-sändare för RS-232-gränssnitt med RTS- och CTS-linjer;
- gränssnitt och kontakter för Ethernet, USB, CAN;
- kontroller för 7-segmentdisplay MAX7221;
- stiftkontakt för arbete med MKIO (MIL_STD_1553) och ARINC429;
- fototransistor Everlight PT17-21C;
- fem färgade lysdioder, en återställningsknapp och två användarknappar;
- strömförsörjning via USB-port 5 volt;
- mått på kretskortet 100 x 80 mm
Jag gillade STM-Discovery-korten för att de har en inbyggd programmerare/debugger – ST-Link. Den officiella ST-Link fungerar endast med STMicroelectronics-styrenheter, men för ett par år sedan blev det möjligt att uppdatera firmware i ST-Link och få SEGGER J-Link OB (on-board) Debugger. Juridiskt finns det begränsningar för användning av denna debugger med STMicroelectronics-kort, men i praktiken är potentialen obegränsad. Således, med J-Link OB kan man ha en inbyggd programmerare/debugger på utvecklingskortet. Jag vill nämna att produkten från "LDM-Systems" använder CP2102-omvandlaren (Usb2Uart), som endast kan ladda upp firmware.
STM32F103C8T6 mikrokontroller, äkta och oäkta, (c) Foto av författaren
Så, jag behövde köpa en äkta STM32F103C8T6, eftersom officiella firmware inte fungerar korrekt med kloner. Jag tvivlade på denna tes och bestämde mig för att prova styrenheten CS32F103C8T6 från det kinesiska företaget CKS. Jag har inga klagomål på själva styrenheten, men den officiella ST-Link-firmware fungerade inte i den. J-Link fungerade delvis – USB-enheten kände igen den, men programmeraren utförde inte sina funktioner och påminde ständigt om att den var "defective".
Fel vid debuggarens drift på en icke-original styrenhet
Jag gav mig inte och skrev först firmware för att blinka en LED, och sedan implementerade jag IDCODE-forespörjningen via JTAG-protokollet. Programmeraren ST-Link, som jag hade på min Discovery-platta, och programmet ST-Link Utility programmerade problemfritt CS32F103C8T6. Som resultat försäkrade jag mig om att mitt kort fungerar. Till min glädje gav styrenheten K1986BE1QI (aviation) glatt ut sitt IDCODE över TDO-linjen.
Oscilloskopdiagram över TDO-signallinjen med den kodade IDCODE-svaret, (c) Foto av författaren
Här behövdes SWD-porten för att debugga själva debuggern och kontrollera IDCODE
Det kvarstod ett alternativ med debuggern . Att bygga projektet från källor från ARM är ingen enkel uppgift, jag tog projektet från , och försökte sedan även DAP42. Tyvärr frös Keil uVision och ville inte fungera med dem. Till slut bytte jag ut debugchipet till den officiella STM32F103C8T6 och återkom aldrig till den frågan.
Framgångsrik drift av den inbyggda J-Link STLink V2-debuggern
När alla nyckelkomponenter för den kommande expansionskretsen fanns tillgängliga, gick jag in i Eagle CAD och upptäckte att de saknades i komponentbiblioteket. Det fanns inget annat val – jag fick rita dem själv. Samtidigt gjorde jag platser för minnet, HanRun-kontakten för Ethernet, och för motstånd och kondensatorer lade jag till ramar. Du kan hitta projektfilen och komponentbiblioteket .
Kopplingsschema för utvecklingskortet MDB1986
Kretskortet får ström från en likströmskälla på 5 volt, som tas från USB-porten. Totalt finns det två USB Type-B-portar på kortet. En är för programmeraren, den andra för kontrollern K1986BE1QI. Kortet kan drivas av antingen av dessa källor eller båda samtidigt. Den enklaste belastningsregleringen och skyddet av strömledningar är implementerade med Schottky-dioder, på schemat D2 och D3 (SS24). Du kan också se självåterställande säkringar F1 och F2 på 500mA på schemat. Signallinjerna för USB-porten är skyddade av USBLC6-2SC6 diodmoduler.
Kopplingsschemat för ST-Link-debuggern/programmeraren är välkänt och kan hittas i dokumentationen för STM32-Discovery-korten och andra källor. För den initiala flashningen av klonen ST-Link/J-Link-OB/DAP (efter val) har jag tagit fram linjerna SWDIO (PA13), SWCLK (PA14), GND. Många använder UART för flashning och tvingas flytta BOOT-jumper. Men jag föredrar SWD, dessutom möjliggör detta protokoll debugging.
Nästan alla komponenter på kortet får ström från 3.3 volt, som kommer från spänningsregulatorn AMS1117-3.3. För att dämpa elektromagnetiska störningar och strömspikar används LC-filter av kondensatorer och spolar i serien BLM31PG.
Det är värt att nämna drivrutinen för 7-segment displayen MAX7221. Enligt specifikationen är den rekommenderade strömförsörjningen mellan 4 och 5.5 volt, och nivån för hög signal (logisk 1) ska vara minst 3.5V (0.7 x VCC) vid 5V drift. För kontrollern K1986BE1QI (luftfart) motsvarar logisk hög fråga en spänning mellan 2.8 och 3.3V. Detta skapar uppenbara skillnader i signalnivåer som kan störa normal drift. Jag bestämde mig för att driva MAX7221 med 4V och sänka signalnivåerna till 2.8V (0.7 x 4 = 2.8). För detta installerades en diod D4 (RS1A eller FR103) i serie med drivarens strömförsörjning. Total spänningsfall är 0.9V (Schottky-diod 0.3V och diod 0.6V), och allt fungerar.
De flesta av mikrocontrollerportarna K1986ВЕ1QI (luftfart) är kompatibla med signaler upp till 5V. Därför medför användningen av CAN-mottagaren MCP2551 inga problem, som också fungerar på 5V. Som RS-232-mottagare anges chipet MAX3232 i schemat, men jag använde faktiskt SN65C3232D från Texas Instruments, eftersom det fungerar på 3.3V och ger hastigheter upp till 1Mbit/s.
På kortet finns 4 kvartsresonatorer – en för debuggern (8 MHz) och tre för den mål-mikrocontroller K1986ВЕ1QI (luftfart) med nominella värden på 32.768 kHz, 16 MHz, 25 MHz. Dessa är nödvändiga komponenter eftersom parametrarna för den inbyggda RC-generatorn ligger inom stora gränser från 6 till 10 MHz. Frekvensen 25 MHz är nödvändig för att den inbyggda Ethernet-kontrollern ska fungera. På Milandras webbplats nämns, eventuellt av misstag, att Ethernet är frånvarande i plastkapslingen. Men vi kommer att basera oss på specifikationen och fakta.
En viktig drivkraft för att skapa min egen utvecklingskort var möjligheten att arbeta med en extern systembuss EBC (external bus controller), som i grunden är en parallellport. Mikrocontroller K1986ВЕ1QI (luftfart) tillåter anslutning och arbete med externa minneskretsar och perifera enheter, till exempel ADC, FPGA, osv. Möjligheterna med den externa systembussen är ganska stora – det går att arbeta med 8-bitars, 16-bitars och 32-bitars statiskt RAM, ROM och NAND Flash. För att läsa/skriva 32-bitarsdata kan kontrollern automatiskt utföra 2 motsvarande operationer för 16-bitarschip, och för 8-bitars – 4 operationer. Det är uppenbart att 32-bitars in- och utdataoperationer kommer att utföras snabbast med en 32-bitars databas. Nackdelarna inkluderar behovet av att i programmet hantera 32-bitarsdata, och på kortet måste 32 spår läggas.
Chip för statisk RAM, begagnade (gissa vilken som har en defekt)
En balanserad lösning är att använda 16-bitars minneschip. Jag hade tillgång till chip från Integrated Silicon Solutions Inc. (ISSI IS61LV25616AL, 16 x 256k, 10 ns, 3.3V). Självklart har "Milandr" sina egna statiska minneschip. , men de är alldeles för dyra och otillgängliga. Som alternativ finns kompatibla från Samsung K6R4016V1D. Jag nämnde tidigare att chipen var begagnade och det exemplar som jag först installerade gav fel och kaotiska värden på den 15:e datalinjen. Det tog flera dagar att hitta hårdvarufel, och tillfredsställelsen var desto större när jag bytte ut det defekta chipet mot ett fungerande. Hur som helst, hastigheten vid arbete med extern minne lämnar mycket att önska.
Extern buss och StandAlone-lägeMikrokontrollern K1986ВЕ1QI (flyg) har ett unikt StandAlone-läge som är avsett för direkt åtkomst utifrån till Ethernet-kontroller och MKIO (MIL_STD_1553) via externa bussen, medan kärnan är i resetläge, dvs. inte används. Detta läge är praktiskt för processorer och FPGA:er som saknar Ethernet och/eller MKIO.
Anslutningsschemat är följande:
- MCU databas (D0-D15) => SRAM(I/O0-I/O15),
- MCU adresser (A1-A18) => SRAM(A0-A17),
- MCU kontroll (nWR, nRD, PortC2) => SRAM (WE, OE, CE),
- SRAM(UB, LB) är anslutna eller dragna till jord via motstånd.
CE-linjen är dragen till ström via motstånd, utgångarna för byteval MCU(BE0-BE3) används inte. Under spoiler ger jag koden för port- och kontrollerinitiering av den externa bussen.
Initiering av portar och EBC (extern busskontroller)
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);
}
Mikrokontroller i LQFP-144-kapsel och minne i TSOP-44-kapsel har många relaterade anslutningar och tar mycket plats på kretskortet. Med erfarenhet av att lösa optimeringsproblem inom ekonomi var det uppenbart för mig att dessa chip måste placeras på kortet i första hand. Jag har sett lovordade recensioner om . Jag laddade ner testversionen och kunde endast exportera mitt projekt från Eagle CAD dit när jag tog bort nästan alla komponenter. Tyvärr kunde programmet TopoR inte hjälpa mig att placera ens 10 element på kortet. Först placerades alla komponenter i hörnet, och sedan ordnades de längs kanten. Denna lösning tillfredsställde mig inte, och jag utförde länge en manuell layout av kortet i den vanliga miljön i Eagle CAD.
Ett viktigt element på kretskortet är silkscreenen. På prototypkortet ska det finnas inte bara etiketter för elektroniska komponenter utan även alla kontakter ska vara märkta. På baksidan av kortet placerade jag minnestabeller med funktionerna för kontrollerportarna (grundläggande, alternativ, överskrivna, aktuella). Tillverkningen av kretskort beställde jag i Kina hos det välkända företaget PCBWay. Jag kommer inte att lovorda dem för mycket eftersom kvaliteten är bra. De kan göra bättre, med mindre toleranser, men .
Tillverkade kretskort MDB1986, (c) Foto av författaren
Att löda komponenterna fick jag göra "i knäna" med en 40-watts lödkolv och lödtenn POS-61, eftersom jag löder sällan, 1-2 gånger om året, och lödpasten har torkat. Jag var tvungen att byta den kinesiska kontroller CS32F103 mot den ursprungliga STM32F103, och sedan också byta minnet. Sammanfattningsvis är jag nu helt nöjd med resultatet, även om jag ännu inte testat RS-232 och CAN.
Prototypkort MDB1986 i arbete - lyser och värmer, (c) Foto av författaren
På webbplatsen "Milandra" kan man hitta tillräckligt med serierna 1986BE9 (Cortex-M3-kärnan), men för mikrokontroller K1986ВЕ1QI (flyg) ser jag inget där. Efter att ha granskat de publicerade materialen, handböckerna och laborationsarbetena för högskolor, gläds jag åt att det utbildas personal över hela landet för att arbeta med ryska kontroller. De flesta undervisningsmaterialen förbereder eleverna för arbete med I/O-portar, timers, ADC, DAC, SPI, UART. Olika IDE-miljöer används (Keil, IAR, CodeMaster). På vissa ställen programmeras det med hjälp av CMSIS-register, på andra ställen används MDR-biblioteket. Det är viktigt att nämna resursen , som innehåller många artiklar av praktiserande programmerare. Och självklart ska man inte glömma .
Duma om MilandrMikroelektronik i Ryssland utvecklas, och i denna process spelar företaget "Milandr" en betydande roll. Det dyker upp nya intressanta mikrokontroller, till exempel 1986ВЕ81Т och "Elekrosila" med gränssnitt som SpaceWire och MКIO (samma som i 1986BE1 och eventuellt med samma problem), osv. Men för vanliga studenter, lärare och civila ingenjörer är det orealistiskt att köpa sådana kretsar. Det betyder att ingenjörssamhället inte snabbt kan identifiera fel och problem med dessa kretsar. Jag anser att man först måste släppa ut kretsar i plastkapsling, sprida dem bland alla intresserade, och först efter godkännande av specialister kan man förbereda en revision i en metallkeramisk kapsling med skydd mot alla skräckfaktorer. Jag hoppas att vi snart kommer att glädjas åt nya projekt som presenterats på mässor.
Den debug-kort som jag har utvecklat kan vem som helst återupprepa, modifiera och använda i undervisningssituationer. Först och främst gjorde jag kortet för mig själv, men det blev så bra att .
K1986ВЕ1QI (flyg) – det är en mycket intressant kontroller med unika gränssnitt som kan användas på högskolor för att utbilda studenter. Jag tror att efter att ha åtgärdat de fel som har identifierats i kontrolleren och genomgått certifieringstester, kommer kontrolleren bokstavligen att flyga!
Källa: habr.com
