Kösz az eddigi segítséget de nem tudnád leírni hogy miben is más, mert angolból nem vagyok valami erős sőt mondhatnám hogy angoltudásom 0

Hali
Ha esetleg a listat lathatnank tobbet lehetne mondani rola. Egyebkent a 12 biteseknel ASM-ben a
hasznalhato a tris allitasara, mert nincs fizikai cime a TRISGPIO regiszternek. Ugyanilyen az OPTION is.
Udv Vili

Valaki help,mert agybaj kapok. Nem akar működni a PORTA-m, hiába küldök rá valamit. Már írtam is rá egy egyszerű programot, de hiába,meg se nyikkan. Mi lehet az ok? Meghalt volna a picem?(pic16f88)

Szia!

Nézd meg konfigurációs szó beállításáat és az OSCCON regiszter leírását, mert gondosan beállítod a belső oszcillátor frekvenciát és a config szóban megadott oszciátor üzemmódot válsztod ki.
A 3. sorban movlw B'01100010' kellene...

Persze, ez jogos. Amúgy működik enélkül is a program
De alapvetően nem ez a probléma, hanem az, hogy hiába írok a porta-ra,nem változik meg a kimenet. Pedig ha mplab-ban a watch ablakot megnyitom, és megnézem a porta-t, ott jól írja, szóval ezért gyanakszom, hogy a picnek halott a porta-ja.

Most nézem, hogy bemenetként van konfigurálva a porta Csak már annyira tele volt az agyam 5 órányi programozás után, hogy nem sikerült észrevennem.

Hi!
Tudja valaki, hogy mi a különbség az A-ra végződő típusszámú, és az A-nélküli PIC-ek között?
(Pl. PIC24HJ64GP206A)

Én úgy tudom hogy az A-ra végződőek azok az eredetihez képest hiba-javított, újabb verziós PIC-ek.

A PIC24 és dspic33 mikrovezérlők első szériái elég gyalázatosan "sikerültek": sok volt a tervezési/vagy gyártási hiba (hosszú volt a hibák jegyzéke az Errata-kban) és alacsony az újraprogramozhatósági szám. Ezeken sokat javítottak az A szériában (de még nem eleget...), s talán a működési hőmérsékélet tartománya is szélesedett.

Ha rosszul definiálod, akkor tudtommal a szimulációban sem tudod módosítani a port értékét ( ilyenkor ne csak '1'-el próbáld !! ) !

Steve

Az A -ra vegzodoek a nonemuek (AndreA, SzilviA, KrisztinA), a tobbi pedig a himnemu (Peter, Zoltan, Andras)

Mondhattál volna Andrea, Petra, Krisztina és András, Péter, Krisztiánt

Na igen Meg meg azt is hozza tehetjuk, hogy ezek kozul a 10F, 12F es 16F-eket, szigoruan tilos ossze parositani, mig a 18F-et mar ovatosan, de lehet, azonban ilyenkor is a kapcsolodo labacskakra ajanlott vedekezo ellenallasokat helyezni

Bár itt most nem vágom, hogy pontosan mire gondolsz, de legalább egy kapcsolódó kép: Link

18F mar nagy koru... A kep nagyon jo

Új fejezetrésszel és mintaprogramokkal gyarapodott az esca.atomki.hu/PIC18 címen található, "Ismerkedés a PIC18 mikrovezérlőkkel" című PICCOLO projekt.

A kiegészült fejezet: I/O portok
A fejezet tartalma:
* Az I/O portok
o A PIC18F14K50 mikrovezérlő I/O portjai
o A PIC18F4550 mikrovezérlő I/O portjai
* Az I/O portok vezérlő regiszterei
* Az I/O portok programozása
* A ki/bement megosztása más perifériákkal
* Bemeneti szint megváltozásának jelzése
* A belső felhúzások engedélyezése
* Nyomógombbal vezérelt bemenet kezelése
* Mintaprogram: LED vezérlése nyomógombbal I. (nyomógomb pergésmentesítése)
* Mintaprogram: LED vezérlése nyomógombbal II. (állapotgépes megközelítés)
* Egy összetettebb feladat: LED vezérlése nyomógombbal és kapcsolóval (állapotgépes megközelítés)
* A PIC18 mikrovezérlők RESET áramköre
* Mintaprogram: A RESET, Sleep és WDT kipróbálása

Ugyanott elérhető a PIC18 támogatói programkönyvtár és a példaprogramok Doxygen-nel dokumentált gyűjteménye (verziószám 0.26, kiadási dátuma 2010-06-10).

Letöltések: code_examples.zip

A támogatói programkönyvtárban most csak apró változások vannak, melyet a dokumentációban található Változások jegyzéke foglal össze.

Az új fejezet mintaprogramjai a PIC18F14K50 és a PIC18F4550 mintaáramkörökre egyaránt lefordíthatók (a forrásfájl ugyanaz de van mindkét MCU-hoz projektfájl).

Eszmeletlen jo anyag! Lassan azt hiszem ez lesz a Magyar referencia anyag, ahonnan a kezdok kiindulhatnak. Gratulalok!

Gondolod el fogják olvasni?

---

Ettől függetlenül én is gratulálok icsernynek

Hali. Esetleg valaki rá tudna nézni a kódomra? Érdekes módon ha csak karaktereket akarok kiírni az működik, próbáltam egyedi karaktert csinálni de azt nem akarja kiírni a képernyőre valamiért. Ha esetleg valaki megtudná nézni megköszönném.

A main részben:
lcdWrite(CMD_REG,0x40);
lcdWrite(DATA_REG,0x04);
lcdWrite(DATA_REG,0x0E);
lcdWrite(DATA_REG,0x0E);
lcdWrite(DATA_REG,0x0E);
lcdWrite(DATA_REG,0x1F);
lcdWrite(DATA_REG,0x00);
lcdWrite(DATA_REG,0x04);
lcdWrite(DATA_REG,0x00);

Ha viszont csak egy karaktert akarok kiírni: lcdWrite(DATA_REG,'C');

Ez működik de az egyéni nem .

Szia!



Az első sorral az LCD-t a karakter generátor memória elérésére kapcsoltad át. A végéről hiányzik egy

amivel a kijelző memóriára kapcsolnál vissza.. Ezután már jöhet a

Szia

Lehet én fogalmaztam rosszul. Amit szeretnék hogy egyedi karaktert kiírni a kijelzőre. Na sajnos ez nem megy nekem . Minden mást ki tudok írni de egyedi karaktert nem tudok összerakni.

Konkrétabban fogalmazva a következő oldalon lévő csengő ikont akartam kiiratni:
http://www.8051projects.net/lcd-interfacing/lcd-custom-character.php

Ez nem megy az istenért sem. Minden más karaktert (pl.: A,B,C,D,....) kitudok iratni viszont pixelekből nem bírok kirakni semmit. Mit rontottam el? Elméletileg az első sort lcdWrite(CMD_REG,0x80)-ra kell lecserélni a 40-ről?

Köszönöm a segítséget.

Hello!
Látom tolmács kell..
Az első sorban, a "CMD_REG,0x40"-el, átváltottál, a CGRAM első byte-jára. Így a következő adatok, oda fognak töltődni.
Viszont, amikor betöltötted a csengő bitmintáit, ezt követően az adatáramlást, vissza kell váltani, a DDRAM-ra, hogy a következő adatok, már a kiírásra kerüljenek. Ehhez kell, a "CMD_REG,0x80"-as parancs.
Tekintve, hogy a CGRAM első karakterét töltötted fel a bitmintával, ennek ASCII címe "0x00". Ha ezt a csengő (User) karaktert ki akarod írni, akkor adatként a "DATA_REG,0x00"-val hivatkozol rá.
Tehát amit HP41C írt neked, az kell a kis programod végére, majd próba kiírásként kiírja a Display első karakter helyére a "C" betűt, majd a második helyre, a csengődet. (Persze ha a kiírás inkrementálása be van kapcsolva)
üdv! proli007

Reggel egy másik topikban már felhívtam a figyelmedet erre a beírásomra, de most Hp41C-től is megtudtad: nem lecserélni kel, hanem a grafikus karakter definiálása UTÁN kell egy lcdWrite(CMD_REG,0x80); paranccsal visszaálítani a címet, s ezt követően tudod használni az általad definált karakter(eke)t.

Naivan reménykedek benne - már csak azért is, mert kevés ehhez hasonló, jól összeszedett anyag van magyarul, a kellemes design és a sok ábra, mintapélda azt az érzést kelti bennem, hogy valóban az oktatás a cél; ráadásul sokszor egy-egy fejezet újraolvasásánál mindig találok benne valami újat ( persze ez lehet az én hibám ). Köszönöm és kitartást, erőt a folytatáshoz!

Nézem, hogy a C18 fordító mit művel az interruptok kiszolgálásakor. Feltűnt, hogy a logikusnak látszó regisztermentéseken kívül elmenti FSR2H értékét is (ez a veremkeret mutató magas helyiértékű fele), valamint a szoftveres veremmutatón is léptet még egyet:


Érti ezt valaki, hogy mire jók ezek a lépések?

Fentieket a Stack Model: Single-bank model beállításban tapasztaltam. Ha átkapcsolom a fordítót Stack Model: Multi-bank modelbe, akkor viszont FSR2H mentése már nem kerül bele a kódba. Ennek nem fordítva kellene történnie? (Számomra legalábbis logikusabbnak tűnne FSR2H mentése, ha a verem kezelésénél laphatár-átlépés is várható...)

A megszakítási rutinból hívsz-e függvényt?

FSR2 az nem a frame pointer? FSR1 pedig a stack (ez utobbi latszik is a kodon amit beideztel). A kovetkezo kerdes pedig, hogy a multi bank modban vajon hasznal-e frame pointert?

Nem.

De igen, azért hívják veremkeret mutatónak.
A megszakítási rutin szerintem nem. Függvényhívásnál van szerepe, lokális változók bázisrelatív címzésénél. Bővebben: Link

Azonban ha nincs laphatár átlépés, akkor FSR2-nek elég az alsó felét elmenteni a verembe.

Csak amiatt kerdeztem, mert nem tudom a C18-ban hogy van megoldva, csak remlett, hogy az FSR2 volt a fram pointer.

Viszont a frame-eknek nem feltetlenul kell a stack-en lennie (en epp emiatt nem hasznalom a stack-frame kifejezest, mert az csak es kizarolag a stack-en megvalositott frame-ekre vonatkozik). Tehat a heap-en barhol lehet a frame-ed, az a comilertol fugg, hogy heap vagy stack ahova helyezi. Prologue es epilogue rutinokbol ki kell derulnie, hogy mit muvel ilyenkor, de gyanitom ha egyetlen bank-on van a stack (merthogy azt kerted), akkor nem a stack-re helyezi a lokalisokat, azokat fenntartja a fuggveny parameterek es kontextus mentes szamara. Ezzel novelheto a beagyazasok szama -- de ez csak spekulacio, nem neztem most bele a C18-ba, hogy pontosan hogy csinalja.

Az interruptnal meg termeszetes, ha nem hasznal frame-eket, mivel ott nem reentrans a kod (elmeletileg), igy a valtozok statikus helyen lehetnek, amivel nemcsak a pologue-epilogue szakaszok lesznek kisebbek, de a valtozo hozzaferesek koruli kodreszletek is csokkennek.

Amugy nagyon sok olyan PIC C firdito van ahol pseudo-stack-et hasznalnak, es akkor a nem reentrans fuggvenyeknel az osszes lokalis overlay teruletre kerul -- termeszetesen ugy kioptimalizalva, hogy a leheto legkevesebb helyet foglaljon az overlayed terulet. C18-nal ha jol emlekszem csak akkor tortenik valami hasonlo, ha overlay kulcsszoval kenyszeriti ki ezt az ember.

Valamivel érthetőbb lesz a dolog, ha egy (auto) lokális változót is definiálunk:


Ekkor kiderül, hogy az ISR mégis használja az FSR2 veremkeret mutatót a lokális változó(k) elérésére!

(remélem, hogy nem írtam el semmit...)

Talán a fentiek kioptimalizálatlan csökevényei lehettek a korábban nem értett (és szerintem teljesen fölösleges)

sorok!