Lietuvos oro uostai utilizavo biški technikos ir ten buvo prietaisiukai su VFD ekraniuku (patys prietaisiukai specifiniai, su ypač kreivu softu). Man bent jau atiteko VFD ekraniukai: Noritake Itron GU112x16G-7806A V3. Softas manau tinkamas visai šeimai, todėl pavadinime rašiau GU140x16G, nes pagal tokį datašytą rašiau. Pats VFD modulis kogero pilnai sutampa su LCD moduliu, tik papildomai turi grafinio modulio režimus. Todėl bet koks softas (ir hardwaras) kuris palaiko standartinį LCD modulį su 14 kontaktų jungtim puikiausiai veikia su VFD moduliu. Yra smulki bėda, kad modulis kiek lėčiau inicializuojasi, bet daugumas softo veikia.
Category Archives: MCU
Žaidimų automato elektronika
Seniau rašiau, kad savo savadarbiams kompiuteriams naudojau CPLD plokštes iš rusiškų Igrosoft žaidimų aparatų elektronikos.
Tai ir pirmas bandymas su dviem CPLD, LCD ZX versija ir keli nepublikuoti eksperimentai.
Tačiau niekada neparodžiau kaip atrodo pilna plokštė. O ir pats nebandžiau tą plokštę paleisti. Gal todėl, kad beveik niekada nebuvo sveikos plokštės ir nelaibai buvo noro. O kitas momentas, aš nemanau, kad Lietuvoje tokie žaidimų automatai leidžiami, tai nelabai dažnai pasitaiko išmesti. Gal kokiose kazino? Todėl ir nelabai atnešdavo utilizuoti tokias plokštes. Ir visai netikėtai, šiandien kažkas atvežė visą kalną visokių kompų plokščių ir tarp jų buvo kelios igrosoft. Visos jos biški pervažiuotos traktoriais, sulankstytos, aplietos vandeniu. Parinkau dvi kurios atrodė sveikiausios. Dar žalioji ploštė turi dvigubai didesnį CPLD.
Tai keistoka konstrukcija- nes viską valdo Z80 procesorius, o grafika dinamiška ir spalvinga. Kaip tai padaryta? Ogi visa grafika surašyta į “bateriją” ROM mikroschemų ir CPLD tiesiogiai generuoja vaizdą iš “gatavų” elementų. Tos mikroschemos su “CM” tai flaš ROMai, šalia keturios CPLD multipleksuoja duomenis. Centre esanti didelė CPLD viską sujungia į vieną vaizdą.
Kairėje Z80, programos ROM ir AY (garso čipas) klonas. Nu dar nepriklausoma nuo maitinimo atmintis ir laikrodis. Nuotraukos apačioje- ryšis su lemputėmis ir mygtukais (ir pinigų valgytoju).
Toliau tik nufotografuoti vaizdeliai iš plokštės ir dar viena plokštė.
Continue reading →
8080 šeimos klonai
va:
Iš dešinės į kairę:
- KR580IK80A (КР580ИК80А) – CPU, i8080.
- KR580IK57 (КР580ИК57) – DMA, i8257
- KR580VV79 (КР580ВВ79) – KBD, i8279
- KR580VK91A (КР580ВК91А) – GPIB, i8291A
- KR580VG75 (КР580ВГ75) -CRT, i8275
Pastovus Atari 1088XEL SMD puslapis angliakalbiams
Mano angliakalbiams draugams ir šiaip smalsučiams, sukūriau Anglišką Atari 1088XEL projekto statinį puslapį.
Taip atrodo V1.0 versija su nauju bugu.
ARM21: STM32-USB-CDC ir hardware handshake
Bežaidžiant su savadarbiu Atari kilo mintis iki galo iššifruoti kaip visdėlto persiduoda senoviniai RS232 būklės signalai į host kompiuterį. O pasirodo, čia didelė bėda. Daugelis interneto puslapių dažniausiai sako, kad tie visi RI, CTS, DSR, CD, DTR ir RTS jums nebus reikalingi “ir esamo straipsnio lygyje nebus padaryti”. Šūdeliai tie autoriai. Todėl, kiek pavargau ir po gabaliuką surinkau informaciją apie tai. Pakeliui STM32CubeMX gamintojai įpaišė eilinį sisteminį atnaujinimą ir su 1.8.0 versija viskas veikia, o su 1.8.3 kažkai biški neveikia ir biški veikia. Todėl pavyzdukinis softas kompiliuojasi su 1.8.0 firmwarės biblioteka.
Visi linijos kontrolės signalai iš įrenginio (device) į host eina per atskirą IN✻ endpointą (interrupt). Jis pagal nutylėjimą sukuriamas CDC pavyzdyje, bet nenaudojamas. Signalai iš host į įrenginį eina per standartinį komandinį (0 – nulinį) endpointą. Standartiniam kubo softe ten biški net padaryta.
Vienintelis signalas CTS niekaip negaminamas per USB, jo būklę nusprendžia host draiveris pagal esamą situaciją. Beja, net keli interneto šaltiniai rašo, kad windows standartiniai draiveriai to nemoka daryti ir iš viso ten bėda. Todėl visokie “hardwariniai” USB-COM adapteriai turi savo draiverius.
Biški prirašiau miglos? 🙂 Gerai- paprasčiau. RS232 būklė perduodama 7 bitais, per CDC status, per dedikuotą IN interrupt endpointą:
// 7 reserved 0.
// 6 bOverRun - received data has been discarded due to overrun in the device.
// 5 bParity - parity klaida, parity error
// 4 bFraming - framing error
// 3 BRingSignal =RI - ring signalas, vienas iš nepriklausomu RS232 signalų
// 2 bBreak - tai BREAK komandos statusas. Kai siunčiama BREAK komanda, RS232 siuntimas stabdomas, o duomenų linija užkeliama high.
// 1 bTxCarrier =DSR, data sender ready ar panašiai. Šitie du signalai užsikeldavo, kai modemas susijungdavo su kitu modemu.
// 0 bRxCarrier =DCD
Tokia informacija eina iš įrenginio. Tuo tarpu host gali siuntinėti daugiau komandų (nes CDC standartas tai ne tik COM portas). RS232 aišku naudoja greičio, stop bitų, parity valdymo signalus. Tai puikiausiai padaryta demonstraciniam kubo softe (komandos CDC_SET_LINE_CODING ir CDC_GET_LINE_CODING). Komanda sukurianti BREAK irgi lengvai randama (CDC_SEND_BREAK).
Lieka valdymo komanda CDC_SET_CONTROL_LINE_STATE, kurios paleisti aš ilgai negalėjau. Ten iš esmės tik du bitai iš 16:
//bitai: 15:2 - 0.
//bitas 1- carrier control. 0- deactivate carrier, 1- activate.
//bitas 0- DTR bukle, 0-not present, 1- present.
Tik kur tie bitai paslėpti? Pasirodo, kad USB CDC standarto kurėjai nutarė juos paslėpti kiek kitoje vietoje- wValue, o ne duomenų bloke. Kodėl? Tikriausiai, kad užsiknistum. Kubo kūrėjai irgi pasistengė viską paslėpti toje procedūroje kur viskas labai elegantiškai surašyta. Tačiau jei pakrutintume vienos struktūros prikabinta substruktūrą, tai joje ir rastume tą reikšmę. Aš tikrai nesuprantu struktūrų ir kaip iš jų traukiami duomenys, tai padariau taip, kaip nei vienam source kode nemačiau:
wValue=hUsbDeviceFS.request.wValue;
Ir čia randam tuos du bitus, kurie konkrečiam projekte nereikalingi.
Einam atgal prie būklės siuntimo per INT IN endpoitą. Kubo softo kūrėjai nenumatė duomenų perdavimą vartotojui per endpointus. Nu gal numatė, bet per žemesnio lygio procedūrą:
USBD_LL_Transmit(&hUsbDeviceFS, endpointo numeris, duomenų buferis, ilgis duomenų);
Alia, ką ten reikia siuntinėti nelabai ir rašo. Vargom vargom ir radom paketo aprašą:
buf[0]=0b10100001; //request type (0xA1). Nu tokis skaičius rodo, kad męs norim kažką pranešti CDC.
buf[1]=0x20; //notification SERIAL STATE, o čia kad pranešam COM porto būseną.
buf[2]=0; //wValue
buf[3]=0; //wValue
buf[4]=0; //wIndex - interface number, 16 bit, LSB
buf[5]=0; //wIndex - nes gali būti keli COM portai ant to pačio USB. MSB.
buf[6]=2; // Čia pranešimo ilgis. Ne paketo ilgis, o "svarbių" duomenų. LSB.
buf[7]=0; // Čia irgi ilgis. Viso du baitai. MSB.
buf[8]=status; // Šitie svarbūs. LSB pirmiau
buf[9]=0; // o šitie visada nuliai.
Šitą masyvą išsiunčiam:
USBD_LL_Transmit(&hUsbDeviceFS, 0x82, buf,10);
..ir? Nifiga neveikia. Tiksliau veikia dalinai. Kodėl? Ogi todėl, kad kubo softo kūrėjai nusprendė, kad “control endpointui” užtenka aštuonių (8) baitų. O šio paketo ilgis- 10. USB Shark ir parodo, kad eina 8 baitai mūsų, ir du randominiai. Todėl einam į “usbd_cdc.h” failą ir taisom:
#define CDC_CMD_PACKET_SIZE 10U /* Control Endpoint Packet size */
Va dabar, jau kažkas pradeda veikti. Paleidžiam softą skirta Atari diskų emuliacijai ir … neveikia. Be “flow control” veikia, su bet kokiu “flow control” trukinėja ryšis. Kol kas nežinau kur bėda. Vienas svarbus momentas, kad USB labai jau “asinchroniškai” nusiskaito būklę. Kartais labai vėluoja. Nes principas toks- “ei! Kompiuteriau, pasikeitė laidų būklė. O kompas po kažkiek laiko- gerai, gerai, jau supratau”. Ar tai MS draiverio bėda, ar mano, aš dar nežinau.
Nu ir pats pilnas softas:
ATARI 1088XEL SMD on board USB firmware for STM32F103, full source code and compiled hex and binary.
Ir kam buvo neįdomu ar nesupratot, va viena iliustracija:
Tikrai veikia.
—
✻) USB endpointų kryptis visada rašoma iš kompiuterio, hosto pusės. Visi signalai iš kompo yra “OUT”, visi signalai į kompą yra “IN”. Ir nesvarbu kas iššaukia perdavimą. Taip padaryta todėl, kad USB yra vienkryptis (pagal hierarchiją) protokolas. Tuo tarpu senovinis COM yra lygiavertis. Kartais susibalamutinasi protas, kai duomenys iš MCU eina į IN endpointą, o gaunami per OUT. Pas COM dažnai susipainioja laidai, nes TX sujungtas su RX. Pas kokį modemą RX pavadintas TX ir laide sujungta RX-RX. Taip darosi painiava.
Atari 1088XEL SMD Rev.0.0
Jau seniau rašiau, kad buvo nupušimas ir paišiau SMD versiją svetimo projekto- Atari 1088 XEL (Mini-ITX Atari 8 ). Kinai pagamino pirmą PCB ir kol kas lygtai kompiuteriukas veikia. Nežinau ar kam Lietuvoje tai domina, bet Rev.0.0 likusias 4 PCB galiu padovanoti. Jei užsieniečiai jų nepaims, tikrai atiduosiu, nes jau paišau Rev.1.0, su pataisymais ir mano fantazijom. Ši revizija buvo skirta tik patikrinti ar svetima schema teisinga ir ar veikia. Šiandien pabaigiau (dalinai) ir schema veikia. Ji 99% suderinama su originalia versija, tik vietoje super brangaus USB-RS232(TTL) keitiklio aš padėjau į PCB STM32F103. Dar pašalinau vieną labai kvailą lizdą, kuris buvo tik dėl kosmetinio suderinimo su kažkokiu moduliu (Audio).
Testavimas. Nėra klavietūros kištuko (PS/2, reikia išlupti iš seno kompo). Čia minimumas, kad paleisti ir pažiūrėti. Dar nėra PAL generatoriaus, joystikų lizdų, PELĖS(!), SIO ir kažkokių prabangių išplėtimų. Kad paleisti reikia dviejų papildomų PCB- ROM lizdeliui ir MMU- PAL/GAL čipui iš originalaus kompiuterio (fuse failus ir “formules” turim, galim suprogramuoti).
Continue reading →
Nupušimas – 1088 XEL rev SMD
Vieną open-source projektą nupaišiau. Dabar reikia tik palaukti, peržiūrėti, nupaišyti silk screen ir rasti kinus kurie pagamins.
Rankutėmis viskas, rankutėmis.
Z80 maketinė plokštė
Šiaip tai “pilnavertis” modernizuotas Z80 CPU kompiuteris.
Kaip jis gavosi šiais 64 bitų laikais? Vienas žmogus prisiprašė “pažiūrėti” senovišką industrinį kompiuterį. Ten buvo “kažkas” su Z80 procesorium ir stipriai ištekėjusia batareika. Batareika ištekėjo ant PCB, paėdė takelius ir šiaip nieko gero. Kompiuteris modulinis, visi “power” ir jutiklių moduliai kitoje PCB. O nukentėjo tik “kompiuteris”. Jo RAM tai dar ant baisių DRAM mikroschemų, kur reikia egzotinio maitinimo (4116, su -5V ir +12V maitinimu) … ir aišku ten kažkas stipriai neveikia. Parakinėjus daugiau supratau, kad ten šikna ir neverta kažką daryti, nes tai paprasčiausias kompiuteriukas. Taip gimė ši PCB.
Continue reading →
ARM:0020 smurtinis hardcorinis žaidimas Rogue
Jau rašiau, kad internetuose radau Rogue žaidimo source code kuris netikėtai susikompiliavo ant mano kompiuterio. Deja ant kitų kompiuterių jis neveikė. Bandžiau tokį iškrypimą, kaip perkelti source code į Microsoft Visual Studio Express, bet ten tikriausiai iš principo negali veikti jokie senoviški C kalbos failai- microsofto programa pranešinėjo keistas klaidas. Numojau į tai ranka ir pagalvojau- jei kompiliuojasi su gcc, tai kodėl jis nesikompiliuoti ir su ARM gcc (AVR tai gal per silpnas). Pasirodo, puikiausiai kompiliuojasi. Teko tik išpjauti dali paprogramiu susijusiu su failais ir prikabinti savo. Taip gavosi toks monstras:
Tai USB-COM-Rogue su STM32F103. Tereikia tik USB terminalo. Po tiekos programinimo, manau UART versija dar greičiau gautusi. Dar beliko viską sukultūrinti, nes dar liko visokių bugų- pvz. po žaidėjo mirties, jis kaip zombis toliau gali vaikščioti po labirintą. Nesvarbu, kad jau parodė mirties ekraną- turėjo pasileisti žaidimas iš naujo, bet kažkaip neišsivalė buferiai ir viskas liko iš seno žaidimo. Visiškai nesupratau dėl TERMCAP failo- vieną įdėjau ir veikia, įdėjau antrą- neveikia. Vėl įdėjau pirmą- neveikia. Veikia tik iš vakar dienos backupo. Originalus source kodas gana užsuktas. Užtat ir ant ARM gcc kompiliuojasi be jokių “warningų”.
Žaidimo source code ir kompiliuotas HEX. Dėmesio! Binaras gaunasi didelis (92kB ir neaišku kiek RAM jam reikia) ir tikrai neveiks ant BluePill. Jis veikia ant mano “white pill“, su pilnaverčiu STM32F106RET6.
ARM:0019 Printeris iš kalkuliatoriaus 2
Buvo straipsniukas, kaip aš sugadinau Citizen CX-123II kalkuliatorių. O dabar šio straipsniuko pratesimas. Toks ilgas tarpas gavosi todėl, kad aš tik mokinuosi. O ir kažkaip įtariu, kad į Bluepill plokšteles kinai sudėjo kažką mažesnio. Nes kartais labai magiškai projektas pradėdavo daryti nesąmones. Todėl labai ilgam sustojau, nes reikėjo savo PCB pasidaryti ir sunaudoti turimas mikroschemas. Dabar mano testavimui teko didesnė mikroschema STM32F103RET6, kuri rodos turi 512K ROMo ir 64K RAM. Tačiau spėju, kad galutinė programa turi tilpti ir į bluepill, jei tik Kinas labai nepataupė.
Šis “printeris” susideda iš kelių modulių: USB modulio, tarpininko tarp USB printerio ir mano citizeno programos. Šio eksperimento pamoka- USB pertraukimas turi būti mažesnio prioriteto nei machaninio printerio. Taip, mechaninis printeris veikia grynai per pertraukimus ir visi “taimingai” svarbūs.
Deja, šis projektas mano nusibodo- aš pilnai nesupratau, kaip veikia spalvos perjungimas ir pirmo (paskutinio) simbolio spausdinimas. Dabar printeris daro tai, kad jam nurodyta- spausdina skaičiukus iš bet kokio teksto paleisto į printerį. Jis kiek stengiasi filtruoti, tačiau vistiek dažnai spausdina nesąmones. Ir kartais užsispiria ir prispausdina ne to, ką norėjau.
Printeriui užtenka energijos iš USB lizdo. Kad paleisti reikia tik dviejų n-kanalo laukinių tranzų (su 3V tolerantišku valdymu, iš kompiuterio motininės plokštės, gal dviejų diodų. Ant PWM motoro valdymo reikia nedidelio elektrolitinio kondensatoriaus.
Ir aišku visas source kodas ir kompiliuotas binaras. Dėmesio! STM Cube projektas neatitinka pačio kodo, pergeneravus, gali nebesusikompliuoti. Dabar binaras yra skirtas STM32F103RET6 mikroschemai.
Buvo smagu.