Köszönöm! Igy már kezd tisżtulni! Na valamit akkor csak össze tudok hozni!

Tisztelt PIC programozók!!

Egy ST62T30B mikrovezérlőből szeretném kiolvasni a programot ill. utána egy másik ugyanilyenbe égetni. A leírását csatoltam.

A kérdésem az lenne, hogy lehetséges-e (28 lába van, PSO28 tokozás) ezt megcsinálni valamilyen eszközzel? Ha lehetséges, akkor nem szeretném megépíteni a programozót, mert annyi mindent kell mindig építenem, hogy most egy kicsit belefáradtam. Azaz egy kész megoldás kellene.

Előre is köszönöm a válaszokat!

Üdvözlettel: olika76

A leirasban lathatsz ilyet, hogy rom readout protection.
Ha ez mukodik, akkor nem megy sehogy. Ezt kellene eloszor ellenorizni.
Ha gyari keszulek, akkor 99.99% az esely, hogy be van kapcsolva.

Kedves bbalazs!

Megtaláltam, az alábbi szöveggel (84. oldal).

"1.2 ROM READOUT PROTECTION

If the ROM READOUT PROTECTION option is
selected, a protection fuse can be blown to pre-
vent any access to the program memory content.

In case the user wants to blow this fuse, high volt-
age must be applied on the TEST pin."

Én úgy értelmezem, hogy a TEST pin segítségével ez feloldható (+12,5V-ot rákapcsolni). Hogyan tudom ellenőrizni, hogy a védelemmel mi a helyzet? Ugyanis jelenleg nincs eszközöm, amivel elinduljak. Kérnék egy ajánlást, hogy mit vegyek hozzá.

Előre is köszi!

Üdvözlettel: olika76

Rosszul értelmezed: "Abban az esetben, ha a felhasználó ki akarja olvasztani ezt a biztosítékot (aminek ÉP állapota teszi lehetővé a memória elérését - teszem hozzá én), nagy feszültséget kell rákapcsolni a TEST lábra."
Az előbbi mondat csak a programozási részre vonatkozhat, tehát a kiolvasásvédelem opció kiválasztása ÉS a nagyobb feszültség rákapcsolása eredményezi a biztosíték kiolvasztását és így a védelem bekapcsolását.

(Nekem ez jött le a szövegből, de magam nem használtam ilyen védelmet, sem ilyen vezérlőt, így tapasztaltabb emberke véleményét is várjuk.)

Tehát, a szöveg alapján, ha a biztosítékot kiégették a programozás után, akkor nem férsz hozzá többé a tartalomhoz. Pont ez a lényege, hogy többé nem olvasható, ezért védelem. Logikus, nem?

En sem vagyok tapasztalt ezzel a vezerlovel, de osztom _BIG_ velemenyet. A TEST pinre kapcsolt nagyfesz kell hozza, hogy kiegesd a biztit.

Mondjuk a PIC-knel ez ugy van, hogy a kovetkezo teljes torlesig el a vedelem.
Magyaran, a tartalmat NEM lehet kiolvasni, de a teljes torles utan a chip URESEN ujbol hasznalatba veheto, mint harverelem, tehat programozhato marad.

Kedves _BiG_!

Rendben van, most már értem. De egy kérdés még mindig nyitva. Azaz milyen programozóval + programmal essek neki a vezérlőnek?

Előre is köszi a választ!

Üdvözlettel: olika76

Mint írtam, ilyen vezérlőt nem használtam soha, így erre sajnos nem tudok felvilágosítást adni. Sajnálom.

Semmi baj azzal, ha kajak vagy asm-ből. Amikor úgy alakul, én is az asm-et veszem elő. De vajon mazochistának lenni miért muszáj?

Példa project. Pic32-re usb kliens mass storage device, ethernet oldalon meg szerver felé back-elni tovább az lba szektor szintű kommunikációt + statisztikai adatokat. Nem lehetetlen asm-ben is megírni, csak nagyon sok. És akkor hol marad a fejleszthetőség? (A statisztikai adatokat alkalmasint bővíteni kell.) C-ben ott a support az mla-kban. Az első verzió lett 67 kbyte. Asm-ben mindaz nem csak 20+ ezer sor, de az usb / ethernet protokollok sajátkezű megírása is. Az usb mass storage protokollja amúgy fizetős t10 doksi. Have fun.

A feketeöv ott kezdődik, amikor már kijózanodott valaki a szakmai kielégülés hajszolásából

Bizonyos értelemben a maximalizmus tényleg mazochizmus.
Valóban van az a szint, amikor már asm-ben programozni horror. Ám mindaddig, amíg elkerülhető a könnyített programnyelvek használata, stabilabban működő, sallangoktól mentes (ezáltal hülyeségeket nem művelő) programok írhatóak. Kisebb hardver elegendő, ami megint csak stabilabb működést eredményez. Két PIC között egyedi kommunikációs protokollok írhatóak, ami azért előnyös, mert kihagyható belőle a sallang, növelhető a sebesség és a zavarvédelem, valamint nincs lábhoz kötve.
Legfőképp pedig teljesebb lehet az "Ezt én csináltam" érzés.

Szerencsere nem ez a szakmam. Igy szabadon elvezhetem a sebesseget.
Ha mar kijozanodtal, az nem jo, akkor a fun factor kimarad, munkava silanyul.

Azt keszseggel elismerem, hogy koltseghatekonysag, olvashatosag, egyuttmukodes szempontjabol a C, ill. a magasabb szintu nyelvek jobbak.
Az assemblynek az az elonye, hogy tulajdonkeppen sajat nyelven programozol (makrokkal es rutinokkal, amiket korabban megirtal).

PS: szerintem PIC-re irni dolgokat mazochizmus, ha meg lehet uszni mashogy, mondjuk PC-re. Minek szorakozzak a sokszor hibas librarykkal?
A sebessegkritikus reszt megirom PIC-re assemblyben, atkuldom USB, radios vagy soros vonalon a PC-nek. A PC oldalon is ott egy gyors ASM progi (MASM32-ben irva), ami lekezeli es a mar keszen levo grafikai es tarolasi (joval fejlettebb) rutinokat hasznalva mehet pendrive-ra.

A megállapítás ott kezd sántítani, hogy a PIC -ek között vannak olyanok, amiben csak 2 szintű a szubrutin stack (10F2xxx), ahol csak 8 (16F) és csak egy munka regiszter (WREG) / egy indirekt regiszter (FSR) van. Nincs lehetőség adatokat a HW stack -re vinni. Ezek kellenének a C -hez, hogy hatékony kódot fordítson. Még a PIC18 család is software stack -et kénytelen használni (FSR2 -vel).
A választóvonal a PIC24 dsPIC30, dsPIC33 -nál van. Ezeknél a típusoknál a korlátokat feloldották. Persze a PIC32 -nél sincs ilyen gond.
Valamint a kezdők nem a TCP hálózat és az USB kommunikációval vesződnek.

Egy 8051 -en is lehetett egész jó kódot készítő C fordítóval dolgozni.

Direkt azért írtam oda a "Pic32"-t, hogy ne akarjátok félreérteni. Hiába, mi nagyon profik vagyunk Amikor Attiny10-essel kellett megküzdenem, én sem nyulkáltam semmi más után, csak egy asm fordítóért. Nyilván a korlátozott erőforrás környezetében az asm a jobb választás. Ha még emlékszünk rá, a kérdés fentebb az volt, mit értek logikai alkalmazás szint alatt? Hát azt, amikor sok szoftveres réteg van egymásra építve. Ami jellemzően nem pic10f-eknél fordul elő, de pic32-nél tipikus. A magasabb szintű nyelveket is természetesen ott kell használni, ahol az erőforrások bőségesek, és inkább szűk keresztmetszet a fejlesztési órák száma, meg a fejleszthetőség és átláthatóság is fontosabb, mint órajeleket számolgatni valami belső ciklusmagban.

Ha átnézel az ESP topikba, ott azt fogod látni, hogy kezdők nagyon is vesződnek TCP-vel

Itt kezdődött... Sajnos nem az ESP -t nézte ki magának. Neki ajánlották az első lépésekhez. Nem hinném, hogy egyből a PIC32 és az MLA jutott volna eszébe.

Mint tudjuk az első lépés a nehéz.
Az alábbi legegyszerűbb C program nem működik.
Segítséget kérnék a hiba megtalálásához.
A PIC (16F628A) jó, mert egy assembler progi megy rajta.
Language: HI-TECH Universal ToolSuite

Én a Confog bitekre gyenekszom.

#include <pic.h>

__CONFIG(FOSC_HS & WDTE_OFF & PWRTE_OFF & BOREN_ON & LVP_OFF & CPD_OFF & CP_OFF );

void main()
{
TRISB=0b00000000; // PORTB minden lába kimenet

ugorjunk_ide_vissza:
PORTB=8;
goto ugorjunk_ide_vissza;
}

A PORA3-on égni kellene a LED-nek, de nem.

A megoldás biztosan pofon egyszerű, de nem jövök rá.

Ha a B portot állítgatod a TRIS regiszterén keresztül és oda is írsz, akkor a az A porton sose fog történni semmi

A PIC kezdőknek témában vagyunk! Ha valaki PIC32-vel és társaival foglalkozik az már régen nem kezdő, szerintem. Az itteni felhasználók ritkán mennek 18F-főlé, megintcsak szerintem, de lehet, hogy tévedek.

Te a B portot kapcsoltad, nem az A portot.

De égetni akarod a ledet, még program sem kell hozzá, csak önts rá valami éghetőt, és gyújtsd meg

Bocsi, elírás történt. A PORTB3-on vártam a LED felgyulladását, nem a PORTA3-on.

Valami nem világos nekem a C Lite fordító lelkivilágában:
Különböző PORTB lábakra adtam ki 1-et és elkezdtem méregetni a PORTA lábait. Ha a voltmérőt hozzáérintem némelyik PORTA lábhoz, akkor kigyullad a LED. Az RA7-re minden esetben ez történik.
Ha leveszem az MCLR értékét VII-re, akkor elalszik a LED, Ha felteszem az MCLR értékét Vdd-re a LED nem gyullad ki, csak akkor ha a PORTA7-hez érintem a voltmérőt, vagy egy drót darabot.
A LED világítás "remegő", mintha közben rövid várakozások lennének.

Ugyanezt a programot megírtam Assemblerben és betöltöttem ugyanabba a PIC-be (16F628A), simán működött, és reagált az MCLR váltogatásra is.

Mindkét progi verzióban a Debugger megfelelően mutatta a TRISB, PORTB értékének változásait.

Homályos, hogy mit művelhet a C fordító.
Lehet, hogy a Lite verzió annyira le van "butítva", hogy itt van a kutya elásva?

.

A led a PORTB3 és 0V között van?

Szia!
Olvasd vissza a C fordító által betöltött hex fájl-t ( vagy csak nézd meg!), hogy mi van a config bitekkel, mert ez ilyen "szenteltvíz gyanús", hogy az egyik kollégámat idézzem !

szerk.: feltételezem ,hogy az asm és a C-s hardver azonos, csak a C-ben nem vagy járatos és így nem tudod, mit művel pontosan !

Öööö... megint elírás? Vagy a PORTB-re kötött LED tényleg reagált a PORTA piszkálására?

Ismét köszönöm az értékes tanácsokat, de Hp41C fórumtársunk megvilágosító hozzászólása -
ezúttal is köszönet érte - folytán nem kellett az OSCAL-t keresgélni.
A minap találtam egy frappáns módszert a DS01146B PIC ötletek Page 2-8 oldalán: "TIP #12 Internal Oscillator Calibration" - ha valakinek ilyen gondja lenne...

Meg van a megoldás.
Egy másik progiból másoltam át a Config sort. Itt szerepelő "FOSC_HS" a ludas.

A PIC külső órajelet várt. Ha hozzáértem az RA7-hez, az OSC1/CLKIN-ként működött.
Ezt átállítottam a Configure ablakban belső jelre (INTOSC) és minden helyre állt.

Jöhet a további ismerkedés a C nyelvvel.

HI-TECH PICC C Lite próbálgatása közben elakadtam a delay témában.
Itt kérnék egy kis segítséget.

Ha nincs külső órajel, belső osc van beállítva, a delas-hoz akkor is kell a "#define _XTAL_FREQ 40000000"?
A config beállításból kiolvasható lenne a 4 Mhz freki. A fenti #define_XTAL.... nem külső kristályra utal?

A "__delay_ms(100);" esetén csak az első LED gyullad fel a négyből akármit írok a zárójelbe.

Az időzítés körül kellene a megoldást keresnem?

Srácok, PIC32MX795-ön nézegetem az RTCC-t és akár hogy is nézem nem látok külön elemhelyet a PIC-en. Ebben az esetben csak akkor fog működni az RTC, ha folyamatosan tápot kap az MCU?

Közben a Microchip oldalán is megtaláltam a problémát, és ott azt javasolják, hogy egy ECR2032-es elemmel legyen hajtva sleep üzemmódban a PIC. Amikor meg ébren van kapcsolja be a tápot, tehát egy + elektronikával legyen leválasztható a táp... Kicsit nekem ez a megoldás unszimpatikus főként mert áramszünet esetén még adatvesztés is lehetne, sőt nullázódna a beállítás..

Vélemény? Volt már valaki aki foglalkoztat a problémával?
Vagy egyszerűen használjak külső RTC-t?

Első kérdésre: Legtöbb c és hasonló programnál kell a define xtal freq megadása, akár külső, belső osc., ebből tudja a fordító az időket kalkulálni. A configot nem feltétlenül kell beírni programba, néha az égető programban adjuk meg, ezért támaszkodik a fordító külön beírt define xtal freq megadásra, és nem a config adatokra.
Második kérdésre: Sok az ismeretlen, a hardver, és a szoftver. A delay_ms(100) 100ms késleltetés, amit az előbb írt define xtal freq -ből kalkulál. Csak akkor lesz 100ms, ha a define xtal freq jól van megadva.

kimaradt előző válaszomból: Csak akkor lesz a delay_ms(100) 100ms, ha a define xtal freq jól van megadva. Ezt általában MHz-ben kell megadni, tehát nem 40000000- negyvenmillió, hanem 4MHz.

Headerekben utána tudsz nézni pontosan mit és hogyan csinál az a beállítás. De a jellegét szerintem nem nehéz megérteni, ha kódból sleepelsz blocking kód végrehajtással, tudnod kell valamiből kiszámolni, mennyi az utasítás végrehajtási idő.