PIC16F876A ja LCD

[6p45s]

Vs: PIC16F876A ja LCD

Mina sain asjast aru sedasi, et library-faili kogutakse kõik vastavatest .asm-failidest saadud objektifailid. Seega ainult Processor.asm muutmine ilma library ehitamiseta LCDlib.lib-i ei tohiks mõjutada.

[6p45s]

Vs: PIC16F876A ja LCD

Library-failiga sain hakkama.

Nimelt peavad kõik .asm ja .inc failid asuma samas kaustas, muidu osasid neist ei leita. Alustuseks valisin Build....MPASM/C17/C17 Suite alt Build Normal target (invoke MPLINK) - tekkisid objektifailid ja seejärel samast kohast Build Library target (invoke MPLIB). Objektifaile projektile eraldi lisada pole vaja ning .lib faili nimi on sama, mis projektinimi (nagu .hex-faililgi).

Library-t projektis kasutades pole selle nimi vist oluline, veatedet igatahes ei tekkinud ja .hex sai ka valmis. Praegu LCD-d veel tööle ei saanud, ilmselt miski viga koodis.

[6p45s]

Vs: PIC16F876A ja LCD

Nüüdseks on õnnestunud ka 16x1 ekraan tööle saada. Kontrolleri seadistamisel oli ADCON0-register märkamata jäänud.

8x2 ekraan kahjuks ei toimi, loodetavasti peitub viga tarkvaras. Näiteks esimese rea alguse aadress ei vasta 16-märgilise esimesele numbrikohale? Hoiatavaks märgiks on 3. klemmi pinge mõju puudumine ekraani kontrastsusele. Samuti ei teki tähemärkide alade tumenemist, kui toide sisse lülitada. Ekraani margiks on WC0802C, juhtlülitus peaks ühilduma HD44780-kontrolleriga, seetõttu peaks 4-bitilise andmesiiniga töötama.

Ekraan on ühendatud õigesti, kuid kontrollin veelkord üle.

Täienduseks eelmisele postitusele - library-fail tekib ka siis, kui valida kohe Build library target.

[felch]

Vs: PIC16F876A ja LCD

Tume riba peaks ikkagi tekkima kui vaid ekraan õigesti ühendet on. Esimese rea aadress on enamasti kõigil ekraanidel sama, edasised võivad varieeruda. Eriti read üle 2-e.

[6p45s]

Vs: PIC16F876A ja LCD

Koodi tükeldamisega eraldi failideks sain hakkama. Tekkis uus probleem - kuidas tekitada ümberpaigutatavas koodis (ingl.k relocatable) globaalmuutujad? Oleks tarvis ühes alamprogrammis arv BCD-ks teha ning teises numberhaaval ekraanile kuvada.

Direktiivi udata abil erinevates alamprogrammides 2 muutujat sama nimega deklareerides ei õnnestunud muutuja väärtust üle kanda. Microchip´i dokumendist DS33014J (assembleri, linkeri ja librarian´i kasutusjuhend, asub firma kodulehel) lahendust ei leidnud.

Paar tähelepanekut:
- põhiprogrammi tsükli lõpus väljakutsutav eraldi .asm failis paiknev alamprogramm peab sisaldama käsku return enne käsku end-i. Vastasel juhul tekib MCU reset.
- Põhiprogrammi alguses tuleb deklareerida reset-vektori asukoht, näiteks nii (Start on põhiprogrammi alguses paiknev silt):

RST code 0x00
pagesel Start
goto Start

kui pagesel puudub, programm mikrokontrolleris ei tööta.

P.S praeguseks kasutan juba MPLAB v_8.00

[felch]

Vs: PIC16F876A ja LCD

Vahest oled juba lahenduse leidnud kuid...
included alguses faili, kus lisaasjade mälujaotus kirjas:

    INCLUDE <MATHVARS.inc>        ; PIC18 math library definitions

ja

;;;;; MATHVARS.INC ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 2001.09.07 ;;;;;
;
;   Memory: Data 29
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
RAMbase         equ     0x20            
        cblock    RAMbase  
        AEXP                    ;AARG
        AARGB0
        AARGB1
        AARGB2
        AARGB3
        AARGB4
        AARGB5
        AARGB6
        AARGB7;28
; jne

Põhikoodi mälujaotus peab include-faili oma arvestama!!!
Kui viitsib uurida, võin saata koodinäite.
16-seeria PICil on jah igavene häda registripankade lülitamisega. Pidevalt pole vaja teha kuid pead pidevalt jälgima, kus pangas oled ja kuhu jump'id.
Soovitaks kasutada 18-seeriat, kus seda jama enam ei ole. Peaaegu, et odavamadki. Ressurssi ja mugavust tohutult rohkem!

[6p45s]

Vs: PIC16F876A ja LCD

Mälu jaotamise .inc-fail on päris huvitav lahendus, samuti universaalne. PIC16F690 mälu on jagatud 4 pangaks, seega pole pankade valik eriti problemaatiline. Hetkel kasutan nimetatud kontrollerit, kuna see sisaldus PICkit2 koosseisu kuuluval arendusplaadil ning lisadest (A/D-muundur, taimerid, katkestused jne.) pole veel kõiki jõudnud rakendadagi. PIC16F84 plaat tuli kõrvale jätta, kuna väline (HS-)ostsillaator muutis ICSP toimimise Ponyprogi kasutades ebastabiilseks ning PICkit2-ga õnnestus programmeerimine vaid 1 kord mitmetunnise katsetamise jooksul (arvutil puudub COM-port, USB-COM üleminekuga Ponyprog ei tööta). Samuti konutab keset makettplaati üks PIC16F877, kuid enne C-keelele ja in-line-assemblerile üleminekut soovin lihtsamat kontrollerit korralikult kasutama õppida.

O.T
Kas Midrange family järel poleks kasulikum üle minna otse dsPIC33-le?
Seniste projektide jaoks on PIC16Fxxx kohati isegi liiga hea ja keerulisemaid asju ainult assembleris teha tundub ajalises mõttes väga ebaefektiivne.

[murphy]

Vs: PIC16F876A ja LCD

Ja ongi ebaeffektiivne, kui tahad veel ebaefektiivsem olla võid otse hex faili kirjutada koodi. Ei pea jurama mingite mälupankatega, ja tegema muid assembleri lollusi, kõik tehakse sinu eest ära, seepärast ongi olemas selline keel nagu C. Korralikult optimiseeritud C on sama kiire kui asm. Olen kunagi ajanud C koodi asmi sest oli kiirust vaja aga avastasin pärast et töö hulk oli meeletu ja selle raha eest oleks saanud palju parema MCU. Samas ma ei väida et asm on mõtetu, sobib väiksemate asjade tegemiseks nagu näiteks ledide vilgutamine serial terminal ja ISR kui viimane pole liiga suure koodi mahuga . Lisaks pole asm protable ühelt proselt teisele.

[andreie]

Vs: PIC16F876A ja LCD

Murphyl on õigus.

Minu jaoks rusikareeglid:
* üksikeksemplaride puhul pole erilist mõtet valida minimaalset võimalikku mikrokontrollerit -- õigem on valida see, mida on kõige lihtsam progeda.
* tasub keskenduda ühele mikrokontrollerile ja kasutada teda n.ö. universaalse tööriistana -- sest erinevate kontrollerite vahel pendeldamine on tülikas.

Vahest on endalgi kiusatus suruda projekti sisse ATmega88 asemel poole väiksema flashiga ja veidi odavam ATmega48, aga milleks

[KaruTEC]

Vs: PIC16F876A ja LCD

Minu kogemus - hinda vajalikku mälumahtu ja kiirust ning korruta VÄHEMALT KAHEGA. Teha progist, mis kasutab 85% prosest, on intellektuaalselt huvitav, kuid majanduslikult lollus. Erandiks on tõesti mõni hästi lihtne single-task soft mida täiustada pole vaja.

[murphy]

Vs: PIC16F876A ja LCD

See on nagu FPGA puhul, võtad suurema mahutavusega kivi kui arvad et vaja läheb ja kui asi on in production, optimiseerid ja võtad kivi kuhu su kood sisse mahub. Sest aeg on 2x raha, üks on töö aeg ja raha mida töö eest makstakse ja teine osa on kuna asi valmis saab tootmise jaoks. Viimane on tihti suurema hinnaga. Ka tootmise ajal saab optimiseerida ja asja odavamaks muuta sest iga prose tootja pakub saba pinoudiga sama jõudlusega väiksema mälumahuga odavamat kivi. Kuigi see on juba sentide taga ajamine aga suurte koguste korral on see suur raha. Kui on tõesti ainult mõned plaadid mille jaoks soft teha ka siis on odavam "rasiata" mälu C koodiga, sest 2x mälu suurus tähendab vast 10% hinnatõusu prosel aga progemis aeg on 2x väiksem. Olen näinud tootmises plaate mis protos omavad 8M muutmälu ja peale 4-5 REV-i mõne aasta jooksul on ainult üks 512K klots alles.