Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ja...
Ha van időd, nézz be légyszi az ethernetes topicba!
Ötleteket várok PIC tartalom kiolvasás illetve adat lementés védelmére. Beszéljük ki, hátha másoknak is tippeket adunk. Komplett védelem, csak memoria tartalom védelme, jelszavas lezárás, stb.
Ha illegális, ha nem, ha egy lezárt PIC-et valaki ki tud olvasni, persze aki nem a titkosszolgálatnál dolgozik, annak szobrot állítok. Úgyhogy ha feltörésről álmodik a kérdező, majd felébred. Ha meg csak a programja védelmét szeretné megoldani, akkor javaslom neki a megfelelő konfig bitek beállítását.
Csatlakozom watt mesterhez: Allitsd be a megfelelo config biteket es meg is van oldva a dolog.
Persze van meg par aprosag amit erdemes tudni, az egyik kiderul az adatlapbol, a masik pedig kis logika: 1. Ami kiderul: Nehany PIC nem kepes az egesz teruletet levedeni, mindig maradnak teruletek amik vedtelenek -- mint pl a 10F sorozat ahol az elso ha jol emlekszem 40 byte vedtelen, na meg a legvegen az osccon. Namost ezekbol lehet tamadasokat inditani, mint pl probalgatasos modszerrel elugrani kulonbozo kod teruletekre, es pl biztonsagi rendszerek mukodeset lehet befolyasolni ilyen modszerekkel. Emiatt ilyen alkalmazasokra ezek a chipek nem javallottak. 2. Ha bootloadert hasznalsz es a felhasznaloidnak szoktal firmware frissitest kuldeni, akkor erdemes a firmware-t titkositassal ellatni. Azaz a firmware titkositva van, es a bootloader az ami egyreszt ellenorzni a firmware valodisagat (azaz, hogy Te csinaltad), masreszt elvegzi a kititkositast -- magyaran hiaba kapja a user kezhez a file-t, nem tudja a tartalmat megallapitani mivel nem tudja kititkositani, sot nem is tud akarmilyen firmware-t feltolteni, hiszen az ellen is vedve van. 3. A firmware ha user inputokat var, akkor nagyon korultekintoen kell megirni, hogy ne lehessen exploitalni. Magyaran a felhasznalo ne tudjon olyan inputot beadni aminek hatasara a firmware nem vart dolgokat muvel, aminek az eredmenye pl a firmware tartalmanak kiolvasasa lehet (pl ha egy ROM-ban tarolt tablazat tartalmat elkuldozgeti USB-n vagy RS232-n keresztul, akkor nehogy bekovetkezhessen, hogy valaminek hatasara a tablat roszul cimzi es emiatt a firmware-t vagy annak reszletet kuldi el)
Nana !
Ezt azért kikérem magunknak. 8 éves korom óta foglakozom elektronikával , még germánium tranyókkal kezdtem , ésTTl ic vel terveztem riasztó központokat, mert akkoriban még nem volt ilyen. 4-5 éve fejlesztek PLC re alkalmazásokat. Még most is tanulok belőle. A parsic -hoz is kell tudás !!! Az sem olyan egyszerű !
Hát ahogy gondolod. Nem érdemes lelki kérdést csinálni ebből, de egy PIC nem PLC. Én egy PAC-et bűvölgetek parsic szerű nyelven, de nem vagyok tőle elájulva, mert több a korlát, mint a haszon...
Idézet: Mit? „Ezt azért kikérem magunknak.”
)))))
Ezt : erdeszek, cukraszok, takaritonok, es szemetesfiuk " A többi "másként gondolkodó" nevében , akik nem a bonyolultabb végén fogták meg a dolgot. Szerintem nem kellene lenézni őket sem . Nagyon elment OFF - ba , mindenkitől elnézést kérek , hogy foglaltam a szervert emiatt ! Átjelentkezem a másik topic ba. mezga END sub
Az tény, hogy ezt a nyelvet arra találták ki, hogy ne kelljen ismerni a PIC felépítését, valamint rendes nyelvet ne kelljen megtanulni. Olyan, mint ha valaki mutogatna, vagy rajzolgatna külföldön. Végül is megérteti magát, de hosszú távon nem sokra fog menni. Ez nem lenézés, ez valóság.
Idézet: Pedig nem is arra válaszoltál! Erről ennyit... „Ezt : erdeszek, cukraszok, takaritonok, es szemetesfiuk "”
Szia!
Egy kicsit nehezen találtam meg... A Microchip fórumának Szimulátor topikjából: Idézet: „It seems to me the simulator always executes in extended instruction mode. I have the configuration bit set to legacy, but still emulator finds the access bank at the address of FSR2. c018*.o modifies FSR2 to point to stack which is by default at 0xD00. Therefore when you try to use ACCESS bank it'll modify file registers above 0xD00 instead of 0.”
Ez csak a PIC18F97J60-ra vonatkozik, ugye?
Tisztelt Köbzoli.
A kérdést, illetve ötletet nem illegális, hanem legális, adatvédelmi célból vetettem fel. Nem kiolvasni, hanem levédeni akarom a PIC tartalmat, a célból, hogy mások, többek között az én általam kifejlesztett PIC tartalmat egy élelmes "élősködő" ne tudja szériában terjeszteni. Gondolom, Te sem szeretnéd, hogy a kifejlesztett termékedet másnap már viszontlásd a piacon. PIC-et nem feltörni. levédeni akarok a fent leírtak miatt. Tisztelettel: alux
Sziasztok,
PIC18F46J11 alatt szeretnék deep sleep-be váltani, a C kód az alábbi:
A probléma, hogy a CPU nem mindig kerül deep sleep állapotba, sőt, a Sleep() után található utasításokat kezdi el feldolgozni. Deep sleep-ből a proci power-on-reset-tel indul, azaz, a Sleep() utáni utasításokat nem hajthatná végre. Azt tapasztalom, hogy az esetek ~50%-ban a proci szépen elmegy deep sleep-be, míg máskor AZONNAL ráfut a Sleep() utáni utasításokra, azaz deep sleep helyett még sleep állapot sem következik be. (Sleep-ből és deep sleep-ből int0, rtc wakeup vagy reset "ébreszthet", viszont sima sleep után a sleep utáni utasítással folytatja a proci a munkát, deep sleep-ből POR-ral ébred.) Tudom, hogy a DSCONH.DSEN bitjének beállítása és a sleep utasítás végrehajtása közé nem kerülhet egyéb utasítás, mert az utasításciklusok száma kritikus a mód szempontjából. Nézegettem a fordított assembly kódot, a DSEN-t beállító BCF utasítást közvetlenül a SLEEP követi. Próbáltam azt is, hogy a Work regiszter tartalmát egy-az-egyben írtam a DSCONH-ba, de az sem segített. Minden ötletet, javaslatot, örömmel fogadok. Köszönöm!
1. Megszakitas legyen tiltva, es az osszes lehetseges interrupt flag legyen nullazva a sleep elott.
2. Config-ban mindent nezz at mi az ami felebresztheti sleep modbol es azokat megfeleloen allitsd be 3. Vegtelen ciklusba tedd a Sleep() -et es az elotte levo inicializalos reszt (ha egyaltalan nem hajlando elaludni akkor a fogyasztasbol meg fogod latni, de lehet 2. vagy 3. Sleep() -re mar elalmosodik az eszkoz, ill. ha valami felebresztene amit nem szeretnel, hogy fleebressze akkor azonnal vissza is altatod...)
Szia!
Nem próbáltam, csak annyit tudok, ami a belinkelt topikban is olvasható. Ott csak a PIC18F97J60 -et említik. A probléma a 8.63 verzióban is benne van, a szimulátor verziója nem változott...
Köszönöm!
A problémát az okozza, hogy deep sleep-be lépés előtt az RF modultól elveszem a tápot, majd az egyébként RF_IRQ bemenetként használt lábat (RC2) kimenetnek konfigurálom és 0-ba állítom. Ha az alábbi két utasítást kikommentezem, mindig sikerül a deep sleep:
Megszakítás generálódna? A fenti utasítások előtt, már korábban tiltom a globális megszakításokat: GIE=0; PEIE=0. Miért, hogyan zavar be a fenti két utasítás?
Ha a GIE tiltva van, attol csak annyi tortenik, hogy nem lesz megszakitasod, de ettol fuggetlen a megszakitas jelzok meg elnek. Ezek pedig azt okozzak, hogy sleep-bol felebred az MCU es mivel nincs megszakitas engedelyezve egyszeruen folytatja a mukodest a sleep utani utasitassal. Mielott elmesz sleep-be probaldd meg az RC2-hoz rendelt megszakitas jelzoket torolni (csakugy mintha azt megszakitasbol tetted volna). De ettol fuggetlen a ciklus nem arthat... tehat ha fel is ebred elmegy megint aludni es nem kodorog el a kodod...
Talán ki lehetne debugolni, hogy melyik interrupt flag ébresztheti fel. A sleep utáni részben vagy valami ICD-s megoldással tenni egy töréspontot és megnézni az interrupt-flag regisztereket, vagy ha ez nem lehetséges, akkor ezeket az értékeket valamilyen módon kiküldeni a külvilágba (pl. soros porton). Biztos, hogy valamelyik flag magas, és amiatt ébred fel azonnal az alvásból.
Gondolom olvastad a megoldást trudnai mestertől: Bővebben: Link
Konkrétumokat akkor tudunk mondani, ha megmondod milyen PIC-ről van szó.
Igazad volt. Ciklusba szerveztem a deep sleep részt, ahol még pluszban töröltem az interrupt flag-eket. INTCON3.INT3IF volt felelős az ébredésért, jogosan, hiszen magam állítottam RC2-őt outputba és 0-ba, ezzel megszakítást generálva.
Nagyon köszönöm!
Üdv mindenkinek
Wattol kaptam egy v4 rajzot mint PIC égető Kérdésem az mikor melyik lednek kell világitania? Üdv Feri
Sziasztok.
Megírtam a Nulláról a robotokig - PIC Mikrovezérlők I rész -ből a HI-TECH C (19. oldal) programrészt MPLAB-ban, persze feltettem a Hi-Tech C -t is, beimportáltam az MPLAB-ba is de mikor lefuttatom ez a hibaüzenetet kapom: Executing: "C:\Program Files\HI-TECH Software\PICC\std\9.60\bin\picc.exe" -C -E"delay.cce" "hitech\delay.c" -O"delay.obj" -Zg9 -O -ASMLIST -Q -MPLAB -16F877 Halting build on first failure as requested. BUILD FAILED: Thu Feb 24 21:03:08 2011 Mit rontottam el? (még kezdő vagyok a pic-ek terén, a C nyelvet vágom ) Előre is köszönöm válaszaitokat
Lenne egy jólelkű ember Debrecenben vagy környékén, aki ki tudna égetni egy PIC16F84A-04/P típusu picet, mert a suliba olyan feladatot kaptam hogy csináljak digitális hőmérőt, és most csak ezért nem szeretnék égetőt építeni. A segítséget előlre is köszönöm!
Én is szívesen beégetném, de nem hiszem hogy közel laknánk, de sokkal nagyobb problémának látom azt, hogy te elsőre soha nem fogsz működő programot írni(abból indolok ki, hogy nekem is ritkán sikerül, mondjuk soha ), tehát az egy égetés nem lesz elég valószínű!
Igen! A nagy precizitású hőmérőt szeretném megépíteni, ami megtalálható a kapcsolásokban, és elvileg ezt kéne beégetni
Utánépítés a feladat, vagy a program megírása is?
|
Bejelentkezés
Hirdetés |