Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Akkor húzz bele, mert a 100kHz-es kristálynak is el kell vinnie az órát.
Amúgy a kiló jele a k és nem a K. A Hertz jele pedig Hz, nem hz. Idézet: „Amúgy a kiló jele a k és nem a K.” Pontosabban kis k mint 1000 es nagy K mint 1024. De ez utobbi azert is zavaro, mert a Kelvin jele is.
Viszont potyonak igaza van, mivel a frekvenciára használtuk a jelölést.
Dehogynem, át lehet. Kell egy MAX232. Még rajz is van az oldamon erről. De még úgy sem biztos, hogy működik minden égetőprogrammal.
Éppen egy leíráson dolgozom és abban különböző programozók beállításainál tartok(amiket nem nagyon szoktam használni). Tegnap meglepődve tapasztaltam, hogy a WPB_RS_V2 soros programozó, ami a WPB_F18_xxx-el hiba nélkül működik, se a IC-Proggal, se a WinPIC800-al nem akar működni(pedig régebben én ezt kipróbáltam és akkor úgy emlékszem ment.) Csak külön agyrém, hogy a WPB_PCB_V2 leválasztott égetőm a WPB_F18 és az oshon 16F és 18F programjaival tökéletesen működik, de a fent említett két égetővel szintén nem! Minden vonal lecsekkolható, minden tökéletes DC szinten, de a kommunikáció nem működik. Hát eléggé csalódott vagyok ezügyben! Próbálok rájönni az okokra, de már így is fél napot elpocsékoltam ezekre a szutyok programokra! Ezek után nem meglepő, ha valakinek egy tökéletes áramkör nem akar égetni! 
A 3.2768MHz nagyon jó érték. Azt 65536-tal osztva ugyanis pont 50Hz-et kapsz. A timer1-gyel meg - ha csak hagyd szabadon futni és sosem töltöd újra az értékét - pont 65536-os osztást (2^16) lehet megvalósítani. Ekkor biztosan nincs az a probléma, hogy az újratöltés idején hány tick-re áll le a számlálás.
Az 50Hz-enként beeső interruptot meg lehet ritkítani az előosztó használatával, de maximum a 2-es osztót érdemes használni, mert nagyobb osztásnál nem egész számú interrupt fog érkezni másodpercenként. Egyébként a másodpercenkénti 25 interrupt egy jó érték lehet, akkor az interruptban le lehet kezelni pl. a billentyűket is pergésmentesítve. Én az LCD-s órámban 16Hz-es interruptban teszem a dolgokat, a köztes időkben pedig alszik a CPU. Idézet: „Kérdeznék még egyet. Hogyan kell ezt: char A; FSR0 = &A; //remélem érthető mit is szeretnék” Es ez nem mukodik? Amugy nem ertem miert van erre szukseged? C-ben nem igy szokas programozni! Rendesen pointert kell letrehozni RAM-ben, es mikor hasznalod azt a pointert majd a fordito eldonti melyik FSR-t fogja hasznalni es hogyan. Ha kozvetlen a regisztereket akarod birizgalni akkor inkabb ASM-ben programozz.
Üdv!
tudom hogy hülye de fáradok. 16F628 - ban ugye van belső osc? beállítani pedig igy kell: _INTRC_OSC_NOCLKOUT ugye? ja és 4MHz - es?
Ha fáradt vagy, akkor hagyd abba!
Adatlapból idézgetek: Idézet: „14.2.6 INTERNAL 4 MHZ OSCILLATOR The internal RC oscillator provides a fixed 4 MHz (nominal) system clock at Vdd = 5V and 25°C, see “Electrical Specifications” section for information on variation over voltage and temperature.” Idézet: „ja és 4MHz - es?” lehet 4-is: Idézet: „PCON reg: bit 3: OSCF: INTRC/ER oscillator speed 1 = 4 MHz typical(1) 0 = 37 KHz typical” És igen: _INTRC_OSC_NOCLKOUT (ASM-ban)
Köszi az infókat, átgondolom. Egyenlőre egy sima akármilyen megszakítást próbálok összehozni, aztán majd finomítom. Csak kevés időm jut a dologra.
Kicsit kiakadtam az égető programoktól.
Az IC-Prog-ot egyik égetőmmel sem tudtam életre kelteni(oshon, WPB_LPT, WPB_PCB_V2, WPB_RS_V2) A WinPIC800 vitte a WPB_LPT-t, az Oshont, és a WPB_RS_V2-t is, de a WPB_PCB_V2-t nem. Az Oshon programjai (18F, 16F) jól működtek az LPT-s égetőkkel(Oshon, WPB_LPT, WPB_PCB_V2). A WPB_F18_4.25b mindegyik égetővel tökéletesen éget. Le lehet vonni a következtetéseket!
Igy nem, és máshogy sem sikerült, azért kérdezem
 Gondolom te is láttad már miket fordit a C18, időkritikus munkáknál jobb belenyúlni itt-ott. Viszont, meg szeretnék már tanulni rendesen C18-ul, és eddig pont azért nem sikerül mert folyton időkritikus munkáim vannak (értsd: marha gyorsan futó alkalmazás kell, és holnapra legyen kész ) és egyből az _asm-hez nyúltam.
Ha már ennyire benne vagy ezekben a dolgokban, nem nézted véletlenül a kommunikáció sebességét (pl. a PGC-n)? Lehet, hogy egy sor ilyen jellegű probléma időzítésekből adódik. A progikban nem lehet a gépet "kalibrálni" valahogy?
Az IC-Prog beállításai között van sebesség állítás. Leglassabban sem kezeli egyiket sem. De nem is érdekel a dolog, mert a WinPIC800 jobb program. Sajnos abban nem lehet sebességet állítani, pedig valószínű ezért nem megy a WPB_PCB_V2.
Az oshon-nal csak egy baj van, hogy kevés PIC-et ismer. Bár az igazat megvallva egy kezdőnek nincs is szüksége többre. Egy PICKit2 építéséhez pedig bőven elég amit ezek tudnak.
Sziasztok!
Nincs valakinek ötlete, hogy hogyan lehetne sdcc-vel véletlenszámokat kipréselni egy picből? Lehet,hogy én vagyok béna, de átnéztem az egész netet és nem találtam semmit.  Előre is köszönöm!  pinyó
Egy 10 bites ADC legalsó bitje elég véletlenszerű lesz. Ahány bit kell, annyi mintavételezést csinálj. Az így előálló számot használhatod "mag"-nak, amiből kiindulva tetszőleges számú pszeudorandom számot generálhatsz.
Assembrlerben például itt és itt találsz programrészleteket (8 és 16 bites számokra).
Hali!
Azoknak tennék fel egy forrást, akik egyszerűen szeretnének egy poti értékét 8 biten beolvasni.(bővíthető akár 16 bitre is.)Méghozzá adc nélkül.A beolvasás meglehetősen stabil.Átírható más portokra, csak schmidt triggeres bemenetű legyen.
Megspórolhatod a tranyót és egy portot ha maga az olvasó port kimenetként konfigurálva sütné ki a kondit.
A programoddal kapcsolatban lenne nehany eszrevetelem, ha nem haragszol meg erte:
1. Utasitasokat es assembly direktivakat soha nem kezdunk az elso oszlopban 2. Csak cimkeket es C preprocesszor direktivakat kezdunk az elso oszlopban, azonban cimkekhez nem kell a kettos pont 3. Ugyanazon a porton nem szabad ket egymas koveto bit muveletet vagy mas RMW utasitast vegre hajtani! 4. Az ISR elejet nem NOP-okkal, hanem ORG-gal kellene megadni, ezzel elkerulendo az esetleges csuszas 5. A status gep allapotat en nem alapoznam a PORTA,3-ra, hanem hasznalnam a FLAG valtozot... Ha veletlen a PORA-t nem sikerul a PICnek lehuzni akkor akar el is rothatja az allapotgepet. A FLAG igy atmehet igazi allapotjelzobe, es akkor az allapotok: 0 - nincs engedelyezve 1 - engedelyezes / start 2 - beolvasas elkezdodott (discharge) 3 - beolvasas vege Mivel keves az allapot az egyszerubb osszehasonlitas erdekeben akar biteket is lehet hasznalni szamertekek helyett...
válaszok:
1. azt,hogy ki hogyan szeret programozni, ne bíráljad. 2.Kettőspont valóban nem kell, ez hiba valóban. 3.Ugyanazon porton nem kiírás és beolvasás van egymás után, tehát mehet.. nem kell várni a tényleges átállásra. 4.a nop nem program soha nem fut rá program, csak helykitöltő. én ezt egyszerűbbnek tartom. 5.Ha alaposabban megnézted volna a programot, akkor a jelző flag bitet a megszakítás állítja be,a kondenzátor kisütésére a timer ujbóli átfutásának ideje áll rendelkezésre(256 ciklus). És itt visszatérnék arra, hogy én így oldottam meg, hogy ebből ki milyen ötletet hasznosít az az ő dolga. Légysz tegyél te is fel sok progit, hogy a nép tanuljon, és majd mi meg kritizálunk... Idézet: „azt,hogy ki hogyan szeret programozni, ne bíráljad.” Ha felteszel egy programot, hogy okuljon a nép a ötletedből, akkor kiteszed magad annak, hogy bírálnak, főleg ha tele van olyan megoldásokkal, amit nem szabad követni! Egyetértek trudnaival, és jobban teszed, ha hallgatsz rá. Idézet: „Légysz tegyél te is fel sok progit, hogy a nép tanuljon, és majd mi meg kritizálunk...” Téged se kért senki, hogy ilyet tegyél.
1. Ez nem szeretet kérdése, hanem az MPLAB nem szokta szeretni, ha az első oszlopban cimkéken kívül más is van. Ezen kívül az olvashatóságot is növeli, ha blokkszerűen átlátható az egész.
2. Mondjuk nem hiba, csak felesleges 3. Ebből látszik, hogy nemis tudod, hogy mit takar az RMW probléma... 4. A NOP ugyanolyan utasítás, mint a többi, csak nem végez semmit. Utasítás arra, hogy ne csináljon semmit. A programot pedig nem "helykitöltéssel" igazítjuk fix memóriacímre, hanem azzal, ami erre való, tehát org-al. Így ha véletlenül elé írnánk valamit, akkor a fordító kiabálni fog, hogy ott nincs hely, ha meg kitörlünk valamit, akkor meg nem cseszi el a programot. 5. trudnai elég sokmindent közzétett már itt a fórumon a nép tanításához...
Én még - sajnos - nem vagyok egy nagy PIC-guru, tehát a vita szakmai részét nem vágom, de az a véleményem, pont itt teljesen felesleges trudnaiba belekötni, aki az egyik legaktívabb segítő ebben a topicban. Ha közzé teszed a munkádat, azzal azt is megkockáztatod, hogy kritikát kapsz. Itt még erről sem volt szó, csupán segítő szándékú jótanácsról - szerintem.
Megkockáztatom hogy bugot találtam a C18ban.
char stimeout; //a 0x81 fizikai cimen van ... char * rxp; //a 0x234 fizikai cimen van rxp++; stimeout=5; 12D8 0102 MOVLB 0x2 12DA 2B34 INCF 0x34, F, BANKED 12DC 0E00 MOVLW 0 12DE 2335 ADDWFC 0x35, F, BANKED 12E0 0E05 MOVLW 0x5 12E2 6F81 MOVWF 0x81, BANKED A 12E0-ban egy MOVLB 0x0-nak kene lennie. Nincs. Bele is irta nekem szepen a 0x281be az 5-öt. Ott, vesztemre egy control regiszterem volt Sajnos most nincs időm tesztelni hogy ez tendencia-e és ha igen, mitől függ.
Upsz, ez tényleg elég csúnyán néz ki...
Most megnéztem egy régi 18f4431es progimban is, ott az egyes bankban van az rxp. Ugyanez.
A gond, hogy ez már kinn van a megrendelőnél  Szerencsére itt a 0x181en nincs regiszter de hogy a timeout se megy az biztos...Nagyon nem örülök ha ez tendencia. 50nél több progit kellene átnyálaznom...
Sajnos már nincs több időm tesztelni. Ami eddig kiderült:
A teljes függvény igy nez ki: void savedat (void) { *rxp=SDATA;rxp++;stimeout=5; } 1. Cserélgettem rxp-t más pointerre, stimeoutot is más reg-re. Ha a reg bankja > mint a pointeré, akkor beteszi a movlb-t. Egyébként nem. 2. A main-be vagy más, hosszabb függvénybe másoltam a sort, ott szabályosan lefordult. Megszakitásrutinban is. Ha van időtök és kedvetek, sztem érdemes utánajárni. Én is folytatom majd.
Ez elég gáz!
Lehet, hogy nem számít, de mi van akkor, ha nem egy sorba írod őket? |
Bejelentkezés
Hirdetés |
