Érdemes elolvasni. Működik... Ajánlom az MpLab Szimulátor használatát.

Pl. egy adattábla áttöltése ROM-ból RAM-ba rendkívül egyszerű és hatékony PIC24-en:

Ha mar 16 bites chip-et hasznalsz, miert nem C-ben programozol? Erre a chip-re egesz jo kodot general a fordito.

1.) Mert nem szeretem a C nyelvet.
2.) Mert az Assembly kód pont azt (és úgy) fogja csinálni, amit (és ahogy) én akarok.
3.) Mert ezen a mikrovezérlőn a legjobb Assemblyben programozni. ...és én szeretek Assemblyben programozni.

Én "leragadtam" a 18F-nél, bár szerintem fényévekkel jobb, mint a 16F. Relatíve elég sok új utasítás jelent meg, ami megkönnyíti az ember dolgát.
A 8 bitnél nagyobb PIC-ekre meg már tényleg valami magasabb szintű nyelven érdemesebb programozni. Bár ha továbbhaladok, asm nyelvvel szeretnék szintén kezdeni, mert anélkül csak a sötétben fogok tapogatózni, ha valahol gebasz van a C-nél.
Egy-két projectet csináltam már C-ben PIC-re, de sajnos nincs meg benne a megfelelő rutinom. Többször volt már olyan, hogy egy feladatnál C-ben elakadtam, aztán fogtam az egészet, és inkább átírtam asm-re, mert az csuklóból ment.
Viszont a C-ben az a jó, hogy nem kell szórakozni az átvitelekkel (8 bit esetén ugye a 255-nél nagyobb számok..), ott már vannak típusok, nem kell szórakozni a memória határokkal (ROM/RAM), és egész hatékonyan tud osztani. Ja meg a bonyolultabb perifériákat könnyebb kezelni (pl. USB). Na meg úgyahogy, de platformfüggetlen.

Srácok, van egy kis problémám.
Egy t6963c GLCD sebességén szeretnék javítani, de nem tudom, hogy miképpen fogjak hozzá.
Jelen pillanatban ott tartok, hogy már nincs semmilyen késleltetés a programomban és az SPI sebességem maximumra húztam ami 4MHz. (PIC-em 64MHz-en ketyeg)
Egy MCP23S17-es portbővítőn keresztül kezelem a kijelzőt.
Az MCP kezeléséhez függvényeket készítettem és azokat makrókon keresztül érem el.
Egyszer mint ha Hp41C mondta volna, hogy a makrók lassúak, lehetséges, hogy ha a makrókat elhagynám (átírnám a program ezen részét) még gyorsulna a téma?

Videó a konkrét problémáról: Bővebben: Link

16F628A-val dolgozok jelenleg. Igaza van Hp41C-nek, működik az rendesen, csak tudni kellene, hogy mi, miért történik úgy ahogy történik. Azért mert elsőre nem megy, még nem fogom feladni.

Nos annyit még teszteltem, hogy a makrókat kivettem, de ez nem hozott eredményt.
Lehetséges, hogy a portbővítő miatt már nem tudok rajta gyorsítani?

Az a baj, hogy ez a GLCD 24 lábú és ebből a minimum amit be kell kössek a PIC-re az 12-14 láb.
Szóval kell a portbővítő.
Mondjuk azt még nem próbáltam, hogy közvetlen a PIC-ről hajtom, de pont az lenne a lényeg, hogy ezt elkerülhessem.
Vélemény?

Szerintem tuti a portbővítő miatt van. Bár én azért kipróbálnám direkt a PIC-ről is.

Egy masik PIC, ami csak ezzel a kijelzovel foglalkozik. Jobb kijelzo. Jobb PIC.

Milyen nyelven irod ?

Még is próbáltam már csak másik PIC-en.
18F4550-en próbáltam direktben is, legalább is a programok szerint mert megtaláltam.
Azt hiszem itt még sem vagy is nem csak a portbővítő lesz a ludas, hanem az, hogy a kijelző teljes felületét rajzoltatom.
Bár már a videón látható sebesség elfogadható, akartam még rajta kicsit javítani, de úgy veszem észre az elérhető sebességet elértem, ha a teljes GLCD felületet nézzük és telibe rajzoltatok.
A megoldás inkább a vonalas keretek kirajzolása lesz, azt most kipróbáltam, egy szempillantás alatt kirajzolja.. Vagy egyszerű keret, vagy kompromisszum a sebességgel.
Az a baj, hogy a grafikus részének törlésénél ez a gond még jelentkezni fog, mert ügye itt a szöveges és grafikus rész külön van... No majd kialakul.
Ha van ötlet ettől független a gyorsításra, szívesen veszem..

Aham, ez sem rossz ötlet, csak most nem áll rendelkezésemre jobb vagy gyorsabb PIC mint 64MHz.
És az a baj, hogy ha külön PIC-ről hajtanám a kijelzőt akkor a két PIC közti kommunikációval lenne küzdés.
Bár ott is élhetne az SPI, de csak feleslegesen megbonyolítanám az egészet.
C nyelven írom a progit. C18

Ha meg tudod oldani, csak azt rajzoltasd ki, ami változik.

Ez persze megoldható, bár gondolom itt azt akartad mondani, hogy azt rajzoltassam ki ami nem változik..
A hátteret egyszer akarom betölteni, de majd tervezek a programon belüli váltásokat amelynél más-más lesz a háttér.
Itt majd még agyalnom kell mert lehet egy kaptafára kellene csinálnom és akkor csak szöveges rész változna, az meg viszonylag gyorsan pörgeti.
Át kell gondolnom ezt az egészet, mert utólag nehezebb lesz vele..

Mármint amikor írsz/rajzolsz az LCD-re, csak annyi adat kerüljön kiküldésre, ami az előző állapothoz képest változik. Pl. ha egy kép közepére akarod kiírni a pontos időt, akkor ne rajzold ki mindig a képet, elég csak a pozicionálni, és kiírni az időt. Ez lehet debil példa volt, de a lényeg érthető.

A C azert szerinted nem lassit rajta?
Mert szerintem NAGYON. Teljesen azonosulni tudok Zsora lenti soraival. Magasszintu nyelv, mert az gyors es hatekony(?) aztan rajovunk, hogy ehhez 200MHz-es PIC kellene.
Minden egyeb makrozas, szubrutinozas, etc. csak ront a helyzeten.
Ha vannak valtozoid, probald meg minel egyszerubbkent megadni. Pl. x,y koordinatat nem kell lebegopontosban, ahol eleg egesz kerekites, oda siman mehet 16 vagy 32 bites egesszam, ahogy a helyzet megkivanja, stb.
Esetleg assembly betetek alkalmazasa az idokritikus reszeknel.

A rajzolorutinokat ki irta? Vagy siman valami library import, azt' hadd szoljon?
Mert pl. vizszintes vonalakat sokkal egyszerubben is lehet huzni, mint pontonkent kirajzolni, ugyanigy a fuggolegeseket, stb,stb.

Ja igen, így már értem mire célzol, termesztésen ez így is van most is..
Azért köszi..

bbalazs_: Igen ez biztosan lassíthat, már mint a C nyelv, de ezt tudom, ASM-et nem kezdem el, elég ez is, még
A rajzoló progikban nagy segítségemre volt egy CSS fájl ami alapján én írtam meg őket, vagy is nagyobb részt én írtam meg mert nem voltak jók, de törekedtem a minimális forrásra.
Így sem egyszerű
Tudok keretet, dobozt, vonalat húzni egyszerűen, szóval menni fog, ha más nem akkor így..
Köszi srácok, azt hiszem ezekből már tudok valamit kezdeni..

16F-en, hogy tudom legegyszerűbben megcsinálni, hogy megvizsgálom PORTA,1 bitjét és ha az 1 akkor legyen 0 és fordítva. Fontos, hogy a változtatás csak ezt az egy bitet érintse!

Ott a pont!
Én is azért programozok asm-ben, mert a gépi kódhoz az áll legközelebb, a PIC jobban érti, és mivel nem előregyártott függvényekkel dolgozom, nincs benne semmi fölösleges.
Hogy mindenki értsse mire gondolok:
Egy ismerősöm C-ben írt egy programot, ami egy potit olvasott be. 1V-os jelnél behúzott egy relé és indult egy másik kimeneten egy PWM jel a poti állásával arányosan.
Ez a progi fordítás után 276 soros lett.
Én ugyanezt megírtam assembly-ben, és fordítás után 50 sor lett. Tehát a C nyelv 226 fölösleges sort pakolt a programba. Egyértelmű tehát hogy a program futása 5x lassabb C-ben. Több a hibalehetőség. Nagyobb programoknál elfogy a memória. Mindehhez, ha egy C progit utólag bővítünk, még akkor is összeborulhat a program, ha a bővítés maga csak egy mellékszál lenne.

Hát erre is jobb lenne 18F mert ott letezik a BTG (bit toggle)parancd de szerintem 16f re így lenne a legegyszerűbb:

Idézet:
„Ez a progi fordítás után 276 soros lett.
Én ugyanezt megírtam assembly-ben, és fordítás után 50 sor lett. Tehát a C nyelv 226 fölösleges sort pakolt a programba. Egyértelmű tehát hogy a program futása 5x lassabb C-ben. Több a hibalehetőség.”

Ez azért nem teljesen így van... A C-ben a változók átadása pl. veremtáron keresztül történik, ezért szükség van bizonyos "alapmemóriára" és a hozzátartozó programkódokra. Ezért lehetett pl. 5x-szörös kódméreted. Viszont ezt nem futtatja folyamatosan, hanem csak inicializáláskor például, így a futási sebességnél nem igaz az 5x-ös viszony! Fordítási opciókkal, fordítási szintekkel és a program kialakításával ez még lényegesen csökkenthető lehet. A C-vel sokkal áttekinthetőbb programot lehet írni, kezdők is gyorsabban eljuthatnak vele egy bizonyos szintre viszonylag könnyedén... Természetesen nem látsz teljesen mögé, de a megfelelő dokumentáció ( fordítóra vonatkozó !) birtokában nagyon jól kézben tartható ! Egy bonyolultabb program megírásánál ( bár én is írtam már több ezer soros programot is asm-ben ) ezért szokták a C-t választani, persze az időkritikus részeket asm-ben írják meg!

Én is ilyesmire gondoltam de nem voltam biztos benne hogy ez a többi bitet nem változtatja meg.

Ez nem változtatja meg, de a PIC RMW ( Read Modify Write ) végrehajtása változtathat rajta, ezért utalt a kolléga az árnyékregiszterre ( LAT ) !

Rendben, de 16F-en nincs olyan.

Nagy dilemma: ezeket a mikrovezérlőket már élvezet assembly-ben programozni, ugyanakkor valóban logikusabb C-ben dolgozni.

Na igen, ez olyasmi, mint a hardver résznél az építés öröme (vs. boltban megveszem olcsóbban).
Közben most nézem, a 16 bites PIC-eknél (vagy legalábbis amit az előbb néztem) van hardveres osztó.

Tudom, de csinálni kell ...!

Veszel egy regisztert (elnevezed pl. LATB-nek !) és minden PORT írást ezen a regiszteren végzel ( mint a 18-asnál!) és megszakításból kellő gyakorisággal ( pl. 5-10 ms!) átmásolod az egészet a példa szerint a PORTB-re ! Máris van "LAT"-od !

Így elkerülheted az RMW problémát ( ezt hívják árnyékregiszternek ! )

Vagy minden művelet elvégzése után. A lényeg, hogy a másolás movwf utasítással írja a PORTx -et.
A 12F1xxx, 16F1xxx sorozatoknál van LAT regiszter, de másik bankban...

pl:

Szia Hp41C!

A cikkedben leírt "nagy táblázatok kezelése" részt szeretném alkalmazni és egy apróság hibádzik. Mégpedig, hogy a címszámító rutin elején növeli a címet, így a beolvasáskor a 0 címen lévő karaktert kihagyja. Az első futáskor ki tudtam küszöbölni azzal, hogy egyszerűen átugrottam, de mivel a rutint többször is használnám, ez nem jó, mert csak az első alkalommal kéne átugrani, különben elcsúszik az egész. Van erre ötleted?