For flere år siden ble jeg kjent med russiske mikrokontrollere fra Milander. Det var i 2013, da ingeniører diskuterte de første resultatene av det føderale målprogrammet "Utvikling av elektronisk komponentbase og radioelektronikk" for 2008-2015. På det tidspunktet var K1986BE9x-kontrolleren (Cortex-M3-kjerne) allerede utgitt, og 1986BE1T-kontrolleren (Cortex-M1-kjerne) hadde nettopp dukket opp. I plastkassen, LQFP-144, hadde den betegnelsen K1986BE1QI (luftfart) i dokumentasjonen, og på selve brikken betegnelsen MDR32F1QI. På produsentens nettsted har den suffikset "avia", siden den har grensesnitt som er spesifikke for flyindustrien (ARINC 429, MIL_STD_1553).
Overraskende nok, på tidspunktet for distribusjon av disse kontrollerene, forberedte Milander-selskapet feilsøkingssett og et bibliotek med subrutiner for å jobbe med periferiutstyr, "men uten noen ekstra garantier eller forpliktelser angående korrektheten til biblioteket." Biblioteket ligner på Standard Peripheral Library fra STMicroelectronics. Generelt har alle ARM-kontrollere bygget på Cortex-M-kjernen mye til felles. Av denne grunn gikk det raskt å bli kjent med de nye russiske kontrollørene. Og for de som kjøpte merkede feilsøkingssett, ble det gitt teknisk støtte under bruk.
Feilsøkingssett for mikrokontroller 1986BE1T, © Milander
Men over tid begynte "barnesykdommer" av nye mikrokretser og biblioteker å dukke opp. Testeksempler av fastvaren fungerte uten synlige problemer, men med betydelige modifikasjoner oppstod krasjer og feil. Den første "svelgen" i min praksis var uforklarlige feil i driften av CAN-kontrolleren. Et år senere ble et problem med modulen oppdaget på 1986BE1T (luftfart) kontrolleren av en tidlig revisjon . Generelt var alle revisjoner av disse mikrokontrollerne frem til 2016 av begrenset bruk. Mye tid og nerver gikk med til å identifisere disse problemene, og bekreftelse på disse kan nå finnes i .
En ubehagelig funksjon var at det var nødvendig å jobbe og håndtere feil ikke på feilsøkingstavler, men på prototypekort av enheter som var planlagt for seriell fabrikkproduksjon. Det var vanligvis ingenting der bortsett fra JTAG-kontakten. Å koble til med en logikkanalysator var vanskelig og upraktisk, og det var vanligvis ingen lysdioder eller skjermer. Av denne grunn dukket ideen om å lage mitt eget debugging board opp i hodet mitt.
På den ene siden var det merkede debugging-sett på markedet, samt fantastiske brett fra LDM-Systems-selskapet fra Zelenograd. På den annen side er prisene for disse produktene svimlende, og den grunnleggende funksjonaliteten uten utvidelseskort svarer ikke til forventningene. Et kort med en loddet kontroller og en pin-kontakt er ikke av interesse for meg. Og mer interessante brett er dyre.
Utviklingstavle MILANDR LDM-HELPER-K1986BE1QI-FULL, © LDM Systems
Milander-selskapet har en unik prispolitikk og markedsføring. Så det er mulig å få gratis prøver av noen mikrokretser, men dette er bare tilgjengelig for juridiske personer og er forbundet med et byråkratisk oppdrag. Generelt er mikrokretser i en metallkeramisk kasse gull i bokstavelig og overført betydning. For eksempel koster en 1986BE1T-kontroller fra 14 til 24 tusen rubler i Moskva. Den statiske minnebrikken 1645RU6U koster fra 15000 1986 rubler. Og dette er prisordren for alle produkter. Som et resultat sparer selv spesialiserte forskningsinstitutter med offentlige ordrer penger og viker unna slike priser. Mikrokretser i et plasthus for sivil bruk er betydelig billigere, men de er ikke tilgjengelige fra populære leverandører. I tillegg ser det ut til at kvaliteten på mikrokretser i et plasthus er dårligere enn "gull". For eksempel kunne jeg ikke kjøre K1BE128QI-kontrolleren på 40 MHz uten å øke parameteren for flash-latens. Samtidig steg temperaturen på denne kontrolleren til 50-1986C. Men 1BE128T ("gull") kontrolleren startet på XNUMX MHz uten ekstra innstillinger og forble kald. Han er virkelig god.
"Golden" mikrokontroller 1986BE1T, (c) Milander
Jeg var heldig at en mikrokontroller i et plastdeksel fortsatt kan kjøpes i detaljhandelen fra LDM Systems, og alle kortdiagrammer er fritt tilgjengelige. Det dårlige er at på nettsiden på bildet av kontrolleren kan du se en markering som sier at dette er den 4. revisjonen av 2014, dvs. med defekter. Jeg tenkte lenge på om jeg skulle kjøpe eller ikke. Det gikk flere år slik...
Ideen om å lage et feilsøkingstavle har ikke forsvunnet noe sted. Etterhvert dannet jeg alle kravene og tenkte på hvordan jeg skulle plassere det hele på ett brett slik at det ble kompakt og ikke dyrt. Samtidig bestilte jeg de manglende komponentene fra kineserne. Jeg hadde det ikke travelt - jeg gjorde alt for meg selv. Kinesiske leverandører er notorisk slurvete - jeg måtte bestille det samme fra forskjellige steder for å få alt jeg trengte. Dessuten viste det seg at noen av minnebrikkene ble brukt - tilsynelatende loddet fra ødelagte enheter. Dette kom tilbake til å hjemsøke meg senere.
Å kjøpe en mikrokontroller Milander K1986BE1QI (luft) er ikke en lett oppgave. I den samme Chip and Dip-butikken, i delen "Artikler til bestilling", fant jeg bare K1986BE92QI for 740 rubler, men det passet ikke meg. Det eneste alternativet er å kjøpe en ikke-fersk revisjon fra LDM-Systems for 2000 rubler. Siden jeg ikke kunne finne en erstatning noe annet sted, bestemte jeg meg for å kjøpe det jeg hadde. Til min hyggelige overraskelse solgte de meg en helt ny kontroller produsert i desember 2018, revisjon 6+ (1820). Men siden har fortsatt et gammelt bilde, og i skrivende stund er kontrolleren ikke tilgjengelig...
Mikrokontroller K1986BE1QI (luftfart) i teknologisk innpakning, (c) Foto av forfatteren
De viktigste tekniske egenskapene til feilsøkingskortet mitt MDB1986 følgende:
- innebygd debugger-programmerer, kompatibel med J-Link og CMSIS-DAP;
- statisk minne 4Mbit (256k x 16, 10 ns);
- flashminnebrikke 64Mbit, Winbond 25Q64FVSIG;
- RS-232 grensesnitt transceiver med RTS og CTS linjer;
- grensesnitt og kontakter for Ethernet, USB, CAN;
- MAX7 7221-segments skjermkontroller;
- pin-kontakt for arbeid med MKIO (MIL_STD_1553) og ARINC429;
- fototransistor Everlight PT17-21C;
- fem fargelysdioder, en tilbakestillingsknapp og to brukerknapper;
- strømforsyningen til USB-porten er 5 volt;
- kretskort dimensjoner 100 x 80, mm
Jeg likte kortene i STM-Discovery-serien fordi de har en innebygd programmerer-debugger - ST-Link. Merket ST-Link fungerer kun med kontrollere fra STMicroelectronics, men for et par år siden ble det mulig å oppdatere fastvaren i ST-Link og få SEGGER J-Link OB (ombord) Debugger. Juridisk sett er det en begrensning på å bruke en slik debugger kun med STMicroelectronics-kort, men faktisk er potensialet ikke begrenset. Med en J-Link OB kan du altså ha en innebygd programmerer-debugger på feilsøkingskortet. Jeg legger merke til at LDM-Systems-produkter bruker CP2102 (Usb2Uart)-konverteren, som bare kan blinke.
STM32F103C8T6 mikrokontrollere, ekte og ikke så ekte, (c) Foto av forfatteren
Så det var nødvendig å kjøpe den originale STM32F103C8T6, siden proprietær firmware ikke vil fungere riktig med klonen. Jeg tvilte på denne oppgaven og bestemte meg for å prøve CS32F103C8T6-kontrolleren fra det kinesiske selskapet CKS. Jeg har ingen klager på selve kontrolleren, men den proprietære ST-Link-fastvaren fungerte ikke i den. J-Link fungerte delvis - USB-enheten ble oppdaget, men programmereren utførte ikke funksjonene sine og minnet stadig om at den var "defekt".
Feil ved kjøring av debugger på en ikke-original kontroller
Jeg var ikke fornøyd med dette og skrev først fastvaren for å blinke LED-en, og implementerte deretter IDCODE-forespørselen ved å bruke JTAG-protokollen. ST-Link-programmereren, som jeg hadde på Discovery-kortet, og ST-Link Utility-programmet blinket uten problemer med CS32F103C8T6. Til slutt var jeg overbevist om at kortet mitt fungerte. Til min glede utstedte målkontrolleren K1986BE1QI (luftfart) muntert sin IDCODE via TDO-linjen.
Oscillogram av en TDO-signallinje med en kodet IDCODE-respons, (c) Foto av forfatteren
Så SWD-porten kom godt med for å feilsøke selve debuggeren og sjekke IDCODE
Det var et alternativ med en debugger . Å bygge et prosjekt fra ARM-kilder er ikke en lett oppgave, jeg tok prosjektet fra , og så prøvde jeg DAP42. Dessverre frøs Keil uVision og ønsket ikke å jobbe med dem. Som et resultat erstattet jeg debugger-brikken med en proprietær STM32F103C8T6 og kom aldri tilbake til dette problemet.
Vellykket drift av den innebygde feilsøkeren J-Link STLink V2
Da alle nøkkelkomponentene til det fremtidige utviklingskortet var tilgjengelige, gikk jeg inn i Eagle CAD og oppdaget at de ikke var i elementbiblioteket. Det var ingen steder å gå - jeg måtte tegne dem selv. Samtidig laget jeg monteringspunkter for minne, en HanRun-kontakt for Ethernet, og la til rammer for motstander og kondensatorer. Du finner prosjektfilen og komponentbiblioteket .
Skjematisk diagram av MDB1986 utviklingsbrett
Brettet drives av en 5 volt DC-kilde hentet fra USB-porten. Det er totalt to USB Type-B-porter på brettet. Den ene er for programmereren, den andre er for K1986BE1QI-kontrolleren. Brettet kan operere fra en av disse kildene eller begge samtidig. Den enkleste lastreguleringen og kraftledningsbeskyttelsen implementeres ved hjelp av Schottky-dioder, i krets D2 og D3 (SS24). Også i diagrammet kan du se selvgjenopprettede sikringer F1 og F2 ved 500 mA. Signallinjene til USB-porten er beskyttet av en USBLC6-2SC6 diodeenhet.
ST-Link debugger-programmererkretsen er kjent for mange; den kan finnes i dokumentasjonen for STM32-Discovery-kort og andre kilder. For den første fastvaren til ST-Link/J-Link-OB/DAP-klonen (valgfritt), tok jeg frem linjene SWDIO (PA13), SWCLK (PA14), GND. Mange bruker UART for fastvare og blir tvunget til å trekke BOOT-hopperne. Men jeg synes SWD er mer praktisk, og denne protokollen tillater feilsøking.
Nesten alle komponentene på brettet drives av 3.3 volt, som kommer fra AMS1117-3.3 spenningsregulator. For å undertrykke elektromagnetisk interferens og strømstøt, brukes LC-filtre fra kondensatorer og choker i BLM31PG-serien.
Separat er det verdt å nevne MAX7 7221-segments skjermdriver. I henhold til spesifikasjonen er den anbefalte strømforsyningen fra 4 til 5.5 volt, og det høye signalnivået (logisk) er minst 3.5V (0.7 x VCC), med en 5V-forsyning. For K1986BE1QI (luftfart) kontrolleren tilsvarer utgangen fra en logisk enhet en spenning fra 2.8 til 3.3V. Det er åpenbart et misforhold mellom signalnivåene som kan forstyrre normal drift. Jeg bestemte meg for å drive MAX7221 på 4V og redusere signalnivåene til 2.8V (0.7 x 4 = 2.8). For å gjøre dette er diode D4 (RS1A eller FR103) installert i serie i driverens strømkrets. Det totale spenningsfallet er 0.9V (Schottky-diode 0.3V og diode 0.6V), og alt fungerer.
De fleste portene på K1986BE1QI (luftfart) mikrokontroller er kompatible med signaler opp til 5V. Derfor er det ikke noe problem å bruke MCP2551 CAN-transceiveren, som også opererer på 5V. MAX232-brikken er angitt som en RS-3232 transceiver i diagrammet, men faktisk brukte jeg SN65C3232D fra Texas Instruments, fordi den opererer fra 3.3V og gir hastigheter opp til 1Mbit/s.
Brettet inneholder 4 kvartsresonatorer - en for debuggeren (8 MHz) og tre for målmikrokontrolleren K1986BE1QI (luftfart) med klassifiseringer på 32.768 kHz, 16 MHz, 25 MHz. Dette er nødvendige komponenter, fordi Parametrene til den innebygde RC-oscillatoren er innenfor et bredt område fra 6 til 10 MHz. En frekvens på 25 MHz er nødvendig for driften av den innebygde Ethernet-kontrolleren. Av en eller annen grunn sier Milandras nettsted (kanskje ved en feil) at plastdekselet ikke har Ethernet. Men vi vil stole på spesifikasjonen og fakta.
Et viktig insentiv for å lage mitt eget utviklingskort var muligheten til å jobbe med den eksterne systembussen EBC (ekstern busskontroller), som i hovedsak er en parallellport. K1986BE1QI mikrokontrolleren (fly) lar deg koble til og arbeide med eksterne minnebrikker og perifere enheter, for eksempel ADC, FPGA, etc. Mulighetene til den eksterne systembussen er ganske store - du kan jobbe med 8-bit, 16-bit og 32-bit statisk RAM, ROM og NAND Flash. For å lese/skrive 32-bits data, kan kontrolleren automatisk utføre 2 tilsvarende operasjoner for 16-bits brikker, og 8 operasjoner for 4-bits brikker. Åpenbart vil en 32-bits I/O-operasjon fullføres raskest med en 32-bits databuss. Ulempene inkluderer behovet for at programmet skal operere med 32-bits data, og styret vil måtte legge 32 spor.
Statiske RAM-brikker, brukt (gjett hvilken som er defekt)
En balansert løsning er å bruke 16-bits minnebrikker. Jeg hadde tilfeldigvis Integrated Silicon Solutions Inc.-brikker på lager. (ISSI IS61LV25616AL, 16 x 256k, 10 ns, 3.3V). Selvfølgelig har Milander-selskapet sine egne statiske minnebrikker , men de er for dyre og utilgjengelige. Som et alternativ er det pin-kompatible Samsung K6R4016V1D. Tidligere nevnte jeg at mikrokretsene viste seg å være brukt, og kopien som jeg installerte ga først feil og kaotiske verdier i den 15. datalinjen. Det tok flere dager å finne maskinvarefeil, og desto større var følelsen av tilfredshet da jeg byttet ut den skadede brikken med en fungerende. Uansett, hastigheten på arbeid med eksternt minne overlater mye å være ønsket.
Ekstern buss og frittstående modusK1986BE1QI mikrokontrolleren (fly) har en unik StandAlone-modus, som er designet for direkte ekstern tilgang til Ethernet- og MKIO-kontrollere (MIL_STD_1553) via en ekstern buss, med kjernen i tilbakestilt tilstand, dvs. ikke brukt. Denne modusen er praktisk for prosessorer og FPGA-er som ikke har Ethernet og/eller MKIO.
Tilkoblingsskjemaet er som følger:
- databuss MCU(D0-D15) => SRAM(I/O0-I/O15),
- adressebuss MCU(A1-A18) => SRAM(A0-A17),
- kontroll MCU(nWR,nRD,PortC2) => SRAM (WE,OE,CE),
- SRAM(UB,LB) kobles til eller trekkes til jord gjennom en motstand.
CE-linjen er koblet til strømforsyningen gjennom en motstand; pinnene for sampling av MCU-byten (BE0-BE3) brukes ikke. Under spoileren gir jeg koden for initialisering av portene og den eksterne busskontrolleren.
Initialiseringsporter og EBC-kontroller (ekstern 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);
}
Mikrokontrolleren i LQFP-144-pakken og minnet i TSOP-44-pakken har mange tilhørende pinner og tar opp mye plass på kretskortet. Etter å ha erfaring med å løse optimaliseringsproblemer innen økonomi, var det åpenbart for meg at det var nødvendig å plassere disse mikrokretsene på brettet først. I ulike kilder har jeg kommet over rosende anmeldelser om . Jeg lastet ned prøveversjonen og var i stand til å eksportere prosjektet mitt fra Eagle CAD der først etter at jeg fjernet nesten alle komponentene. Dessverre hjalp ikke TopoR-programmet meg med å plassere engang 10 elementer på brettet. Først ble alle komponentene plassert i et hjørne, og deretter arrangert langs kanten. Jeg var ikke fornøyd med dette alternativet, og i lang tid sporet jeg brettet manuelt i det velkjente Eagle CAD-miljøet.
Et viktig element i et trykt kretskort er silketrykk. Utviklingskortet skal ikke bare ha etiketter for de elektroniske komponentene, men alle kontakter skal også være merket. På baksiden av brettet plasserte jeg bord med funksjonene til kontrollerportene (hoved, alternativ, overstyrt, faktisk). Jeg bestilte produksjon av trykte kretskort i Kina fra det velkjente PCBWay-kontoret. Jeg vil ikke rose det fordi kvaliteten er god. De kan gjøre det bedre, med strammere toleranser, men .
Produserte MDB1986 trykte kretskort, (c) Foto av forfatteren
Jeg måtte lodde komponentene "på knærne" med en 40-watts loddebolt og POS-61 loddetinn, fordi jeg sjelden loddet, 1-2 ganger i året, og loddepastaen hadde tørket ut. Jeg måtte også bytte den kinesiske CS32F103-kontrolleren til den originale STM32F103, og da også bytte ut minnet. Generelt er jeg nå helt fornøyd med resultatet, selv om jeg ennå ikke har sjekket driften av RS-232 og CAN.
MDB1986 feilsøkingstavle i drift - det skinner og varmer, (c) Foto av forfatteren
På nettsiden til Milandra kan du finne nok serie 1986BE9 (Cortex-M3-kjerne), men for K1986BE1QI (luftfart) mikrokontroller ser jeg ikke noe der. Etter å ha sett på materialer, manualer og laboratoriearbeid for universiteter som er publisert der, er jeg glad for at personell blir utdannet over hele landet til å jobbe med russiske kontrollører. De fleste opplæringsmateriell forbereder for arbeid med I/O-porter, tidtakere, ADC, DAC, SPI, UART. Ulike IDE-utviklingsmiljøer brukes (Keil, IAR, CodeMaster). Et sted programmerer de ved hjelp av CMSIS-registre, og et sted bruker de MDR-biblioteket. Ressurs må nevnes , som inneholder mange artikler fra praktiserende programmerere. Og selvfølgelig skal vi ikke glemme det .
Tenkte på MilandraMikroelektronikk er under utvikling i Russland, og Milander-selskapet spiller en fremtredende rolle i denne prosessen. Nye interessante mikrokontrollere dukker opp, for eksempel 1986BE81T og Elektrosila med SpaceWire- og MKIO-grensesnitt (det samme som i 1986BE1 og muligens med de samme problemene), etc. Men vanlige studenter, lærere og sivilingeniører kan ikke kjøpe slike mikrokretser. Dette betyr at ingeniørmiljøet ikke raskt vil kunne identifisere feil og problemer med denne brikken. Det virker for meg som om det først er nødvendig å produsere mikrokretser i en plastkasse, distribuere dem til alle interesserte parter, og etter godkjenning (latinsk approbatio - godkjenning, anerkjennelse) av spesialister, kan de forberede en revisjon i en metallkeramisk sak med beskyttelse mot alle forferdelige faktorer. Jeg håper vi ALLE i nær fremtid vil være fornøyd med de nye prosjektene som ble annonsert på utstillingene.
Feilsøkingskortet jeg utviklet kan gjentas, modifiseres og brukes av alle i undervisningsprosessen. Først og fremst laget jeg brettet til meg selv, men det ble så bra at .
K1986BE1QI (luft) er en veldig interessant kontroller med unike grensesnitt som kan brukes på universiteter for å undervise studenter. Jeg tror at etter å ha korrigert feilene identifisert i kontrolleren og bestått sertifiseringstester, vil kontrolleren fly i ordets sanneste betydning!
Kilde: www.habr.com