Valószínűleg nem tiltottad le a konfigurációs biteknél az alacsony feszültségű programozást (Low Voltage Programming).

Ismét C-s kérdésem lenne.
Van egy

változóm.
Két féle módon próbáltam feltölteni, és nem értem mi az oka a hibának. Csatoltam a két képet, amin az egyik beviteli mód mellett teljesen fals érték kerül a változóba. (PICKit2-vel debuggolva)

Az MC18-ban van egy eleg nagy hulyeseg, hogy a 255-nel kisebb szamokat char-nak kezeli (elojeles, tehat -127 - +128) es igy ilyen szamolasoknal problemazik.

Megoldas: Castolni kell:

unsigned long testLong;
testLong = 512 * (unsigned long)100;

Eleg gagyi az MC18, de oromhir, hogy a 16 es 32 bites MCU-jaihoz mar GNU C compilert hasznalnak

Megnéztem Hi-Tech féle fordítóval is, és abban is ugyanezt csinálja, tehát nem fordítóhibának néz ki. Gyanítom, hogy azzal függ össze, hogy a fordító alapból előjelesként kezel minden számot. Írd úgy, hogy 512U*100, vagy 512L*100, akkor azt kapod, amire számítasz.

Köszi, mindkettőtöknek, kipróbálgatom!

Az U és az L mit is jelent?
U=unsigned?
L=long?

És pontosan mire vonatkozik?

Kérlek magyarázd el, hogy ez mitől castolás, és egyáltalán mit is jelent a szó pontosan?

Az U betű egy szám után azt jelenti, hogy azt a számot unsigned-ként kezelje a fordító, ne az alapértelmezett signed-ként. Az L ugyanígy azt jelenti, hogy long-ként kezelje. Lehet a kettőt kombinálni is, tehát UL is állhat. Ez a rövidebb formája annak, amit trudnai írt. Tehát az (unsigned)512 és az 512U ugyanazt jelenti.

A castolás pedig valami olyasmit jelent, hogy kényszeríted, hogy másként kezelje azt a valamit, mint ahogyan azt alapból kezelné. Pl. azért hasznos, mert ha két 16 bites számot szorzol, akkor az eredményt alapból 16 biten kapod, így előfordulhat csonkolás. Ha viszont az egyiket castolod 32 bitesre, akkor már 32 biten kapod az eredményt. A fenti (unsigned)512 is azt kényszeríti ki, hogy unsigned-ként kezelje az 512-t, ne signed-ként. De a castolás használható változókra is. Van két unsigned char változód (valt1, valt2), amiket ha direktben összeszorzol, akkor csak 8 biten kapsz eredményt. Ezért azt kell csinálni, hogy legalább az egyiket castolod 16 bitre, és akkor 16 bites eredményt kapsz: ((unsigned)valt1*valt2)

Ez utóbbi mutatványról volt szó itt nemrég, hogy két 8 bites szám szorzásakor a C18 fordító nem generál elég optimális kódot. A tényezők castolása nélkül jobb kódot lehet kapni:


A tényezők castolása helyett van benne pointer castolás, hogy szebb legyen az élet

A castolás az, amikor egy kifejezésnek a típusát direktben megmondod.

Jelen esetben a kifejezés, amire vonatkozik, az a "100" konstans, és a castolás annyit mond a fordítónak, hogy ezt a konstanst mindenképpen "unsigned long" típusúnak értelmezze. Ez azért jó, mert a fordító az operandusok típusától függően fordít ugyanahhoz a művelethez (most éppen a szorzáshoz) különböző kódokat. Az operandusok közül ráadásul a legbővebbhez igazítja a többit, azaz mivel már egy long szerepel a műveletben, így az 512*100 szorzást long-okkal fogja elvégezni.

A potyo által lentebb írt L és U utótagok a konstansok castolását szolgálják (azt nem tudom, ez minden C-ben szabványos-e), és pont olyan jelentéseik vannak, mint ahogy azt írtad is.

(Remélem, nem írtam nagy hülyeségeket)

Srácok!

Miért van az, hogy egy nyavalyás karakteres LCD egyszer rendesen inicializálódik 2 soros üzemmódban, de néha-néha csak egy sorosban marad!
Így próbálkozok, mit javasoltok?

A meghívott függvények megbízhatóan működnek, itt csak valami elrendezésbeli probléma lesz, a legelején mit szoktak többször kiadni?

Kotorj rá a HD44780 pdf-jére a guglin, és nézd meg az inicializálási szekvenciát! Le van írva folyamatábrával 4 és 8 bites üzemmódra is, benne vannak a kivárandó időzítések is. Én aszerint szoktam csinálni és nem szokott gond lenni vele.

Tessék időzítgetések helyett busy flag-et vizsgálni!

Ennyi az egész, amit az LCD-vel csinálsz? Ebből nem lehet megmondani, hogy mi a probléma. Az ilyen gyári függvények miatt írtam saját függvényeket az LCD kezelésére. Azokat tudom, hogy mit csinálnak. (ha valakit érdekel, feltöltöm valahová)

Nekem akkor volt ilyen, amikor nem vártam eleget az LCD inicializálásával a kontrollerben. Amíg az LCD saját, reset utáni inicializálása nem fut le, addig nem hallgat a külső parancsokra. Vagy többet kell várni, vagy figyelni kell az LCD Busy Flag-jét. Én úgy oldottam meg, hogy amit lehetett az LCD inicializáló függvény elé tettem, így már eleve későbbre került az inicializáló rutin, valamint ezután még várok a Flag-re.


Topi: kösz a javítást.

potyo, szilva!
Köszönöm a kiegészítést, tiszta és világos!

Egy kis szívást elmesélek "hálából".
4 napja nem jöttem rá, hogy az SD inicializálás miért nem működik stabilan. Egyszer minden lefutott hiba nélkül, másszor nem. A hiba egy forrasztás volt az SD foglalaton. Azért szívatott napokig, mert amikor betoltam a kártyát, akkor nyomtam a foglalatot, és akkor érintkezett a láb, aztán miután elengedtem már nem, ezért a további parancsok nem működtek. Azt hittem program hiba.

A másik, hogy sok kezdő azt hiszi, a C könnyű, ezért azzal kéne kezdeni. Itt jelzem mindenkinek, hogy az ASM sokkal egyszerűbb és áttekinthetőbb. Legalább is nekem biztosan. SD-t is fele ekkora gőzzel sikerült megirnom korábban. De azért most már kezd összeállni a kép, hála trudnai, potyo, és szilva segítségének!

Ha jól tudom, nemrég óta a Tartalomszerkesztő részben (ahova cikkeket, kapcsolásokat is fel lehet tölteni), ott van egy Kódfeltöltő részleg is. Ha megjelenik nálad, bátran használd!

Uraim,

Tisztában vagyok az inicializálási szekvencia menetével, nem ez az első LCD, amit használok a _saját_ függvényeimmel, t. potyo, én is tisztában vagyok lépésről lépésre az assembly utasításokkal, már többször is felülvizsgáltam hibakeresésnél a disassembly listing-et.
A busy flag-et azért nem használtam soha, mert párszor megszívtam, egy olyan utasítással: hogy while(~BusyFlag); oszt egyszer csak lefagyott a kijelző, meg a uC is.
Várhatok inicializáláskor több mp-et is, a jelenség ugyan az! Érdekes módon csak akkor jelentkezik, ha tápon marad a kijelző, és úgy kapja újra az inicializáló parancsokat.

Ha megnézed a doksiban az init folyamatot, akkor abból láthatod, hogy nem elég egyszer kiadni a mód parancsot. Mellesleg pont akkor nem elég, ha már valamilyen módba fel van inicializálva a kijelző. Nem véletlenül van ott (látszólag tök feleslegesen) háromszor egymás után a mód parancs kiadása.

Egyáltalán megnézted Te a doksit? Mert a kódrészlet, amit beidéztél, az köszönő viszonyban sincs az abban leírtakkal...

Akkor mutasd meg a Listing-et, mert valamit elnézel. Ennek működnie kell minden esetben.



Ezt is ki lehet küszöbölni. A ciklusban léptetni egy számlálót, ha az leért nullára, akkor is továbblépni, vagy resetelni a kijelzőt, stb.

Ez igy nem korrekt szerintem, valoszinuleg while(!BusyFlag); megfelelobb lenne. De ahogy potyo is mondja kellene timeout, pl:

for(i=1234; i && !BusyFlag; i--);

Vagy timert felprogramozni es ott csinalni valamit...

Köszönöm szépen a segítséget a jelen lévőknek, a kis ördög egy részletben rejtőzött, amire szilva hívta fel a figyelmem.
Kiadtam én 3-szor a lcd_sendnibble(0x02); -et egy delay-et közöttük, de arra nem gondoltam, hogy 3 nibble az csak másfél parancs, szóval kellett volna 6 nibble, azaz így:


Köszönöm potyo és Topi segítségét is, de szilvát jutalmaznám most.

Igaz a timeout-os busyflag vizsgálat is egy megoldás, a csak úgy írtam, beolvasni egyébként is az input() fgv.-nyel kéne.

Rendben, csak a logikai operatorokat es a bitmuveleteket nem szerencses keverni mert problemahoz vezet - nyilvan tudod, csak azok kedveert akik esetleg most ismerkednek a C nyelvvel: '~' az negalas, azaz az osszes bitet negalja, avagy COMF utasitas, mig a '!' az logikai NEM operator.

Igen, értelek, de mivel az input() függvény 0-ás vagy 1-es bit-et ad vissza, probléma mentesen lehet negálni a "~"-jellel.

Sziasztok!

Jól sejtem hogy egy pickit2-vel nem lehet 877et programozni??

Köszi

Rosszul sejted!

akkor jó

Be lehet állítani a fordítóban, hogy alapértelmezésben unsigned legyen a változók típusa? Most olvastam, hogy PC-s fordítókban erre van lehetőség...

A char tipust be lehet allitalni, hogy unsigned legyen, de kiprobaltam a peldaddal, es az 512*100 ugyanugy rossz eredmenyt ad castolas nelkul. Amit potyo irt viszont nem annyira bonyas megadni.

Project menu, Build Options, Project, elojob a beallito ablak, fuleknel kivalasztod a C18-at...

Értem. Jobban elolvasva a PC-s C fordítónál is csak a char típusok előjelnélküliségét lehet előre megadni.
Gondolom a kézzel bevitt kondtans nem minősül char típusnak, ezért rá nem vonatkozik a beállítás.


Úgyvan, és amit Te ajánlottál hosszú verziót azt sem.

Azert szoktam a hosszu "nomalis" castolast hasznalni, mert ugy konnyen lathato hogy mi van. Ugy emlekszem persze gcc-vel meg VC++ -al nem voltak ilyen jellegu varazslasok. Ugyan sok pelda pl "0L" -t hasznal long intek inicializalasara, de meg sohasem volt abbol problemam ha sime nullat irok ilyenkor.

Mindegy, itt a PIC-eknel akkor lehet es erdemes is hasznalni ezt a jelolesi format.

Pontosan, én is ezért írom inkább úgy. Párszáz sor után nincs kedvem U és L betűk után kutatni, vagy éppen hiányukat keresni...

Más kérdésem lenne:
Hogy oldjátok meg a legegyszerűbben egy 4bájtos kézzel bevitt kondtans érték 4 bájba való szétosztását? Én maszkolgatom, meg shift-elgetem(tiszta assembler szindróma )...