- EBTRB: Boot Block Table Read Protection bit
- 1 = Boot block (000000-0007FFh) not protected from table reads executed in other blocks
- 0 = Boot block (000000-0007FFh) protected from table reads executed in other blocks
Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Az adatlap megmondja:
Vagyis letiltja a 0-7FFh kódterülethez való hozzáférést a programmemória többi területéről. Ez azt jelenti, hogy ha a PICOS18 vagy bármely más program ezen a területen konstans adatokat vagy táblázatot tárol, akkor nem fog hozzáférni. Így nem csoda, hogy fejreáll...
Sziasztok!
Nem olyan rég keltette fel a figyelmem a PIC,elég sokat olvasgattam a programozásukról és a különböző tipusairól és közben megépítettem magamnak egy égetőt is(propic2) de sajnos elakadtam és még 1 PIC-et sem tudtam égetni  Na szóval: Az lenne a problémám hogy a hardware settingsnél nemtudom beálítani portnak LPT1-et pedig csatlakoztatva van a gépemhez az égető.  ezt miért csinálja? A Hardware settings-ről csatolok képet!A tápja a számítógépem tápegysége., ez gond lehet? ha valaki tudna segíteni nagyon hálás lennék. üdv:kotla ui:Ha netán olyan témában szólaltam meg amit máshol kellet volna feltennem vagy éppen már nagyonsokszor elmondtatok akkor elnézést kérek de csak ebben a témában 1214 oldal van és nem nagyon van időm jelenleg az olvasásra 
Nem tudom, hogy az IC-Prog-nak ez-e a baja, de saját fejlesztésű programoknál működik, ha bemásolod az io.dll fájlt a \windows\system32 könyvtárba aztán restart. Ez engedélyezi az ezt használó programoknak az LPT port közvetlen kezelését. Egy próbát megér.
Az io.dll-t tudomásom szerint csak én használom a többi valami más módon olda ezt meg. Azért ki lehet próbálni, de szerintem nem ez a baj. Végig kell menni a szokásos beállításon, amit már oly sokszor leírtunk. Az oldalamon is lehet találni ilyen jellegű infót külünféle égetők kapcsán. Végig kell olvasni és megérteni, mi miért van.
Szia!
Az ic prog beállítása xp esetén: Programmer: Interface ProPic 2 Programmer Direct I/O X Windows API Ports Communication X LPT 1 X Invert Data Out X Invert Data IN X Invert Clock Invert MCLR Invert VCC settings->option menü ->misc ->xp engedélyezése
Sziasztok !
Nem értem mit bénázhatok el ? A kódrészlet működik ,nyomom a buttont ,világít a led ,elengedem kialszik. De,ha a BSF GPIO,4 helyére egy goto ,vagy call utasítást írok ,nem ugrik oda...... Vajon miéer ? Köszi előre is ! Üdv : István
Ha a jó programrészletet adod meg nekünk, ami működik, akkor nem fogjuk tudni kitalálni, hogy a call-os vagy goto-s programrészlet - amit nem adtál meg - az miért nem működik...
Jogos !
Köszi !
És mi a hibajelenség?
Ha jól látom, ennek a programnak azt kéne csinálnia, hogy ha kezdetben nem nyomsz semmit, akkor a GPIO,4-re kötött LED nem világít, ha viszont egyszer megnyomod a gombot, akkor belekerül a végtelen ciklusba, ahol ki-be kapcsolgat, a delay-nak megfelelő időértékkel. Ugye, a call-lal meghívott szubrutinból megfelelően visszatérsz, return-nel?
Igen ,tökéletes a meglátás !
Így kéne működnie  Egyből ide kellett volna tennem az egész "programot" ,most megteszem..... Most momentán az a jelenség ,hogy egyből villog GPIO,4 és nem reagál a buttonra
Két dolog tűnik fel elsőként, amit javítani kellene, ha valóban úgy van megírva a forrásban, mint ahogy most itt kinéz:
1: movlw B'001101' movwf GPIO A GPIO regiszter 8-bites, tehát nem szabad csak 6 bittel megadni a fenti módon! 2: A GOTO PIROS előtt, ahogy látom, nincs tabulátor? Ezt is javítani kellene, ha így van a forráskódodban is, a sor legelején a címkék helye van, aztán legalább 1 tabbal elválasztva kell lennie az utasításnak, és ezt követően legalább 1 szóközzel, de méginkább 1 tabbal elválasztva kell lennie az operandusoknak.
Dolgok javítva !
Idézet: „movlw B'00001101' így jó lesz szintaktikailag ? movwf GPIO” Hiba ugyan úgy fenáll ..... Input lábak 2,2k val "+" ra húzva vannak és lenyomáskor teszem földre ,ha fontos lehet....
Hogy van az a gomb bekotve? Amugy ha egyszer bemegy a PIROS nevu reszbe onnan ugye nem johet ki. A masik, hogy nincs debouncing, tehat ez a jelenlegi elrendezes inkabb jumperes / dip swithes kapcsolasokra emlekeztet mikor a beallitasok a keszulek bekapcsolasa elott tortennek meg.
Idézet: „Input lábak 2,2k val "+" ra húzva vannak és lenyomáskor teszem földre ,ha fontos lehet....” Az rendben van, de nincs debouncing, es a PIROS-bol sem jon ki.. Amugy az ORG 0 utana nncs GOTO Debut vagy hasonlo, igy az ORG 0 es ORG 10 kozti memoria szemet miatt a program lehet hulyeseget csinal...
Szia !
Kapcsoló bekötése a képen. A Idézet: sajnos nem értem „debouncinget” Idézet: „es a PIROS-bol sem jon ki.. Amugy” mert ott még nem tartok .... Tegyem vissza a Idézet: -ot ? „GOTO DEBOUT” Idézet: „Tegyem vissza a „GOTO DEBOUT ”-ot ?” Nem kell, ha azt az ORG 10-et kiveszed... a 12F509 kulonben is baseline, abban nincs interrupt kezeles, szoval teljesen felesleges a reset vektort es az init reszt elvalasztani. "debouncing" --> prellezes, avagy perges ha ugy jobban tetszik. Ugye minden mechanikus kapcsolonak van ez a nem tul jo tulajdonsaga, hogy nehany ms-ig ide-oda kapcsol akar tobb szazszor is. Ezt kell vagy elektronikusan vagy szoftveresen kiszurni. (itt ebben a temaban is kitargyaltuk ezt jonehanyszor, ha rakeresek a keresovel meg fogod talalni a megoldasokat  )
Sziasztok!
USART kommunikációval küzdve float tipust szeretnék küldeni.
Probáltam startchar nélkül is, de úgy sem jó. A pi értékét szeretném kiratni, ami 3,14, float tipusú. Az ellenőrzésre betett helló világ visszajön, de a konvertált érték nem. A start és stop char:
Van valami ötletetk mit rontottam itt el?Esetleg hogy helyes? A segítségeteket előre is köszönöm! (A google barátom most nem igazán tudott segíteni.) üdv, bubu
A \0 gondolom ideje-koran lezarja a stringedet (jelen esetben a buffer leges-legelejen). Emiatt nem fog kuldeni semmit sem. Nem tudom miert raktad ezeket a START/STOP dolgokat bele amigy?
Hali,
Köszi a tippet, de igy sem akar menni. most igy né ki:
Te is így gondoltad?
Nálad milyen PIC és milyen fordító van? Nálam MPLAB_8.15 és C18-Student Edition-v3.22 van telepítve, de ebben nem látok putrsUSART() függvényt, csak putsUSART() van.
Azt hiszem ez a CCSC-ben van (marmint ha rakeresek a tutrsUSART es putsUSART fuggvenyekre akkor CCSC dolgok jonnek elo, de amugy en sem ismerem). Ha jol latom a putrsUSART() a ROM-ban tarolt stringek elkuldesere valo, mig a masik a RAM-ban taroltakra.
Passz, masra nem tudok gondolni, minthogy nehany forditonal (ill. C konyvtarnal) alapbol nem szokas a printf-nel a float tamogatast belerakni, merthogy attol erosen egno a kod merete. Elkepzelhetonek tartom, hogy itt is errol van szo, es egyszeruen csak lenyeli a %f-et de nem kezd vele semmit sem. Utana kellene olvasni, hogy valoban lehetseges-e ez es hogy mikent lehet a floatos printf-et beizzitani.
UI: Ja, es elotte probaldd ki egesz tipusuval, hogy mukosidik-e ez a putsUSART, tehat sprintf(buf, "%u", 1234); es utana a putsUSART(buf);
Kiprobáltam és így sem megy.
Valakinek van ötlete? Ezek szerint tényleg nem egyszerű, mert egész kiiratása sem megy.
Még mindig nem árultad el, hogy milyen PIC, milyen fordító...
Meg egy utolso otletem van: Lehetseges, hogy a compiler szepen kioptimalizalja a kifejezeseket, es mivel a valtozod nem valtozik, ezert optimalizalas gyanant a RAM stringbol csinal egy ROM stringet... (csak spekulacio)
Tehat ha ugyanaz mukodik putrsUSART() -tal (az "R"-es valtozattal, akkor valoszinuleg ez tortenik. Ill. amit meg meg lehet probalni, hogy a pi valtozot volatile-nak megjelolni, hatha akkor az optimalizacio kimarad a kepletbol. Na jo, meg egy otlet: Lehet valami hand-shaking be van kapcsolva amitol a kommunikacio leall -- ill. a PIC ezt nem veszi figyelembe, kiloki az kuldendo adatot, de a terminal meg nem all keszen a fogadasra. xon-xoff ill rts-cts-dtr ilyeneket kellene keresgelni.
Találtam egy egész jó megoldást:
És it belehet állítani a tizedes pontosságot is. Már csak akkor van baj, ha más kommunikációval együtt kell használni. pl i2c-n lekérdezett adatot továbbítok.
De nem azt irtad az iment, hogy a putsUSART() nem mukodik?
|
Bejelentkezés
Hirdetés |
