Fórum témák
» Több friss téma |
Átírtam, de hibára futott. Bizonyára nem pontosan ugyanaz a konfigurációja. Végig kell néznem.
Így csak sajnálkodni tudunk, de ha látnánk is a hibalistát, rögtön lenne ötletünk.
Annyi volt, hogy írtad, hogy felülírtam a delay_ms definiálását, így azt a sort kikommenteltem. Erre most meg az lett a baja. Így ismét benne hagytam és most szépen lefordult. Köszönöm. (Elhamarkodottan írtam, bocsi.)
De abban mégis kérném a segítségeteket, hogy miért van az, hogy a stopper szépen számol másodpercenként, akár másfél, két percig is, utána valamiért várakozik 2-3 másodpercet, majd újra szépen fut. Mi lehet ennek az oka?
Lehet, hogy a baj, hogy számítógépes szimulációval nézem és ha a számítógépem éppen csinál valami gondolkodtatót, akkor itt megáll egy kicsit az "idő" ?
Ó, nemár! A szimuláció az nem a valóság! Ha hibát keresel akkor legalább rakj fel egy stoppert a szimulációra, és nézd hogy nem-e állt meg arra az idôre az is. (Mármint nem amit írsz, hanem egy mindentôl független számlálót. Esetleg állítsd meg a szimulációt amikor úgy érzed megakadt, hogy épp hol tart a programban.)
A hozzászólás módosítva: Jan 26, 2022
Hogy szokás azt csinalni, ha egy LCD-re kiírt visszaszámláló kezdő értékét szeretnénk beállítani? Van erre egy bevált programrészetek C-ben?
Tehát a megfelelő helyen a kurzor villog, vagy az állitandó szám villog. Utána, ha egy gombot hosszan nyomunk, akkor gyorsan fut a szám, ha röviden, akkor csak egyesével. Köszönöm!
Az lenne az ideális ugye, hogy mások által írt kódrészleteket egymásután pakolva mûködne a szimulációd (netán egyszer valami amit összelegóztál)? Tulajdonképp fel is adhatnál egy hirdetést, hogy valaki írja meg neked amit akarsz. De így sosem tanulsz meg programozni, vagy ez nem is volt cél?
Szégyelld magad! El se tudod képzelni mennyit küzdök vele. Talán Te is voltál kezdő....
A minimális önállóság ebben a sportban nem lehetôség hanem kötelezô tulajdonság.
Pl. azt megkérdezni hogy a felhúzó ellenállás hogyan van, nos ha elôkapod az adatlapját akkor egyértelmû a helyzet. Mindent is kérdezni persze kényelmesebb nyilván. szerk: És azért kell egyre nagyobb tokot keresned egy ennyire banális feladatra is, mert ez a PIC16F sorozat nem C nyelvre van optimalizálva, ASM-ben programozva töredék helyet foglalna. A hozzászólás módosítva: Jan 27, 2022
Hozz létre egy változót, mondjuk "szamlalo" néven, és azt pöcögtesd ahogy szetretnéd.
Utána ezt kiírathatod ahogy jól esik, akár ciklusban akár valami megszakításon kersztül. De az LCD az csak legyen egy megjelenítő egység humanoid egyedek számára. Ha direkt az LCD megjelenítésben játszol ezekkel az értékekkel, előbb utóbb eljutsz oda, hogy készítesz egy eszközt és annak a beállításait az LCD -ről kéne vissza olvasnod. Tehát - minden munka a háttérben folyik, az LCD csak informálja a felhasználót.
Tudom, sokan nem értenek egyet velem, de én minden kezdőnek azt javaslom, első körben assemblyben tanuljon meg programozni, mert ahhoz elengedhetetlen, hogy megismerd a mikrokontroller működését, lelki világát.
Ezen alaptudás nélkül ugyanis csak KBal76 által felvázolt "kódrészletek összelegózása" módon fogsz tudni programot írni, és ha valami nem működik, önerőből meg nem fejted, mi a gondja. Ui: Nem utolsó sorban, ha magadnak készítessz pl LCD kezelő rutint, mindíg fogod tudni, hogy működik, és akár sokkal jobbat is írhatsz, Rövidebbett, gyorsabbat, megbízhatóbbat) mint amivel a C könyvtárból dolgozhatsz. A hozzászólás módosítva: Jan 27, 2022
Én totálisan az ASM híve vagyok, talán két alkalommal vetemedtem rá hogy PIC16 családdal magasabb programnyelvhez nyúljak, de ott tipikusan egy szögegyszerû feladat leküzdése volt a cél.
Most feltúrtam egy ~15 éves projektem, itt ugyanez a f628 volt a tok, és kicsivel több fért bele ASM-ben egy stoppernél (konkrétan 5 vaku+dslr fényképezôgép távvezérlô, 4 soros LCD-vel, , menüs agyonkonfigurálással). Épp csak sörért nem ment le. A gombokat és néhány nem idôkritikus funkciót shift-regiszterekkel kezeltem le.
Én assemblyvel kezdtem a PIC programozást, akkor még nem is lehetett máshogy. Sok évig így is folytattam.
Ennek ellenére ma már szerintem nem ez a célszerű. Nagyobb, komplexebb uC-k vannak, a programozók döntő többsége a hatékonyság érdekében már nem a hardver részleteinek megismerésével, regiszter szintű hardver kezeléssel dolgozik. Más emberek munkájára támaszkodunk, kész periféria könyvtárakat használunk. Nem a hardver regisztereket nézegetjük, hanem a könyvtárakat, API-t, kód generátort. C-ben, C++-ban, vagy akár python, java, feladattól függően.
Én is így gondolom. Mindenki használ könyvtárat, előre (maga vagy mások által ) megírt blokkokat. Nincs ebben semmi különös. Másoktól tanulni nem szégyen! Senki nem az alapokból rak össze egy programot, hanem tulajdonképpen legózik. Teljesen soha nem megyünk vissza a kályháig. És talán - hobbiként- nem is az a cél, hogy profi programozók legyünk, hanem kedvtelésből egy-két apróságot a magunk számára meg tudjunk csinálni.
Nulláról elindulva még csak nem is assembly nyelvvel kellene kezdeni.
Folyamatára, amit annyira hajlamosak vagyunk elfelejteni. A feladat megfogalmazása után szerintem alap egységekre kell bontani, "kiemelve"/elhatárolva döntéseket, elágazásokat. Utána jöhet a többi rész, egy processzor értelmi képességeihez idomítva. Pár év gyakorlattal el lehet jutni oda, hogy az általunk teljesen uralt szubrutinkészlettel komplex feladatokat is meg lehet oldani. A úgynevezett magas szintű nyelvek természetesen jól használhatók, amíg nem kerülünk közel a hardverhez. A funkciók nagy részét el tudja takarni a nyelv, és keretrendszere, de amikor bonyolultabb perifériát kell vezérelni, regiszterek tucatjait állítgatva, nagy hátrányt jelent a hardver ismeretének hiánya.
Mikor a PIC megjelent itthon, csak egy éktelen rossz assembler volt hozzá. Valamilyen más oprendszerre írhatták eredetileg, és átgányolták PC-re. Állandóan lefagyott, bizonyos kódméret felett rendszeresen elszállt. Ez odáig ment, hogy kénytelen voltam egy általános célú assembler szerkesztő programban megírni egy primitív fordítót. Lényegében egy macro gyűjtemény volt, az első PIC-eknek kb 40 utasításuk volt összesen.
Aztán a Parallax készített egy jó assemblert, majd némi késéssel a Microchip is. A szimulátor is elég kalandosan alakult. Eredetileg egy terminálban írogató szimulátort adtak hozzá, iszonyat kényelmetlen volt. Kb. úgy működött, mintha a GDB-t közvetlenül terminálból, parancsokkal vezérelnék. Aztán Rétallér Pista írt egy jól sikerült kis szimulátort, amit kényelmesen lehett használni. Majd jött a Parallax, végül a Microchipé.
Hobbielektronika: PIC kezdőknek.
Pl.: PIC18F27Q43: 128 KB programmemória, 8192 byte RAM, mai áron kb. 1100 Ft bruttó. Ebbe azért belefér egy-két nagyobbacska program úgy is, hogy nem ASM-ben van írva. A regiszterek ismeretével egyetértek, egyszerűen kell.
Jópofa ez a PIC18 mcu amit írtál. Érdekes/elgondolkodtató a Microchip árképzése, ez olcsóbb mint a legtöbb PIC16 mcu (a Chipcad-nál valami 711Ft br. az SOIC tok), és a tudása meg minden irányban sokszoros. Nyilván egy ilyen chipbe okafogyott ASM-ben fejleszteni , PC-re sem abban írja az ember a szoftver nagyját (bár vannak részletek a mai napig amikor kell).
Laja1: Idézet: „Senki nem az alapokból rak össze egy programot, hanem tulajdonképpen legózik. Teljesen soha nem megyünk vissza a kályháig.” Ez teljes tévedés, nincs királyi út. Egyrészt igenis sokszor kell visszamenni. Valóban legtöbbünknek, nekem is van bejáratott kódgyüjteményem, de egyesével magam írtam, vagy ha valami AppNote-bôl mazsoláztam, akkor lepróbáltam a mûködését, megértettem és felkommenteltem magamnak. A legózás a megúszásról szól nem a tanulásról-tudásról. Ez olyan mint a puskázás a suliban: ha nem tudsz semmit, akkor lehet neked egy novellára való puskád, akkor is megbuksz Idézet: „Senki nem az alapokból rak össze egy programot, hanem tulajdonképpen legózik. Teljesen soha nem megyünk vissza a kályháig.” Ez nem igaz, mert van legalább 1 kivétel, ... én Aritmetikai rutinokon kívül soha nem használtam semmi mást, sőt, volt, hogy még azt is én írtam, amikor 13 bites értéket kellett elosztani 5 bites értékkel, akkor a 16/8-as osztás helyett megírtam a sajátomat, mert pazarlásnak gondoltam Idézet: „A feladat megfogalmazása után szerintem alap egységekre kell bontani, "kiemelve"/elhatárolva döntéseket, elágazásokat” Pontosabban bármit csinálni akarunk, ez a létező legelső lépés! Amíg ez nincs meg, addig nem lehet megtervezni még áramköri szinten sem. Legalábbis jól nem. Én jelenleg pont ezért szívok a munkahelyemen. Egy komplett gépsor vezérlését készítem éppen. Azzal kezdték a főnökeim, hogy első lépésként (úgy, hogy nincs folyamatterv, nincs elektromos terv, gyakorlatilag csak egy körvonalazott elképzelés van) határozzam meg a kapcsoló szekrények méretét, a kezelőszervek mennyiségét és helyét. (Naná, hogy a tervezett szekrénybe nem fért bele a vezérlés.) Ezt követően tervezzem meg a vezérlést, hogy el tudják kezdeni a gyártást. Folyamatterv még mindig sehol! (Marhára boldog volt a vezérlés építője, mikor a kész szekrényen kellett módosításokat végeznie.) Majd közölték velem, hogy jó lenne, ha iparkodnék a program (azaz programok, mert 3 PLC van a gépsorban) megírásával. Ja, hogy folyamatterv még mindig nincs? Sebaj! Csiáljam programírás közben!
Lehet azért lettek ők a főnökeid , mert nekik sem ment a folyamatterv megalkotása
Véletlenül nem egy helyen dolgozunk? Az én főnökeim is ilyenek. Egyébként én gépész karbantartó mérnök vagyok.
Idézet: „Véletlenül nem egy helyen dolgozunk?” Nem valószínű. Nálunk rajtam és a kollégámon kívül még hobbi szinten sem konyít senki az elektromossághoz. Bár azt már megtanulták páran, hogy a fázis az ráz is.
Én is pont ilyen vagyok, és élvezem. A projektjeim túlnyomórészt időkritikusak, így assembly nélkül nem is igazán lehetne őket megcsinálni, csak erősen túlméretezett procikkal.
Csak érdekességként: 8085-tel kezdtem, és helyszűke miatt többször előfordult, hogy három bájtos utasításokat derékba kapott egy ugrás, ilyenkor kellett bűvészkedni, hogy ne legyen ebből baj. Továbbá kénytelen voltam használni a 8085 nem publikus, de jól működő utasításait is... Ezért vagyok bitmixer
A Videoton VDT 521xx, ipari, sorozatban gyártott, igen sikeres terméknél is használtunk hasonló megoldást. Egy szurutinba két helyen lehetett belépni, funkciótól függően. A második belépési pont egy utasítás közepe, ahol a kétbájtos második fele egy NOP-nak felelt meg.
Könnyen el lehet képzelni olyan felhasználást, ahol a kontroller fizikai mérete korlát. Nem lehet nagyobbat betenni egy nyolclábasnál, de a program nem fér el a rendelkezésre álló ROM memóriaterületen, ha "magas szintű" programnyelvet használunk.
Mindenre van magyarázat és az ellenkezőjére is.
Lehet mutogatni hogy kinek mekkora csak éppen a lényeg mellett siklotok el: Hobbielektronika, PIC kezdőknek téma.
Az nem hobbi témának minősül, hogy egy áramkört a lehető legkisebb méretben készítsünk el? Az sem kifejezetten a hobbisták jellemzője, hogy ágyúval lövik a verebet, és egy tenyérnyi lapra készítenek el az áramkört. A hab a MicroChip tortáján, hogy az újabb kontrollerekhez már valószínűleg új programozó (Pickit4) kell.
Kezdőnek, tanulásra, a processzorok, kontrollerek lelkivilágát megismerni nem olyan nyelv kell, ami eltakar mindent. A hozzászólás módosítva: Jan 28, 2022
Ha már hobbi meg "olcsóság", meg szimuláció: pl. Proteus-ban szimulálható a PIC16C62B (so28), ami ugyan OTP tok (egyszer írható), viszont Lomex-ben bruttó 100Ft alatt van ha egy csíkot (27 db) vesz valaki, ez kb. két 555 ára. És a PIC16F72A-val kódkompatibilis (kivéve A/D), tehát élôben is be lehet járatni a programot próbapadon. A véglegesbe meg mehet az OTP, és örülés van.
|
Bejelentkezés
Hirdetés |