Ha Pic le van védve kiolvasás ellen ,Hogyan lehet feltörni?

Chip Erase parancs feloldja a védelmet , de a tartalmat is törli

Hali
Pl kis vagokoronggal levagod a tetejet, majd mikroszkoppal kisilabizalod a flash bitjeit. Amugy arra talatak ki a kodvedelmet, hogy meg tudd vedeni a kododat a lopicsekektol. A HW-t altalaban konnyu masolni, de a SW-ert meg kell dolgozni.

Szia!
A könyv amit ajánlottál fent van az oldaladon itt? Köszi.

Ja. Ez a konyv a CCS team szerzemenye, de nem mai termes. szepen leir sokmindent a C programozasrol, es kulon a CCS szintaktikajarol, trukkjeirol. De talasz meg az oldalon mintapeldakat is.

JDM égetőm van, és pic16f690 -hez keresek kezdőnek is kezelhető programot.(de gondolkozok itt közölt JDM égetőn is,az tuti legalább hogy jó és hogy az.)

Olvass utána erről az oldalamon...
Ha jó soros égetőt akarsz építeni, a WCOM_v4-et, vagy 5-öt ajánlom(hmli-nek van nyákterve is az 5-höz).

Köszi a segítséget.
Először csak működjön a dolog és utána úgyis fejlődik a dolog és bővítem tudást-eszközöket. De ha egyerű ez a wcom_v5 akkor ez lesz.

Na hát pont ez az...

Leginkább a Low Pin Count demókártya mintaprogramjait nézd meg!

Kiolvasas ellen van hardware-es vedelem (code protection), ha pedig azt szeretned, hogy a PIC bekapcsolas (vagy mas esemeny) utan csak akkor csinaljon valamit ha begepelsz egy jelszot, akkor azt neked kell leprogramoznod. Ha bele gondolsz a riasztok is igy mukodnek...

JDM programozóról itt a fórumon már sokszor lebeszélték a kérdezőket (nem véletlenül). Régi számítógépen, leginkább DOS alatt tökéletesen működik. A mai soros portok általában nem megfelelőek. (nem tudják az RS 232 minden előírását!!) Régebbi CNC vezérlőknél ezzel kínlódunk. Én a PICkit 2-t javasolnám még, "watt" javaslatán kívül. Ez nemcsak égetni tud... (JDM az ICPROG.EXE -vel megy, ingyenes - letölthető)

Nem a soros portokkal van a baj, azok teljesítik a szabványt. Esetleg pont a régiek nem! A szabvány szerint a -3 +3 V közötti feszültség nem értelmezett. A JDM viszont csak +5, vagy 0V-ot tud kiadni a viszirányú adatvezetékén, azaz elvileg nem működhet egy a szabványt teljesítő porton! (részletesebben az oldalamon a cikkben...)

Idézet:
„A mai soros portok általában nem megfelelőek. (nem tudják az RS 232 minden előírását!!) ”
Nem tudom megmondani, hogy mi a baj a "mai" soros portokkal, talán a terhelt kimeneti jelszint. '70-e évek óta használunk soros portokat NC-CNC gépek adatbevitelére. Kollégák által fejlesztett eszközökkel is, gond csak azóta van amióta megjelent az USB. Próbálkoztunk az USB-soros átalakítókkal is, de ezek is hol működnek-hol nem. Eddig a bevált módszer a következő: lomokból összelapátolt max. 486-os gép vagy régi laptop amin még nincs USB. Ezért írtam amit írtam, nem a JDM-et akartam védeni. Egyébként 486-os gépen a JDM programozóm hibátlanul működött.

Újabb fejezettel gyarapodott a PIC-kwik projekt (Mesterkedések pic24 és
dspic33 mikrovezérlőkkel): Szinkron soros perifériák - I2C és SPI

A fejezet tartalma:

* Az I2C kommunikációs csatorna
* Az I2C egység felépítése és működése
- Az I2CxCON regiszter
- Az I2CxSTAT státuszregiszter
* I2C támogatói függvények
* I2C kommunikáció a TCN75 digitális hőmérővel (tcn75_i2c.c )
* A DS1621 digitális hőmérő használata (ds1621_i2c.c)
* A DS1631 digitális hőmérő használata (ds1631_i2c.c)
* 24LC515 típusú EEPROM írása és olvasása (mcp24lc515_i2c.c)
* Az MCP23017 portbővító IC használata (mcp23017.c)
* Az SPI kommunikációs csatorna
* Az SPI egységek felépítése és működése
* SPI támogatói függvények
* A DS1722 digitális hőmérő használata (ds1722_spi.c)
* 25LC256 típusú SPI EEPROM használata (mcp25lc256_spi_eeprom.c)
* SPI master-slave kommunikáció két mikrovezérlővel (spi_master_revstring.c, spi_slave_revstring.c)
* MCP41xxx digitális potenciométer vezérlése (mcp41xxx_spi_pot.c)

Újdonság, hogy ezentúl a PIC24 támogatói programkönyvtár a dsPIC33 sorozat tagjait is támogatja. A két mikrovezérlő SPI kommunikációját bemutató példában slave-ként dsPIC33FJ128GP802 mikrovezérlőt használtam.

Halmozzuk az élvezeteket: PIC24HJ128GP502 és dsPIC33FJ128GP802 kommunikál SPI buszon, s a háttérben látható, PIC18F14K50-ből kialakított USB-UART konverter segítségével a PC-hez is kapcsolódunk.

Én csak arra reagáltam, hogy a soros port szabványa szerint a JDM elvileg nem működhet.
Lehet, hogy több olyan alkalmazás volt, van(lenne) alkalmazásban, ami kihasználta a régi soros portok "szabványtalanságát".
Gondolom belátod, hogy ha -3V alatt kéne logikai magas szintet érzékelnie a port bemeneteinek, akkor a TTL, vagy CMOS áramköröktől várható 0V, soha nem eredményezhetne 1-et! Ez sok esetben meg is tőrténik, azaz pl. nem működik a JDM.

Az USB-RS232 átalakítók nem képesek a direkt jelek átvitelére. Szintén csak a szabvány szerinti kommunikációra képesek(már amelyik teljesíti azt), mert más időzített jelváltást elrontja az USB pollingja. Ezért direkt vezérlésre, mint pl. egy égető áramkör, vagy CNC vezérlő, stb., ami kihasználná ezt a lehetőséget, nem alkalmas.

Nem vitatom, hogy a régi akaplapokkal eredményt lehet felmutatni, ennek megvannak az okai, de nem az hogy azok voltak a jobbak a szabvány teljesítésében.

A régi soros portokhoz ott volt a +/-12V a tápról. Egy USB-s átalakító meg ha MAX232-es vagy hasonló áramkörrel oldja meg a magasabb kimenőfeszültséget, akkor a duplázással is csak legfejjebb 10V-ig jut el. Szerintem ezért nem úgy működnek az USB-s soros portok, mint a régi multi i/o kártyákon levők. A JDM programozómat én arról az oldalról védeném, hogy működik. És én nem az a tanárnéni, vagy tanárbácsi vagyok, aki azért ad a gyereknek elégtelen osztályzatot a dolgozatára a jó eredmény ellenére, mert valahol egy számítási hibát vétett és elvileg nem jöhetett volna ki a jó eredmény. A programozóm működik, tehát nekem jó. Másnak én sem ajánlom, mert már nincs értelme. Ma vettem a fáradtságot és utánanéztem, mi is az az open programmer amit az egyik felhasználó lelkesen javasolt a PIKlab fejlesztőjének a programozók közé felvenni. Szóval ezt inkább javasolnám másoknak is megépíteni, mint JDM-et. A JDM maradjon meg emlékbe, de ahogy Watt is javasolja, ne építse senki.
És végül nemgyurinak a magyarázataimmal kiegészített megszakításkezelő, amihez még annyi, hogy nem volt szép rtf formátumban mentenie az asm állományt. Meg talán még annyit, hogy ha bár az MPlab engedi a magyar abc ékezetes betűit használni, én javasolnám neki is és minenkinek elkerülni a használatukat. Rejtélyes hibákat okozhat. Nekem még idáig elég volt az angol ABC meg számok, meg alahuzas.

Én is most már lebeszéltem magam erről a régi égetőről.
Nem szenvedek tovább ezzel az áramkörrel ,megy a sarokba.
Én is olvastam már sok helyen hogy nem jó választás+ milyen lehetőségek vannak, csak ha már ajándék volt........
Csak a pic fejlesztésre raktam össze 1 p3 gépet a régi(egyszerű) programok miatt.( de már usb-s).
Ha esetleg kéne p2-p1 korszakból gép alkatrész adok szívesen, ne keljen lomokból (:

Ideiglenes, watt!
Lehet, hogy nem fogalmaztam jól! Én sem használom már régóta a JDM programozómat, pontosan azokért a várható hibákért amit "watt" honlapjában részletesen kifejt. Csak arra utaltam, hogy amíg használtam nem volt vele problémám. Azt azért nem hiszem, hogy a nagy CNC gyártók nem a szabványnak megfelelő soros port kezelő hardware-t építenék be a vezérlőkbe, az újabb számítógépekkel viszont általában nem tudnak kommunikálni. Az rtf formátumért bocsánatot kérek, legközelebb jobban figyelek. (nekem a LISTER és a WORD PAD is úgy van beállítva, hogy normálisan olvasható, mégegyszer bocs) Az átírt változatodat lepróbálom, ha rövidebb a idő alatt lefut, azt fogom használni, köszi.

Idézet:
„Azt azért nem hiszem, hogy a nagy CNC gyártók nem a szabványnak megfelelő soros port kezelő hardware-t építenék be a vezérlőkbe, az újabb számítógépekkel viszont általában nem tudnak kommunikálni.”

Ezt csak akkor lehetne megmondani, ha ismernénk a kapcsolásukat. Én tudok olyan ipari hőfokszabályzó műszereket mutatni, amikben van soros kommunikáció, de viszirányban TTL illesztéssel. Nem említi a gyártó, csak ha nem működik a felhasználónak(ugyanis van olyan PC, amin működik), ezért az rákérdez...
Egyébként az első égetőm egy PonyProg volt, gyakorlatilag egy JDM. Az első P2-esemen működött, a többin nem, jókat szívtam vele!

Rövidebb futásidőt nem ígértem, sőt, mást sem. A mellékelt sémát javaslom a megszakításkezeléshez, mert sokkal átláthatóbb, hogy mikor merre megy a program. Ha ilyen vagy ehhez hasonló sémával állítod össze a megszakításrendszert, akkor a hibát könnyebb felfedezni. A 690-esnél a következők miatt voltak gondjaim:
- amikor megszakítási esemény bekövetkezik, a programfutás átkerül a 0x0004-es címre. Ez a 0. lap, de a PCLATH regiszter nem feltétlenül ide van beállítva, így a legelső goto utasítás a futási szálat elviszi valahova arra a lapra, ahová a PCLATH éppen mutat.
- a regiszterbankok kezelésére a megszakítás feldolgozása alatt szintén oda kell figyelni. Azt nehéz előre megjósolni, hogy a megszakításba belépéskor melyik volt az aktuális regiszterbank. Ezért a szükséges regisztermentések után már ki kell választani a megfelelő bankot.
- a megszakítási rendszer a nyolcszintű veremtárból egyet visz. A maradék hét szinttel tehát óvatosan kell gazdálkodni és a CALL utasításokat ésszel kell betenni bárhova is. Ha a megszakítási rendszerbe CALL kerül, az tovább ront a helyzeten. Minden egyes CALL utasítás a megszakítási folyamatban egyel csökkenti a főhurokban használható veremméretet.

Sziasztok!

Nem értem miért nem jók a gyári függvények CCS-ben?!


A beadott adatokat 0..814-ig jól kezeli, de 815...818 között értelmetlen adatot ad a 0.00 formátum helyett 0.:0 és 0.:1 -ad vissza. 819-től a következő egyes helyiérték váltásáig megint jó de 1.99 -nél megint a feni hiba, 2.99 - 3.99 - 4.99 megint. Honnan szedi a kettőspontot?!
Így hívom a függvényt:


Előre is köszönöm a segítségeket, és elnézést, hogy ilyen semmitmondó problémákkal zavarlak benneteket!
Sanya

Sziasztok!
Egy kis segítséget kérnék LCD vezérléssel kapcsolatban.
Van egy 2*16 os ST7066U vezérlős LCD kijelzőm ami adatlapja szerint kompatibilis HD44780-vel.
Mikrobasicban írom a programot rá, és itt az LCD8_ parancsokkal szeretném használni.
Az inicializálás szépen működik, illetve karakter léptető stb. parancsok is működnek, ám amikor LCD8_OUT paranccsal ki szeretnék íratni valamit nem működik.
Ilyenkor az LCD teljesen elveszti az inicializálás beállítását és visszaáll egy soros állapotba, és a kurzor is a kezdő pozícióba. Szerintem valami a register select-tel lehet, ugyanis amíg 0, addig jól működik de amint 1 re kéne váltson valamit nem jelez ki semmit.Ellenőriztem a bekötést és tökéletes. Leszimuláltam Pic szimulátorral és ott működik a program.
Tudnátok segíteni mi lehet a gond? Esetleg az LCD vezérlő működik másképp mint a beépített LCD függvények?

8 bites bekötéssel használod?

Igen.

13.sor végén:

szerintem, de számold át!

Ja, és 9.sor nem kell.

Szia!

A ':' kódja 0x3A, az egész osztás kerekítési / csonkolási hibái miatt a számjegyek között előfordul a .10 = 0x0A is.

A feladat egyszerűbben is megoldható. A Data értékét 0 .. 500 közé képezd le, ezen a számon végezd el a decimálissá alakítást. Ha a legkiszebb decimális számjegynél kezded, akkor a moduló ( % ) 10 megadja a az aktuális számjegyet ( +'0' karakterré konvertálja ), ezután csak osztani kell 10 -zel. Mehet a ciklus mind a 3 jegyre....

Biztosan azért van, mert nem vagyok elég gyakorlott, de én nem látom, hogy mit szeretne Sanyi a függvényével megvalósítani.
Szóval most értetlenül nézek, mert a két javaslat ellenére sem értem, hogy mi lenne a feladata. Ha bináris decimális átalakítás lenne, arra vannak sokkal elegánsabb megoldások. Viszont nekem nem annak tűnik. Vagy esetleg hexadecimális?

Sziasztok,
PIC -et PC-vel egy USB-RS485 átalakítóval kötök össze, ebben van egy FTDI és SN75176 chip, ezért a pic mögé is raktam egy Sn75176-ot. Kérdésem annyi lenne hogy : hogy oldjam meg a kommunikáció gond nélküli áramlását ha az RE és DE lábakat is vezérelnem kéne közben ? Interruptos megoldással egy buffert tölt fel írásnál és olvasásnál is, de ugye mindkét módnál más állapotban kell lenniük a vezérlő lábaknak. Icserny projectje az alap.
Előre is köszi minden hozzászólást .

Szia!

A leírásod szerint 2 vezetékes RS485 konfigurációd van, amin a kommunikáció half duplex. Kétféle egység van, a master és a slave. A marter kezdeményezi az átviteleket, ami a mester és a megcímzett slave között történi. A slave általában figyeli az adatvezetékeket, veszi a táviratot. Ha megérkezett egy távirat, akkor eldönti, hogy neki szól-e. Csak az a slave válaszol, akinek a távirat szólt, a válasz karaktereit elküldi a vonalon. Csak az adása idejére kapcsolja be az adó meghejtóit. A master a távirat kiadása után várakozik a válaszra. Ha az időkorlát alatt beérkezik a válasz, akkor dekódolja, ellenőrzi, feldolgozza, ha jó a válasz. Ha nem jó, nem attól a slave-től érkezik, aminek szólt a távirat vagy nem érkezett meg, ismételten elküldi. A master is csak az adásának idejére kapcsolja be az adó meghajtóit.

Hibaellenőrzésre, ütközés detektálása felhasználható a saját adás vétele. Ha a saját adás vétele nem azokat az adatokat dekódolja, mint amit elküldött, feltehetőleg másik meghajtó is be van kapcsolva az adás ideje alatt.

A protokol sokféle lehet: pl. MODBUS, IEC 60870-5-103, stb