Fórum témák
» Több friss téma |
Rendben, köszi!
Közben rájöttem, hogy végül is ez a kód, amit az előbb írtam, egy sorba is beírható, így a rövid ideig történő "kinullázást" el is lehet kerülni. Bár nem szép, de ha nincs más megoldás, marad ez a maszkolás. 
Tedd egyetlen sorba!
De makrot is gyarthatsz ra ha az egyszerubb neked:
Idézet: „Ezzel csak az a gond, hogy egy nagyon rövid időre ugyan, de a lábak alacsony jelszintet adnak majd, mielőtt az új értéket megkapnák.” A legtisztességesebb módszer a kizáró vagy kapcsolattal történő módosítás, ami konkurens folyamatoknál is használható. Például vegyük azt a helyzetet, hogy interrupton matatsz bizonyos biteket, a főprogramban pedig ugyanazon regiszter más bitjeit. Kínos volna, ha a főprogramban beolvasom a regisztert, közben az interrupt módosítja bizonyos bitjeit, én pedig a saját bitek módosítása után visszaírnám a többi bit RÉGI értékét! Az alábbi inline "függvény"-ben szereplő formula megoldja ezt a gondot:
A példádat ezzel így kell írni:
Természetesen az RMW probléma miatt a PORTB nem a legszerencsésebb példa, ezért vezették be a PIC18-tól fölfelé a LATA, LATB, stb. hozzáférést a kimeneti adatbufferhez. PIC24/dsPIC33-hoz pedig ebben a topikban található a téma diszkussziója és egy lehetséges megoldása.
Így van, az utolsó hozzászólásomban írtam is, hogy egy sorba is írható ez a kifejezés, így a rövid ideig történő kinullázást is elkerüljük. A makrós megoldás viszont tényleg szép, hiszen ezt a számomra "csúnya" kódot legalább csak egyszer kell leírni...
Sziasztok!
A feltételes fordítási direktívákkal gyűlt meg a bajom, de végül is sikerült orvosolni a problémát. Mivel elég furcsa a hibajelenség, gondoltam megosztom veletek. A projektem több forrásfájlból áll. A gondot az #if defined(...) direktíva lezárásaként szolgáló #endif direktíva jelentette. A main.c forrás végén elhelyezett #endif direktíva csak akkor nem okozott fordítási hibát, ha a direktíva után volt egy soremelés is. Ha pl. a soremelés kimaradt, vagy a soremelés után egysoros komment volt, akkor különböző hibákkal leállt a fordítás. Nem tudom, hogy ez bug avagy feature, de szerintem ez nagyon nem jó így. A rendszer: MPLAB IDE 8.63 C18 Compiler 3.36
Tipikus elkövetési hiba szerintem a C programozóknál, főleg include fájloknál.
Valahogy úgy felfogható, ha a fájlokat egybemásolod, akkor ugye a 2. fájl első sora, az első fájl utolsó sorába folytatásként másolódik be, és a fordító eszerint "értelmezi" azt az utolsó sort...
Szia!
Köszönöm a választ, bár szerintem félreérted (vagy én nem értelek meg rendesen). Az én olvasatomban a válaszod csak arra az esetre korlátozódik, amikor az #endif után nincs soremelés. Viszont akkor is kiakad a fordító, ha van soremelés, de utána pl. komment helyezkedik el. Valami ilyesmire gondolok:
Ekkor fordítási hibát dob. Szerintem nem kéne, hogy kiakadjon erre. Egyébként #if #endif nélkül mindig jól fordított, akár volt soremelés, akár nem.
A forráskód utolsó sora mindig egy újsor karakter kell, hogy legyen, függetlenül, hogy az utolsó előtti sor csak komment vagy valós utasítás.
Amúgy én sem értem, hogy a fordítóprogramok miért nem tesznek a fájlok végére a feldolgozás során sajátmaguktól egy plusz újsor karaktert.
Na erre látod nem gondoltam, pedig így, hogy említed nekem is beugrott. Köszönöm a válaszodat.
Idézet: Szerintem azért, hogy ne lehessen "véletlenül" fordítani, csak a megfelelő szabályok betartásával! Ugyanígy nem fogadja el például, ha a megjegyzésnek csak az elejét jelölöm (/* ) és így érne véget a program ( pedig néha jól jönne ), ez is biztosítja, hogy ne "bambulhassak el", oda kelljen figyelni.„Amúgy én sem értem, hogy a fordítóprogramok miért nem tesznek a fájlok végére a feldolgozás során sajátmaguktól egy plusz újsor karaktert.” Ez csak a magánvéleményem volt Steve
A kommentelésben igazad van, ugyanakkor ha a fájl végére betenne egy újsor karaktert, akkor nekem nincs elképzelésem róla, hogy ez bármilyen problémát is felvetne. Gondolom olyat senki se akar szándékosan csinálni, hogy egyik fájlban elkezdi a kommentet // jelekkel, majd másik fájlban fejezi azt be.
Sziasztok!
Látszólag tök egyszerű kérdésem van, de én a pdf-ek böngésésével nem találtam meg a választ. Szóval hogy lehetne constanst alkotni a rom-ba, hogy egy számot adok a karakterek elé, mögé. Ez az alap:
Ez kéne úgy, hogy működjön:
VB-ben ez a Chr$(10)&"Akármi" módon megolható, itt mi a megoldás? Soha nem kellett még így, de most igen. A legalapvetőbb dolgokat nem találom meg, miközben már ezer éve írom a kódokat. Szép mi? 
A tömbelemeket vesszővel kell elválasztani, eddig OK, de az egészet kapcsos zárójelek közé kell tenni.
Azt nem tudom, hogy ez hogyan kombinálható stringgel.
Letre kell hoznod egy strukturat:
Most ez a pelda nagyon le van egyszerusitve, de remelem ertheto...
Köszi, de nem egészen ez a feladat. A fenti első kódrészlet a programmemóriába tárol le konstansként szöveg ASCII kódokat. Közé kéne tenni olyan értékeket, amik nem írhatóak le karakterekkel, mint pl. a 0, 12 stb. Tehát nincs szükség változókra, strutúrára, hanem arra lenne szükségem, hogy valahogy a előfordítónak el tudjam mondani, hogy a CHR$(0)-t tegye be a karaktereim közé.
Igen, ez is megvan, de pont az kéne, hogy kombináljam.
Ez sajnos nem működik:
Elvileg birsz ilyet csinálni:
De egyelőre nem tiszta számomra, hogy ebből miért lesz a memóriában hexadecimálisan: 0A 61 01 62 02 63 03 64 00. A végén a 00 világos, a 0A-t nem értem, hogy hogyan keletkezett a 12-ből...
Alakul! Tényleg érdekes, hogy 2-vel kisebb szám kerül be a memóriába az első ponton! ?
A 128-as értéket még mindig valami karakterrel tudnám bevinni, jobb lenne számmal, mert ez egy cím és beszédesebb lenne. De eddig még ez áll a legközelebb a megoldáshoz! Köszönöm!
Azt hiszem megoldódott, legalább is így áttekinthető és jó is:
Köszönöm a segítségeket!
Egy indexszel akarsz végigmenni a két tömbön? Mert azt nem garantálja senki, hogy ezek mindig egymás után lesznek elhelyezve a memóriában.
Ja ertem mar mit szeretnel! Es valami ilyesmi?
es akkor ennek egy valtozata lenne:
UI: Stringbe 0-t ill '\0' -t ne tegyel lehetoleg, mert az a string kezelo fuggvenyeket fejre boritja...
Igen, de eddig úgy tűnik egymás után vannak, többet is deklaráltam. Azt mondod elkeverheti a fordító? Végül is miért ne! Na mindegy, majd ha megteszi, akkor eszembe fog jutni, hogy van ilyen, és akkor korrigálok!
Igen, elkeverheti. Valószínű, hogy nem fogja, de előfordulhat.
Ez is jól néz ki, köszönöm!
0-t nem teszek, azt beteszi a fordító a karakter végére. A te verziód végére nem tesz, ezért ha karakter vektorként akarom kezelni, akkor bizony nekem kell! Az én példámat is csak azért lehet összefűzni, mert egyrészt két változót teszek a szöveges elé, másrészt nem tesz be 0-t a végére. Két karakter vektort ezért nem is lehet össszefűzni simán a végén lévő 0 miatt. Idézet: „Igen, elkeverheti. Valószínű, hogy nem fogja, de előfordulhat.” Ezt ugye semmi sem garantalja -- pl egy bankon keves a hely, es lehet az egyiket meg oda be tudja nyomni a masikat mar nem... Az en verziomban a 0-t valoban illene oda biggyeszteni, azt kifelejtettem Idézet: „Ezt ugye semmi sem garantalja -- pl egy bankon keves a hely, es lehet az egyiket meg oda be tudja nyomni a masikat mar nem...” Az jutott eszembe, hogy ugye ezeknek a konstansoknak a memóriacímük ismert fordítási időben. Vajon lehetne-e valami ilyesmit csinálni?
Ez persze nem jó, de hátha valaki tud valamit, hogy lehetne ilyen ellenőrzést csinálni. Idézet: Szerintem fordításkor még nem ismert, csak linkeléskor dől el. „Az jutott eszembe, hogy ugye ezeknek a konstansoknak a memóriacímük ismert fordítási időben.”
Közben én is erre jutottam, hogy ez lehet, csak már nem tudtam az előzőt szerkeszteni...
Viszont futas idoben ellenorizheto, igy bekapcsolaskor / inicializalaskor meg kiabalhat, hogy valami nem stimmel. Azonban az osszes ilyesmi nekem kicsit ganyolasnak tunik.
Ezek az adatok szövegek, ha valami nem stimmel a sorrenddel, az könnyen kiderül a program kipróbálásánál. Eddig nem volt gond, meglátjuk lesz-e, ahogy bővül a lista. Egyébként egy 18F-nél nem nagy gond a programmemória olvasása a táblacímző regiszterekkel, szerintem nem lesz baj...
|
Bejelentkezés
Hirdetés |
