Egy lehetőség arra, hogy elkezdd!

LINK

Mellékesen megsúgom: irtózatosan sokat kell hozzá olvasni, és nem árt, ha van egy alapvető angol tudásod a témában

azért nyitotam a témát mert ez sok embert érdekelne de itt mindenröl szo van

ha már PIC akkor miaz a PIC?

Én már nem egy hex-et visszafordítottam az MPLAB-al. Tökéletesen fordít, csak értsd meg a kódot!

Viszont potyo-nak a C-ben írt forrást soha nem fordítja vissza, csak asm-ra, azt meg próbáltam már fordítani, nem egy leányálom! Ugyanis a C fordító nem úgy fordítja a hex-et, mint az MPASM egy asm forrásból!

Szóval van mivel(és mindig is volt), csak nem érdemes ilyennek nekiállni.

Ügyi vagy! :law: Gondolom nem is káromkodtál nagyon! Legalább gyakorlod a nyelvet!

http://www.freeforum.hu/pic ez már jó

Igen az MCLR láb 100k felhúzva. (jumper a vpp1 és a vpp2 között). Ha konfigból ki van kapcsolva az MCLR akkor is ugyan az a helyzet. A power up time holnap kipróbálom. Sokat gondolkodtam az RF modulnál hogy a vdd vagy pedig a gnd kapcsolgassam de több helyen igy láttam. Szerinted melyik megoldás a jobb?
Üdv BlackStar

Ja, hogy C... az elég gáz

Tamás szerintem arra gondolt, hogy ha a kapcsolásban tudható, hogy melyik láb micsoda, akkor lehet adni értelmes neveket ezeknek és esetleg a visszafordító valamivel emészthetőbb kódot ad, mintha csak "PORTA.3" és hasonlókat látsz. Sajnos a C-ből fordított gépi kód tényleg elég embertelen visszafordítva.

szerintem érdemes megnézni a microchip-féle C fordító forráskódját, hogy milyen szerkezetet milyen asm struktúrára fordít.

ezután feloldani a regiszterek nevét, kicopyzni az egészet pl wordbe, majd az összes olyan sort megjelölni pirossal, ahol speciális regiszternek adsz értéket (első lépésben), majd egy másik színnel megjelölöd azokat a sorokat, ahol valami más regiszterrel bütykölsz valamit

harmadik színnel jelöld a feltételes elágazásokat, negyedikkel az ugró utasításokat

ezután azokat a sorokat kell átnézni szisztematikusan, amelyikben feltétel nélküli ugró utasítás volt, itt átcserélni valami címkére, meg bepakolni egy címkét oda, ahová mutatott, ezeket is külön színre érdemes átcserélni, ezzel megkapod a program körülbelüli vázát

utánna érdemes levadászni azokat a sorokat, amelyek nop-ot tartalmaznak, és megvizsgálni, hogy vajon csak egyszeri késleltetésről van szó, vagy speciális ciklusos késleltetésről, megnézni, hogy esetleg paraméterezett-e
ezeket a blokkokat kiszürkíteni :p (mert úgyis csak az időt húzzák ) (plussz melléjük írni megjegyzésbe, hogy az adott oszcillátor beállítások mellet mekkora késleltetést jelentenek (úgy általában, vagy paraméter(ek) függvényében)

meg kell keresni az interrupt service rutin(oka)t (ez gondolom egyértelmű, mert ismert az a memóriacím, ahol kezdődik)

akkor érdemes egy lépésben megjelölni az összes olyan sort, amely valamelyik portról olvas, vagy portot ír ( a hardware ismeretében ezeket is elnevezni)

mindezek mellett érdemes magadnál tartani papírt, tollat, hogy nagyvonalakban ábrázolni tudd az algoritmus gráfját, miután megvannak a nagyobb blokkok, és felrajzoltad magadnak az elágazásokat (az elején megjelölt feltételes ugró utasítások alapján), elkezdheted kibontani a részleteket, érdemes a program elején lefutó inicializáló kóddal kezdeni, hogy tudd milyen perifériákat használ, meg milyen beállításokkal. (ezeket is kigyűjtöd magadnak papírra)

iszonyú nagy meló nagyobb programoknál, de az a lényeg, hogy szisztematikusan csináld

Igen, hat ez a kiindulasi alap mindenkepp,m ill az adott PIC architeckturaja. Az a kis tool amit emlitettem is keri az MCU header/INC file-jat, es ebbol pl a specialis fileregisztereket mar ismeri egy pl nem btfss 0x03,0 hanem btfss STATUS,C van kiirva, ami mar eleve nagy segitseg lehet.

Nehany nagyon egyszeru szerkezetet is felismer, igy pl a sok retlw-k egymas utan, es igy akkor a labelt mar tablazatozza - sajnos meg nem forditja at DT-re, talan majd egyszer

Felismeri meg a call-return dolgokat, szoval megintcsak a labelek ill a tordeles ennek megfelelo ami jobb eredmenyt mutat mint az MPLAB-os vagy eddig altalam ismert mas visszaforditok csinaltak.

Ami jo lenne meg a szerkezeti hasonlosagokat selifmero algoritmus, ami esetleg makrokat csinalhatna a hasonlo kodreszletekbol. Hianyzik tovabba, hogy egy parameter file-ban el lehessen tarolni a felismert vagy nevesitett labeleket/valtozokat, igy egy ujrafuttatassal megjobban ertheto kodot kapjunk.

Ehh, de jo is lenne mindez, es akkor meg ott a 16 bites, meg mostmar a 32 bites MCU ehhh

Tamas

PIC az a Microchip ceg microvezerlo csaladjat takarja - jo kis cuccok es eleg olcsoak, azonkivul eleg sok kulso alkatreszt meg lehet ezekkel a PIC-ekkel sporolni, amiket amugy bele kellene tenni az aramkorbe ha mas microcontrollert hasznal az ember.

Tamas

Ez nem is rossz otlet, de eleg idoigenyes sajnos kikeresni a dolgokat azokat dokumentalgatni es osszehasonlitgatni a meglevo visszaforditott assembly kodreszletekkel. Nem beszelve arrol, hogy a C forditok tobbsegeben vannak kod optimalizalo eljarasok amik a forditas soran elegge eltero gepi kodokat tudnak produkalni.

PC-re letezik egy IDA nevu visszafordito program (marmint x86-os procira es DOS/Windows-os es ujabban Linuxos inarisokra). Ebben ket nagy otlet van:

1. Interaktivan lehet a cimkeket, valtozokat stb definialgatni, atnevezni stb (innen a neve is: Interactive Dis Assembler)

2. Eleg sokfajta fordito konyvtarat felismeri igy a fuggvenyek tobbseget megnevesiti es segit a parameterek kibogozasaban is. Pl. felismeri a printf-et, igy ugyan a visszaforditott kod assembly marad, megis lehet tudni, hogy epp a printf fuggvenyt hivja meg ilyen es olyan parameterekkel. Ha szerencseje van az embernek akkor a konyvtari rutinok nem forrasban vannak hanem LIB file-okban (forditott allapotban de meg linkeles elott) ugyanis akkor mar nem optimalizalgat rajta a fordito. Ha megnezed a PICC dolgatit pl, akkor felfedezheto, hogy a Drivers konyvtarakban forrasban vannak meg alapveto funkciok, mint pl a putc, mig a printf-et nem talalni, azt megmondom oszinten nem tudom hova dugtak el, de az csak a konverzios rutinokat szorja bele nagy valoszinuseggel a kodba mig a kiirast ezek a driverek vegzik. Nem vizsgaltam meg hogy mukodik, de feltetelezesem szerint a konyvtari fuggvenyeket is optimalizalja es a hozza tartozo drivereket is - mivel azok eleve forrasban vannak leteve. Egyszoval felismerni, hogy a sok konverzios rutin hivogatas meg a driver kodjanak hivogatasa egy printf nem biztos, hogy egyszeru feladat.

Egy gyakorlott reverse engineer sok C szerkezetet is felismer rapillantasra, persze ha a kod nincs agyonoptimalizalva - de ugyanezt automataval visszaszedni igazi C kodda majdhogynem lehetetlen - legalabbis kielegito hatekonysagot nem lehet elerni hacsak a C fordito garat=ntaltan ugyanazt a kodsort nem forditja minden egyes esetben - de ha ez igy van akkor kosz, az a C fordito nekem nem kell (ugyanis nem optimalizal).

Sokat segitett volna, ha lett volna CVS felinstallalva a gepre es rendszeresen tortent volna kod update - igy meg a fejlesztes szakaszaiban torteno valtozasokat is vissza lehet keresni, es van egy biztonsagi backup. Ha lenne egy LST file, az is nagy segitseg lehet... de gondolom nincs az sem.

Oszinte resztvetem
Tamas

Mivan, itt nem alszik senki?
Ezen okulva még sűrűbben fogok mentegetni! Mert ugye okos ember más kárán... A másik fontos következtetés, hogy ne tartsuk ott a fontos adatainkat, ahová a rendszert telepítjük! És még így is el szokott felejtődni néhány fontos adat(háttérkép, indulóhang, hálózati beállítások, meg ilyenek... )

Dehogynem alszik, mindenki alszik, csak en csalok az idoeltolodassal

Na igen, a munkahelyi gepem az jol van megalkotva, ott a C-n csak a Win es a Program Files van meg, a D-n meg a Document and Settings - es eleg sokaig kovettem a gyakorlatot, hogy minden a D&S alatt volt igy tudtam melyik konyvtarat kell menteni, aztan kezdett borulni minden, pl CVS repository-ja a fokonyvtarbol nyilik, aztan az MPLAB nem volt hajlando mukodni mert a konyvtarnev nem lehet hoszabb 28 karakternel (persze ki is kapcsolhatom a COD file genmeralast, de akkor meg mi ertelme van az egesznek, akkor mar inkabb VIM-ben szerkesztem a szoveget es parancssorbol indiutom a forditast )

Ja es a lenyeg: C: le van Ghostolva, igy a hatterkep megmarad Az otthoni gepemen meg nem torodtem ilyenekkel, de hasznalok egy ingyenes backup szoftvert, a Comodo ceg backup programjat - mas erdekessegek is vannak ott, pl a Firewall-re sok tesztelo ceg azt mondja az egyik legjobb - megis ingyenes es nem adware. AV-je nem versenykepes a nagy AV cegek termekeivel ugyan, de ugy tudom a gyakorlatban felbukkano peldanyokat azert elkapja.

Na most ez jo offtopic lett, remelem azert hasznos lehet a PIC fejlesztok szamara

Mondjuk úgy, ez a téma a PIC programfejlesztés adatvédelmének egyik fontos aspektusa!
Köszi a tippeket, megnézem azt a backup-os oldalt!

Annyira nem káromkodtam, csak amikor egy lefagyás után nem működött a billentyűzet, akkor elkezdtem gondolkodoni azon, hogy hol lehet a hiba az átalakító programjában, és akkor esett le, hogy elfelejtettem lementeni.

A C nyelv gyakorlására gondolsz? Most megpróbálom az egészet C18-ban újraírni. Ez CCS-ben volt, mert ott volt példaprogram több Interface-t tartalmazó USB HID-re, és örömömben beraktam egy sima billentyűzetet, egy multimédiás billentyűzetet, egeret és joystick-ot is. Meg akartam még valami mást is, csak nem foglalkoztam vele utána. A régi billentyűzetemet meg kölcsönadtam, szóval nincs is mivel tesztelni az új programot, de majd elvileg visszakapom valamikor. Ha meg nem, akkor kukázok egyet valahonnan. Egyelőre úgysincs időm ezzel foglalkozni, majd talán egy hónap múlva, akkor ér véget a vizsgaidőszak az egyetemen.

Mellesleg nem szoktam a rendszer mellett tartani a cuccokat, minden mást a D-n tartok, csak ez most valahogy ott maradt a CCS (asszem) samples könyvtárában.

miaz a PIC?

Mi az a PIC

Mar egyszer valaszoltam neki potyo, de ugy hiszem elkerulte a figyelmet

Remelem az alahuzott valaszodra rakattint

bocs! tényleg nem vetterm ésdzre pedig kerestem....

elolvasrtam...akkor ezt lehet az audioelektronikában is használni?

akár ott is lehet használni. de pontosan mir szeretnéd?

hi
mint már említettem most kezdek a pic progizással foglalkozni, és kezdésnek (amíg nem jön meg a 16F877,18F4321,18F2321) a topi féle "nulláról a..." cikkben található futófényes progit próbálom meg átírni 16F628-ra.
az egész sikerült is minden király, egy fontos dolog kivételével, ez pedig a bankok közötti váltás.

BSF STATUS,PR0 parancsal nem vált át a bank1-re. de nem csak így nem vált, hanem se a:
BCF STATUS,PR1
BSF STATUS,PR0

se egyik lehetségs kombinációval sem.

hogyan lehet akkor átváltani ha nem így?

ui: most eszembe jutott még1, de lehet hogy full hülyeség:
MOVLW B"011"
MOVWF STATUS

nem tuom hogy workbe lehet-e így tölteni, mármint hogy csak az első 3 bit értékét adjuk meg a többiét nem, mert azokon nem akarok változtani

na megpróbáltam ezt a verziót is, de így sem volt jó, legalábbis amikor az MPLAB átkonvertálja HEX-re akkor kiírja ugyan hogy "build was succesfull", de ott van az is, hogy a TRISA és TRISB register nem a BANK0 van.
és miután beégetem nem történik semmi

Szia,

Ilyen uzenetekkel ne foglalkozz, az csak figyelmeztetes, hogy bele tetted-e a bankkezelest. MPLAB-ban a szimulatoron kovesd vegig a programot es nezd meg, hogy a megfelelo erteket olvasod-e/irod-e.

A MOVWF nem hulyeseg, de ovatossagbol nem irnam at az osszes status bitet.

Az a helyzet, hogy ahany MCU annyi fajta bankkezeles letezik (ez igy nem igaz de majdnem), igy jobban jarsz, ha raszoksz az MPASM belso makrojara, amit ugy hivnak, hogy BANKSEL.

Szoval csak annyit kell csinalnod, hogy:



De pl ha tudod, hogy valtozo1 es valtozo2 ugyanazon a bankon van akkor nem kell nyilvan valoan a masodik BANKSEL... Ez a modszer mukodik az osszes PIC-en, es nem kell tudnod, hogy a STATUS-ban van-e a bank selection vagy mashol, hany bites, sot ha valtozo1-et kesobb atrakod masik bankra akkor is mukodik a dolog...

MPLAB Help-jeben ezek nagyon jol le vannak irva, erdemes az Assembly szekciot tuzetesen atolvasni mert mas hasznossagok is benne vannak.

Udv,
Tamas
UI: De bolondul mukodik a [ code ] dolog

szerk. [ c o d e = c ] ill. [ c o d e = a s m ]. deguss

ok köszi, kipróbálom.
ja még 1 dolog közben eszembe jutott:
a 16F877-es verzióban van egy olyan rész hogy

és magyarázatnak oda van írva hogy "mindegyik PORTA digitális"
de ilyen regiszter nincs a 628-nál, szóval ezt a két sort ki kellett törölni, mert hibásnak jelezte a progit, és nem fordította le. szóval ez a 2 sor nagyon fog hiányozni, és van valami regiszter a 628-nál amivel lehet helyettesíteni, vagy nem anniyra fontos?

Mikor egy kodot atteszel egy masik MCU-ra, akkor egyszerre ket adatlapot kell nezned. Nezed a regit, es nezed az ujat. A portok kiosztasa ill felprogramozasa szokott a legtobb problema lenni, szoval nezd meg mi volt az eredeti program celja - jelen esetben, hogy digitalis ki/be meneteket csinljon a PORTA-n, ugyhogy nezd meg az uj PIC-ed adatlapjat, abban gyakran van peldaprogram, hogy hogyan kell portokat inicializalni, leirjak, hogy milyen regiszterek erintettek a PORTA-val kapcolatosan stb es az eredeti rutint ennek megfeleloen at kell irni vagy lecserelni az egeszet egy ujra. Szoval most ha megnezed pl az ADDCON1-et, hogy az mire valo es mi tortenik ha 0x06-ot beletesznek a 877 eseten, akkor utana nezd meg, hogy hasonlo funkcioja van-e a 628-nak es mit kell csinalna ahhoz, hogy ugyanaz legyen a beallitasa (melyik regiszter(ek) milyen ertekekkel).

Udv,
Tamas

Sziasztok!
Végre „megoldódott” a rejtélyes PIC működés. Bármely lógó kivezetését gnd kötöttem akkor működött. Gondoltam ez nem normális dolog. Kértem kölcsön egy scopot és elkezdtem méregetni (táp, resonátor, alkatrészek,stb). Mivel nem találtam meg hogy mi lehet az oka a rejtélyes működésnek kicseréltem egy másik PIC-re. Azóta tökéletesen működik. A PiC volt a hibás.

Nagyon köszönöm a fáradozásotokat és a segítségeteket és a tanácsokat.

BlackStar

Orulok, hogy megoldodott a problema, BlackStar. Pusztan kivancsisagbol kerdem, hogy ha a masik Vss-t huzod le a foldre akkor mukodik-e az a tonkrement PIC?

Felmerült bennem is hogy esetleg szakadás lenne PiCen belül a két vss láb közzött. Megnéztem nincs szakadás a két láb közt. Sajnos akkor is ugyan az a helyzet ha a másik vss-re kötöm a gnd-t. olyan mintha a PiC belül el lenne kötve mert a kettö vss láb nem funkcionál. Mivel ha egyik vss lábra sem kötöm a gnd-t csak a vdd van kötve a PiCre és a gnd-t egy nem hasznát lábra kötöm akkor a PiC üzemel. :yes:
Jól meszivatott az tény