Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Az áramkör alapvetően semmire nem jó. Ha a led közös katódos, akkor az anódot pnp tranzisztorral kell kapcsolni. Vagy lehet npn-el is emitterkövetőként, de ahhoz meg nem így kell az egészet bekötni. A pic-ről hiányzik a tápszűrés, és a felhúzó ellenállás az mclr lábáról. A pic önmagában a feladathoz teljesen jó.
Idézet: „Hogy kezdjek a programhoz?” Na én annakidején ezen kérdés feltevése helyett kb. 500 oldalnyit olvastam az ezzel foglalkozó fórumokon. Neked is ezt ajánlom, mert nem lehet csak úgy levegőből csinálni a dolgot.
Én csak csendben olvasgatom itt a dolgokat, de szerintem nem lenne gyorsabb a bitfield-el sem. Sőt még lassabb is lenne. Legalábbis nálam 16F-es procihoz a Hitech-C kisebb kódot generált ha maszkolással vizsgáltam a biteket, mint az unionos struktúrással. De ez azért van szerintem mert elég szerencsétlen a bit vizsgáló asm utasítás, nem tud csak előre lekódolt bitet vizsgálni. Azaz az nem lehet paraméter hogy melyiket nézze. Én ezen úgy lendültem túl, hogy #DEFINE -ekkel deklaráltam a maszkokat. Így szépen olvasható a kód, meg gyors is. Ha pedig nem fix, hanem paraméterezhetően kell biteket kapcsolgatni arra meg van két makróm:
#define CBITSET(x,mask) (x) = (x) | (mask) #define CBITCLR(x,mask) (x) = (x) &~ (mask) a maszk itt nem a bit száma, hanem 1,2,4,8 stb..
Most látom hogy Watt fix bit pozíciókat vizsgál. Úgy jó, csak nekem nem fixek kellettek.
Ezt viszont tökre nem értem : if( !(PORTA & 0x02) == !(PORTB & 0x80) ) {} Ennek semmi értelme, mert mind a két logikai vizsgálatot negálod aztán meg összehaszonlítod. Még jó hogy ugyanaz lesz az eredmény csak hosszabb úton. Idézet: „Ennek semmi értelme, mert mind a két logikai vizsgálatot negálod aztán meg összehaszonlítod. Még jó hogy ugyanaz lesz az eredmény csak hosszabb úton.” Nem, ez ket bitmuvelet, amit ha csak ugy ossze hasonlitana akkor soha sem lenne igaz az eredmeny mivel mas-mas biteket vannak kivadaszva... Gondolom a negalassal a logikai kifejezesse torteno konvertalast szerettek volna elerni - talan egy jobb optimalizacio eszre is veszi, hogy egyszerubben is meg lehet ezt csinalni, de valoszinleg C18 nem veszi ezt (sem) eszre 
Na most olvasom mégegyszer át a postokat, és látom hogy ennek az egésznek nincs így értelme. Mivel ez az if tényleg csak akkor lesz igaz, ha mindkettő nulla, pedig valószínűleg nem ez lett volna a feladata. Icerny jól irta a #361694 -ben. A #define -olt maszkok is természetesen csak "fix" bitek vizsgálatára jók.
Nem fix bitek vizsgálata alatt azt értem pl, hogy egy for ciklussal végiglépkedünk egy byte bitjein. Na ezt nem lehet egyszerűen megcsinálni. Aztán még bekavartam a feltételes összehasonlításba a bit állítgatást. Az külön téma, csak azért írtam le mert hasznos lehet. Na asszem mára elég is ennyi inkább ledőlök filmet nézni.  Idézet: „Ennek semmi értelme” Szerintem azért csinálta, hogy az aritmetikai kifejezéseket logikaivá konvertálja. Mert a 2 és a 80 összehasonlítása nemkívánatos eredményre vezetne, de ha csak a nullától való különbözőséget vetjük össze, akkor már jó. Tulajdonképpen így is írhatta volna: 
Ismét itt. Szándékosan nem valakinek az írására válaszolok, mert nem szeretnék senkit megsérteni, hogy kihagyom, ezért most mindenkinek ismét köszönöm a segítségeket.
Én meg közben megoldottam a megoldhatatlant? Tömböt hoztam létre, amit bitenként is el lehet érni. Még nem néztem a kódot, de előtte sem volt túl fényes, és most mint ha rövidebb lenne! Így sikerült:
Mi a véleményetek, jó ez így? Már azon kívül, hogy működik(az előző is működött. )
Nem jól nézted, a (PORTA & 0x02) maszkolás...
Ne csak a C18-ról és Hitech-C-ről legyen szó, érdekesség képpen a "nem annyira szeretett" ccs-ben van külön bitvizsgáló függvény. Azt használva ilyen lesz a kód:
és ha úgy irja hogy:
Végigmenni nem olyan vészes.
18F esetén, ha a sebesség számít, akkor a TBLRD utasításokkal megoldható egy kis táblázatba elhelyezni a szükséges maszkokat, és annak segítsével AND művelettel tesztelni.
Ha működik, akkor jó.
Valami ilyent akartam én is kipróbálni, de megelőztél.
C-ben nem igazán vagyok otthon, de azt kérdezném, hogy logikai értékeket szerencsés-e aritmetikai egyenlőség szerint összehasonlítani?
Arra gondolok ugyanis, hogy azt tudjuk, a C-nél a nulla érték hamis, a nemnulla pedig igaz. Viszont megköveteli-e bármi, hogy a fordító által generált kód a két logikai kifejezés kiértékelésekor az igaz értékhez ugyanazt a nemnulla értéket rendelje? Mert ha igen, akkor korrekt a dolog, ha nem, akkor viszont nem biztos, hogy jól működik (fordítófüggő).
Uhmm! Én jó vagyok C ből, de ez... hát itt nem egyszerű kikövetkeztetni hogy hogyan készül el a maszk amit megvizsgálunk az if-el. Na azért csak kibogoztam.
"c"-n vizsgáljuk a biteket, "b" a maszk, "a" meg a számlálónk. Ennél azért talán lehet egyszerűbben. Szerintem az "a" változó nem kell, a maszk ellenőrzésével is eldönthető hogy megvolt e már a 8. bit. Tömbbe foglalt maszkokat próbáltam még. De ott meg a tömb címezgetése volt ami megdobta a kódot. Még a legjobb megoldás a végiglépegetésre tényleg egy alap maszk shiftelgetése.
Megnéztem mit fordít a régi és az új verziómmal. A régi nem volt valami optimális, még a ti verzótokat is ki kéne próbálni, csak azzal az a baj, hogy tömböm is van, amivel ti nem számoltatok eddig!
Ez a régi kódom egy részlete:
Ez 32 sorra fordult le és volt benne ciklus is a C >> 6 miatt! Ez az újabbik kód:
18 sorra fordul! Ezzel már elégedett vagyok. Idézet: „Viszont megköveteli-e bármi, hogy a fordító által generált kód a két logikai kifejezés kiértékelésekor az igaz értékhez ugyanazt a nemnulla értéket rendelje?” Én úgy tudom, hogy nem garantálja senki egy logikai kifejezés nemnulla értékét. Valószínűleg a fordítók 99%-a 1-et tesz be az x változóba egy (x=b>c) után, de erre nem szabad építeni szerintem, és kerülöm is az ilyesmit. Idézet: „Arra gondolok ugyanis, hogy azt tudjuk, a C-nél a nulla érték hamis, a nemnulla pedig igaz. Viszont megköveteli-e bármi, hogy a fordító által generált kód a két logikai kifejezés kiértékelésekor az igaz értékhez ugyanazt a nemnulla értéket rendelje?” Jó a kérdés. Én a netről szerzem az ismereteimet. Ebben a leírásban ez olvasható, ezért gondoltam, hogy a logikai értékek összehasonlíthatóak. Azért, ha a leírás hibádzik, jelezzétek!
Sziasztok!
Egy napkövető elektronikát szeretnék készíteni PIC - el. 16F628 - asom van otthon. Érzékelőnek mit ajánlotok? Mivel lenne a legoptimálisabb megcsinálni? Esetleg van valakinek tapasztalata?
Sziasztok !
PICnel hogy kell keresni a fuse biteket az adatlapban? Koszi.
Hali
Egyszeruen megoldhato, de valami AD-s PIC-el. Pl 16F819, 16F690. Veszel 2 fotoellenallast (LDR) egyik kivezetest a GND-re a masikat egy 4k7 v. 10k ellenallassal a 5 V-ra. A csomopontokban levo feszt mered a PIC AD-jevel. Ha kulonbseg van a ket fesz kozott meghuzatsz egy relet ami egy motoron keresztul mozgatja a mechanikadat. Ugy nagy vonalakban ennyi. Termeszetesen a reles aramkor fugg az alkalmazott motortol. Jol hasznalhato pl a SAT antenna mozgato motor, de ha beirod a kedvenc keresodbe a "sun tracker" szavakat lesz millio talat hazi gyartasu napkovetokre. Udv Vili
OshonSoft-nal a Config. WOrd alatt csak egy byte hosszu adat van: 0044. Ez most az also vagy felso byte lesz?
Ha négy hexadecimális karakterből áll, akkor az csak egy bájt? Vagy esetleg kettő?
 Idézet: „WOrd alatt csak egy byte hosszu adat van: 0044” Ez nagyon gáz, nem gondolod?  
Most ismerkedek az A/D konverzióval. Nézzétek el ha valamit rosszul látok. Olvasgatom a 16F819 adatlapját.
Szépen írja hogyan kell beállítani. Azt ADCON1(ADCS2) bit mit is állít tulajdonképpen? Akkor állítsam 1 - re ha belső osciról megy a cucc, egyébként 0 ?? ez nem tiszta. És ha beállítotam akkor az ADCON0 (ADCS1:ADCS0) biteket hogyan állítsam be?
Hali
Az ADCS2 bit beallitja a 2-es osztast ha a system clockot allitod be mint az orajel forrast. egyszerobb ha a belso RC oszcit allitod be mint AD-clock forrast (ADCS0:ADCS1 = 11). Itt nincs jelentosege a gyors AD-nak. Eleg lassu a valtozas ezert van ideje olvasgatni a bemeneteket.
Ez egy pelda ami beallitja az AD_t a system clock 1/8-ra Udv Vili |
Bejelentkezés
Hirdetés |
