Fórum témák
» Több friss téma |
Köszönöm a magyarázatot!
Bocsánat hogy állandóan jövök a kérdéseimmel, de még van mit tanulnom a témában. Már értem a lapozás lényegét és hogy miért is használják. Közben olvasgattam a PIC adatlapját és ezt találtam: Idézet: „PIC18 microcontrollers implement a 21-bit Program Counter (PC) that is capable of addressing a 2-Mbyte program memory space.” Ezt a részt kellett volna csak elolvasnom amiből már következtethettem volna, hogy az én PIC-em 8k-s területén nem kell semmilyen plusz műveleteket végeznem.
Sziasztok! Egy bagatel kérdésem lenne, van 4db 8 bites regiszter R1,R2,R3,R4, mikor UART-on bejön adat, akkor RCREG-ből bemásolom R1-be az értéket. RRCF bitforgatóval minden bájt érkezésekor átforgatom az értéket a következő (R2) regbe. A problémám ott van, hogy R4 már első forgatásnál belefordul R1-be...
Valahogy nem jövök rá, hogyan kerüljem el, hogy visszaforogjon R4, R1-be. Valaki tudna segíteni?
Az direkt van, hogy egy nyolcas ciklussal masolsz a carry-n keresztul bitenkent at harom byte-ot?
Jol ertem, hogy azt szeretned,hogy r4 = r3, r3 = r2, r2 = r1? A hozzászólás módosítva: Jan 4, 2015
Miért zavar ez, ha a következő karakter beérkezésekor úgyis felülírod R1-et?
Nem a másolás a lényeg, hanem hogy ez R1 re érkezzen mindig a legfrissebb érték, és tolódjon hátrafelé, ahogy jönnek újabb bájtok.
Azért, gond, mert valamiért nem tudom R1 értékét megjeleníteni kijelzőn. Viszont 4 bájt beérkezése után megjelenik az R1-en a negyedik bájt. Nade közben kitaláltam, hogy nem forgatással fogom megoldani.
Hat akkor masold a harom byte-ot at, es az R1-be a beerkezett karaktert. En csak azt nem ertettem, hogy sima byte mozgatas helyett miert bitenkent masolsz.
A hozzászólás módosítva: Jan 4, 2015
Töröld a carry-t mielőtt rotálod, ha azt szeretnéd, hogy mindig 0 legyen R1-ben.
Igen, én sem értem miért ezen szórakozok már fél órája
 Lehet kezdek fáradni reggel óta...
Köszi, erre nem gondoltam!
Idézet: Négy bájt esetén egyszerűbben is megoldható a pakolgatás. „Nade közben kitaláltam, hogy nem forgatással fogom megoldani.” Jobb helyeken viszont gyűrűs tárakat (ring buffer) alkalmaznak már ezer éve! Nem a tárban levő adatokat pakolgatják ide-oda, hanem beviteli és kiviteli mutatókat léptetnek.
Még a ring buffer-nél is van egyszerübb megoldás, de csak szigorúan jobb helyeken:
Azt hiszed ez nem pakolgatásra fordul 8 bites környezetben?
 A hozzászólás módosítva: Jan 4, 2015
A valóság még rosszabb. A C18 egy 8 -as ciklusban bitet léptet majd 32 bitre végrehajtja a logikai vagy műveletet:
Tudom, hogy mire fordul, ezert is irtam, hogy csak "szigoruan jobb helyeken", ezert off a post es ezert van a vegen a smiley.
Asztak@! Na, azert ennel jobb kodra szamitottam. Ezen a forditon lehet optimalizaciot kerni?
Szégyen és gyalázat. Négy MOVFF-fel megoldhatta volna az egeszet. A hozzászólás módosítva: Jan 4, 2015
Igazad van, elég hülyén és átgondolatlanul fogalmaztam. Van még hova fejlődnöm, de már tudom, hogy tanulni akarom, és fogom is.
Vicsys, nagyon jó lett ez a videó is, most néztem meg. Ha nem írja Péter, hogy elfelejtetted mondani a PIC típusát, fel sem tűnt volna. Csak így tovább, én személy szerint várom a videóidat, nagyon tetszik! 
Sziasztok!
Ismeri valaki a DDE protokolt? Mármint ha egy program dde protokollal komunikál azt hogyan tudom PIC számára értelmezhetővé fordítani? ( csak számérték) Köszönöm!
Köszönöm a visszajelzést! Igyekszem folytatni.
sziasztok valaki tudna video linket kuldeni hogy hogyan kell pic-t programozni?
Elore is koszonom.
Hali
az IPE 2.05-el "Blank Check"-kel igazoltan törölt (Erase) és 877A-ból kiolvasott és exportált tartalom miért nem nulla? Miért keletkezik egy 47K-s hex fájl, ami nem üres? Az előzmény: szerettem volna tudni korábban mit töltöttem fel a PIC-be, de a kiolvasott hex más volt, mit bármilyen korábbi próbálkozásomé volt. Ezután töröltem, ellenőriztem, kiolvastam, exportáltam - és nem nulla (a tartalom sem). Mit csináltam rosszul? kösz
A törölt 16F* kontroller minden utasítása, konfigurációs szava, felhasználói azonosítója 0x3FFF, minden EEProm cellája 0xFF.
Ebben mintha lenne más is:
Akkor hogy lehet kinyerni (visszanyerni) a feltöltött hex fájlt? (bocsi, de még kezdő vagyok)
Ez egy üres kontrollernek tűnik.
Berakod a PIC-et egy programozóba, a programozónak pedig kiadod az olvasási parancsot. Ha a program nincs védve olvasás ellen, akkor látnifogod a tartalmat, amit el is lehet menteni.
Üres is, én töröltem kínomban. (Pickit3 + IPE 2.05)
A gondom az, hogy noha üres, a fenti 47kB-os a kiolvasott és exportált fájl. Az előzményben írtam, hogy az én általam beírt tartalmat olvastam volna vissza, hogy tudjam mit tettem bele annó. Erre kijön egy 47k-s fájl, ami nem is hasonlít arra, amit beletöltöttem. Ezért töröltem, és jött ki a feltett hex. A kérdés továbbra is az: hogy tudom a korábban beírt hex fájlt kinyerni, eredeti formátumban (hogy azonosítani tudjam, mi volt az) ? Több darabom is van, a fene emlékszik, melyiket mivel hagytam félbe, mikor utoljára PIC-eztem. Így már érthető a bajom?
Köszönöm mindenkinek, hogy segítettetek, de megoldottam végül léptetéssel, úgy hogy Carry-t töröltem az utolsó reg után. Egyébként volt egy elírás is elötte a kódban, MOVFF helyett MOVF-t de az már csak a figyelmetlenség volt.
A pickit saját programjával kiolvasod és elmented. De azokon a címeken ahol nem volt program ott nullák lesznek. Ha jól sejtem a kiolvasott hex soha nem lesz ugyanolyan mint amit te beletöltöttél. A nullák miatt nagyobb lesz, de ebbe nem vagyok teljesen biztos.
Csináltam egy kísérletet:
Betöltött - kinyert hex fájl. Az első 9 sor rendben, az megegyezik a betöltöttel, a 10. sor nem ok, ilyen nem volt a bemenőben, más jön ki. Az utolsó négy sorból (ami 0-val indul) kettő szintén eltűnt, az utolsó kettő viszont megjelenik az export utolsó két soraként.. Szóval nekem káosz |
Bejelentkezés
Hirdetés |
