Találtam egy uPong nevű programot, ami a hagyományos PONG játék, amit egy PIC12F675 futtat, minimális áramköri elemekkel kiegészítve. A képet kompozit monitoron lehet látni. (És a 8-pin pong-gal ellentétben, ez valóban működik is.)
Bár nagyjából el tudom képzelni a működését, szeretném pontosabban látni, hogyan lehet ilyen módon képet generálni, változó tartalmat előállítani. Mivel eddig még a PIC assembly-jét sem használtam soha, sokat segítene a tanulásban, ha létezne olyan emulátor, ami képes a futtatott programot meg is jeleníteni egy szimulált kompozit megjelenítőben. A simulIDE programmal próbálkoztam, de szkóppal nézve az még a kompozit kimeneten megjelenő jelet sem tudta szimulálni.
Létezik ilyen szimulációs környezet, vagy nincs más hátra, mint minden tesztet beégetni, és valós környezetben próbálgatni?
Hozzászólások
nem egyszerűbb egy arduinoval, ami tud in-chip programmingot? pl. ez, netán egy esp32.
szóval, szopatni magad, egymilliószor kiszedni/berakni/kiszedni/visszatenni a chip-et... s közben szidni a microchipet...
A célom nem az, hogy egy csippel csináljak kompozit jelet, hanem, hogy megtanulja, hogy egy ilyen minimális erőforrással bíró PIC hogyan tudja ezt megtenni. Nem mellékes cél, hogy általában jobban megismerjem a PIC programozását, ami teljesen ismeretlen még számomra.
de miért PIC-et?
- a PIC szar, csak akkor olcsóbb, mint az avr, ha ezresével veszed
- qrvára elcseszett arhitektúra, gányolás a memory bankokkal, Harvard arch. (nem tudsz flash-ben konstansokat tárolni, mint avr-n)
- ha a pro mplab kell (a free nem tud pl. jó optimalizálást), akkor fizetsz
- indirekt címzés szó szerint sux (INDF...)
- szar support
- avr-re van rendes open source toolchain, rengeteg library, példa, normális fórum (avrfreaks.net)
hat ezt nem ertem en se, a pic a 90-es evekben volt meno, max meg 2000esek elejen, aztan jottek jobbak, eljart felette az ido.
Árnyalnám a képet. Ez egy hobby project, aminek az a lényege, hogy assembly-ben időzítésekkel összerakja a képet, s közben A/D-zik, hangot generál, stb. A másik, hogy kis feladatokhoz - pl. kerékpár világítás vezérlése - tökéletesen megfelelnek ezek a picik e PIC-ek.
Ha C-ben szeretnél kódolni, ott van például a PIC18F26Q71, abban van elég FLASH, RAM, folytonosan is címezhető, valamennyi stack is van, 12 bites A/D, 10 és 8 bites D/A, műveleti erősítők, analóg komparátorok, timerek, DMA kontrollerek, UART-ok, PWM-ek, CLC-k - ezek picike FPGA cella kezdemények -, meg egy rakás egyéb cucc, és elfogadható a sebessége is, továbbá csak 28 lábú, azaz még épp elég pici.
Ha meg nagyobb kell, ott a PIC32MZ sorozat, 32 bites MIPS core, PIC perifériákkal körbeépítve.
Nem véletlenül mondom, mindkettőt használom, szerethetők, nincs velük semmi bajom.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
árnyald, nyugodtan... a hobby projekt s az assembly-ben írni composite videojel generátort, az már önmagában ellentmondás, de verjetek meg.
ugyanazt mondom, amit már fennebb is: a pic ipari dolgokhoz jó, kezdő hobbistáknak nem annyira. ugyanazokért:
- ha normális kódot akarsz, akkor megveszed a mplab-ot
- kell hozzá pic programmer
- közel sincs annyi elérhető lib, mint másra
- ha bajod van, akkor fórumozhatsz, de hol, ugye...
- személy szerint gányolásnak tartom a risc architektúrájukat
ha videojel generátorkell, itt van pl. egy , esp32-re, egy sor assembly nincs benne.
Mindebből csak annyi derül ki, hogy lövésed sincs hogyan használj egy PIC-et, de azért kemenyen tudod szidni.
Megjegyzem, hogy a topicnyitóban említett PIC képességei tényleg a bitbang és az ötökönlövés között mozognak. :-D
A PIC konkrét típusának kiválasztása bizony némi tudást feltételez, amit locsemege is felsorolt, csak az a baj (nem baj!) hogy ő érti amiről beszél és használni is tudja. Periodikus jelek előállításához (pl.) csak a feladathoz megfelelő perifériákkal rendelkező modellt kel kiválasztani, miközben a lib, fordító és optimalizálás okafogyottá válik. Néhány utasítással összekötögeted a megfelelő perifériákat és inicializálod. Ez assemblyben kb. pot ugyanúgy fog kinézni, mint bármely más nyelven, legfeljebb az adatlaphoz képest nem kell megtanulnod újabb "mire gondolt a költő" absztrakciókat. Szóval berúgod és ketyeg a hardver.
Ez is egy vélemény. Pedig egyik topicban pont azt sikerült kiszámolnom, hogy "egy ültő helyében" egy PIC nagyságrendekkel több adatot ér el, mint a hasonlónak tartott mcu-k.
nyilván, hogy lövésem sincs, azt sem tudom, hogy mi az :P csak 4 típust programoztam eddig... de ha összeszámolom, csak a lakásban több, mint 10 mikrokontroller van használatban, ebből 4-nek van webes interfésze. Nem pic-ek :P
ez lol. szerinted egy átlag mikrokontroller projekt arról szól, hogy generáljon egy periodikus jelet. Szerintem már teljesen már igények vannak, like pl. tudjon kommunikálni, netán etherneten, de wifin is. Kezeljen egy qrva displayt, egy pár buttont. De mindeközben a háttérben menjen a stepper motor és a szenzor olvasás.
ezen felröhögtem. tényleg azért kell fizetni a mplab proért, mert nem fontos az optimalizáció. és ti azért nyomjátok a assembly-t, mert attól
gyors leszbelefér abba a spórlós rom-ba.persze... s ha megírod rá kódot, akkor még működik is 🤣
szerk: na de pontosan mivel nem értesz egyet, azok közül, amit írtam?
Valami feldolgozatlan traumád van a PIC-ek által? :D
Az, hogy mi az igény, teljesen helyzetfüggő. Olyannyira, hogy azt is mi, mérnökök döntjük el, hogy a léptetőmotort hajtó elektronika intelligens legyen-e, amellyel lehet kommunikálni, vagy az egész cucc valami monolitikus borzadály, ahol a léptetőmotor hajtását ugyanaz az MCU végzi, mint a billentyűk olvasását meg a kijelző kezelését.
Ami a kommunikációt illeti, mondom, van MIPS core-ral PIC, USB HS, ethernet, I2C, UART, SPI kommunikációkkal, meg persze FPU is van benne. Aszerint kell eszközt választani, hogy mire használod. Amikor nem kellenek az efféle dolgok, felesleges a 32 bites, 144 lábút választani, elég lesz az olcsó, de még bőven sokat tudó PIC18-as sorozat valamely tagja. Konkrét típust írtam is. Azon hülyeség hőbörögni, hogy egy PIC12F510-ben nincs USB host controller, mert nem arra lett az az MCU kitalálva. Ha azt használod, miközben nem arra van szükséged, akkor alulméretezted. Van megoldás.
8 bites PIC-re XC8-ban -O2 még free, 32 bitesre XC32-ben -O1 free. Volt, hogy használtuk a 30 napos próbaverziót, és el kell mondjam, nagy csodát nem tett a kóddal, szóval ha azon a minimális plusz optimalizáción múlik minden, akkor megint csak alul van méretezve az egész.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
vagy megmondják, hogy költséghatékonysági okokból nem engedhetünk meg 2 kontrollert
nincs feldolgozatlan traumám, csak személyes véleményem. A topicindító egy PIC12F675-ről beszélt, tehát maradjunk ennél...
Az egész a General Instrument-től származik, még a 70-es évekből, tudtommal ezt vette át a Microchip... tettek bele dolgokat, de nem merték újratervezni az egészet, kompatibilitási okokból.
Szóval "szerintem" ezért szar:
- már mondtam: a memory bankok, amiket manuálisan kell váltogass
- már mondtam: az indirekt címzés maga a megtestesült gányolás
- a programmemória is lapokra van osztva
- nincsenek regiszterek, van a W és gyakorlatilag annyi
- "risc"-nek hívja a Microchip, de köze sincs, ugye... egy nyavalyás szorzást nem tud megcsinálni hardverből
szóval, vállalom, teljes mellszélességgel, hogy a topicindító az energiáját más, értelmesebb dolgokba fektesse, mint ezt az architektúrát megtanulni assemblyben programozni.
Jössz azzal, hogy assemblyben fárasztó megtanulni. Épp a PIC16 kb. 36 utasítása olyan kevés, hogy kezdőnek sem több két napnál. Ha meg C-ben programozod, engedd el a banksel-t, tekintve, hogy megoldja a fordító. Amúgy ez is méretezés kérdése. Ha kis konroller kell, de C-ben akarod programozni, akkor PIC18-as sorozatból válogass. Azon egyébként folytonos címzéssel is elérhető a memória.
Miért gányolás az indirekt címzés? Van hozzá pointer regiszter. Mi kell még?
Nincsenek regiszterek? Az op. kód 7 bitje vajon mi? Mert az adott bank-en belül minden regiszter. Ugye, ez is értelmezés kérdése.
Van olyan PIC, amelyik tud hardwerből szorozni, bár nem egészen világos, ez miért volna követelmény. De ha az, akkor olyat választasz. Ha lebegőpontos hardware támogatás kell, akkor meg olyat, amiben van FPU.
Az, hogy kinek mi az értelmes, ki-ki eldönti maga. Életszakasztól, élethelyzettől, motivációtól, lehetőségektől függ.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Itt kezdődik az agyrák. ;) Sajnos az ebay és tsai néha kifejezetten ósdi típusokat árulnak, pontosan azért, mert jó régen lelkes amatőrök ezekkel dolgoztak ki (akkor) egy csomó érdekes és hasznos (bitbang) megoldást. Mindeközben a PIC16 családban (ami nem a legfejlettebb 8 bites) rengeteg új típust hoznak ki még manapság is. Ennek pontosan az az oka, hogy itt nem az FPU-k száma, vagy az ethernet ínterfészek sokasága a választás szempontja, mert nem arra való. Szintén kutya nem akar egy vezérlési célra szerkesztett mikrokontrollerrel webszervert csinálni, vagy dataflow processzort játszani, mert arra sem való. De ha PID kontroller libet linkelnél, akkor helyette választhatsz PID kontroller math engine-t tartalmazó PIC16 modellt. Nincs benne FPU, de a 30 bites (asszem) számításokat kiválóan végzi hardverből. A PIC18 bizony tartalmaz hardver szorzót. (RISC == FPU ???)
Biztosan, bár pont olyan, mint az x86-ban, esetleg többet is tud. :)
Bizony, nem egy sokregiszteres eszköz. Pedig már korábban is írtam, de mégegyszer nem számolom ki: kb. 276 címet tud elérni ez a szegényes megoldás, amíg egy "sokkal jobb" talán 20-at. Ez azért van, mert ez egy "register file" szervezésű CPU - de nevezhetjük gyostárnak is. Azt a műveletet amit a W (legyen most akkumulátor) el tud végezni, azt általában bármelyik megcímezhető entitással is működik. Ettől risc a risc ebben az esetben, mert "akárminek az elérésére is" ugyanazt az utasítást kell használni.
Nincs, legfeljebb több részre hívatkozhatsz pl. védelmi biteknél. Egyébként teljesen folyamatos a címzése. PIC18-tól (ha kell, ha nem) már 24bites a címzés, amivel a flash írható-olvasható.
Ezt egy kicsit szokni kell, de némi ész meg a fordító sokat segíthet. Ez az ára annak, hogy az utasítások rövidek, így az opcode kevés címbitet tartalmazhat. Ettől viszont sokkal gyorsabb lesz. A sok SFR is több lapon helyezkedhet el, de a gyakran használt regisztereket általában egyszerűsítve direkt is elérheted.
Achtung! Magánvélemény következik.
- Bár PIC18-tól az architektúra C-re készült - mármint van egy extended mód és utasításkészlet is. Szerintem ez csak a C-hez ragaszkodó, kis processzoron bazinagy projekt szemléletű emberkék kedvéért létezik. Vagy akik nem tudják kiválasztani a megfelelő modellt, ezért "hordozható" kódot szeretnének írni. Szerintem ez a szint inkább firmware. Nekem viszont nem okoz gondot az awk vagy C közvetlen assembler kóddá alakítása. Természetesen ilyenkor pl. nem az FPU megléte az alapfeltétel, sőt webszerver sem készül.
Szerencséd, hogy áthúztad. Az csak a naívak elképzelése, hogy az assembly a sebessége miatt jó. Ha tudod mit csinálsz, akkor a C is pontosan olyan gyors. Pl. ne írjál stack igényes C programot egy PIC18-ra, mert ott bizony a stack csak egy szoftveres emuláció és ennek megfelelően igen lassú! A rom nem spórolós, csak nem megfelelő modellt választottál, vagy túl nagy feladatot próbálsz bepréselni a nemlétező helyre.
Pl. én a legtöbb munkát PC18F24K50-en végeztem (16kB) és a "nagy" program 8k feletti. Ha megszorulnék, akkor van 25K50 (32kB).
Hasonló a PIC18F2[456]J50, ahol 10k a program, a három modellben 16/32/64kB flash van. Az utóbbiba már bazinagy program is belefér.
[...] Pl. ne írjál stack igényes C programot egy PIC18-ra, mert ott bizony a stack csak egy szoftveres emuláció és ennek megfelelően igen lassú! A rom nem spórolós, csak nem megfelelő modellt választottál, vagy túl nagy feladatot próbálsz bepréselni a nemlétező helyre.
Eddig csak 2-3 kisebb PIC-es projektet csinaltam, PIC16/PIC18-as csaladokra, szoval az ketsegtelen hogy nincs annyi tapasztalatom ezekben mint nektek. Ettol fuggetlenul ezeknel az tunt fel a tobbi es/vagy hasonlo kontrollerekhez kepest hogy a generalt binaris az kb 2x akkora volt (mint pl AVR-en), es leginkabb az indirekcios megoldasok miatt szallt el a meret. Szoval nemcsak a stack a draga sajna hanem az ilyen value=object->member; konstrukciok, vagy altalaban a strukturapointerekkel valo jatek (parameternek atadni kulso fuggvenyhivas eseten, stb). Aztan kicsit jobban megnezve latszik hogy meg a legegyszerubb, legalapabb RISC architekturakon is ott van az LD/ST Rx,[Ry+offset] jellegu utasitas (beleertve mar az AVR-t is), es tkp ez az amit nagyon nehez osszerakni banklapozos hatteren. Jol megcsinalta az xc8-cc, nem az (a bitfield jellegu temakat leszamitva 1:1-ben hordozhato is volt a kod), csak ez az atlag 2x-es szorzo tunt fel. Nyilvan sebessegben is megjelenik ez, de az ott anno nem volt szuk keresztmetszet.
Igen, ezeket az utasításokat megtalálod a PIC18 extended utasításkészletében. (pl. PIC18F24K50 , TABLE 27-3) Mivel a CPU nem rendelkezik soft stackkel, ezért (x86-hoz hasonlítva) az SP, BP, FP emuláláshoz és ugrótábla (offset) kezeléshez való utasításokra van szükség. Az indexregiszterek lineárisan kezelik a memóriát, tehát lényegtelen a lapozási mechanizmus. V[iszont 8 biten a 16 bites index kezelése sok esetben 2 bájt LD/ST, ami két utasítás is lehet.
No, szinte meg is vagyunk a "magasszintű nyelvek támogatására" alkalmas CPU emulálásával. Sajnos az index, offset, loop, esetleg a rep kezelésének mindig ára van, különösen ha több regiszter összeadogatásával kívánod a struct kezelését megvalósítani. A példához nem kell egy olyan CPU, ami alapvetően NEM erre készült. Ott van a 8086/88, ahol a hasonló mutatványokat mikrokóddal végzik (mikroprogramozott utasítások), ami keményen növeli a futásidőt. Ugyanezeknek a japán klónjai a V30/V20 (NEC μPD70116/μPD70108) ezekre a számításokra mikrokód helyett külön ALU-t használ, amivel a kompatibilis utasítások futásideje lényegesen csökken. A PIC18-nál ráadásul nem a háttérben futó mikrokód, hanem valódi kód végzi a számításokat - ezért nő a kód mérete.
Igy jár aki "hordozható" kódot szeretne írni egy olyan processzorra, ami nem arra készült.
Induljunk ki ebből! A feladathoz ki kell választani a kellő fajtájú és mennyiségű perifériát tartalmazó modellt. És erre ne írjunk hordozható adatbáziskezelő szoftvert! A feladat elegánsan elvégezhető (macro)assembler segítségével, amellyel akár index/offset kezelésére is meg lehet tanítani a CPU-t, sokkal hatékonyabban, mint a C és egyéb magasszintű nyelv emulálásával való görcsöléssel.
Noha én szeretek assembly-ben programozni, egy PIC18F26Q71-re épp az imént fejeztem be egy programot C-ben írva munka kapcsán. Csak a programmemória 16 %-át használtam ki, s ebben minden benne van, többek között a kommunikáció is. Ráadásul szokásom struktúrák és függvénypointerek használata.
Egyébként néztem, függvénypointereket elég egyszerűen oldja meg. Felteszi a stack-re a változóból származó címet, majd return, s így adja át a vezérlést tetszőleges, futásidőben számolt címre. Egyébként a ZX Spectrum is valahogy így csinálta:
PUSH BC
RET
:)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
woow... s akkor ez már tud szorozni is? :D
a JP (HL) gyorsabb volt
Persze, ha a HL-ben keletkezett volna az eredmény, illetve a HL-ben nem akarunk épp semmilyen paramétert átadni. Amúgy szerettem a Z80-at, ám a JP (HL) az épp egy hibás mnemonik. JP HL lenne helyesen, hiszen nem a HL által mutatott címről szedi fel az adatot, és teszi a PC-be, hanem valójában egy LD PC, HL, már ha szabad ilyet írnom. :)
Szorozni? Megnéztem, van MULWF utasítása, egy gépi ciklus.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azt is tudod, hogy csaltál? :-D Aki alacsony szinten tud (hardvert is) programozni, tehát látja mi fog történni, az egészen más kódot tud írni, mint egy szoftveres. Persze egy jó CPU egy jó fordítóval kombinálva is eredményezheti, hogy egy sor C szinte mindig egy utasítássá fordul.
Régebben gyakran a C asm kimenetét optimalizálták. Erre pl. a POWER + xlc esetében esélyem sem volt, annyira tökéletesen végezte a dolgát. Néha a "forró pontok" környékén meg-megnéztem a függvények straight line execution time értékét. Ha túl magas volt, akkor átfogalmaztam a költeményt. ;)
Már csak a kerkeckedés kedvéért
Eltelt néhány évtized, amikor ezt a kifejezést először hallottam. Egészen addig csak assembler programokat (assembler language program) írtam, többek között: MACRO-80 Assembler, ISIS-II 8080/8085 Macro Assembler (ASM80), Microsoft Macro Assembler (MASM) {is an x86 assembler}, stb., stb. segítségével. ;) Az assembly kifejezést csak a fiatalok használják. :-D
Jó tudni, hogy még fiatal vagyok! :)
Hozzám képest biztos, de az meg nem nagy durranás. ;)
Elég későn kezdtem, ezért a fiam 34, a lányom 32 éves, az unokám 4 hónapos (a fiamé). Ebből könnyedén kikövetkeztethető a korom. ;)
Szerintem az assembler a fordító, amely az assemblálást végzi, a nyelv pedig az assembly.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Gondoltam, hogy ezt mondod. ;) Az a program, amely tartalmazhat REPT, IRP, IRPC, MACRO/ENDM direktivákat, az nem assembly.
Sajnos a C(++) aggyal írt gpasm az első hármat nem tudja. :(
A program attól még assembly nyelven íródik, mert a fordító ismer és használ különféle direktívákat, ugyanis a direktívák a fordító (az assembler) részére szolgáló spéci utasítások, nem a nyelv része. A direktívák "hatására" az assembly nyelvből nem lesz assembler nyelv.
Most azon erőlködsz, hogy egy öreg szakinak elmagyarázd: de a sublert TOLÓMÉRŐNEK HÍVJÁK! 83-tól dolgoztam a VIFI-ben (VIDEOTON Számítógépgyár Fejlesztési Intézet) 120 fejlesztőmérnök között. A szobatársaim pl. Amerikát és Indiát megjárt felsőfokú angol+nyelvi szaklektor képesítésű villamosmérnökök voltak. Arra felé senki nem használta az assembly kifejezést. De még a C tudorok is inline assemblert írtak az inline assembly helyett, pedig az inkább assembly.
Még a wiki is az elsői mondatban leszögezi:
Szóval ez olyan, amikor a nagyi a tornacipőt dorkónak hívja. ;) (Megjegyzem, a Dorkó márkát újraindították.)
Én nem erőlködök. Te hívod következetesen assembler nyelvnek azt, amit nagyjából mindenki más assembly nyelvnek hív. Persze ez nem gond, többször előkerült ez már itt, a wikit én is tudom használni, abban azt is látni, hogy egyetlen hivatkozást csatoltak az assembler nyelvre magyarázatkánt, ami az IBM egyik ősrégi dokumentációja. A nyomdahibák veszélyesek!
Javaslom, ezután hívjuk szimbolikus gépi kódnak. :)
sokkal hatékonyabban, mint a C és egyéb magasszintű nyelv emulálásával való görcsöléssel
Hat, halistennek azt kell mondjam hogy mostanaban a GCC mar igencsak eleg jo kodot general. Avagy magam is meglepodom hogy viszonylag altalanos (tulzas hogy esz nelkuli, de azert abszolut nem erre kihegyezett modon irt) kod eseten is nemhogy meglepoen jo, de ilyen "erre nem is gondoltam volna hogy igy meg gyorsabb is lesz" jellegu assemblyt/gepikodot general a fordito. Olyanokrol nem is beszelve hogy pipeline optimization-t is csinal (leheto legjobban szetszorja a writeback-eket es eltavolitja a read-after-write eseteket, stb... na, ezt tartsuk fejben). Mondom ezt ugy hogy nem all tavol tolem, es szeretem is az assemblyt (sot). Szoval nem lenne ellenemre akar sokmindent is megirni assemblyben, de mar lenyegeben minek. Par pelda, amire kellett az elmult idoszakban: uint32_t * uint8_t szorzas (AVR alatt), GF(2^32)-n fused multiply–add egy tomb elemei felett (azaz for (i=0;i<...;i++) a[i]+=b[i]*c; de ugye a + az xor, a * meg Galois szorzas),meg persze az osszes tradicionalis dolog amire kell (context management RTOS-oknal, yielding, syscall szimulalas syscall nelkul, startup code snippetek, ...). Az algoritmikusabb peldakban tenyleg 3x-5x gyorsabb is lehet a sajat assembly mint amit a fordito general, de ezek tenyleg elegge extrem peldak.
Ez a kis CPU a felépítése miatt alkalmatlan az intenzív stack használatot szerető nyelvekhez, mert nincs dinamikus SP és az sem a RAM-ra mutat. Helyette fix mélységű hardver stack van. Ezért pl. a PUSH valami az egy program.
A 2000-es évek elején láttam egy szenzációs optimalizálás. A Motorola rájött, hogy elakadt és nem tud gyorsabb CPU-t készíteni. Ezért készítettek egy olyan fordítót, amely meghekkelte a CPU belső lelkivilágát, pl. kitalálta hogyan fognak működni a rename register-ek. Ezzel az okoskodásssal akár háromszoros sebességű kódot tudtak generálni!
Helyette fix mélységű hardver stack van. Ezért pl. a PUSH valami az egy program.
Igenigen, raadasul ez a "call stack" verzusz "adat stack" problemakor. Nehany architektura (pl. X86, MSP430, AVR) ugyanazt a memora-regiszter kombot hasznalja mindkettore, nehanynal meg csak egy egy elemu hw stack van (pl. ARM, RISC-V, ahol ez az egy elemu hw stack lenyegeben egy regiszter). Es a PIC-nel pedig tobb elemu hw stack van, viszont legjobb emlekeim szerint a nem mindegyik PIC csalad enged szoftveres hozzaferest a hw stack elemeihez (a PIC16 meg nem, de a PIC18 mar igen, vagy valahogy igy remlik). De a massziv RTOS tamogatast pl ezert engedtek el ennel a csaladnal.
a pic ipari dolgokhoz jó
Itt mire gondolsz? Marmint van olyan problema amire kimondotottan a PIC (8-bites, bankozos) a jobb valasztas mint mondjuk egy ~ugyanakkora flash/memoriaval megaldott, ~egyenrangu periferiakeszlettel rendelkezo mondjuk AVR? Ahol a "kimondottan" alatt nem szubjektiv okokat ("ebben van tapasztalatom", "fizetos/ingyenes a fordito", "sajat programozo kell/nemkell") hanem kimondottan az adott, csak ezen MCU altal biztositott specialis funkciokat ertjuk? Szerk: ilyesmikre gondolok (ha en lennek a kolto): rettento alacsony interrupt latency, fix 1 v. 2 ciklusos memory i/o vagy 1 ciklusos bitbanging. Marmint nem mintha ezekben a parameterekben az AVR ne lenne rossz, de valami ilyesmire gondolnek mint "ipari dolgokhoz jo". Peldaul ha nincs sw stack az ugye alapbol nem jo, de pont interrupt entry-nel egy hw accelerator (segedregiszter) az baromi sokat tud javitani a latency-n (lasd: RISC-V, mepc CSR: szinten effektive 1 ciklusos interrupt/trap entry vs. AVR-nel a 4-5 ciklusos belepes az sw stack miatt).
van benne code protection, hogy elvileg ne tudd másolni a firmware-t
vagy hosszú a támogatása (ha jól tudom, a pic16x84-et még mindig lehet kapni, 30 év után)
vagy licencelési okokból (a sok library sokszor gpl-es)
vagy mert nehezebb a tanulási görbéje... akkor éri meg, ha kifejleszted a firmware-t, aztán ezerszámra flasheled
igen, a hardver stack lehet, hogy reszponzívabb... de azért ezt a reszponzivitást ne hasonlítsuk egy 240MHz-en futó, kétmagos esp32-vel. Ami ráadásul nem sokkal kerül többe, mint egy pic16F84A
szóval, szerintem hobbistáknak jobb az arduino, az esp8266, esp32, esp01 (locsemege kerékpár-világítás vezérlőjére), sokkal könnyebb tanulni, millió library előre meg van írva, letesztelve, stb.
és ez nem jelenti azt, hogy arduino-ra ne írnának komoly firmware-t (pl. grbl... elvileg tud stabilan 30kHz-es pulzusokat generálni a stepper motorokhoz egy arduino uno-n).
Ma már leginkább 32 bites Cortex-M sorozatú arm MCU-k, amit a valódi ipar használ. A 8 bitesek beszerezhetősége is erősen kérdéses kezd lenni.
Most vettem új kaputelefont a régi retek helyett. PIC12F508 van benne. (512 szó flash, 25 bájt ram, 1x8bit timer, még interrupt sincs, csak wake-up from Sleep on pin change) Ide még ez is nagyágyú. Ára <0,8€/360Ft. Az órajel 1%-ra kalibrált, fogyasztása elhanyagolható. 8 lába van, ami még sok is. Csak a csengetéskor jövö impulzusokat kell megszámolnia. Itt is érvényesül az ökölszabály: 2 RC tagnál több esetén CPU kell. Az arduino, az esp8266, esp32, esp01 tök felesleges, drágább és még bonyolultabb programozni is. Amatőrök nem ezzel játszanak.
tme.eu-n: a te PIC12F508-asod DIP8 525.00HUF, az smd az 574.00
STM32F030K6T6TR az csak 392.00
de egy TI MSP430G2001IPW14 is 450HUF
vagy egy Infineon XMC1100T016F0008ABXUMA1 is 337HUF
de aliexpressen az esp8266 chipet is megveszed kb. 470HUFért
miről is beszélünk?
de ugye nem szines? mert ott kezd izgalmas lenni. Fabrice Bellard amugy (az ffmpeg/qemu iroja) csinalt ilyesmit linuxra mar.
feketefeher kompozit jel igen egyszeru, kell vizszintes es fuggoleges szinkronjel, kozte pedig a pixelek szurkearnyalatanak megfelelo feszultseg (ugy remlik 0-1 Vpp). a trukk hogy olyan frekvencian kell amit a tv megeszik, ez ha jol remlik PAL eseten 6.5mhz
20 eve programoztam PIC-et asm-ben es c-ben is, nem volt nehez, de azert nem art ha elotte mondjuk c64-en is asm-eztel mar :) a pc asm-hez kepest azert iszonyu buta/egyszeru/korlatozott.
PIC emulatorrol en nem tudok, de elvileg ha megveszed az o gyari programozo cuccukat (nem occso) azzal lehet live debuggolni, talan meg kivulrol (SPI-n) beadagolt programot is futtatni, igy nem kell mindig "beegetni".
PAL eseten 6.5mhz
Ha a képpontfrekvenciára gondolsz, ez a régi TV-re köthető gépeken a 3,5 MHz-től a 8 MHz-ig mind előfordultak, sőt "nagy felbontású" módban 16 MHz is volt (csak ez már nem feltétlenül volt jól olvasható). Igazából analóg képnél nincs is képpontfrekvencia, mivel az elektronsugár folyamatosan "rajzol" (persze színes tévéknél ott a maszk), csak egy bizonyos szint felett elfogy a sávszél.
Lényegesebb a 15625Hz sorszinkron, és az 50Hz félképszinkron. Aztán, ha fixen 312 soronként adsz vsyncet, akkor kapsz 288 soros képet, ha váltogatva 313/312 soronként, akkor megjelenik az 576 sor úgy hogy minden második 288 soros kép fél sorral eltolódva lesz beszúrva az előző sorok közé.
Itt lép be esetleg a 6.5mhz, mint a képpont frekvencia korlátja, ami még mindig csak 320 pontot engedne meg egy sorban, de alapon 720x576 a PAL kép, ami nagyobb ponfrekvenciát feltételez, úgyhogy ez inkább a tévéadások 8mhz csatornaszélességéből adódhat, amiből a 6mhz-vel eltolt hangsáv lejön, mert ugye, mennyivel kevesebb tévécsatorna jöhetne az erre biztosított frekvenciatartományban.
Közben még ezt találtam, nem pontosan fogalmaztam:
https://martin.hinner.info/vga/pal.html
proteus pic vsm tudja szimulálni a 12f675-öt, de a ráakasztható virtuális szkóppal max 0.5us/osztásig tudsz lemenni, virtuális pal screenről nem tudok
Én foglalkoztam mikrovezérlős program szimulációjával PC-n, de lényegében minden feladatra külön megcsináltuk a szimulátort. Ami pont azt szimulálta, ami a projekt számára lényeges volt. ASM-et nem szimuláltunk, hanem platfromfüggetlen C-t egy absztrakciós rétegnél elvágva.
ARM-hez létezik szimulátor azt hiszem QEMU alapon. AVR-hez csináltam egyet magamnak, de épp csak annyi utasítást valósítottam meg, ami az aktuális projekthez kellett. Ez is egy út lehet, ha hobbizni akarsz. Úgy értve, hogy annyi munka, hogy csak akkor éri meg, ha megfizetik, vagy ha szórakoztat.
https://sourceforge.net/projects/picsim/
https://lcgamboa.github.io/picsimlab_docs/stable/Oscilloscope.html#x69-…
Tudsz, lehet ISA szimulátorokat írni, egész jó sebességgel is: ARMv6-M, RV32IMC is simán megy 50-100MIPS-sel egy mezei PC-n mindenféle flanc nélkül - de a realtime viselkedést visszaadni, hát, az nagyon nehéz, nagyon nagy is lehet a latency. Még egy 1ms-es SysTick periféria is tudja dobálni a double overflow-okat ha a terheled a host rendszert (pl egy böngésző a háttérben videót játszik le).
Szoval hogy ennyire masszívan hard real time probléma mint video megjelenites mennyire szimulálható... hát... valami trükkkel biztos, de akkor a display-t is szinkronizaltan kell szimulalnod. Az meg nem igazan vezet sehova...
Nagyon egyszerű pedig. A szimulátor nem real-time működik, hanem egy virtuális óra szerint, azaz csak számolja, hogy szerinte mennyi az idő. Ahogy a csövön kifér egy streambe írja a kimenetet (akár IPC stream, akár stdout, akár egy processzen belüli stream pl ringbufferrel megvalósítva) időbélyeggel megjelölve, hogy mi mikor történik. Egy dekóder szál (processz) ezt feldolgozza, és képkockákat csinál belőle. És a trükk az, hogy csak a képkockák megjelenítését szinkronizálod a valós időhöz!
A real time szimulációnak pont az az achilles sarka, ha valóban a valós időhöz akarod szinkronizálni szub-milliszekundum felbontásban. Mivel PC-n az oprendszer hívások rendkívül költségesek, az időzítők viszont pontatlanok. Összevissza fog járni az óra, katasztrófa lesz. De ha virtuális órát csinálunk és egyáltalán nem, vagy csak makró szinten szinkronizálunk a valós időhöz (pl 1ms, vagy 16ms - azaz minden képkocka), akkor jól fog működni és akár a valós idő többszöröse is elérhető, ami autoteszteknél előnyös.
Nagyon egyszerű pedig. [...]
Igenigen, pont ezt mondom en is. Meg lehet ezt csinalni, csak (szerintem es/vagy szvsz) az mar elegge tulbonyolitja a folyamatot. Lenyegeben akkor inkabb egy *.vcd-t kell letrehoznod, es azt elemezni valamivel (celprogrammal) a vegen es/vagy valos idoben. Kb ugy mintha konkret hardveres szimulaciot csinalnal.
Összevissza fog járni az óra, katasztrófa lesz.
Osszevissza azert annyira nem, legalabb azert monoton marad :) Ha nem lenne monoton, na, az lenne az igazi osszevisszasag :)
A linkelt doksi ír róla, legalább is a 7-es ábra eléggé beszédes. Az a lényeg, hogy negyon pontos időzítésekkel kell kapcsolgatni a port adat illetve tris regisztereket, ami miatt szinte semmire sem marad időd, de ez a szépsége az ilyen project-eknek, hogy mégis megcsinálják. Amúgy az egykori ZX81 volt sok vonatkozásban nagyon hasonló.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ha Z80-al sikerült, ami ráadásul még programot is futtatott, akkor egy PIC-el lehetséges :)
A ZX81 amúgy már a vízszintes szinkront hardverből csinálta, a ZX80 még CPU-ból.
Minimálisan itt is kell programot futtatni. Karaktergenerátor az eredményjelzőhöz - persze, lehet valós időben, de akkor is kell -, a labda és az ütők mozgatása, az ütők pozíciójának beolvasása, A/D konvertálás - igaz, hardware támogatással, hang generálása. Labda mozgatásához némi algoritmus is kell, ha nem is túl bonyolult.
Azért azt megverném, aki C2-t és C3-at arra a portra kötötte kvázi kapacitív hurkot képezve. Jó, tudom, van csatornaellenállása a MOSFET-nek, de marhára nem jó, amikor megrántjuk a portról a tápot, próbára téve, elegendően jó-e a mikrokontroller tápján a hidegítés.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Sziasztok, én a SimulIDE programját szoktam használni a kis játszós dolgaimhoz.
https://simulide.com/p/