Az égetőprogrammal tudod kiolvasni

Üdv, elveszett osccal értéket próbálok visszaállítani, így: http://www.rcgroups.com/forums/showatt.php?attachmentid=1588752
Minden oké, csak éppen nem tudom hogy mivel tudnám kiolvasni az eepromot. milyen címen van, vagy hogyan van ez?

Nem kontrétan a 7407-ről van szó, hanem arról, hogy ezek a digitális elektronika építőkockái. Senki sem ismeri fejből az összes logikai áramkört, de előkapjuk az adatlapjukat, és már képben is vagyunk.

Ezzel teljes mértékben egyetértek. Sajnos futottunk már bele jónéhány, az általad leírt problémába. Most pl. az a szívás tárgya, hogy a Microchip az egyik 33F-nél eddig 2 fajta TQFP tok helyett már csak egy fajtát gyárt. A sok NYÁK pedig természetesen a megszüntetetthez van legyártva...

De azért látszik valami fejlődés is:
Link

Bezzeg, az mennyivel épületesebb, mikor leszólsz valakit, mert az nem ismeri - mondjuk - a 7404-est!

.....

Egy újabb okos hozzászólást hallhattunk T68m-től...

kb. olyan, mint a windows vs. linux vita. Mindkettő egy nagy sza.r, de más nincs.

Mondjuk engem a sokat dicsért AVR-ek se nyűgöztek le, szerintem a PIC-nél sokminden lényegesen logikusabb... De ez szubjekív, meg off, meg flame...

... és a lábakkal sincs nyűg, minden modul alapból ki van kapcsolva, Neked kell bekapcsolnod, ha használni szeretnéd, a Reset-et kivéve, azt a fuse biteknél lehet kikapcsolni.

8722vel volt periféria konfigurációs problémám. Nézem az adatlapot, a párhuzamos port kavart valamit, de már nem emlékeszem, mind1.

A lényeg az, hogy apró differenciák tucatjaival lehet találkozni pl. PIC18 család egyes tagjai között is. Az AVR-esek szoktak dicsekedni, hogy a 28 lábú kontrollerre megírt program tökéletesen fut 40, 64, ... lábú kontrolleren is, mert teljesen megegyezik az UART, TWI (I2C, SPI), OSC konfigurálása, kezelése. Ezt el bírnám viselni, ha a Microchip is így csinálná, mert nagyon fárasztó mindig A-tól Z-ig elolvasni egy adatlapot, ha az ember nem akarja, hogy meglepetések érjék.

NickE

Egytértek, néha valóban nagyon apró eltérések vannak egyes tipusok között. Én se bánnám, ha univerzálisabb chipek is lennének (pl. egyben Ethernet, USB, CAN, stb.), de tekintetbe kell venni, hogy a piac diktál, és csak akkor tud konkurens lenni már gyártókkal szemben, ha rendelkezik az adott igényhez minimális tudású chippel. Ha már többet tud, akkor másik gyártó előállna a kisebb tudásúval olcsóbban, és akkor attól vennék, nem a Microchiptől.
Melyik chip volt az egyébként? Mert én úgy emlékszem, hogy a digitális perifériák alapból tiltva vannak, csak az analóg perifériák vannak engedélyezve resetkor.

Potyo! akkor ezek szerint mégsem én vagyok a hü.lye?

Hát én nem tudom, nekem annyira nem tetszik az, hogy már lassan óránként dobnak piacra újabb piceket. Aztán még a ChipCAD-ig el se jutott, de már a 4-ik erratát írják, hogy bocsika, de ez meg az az utasítás nem jó, uartot még sose tudtunk csinálni, most se sikerült, tegyél néhány NOPot a prog elejére, mert néha nem indul a pic, meg a legjobb az, mikor a workaroundban leírják az elvi megoldást, de hozzáteszik, nem biztosak benne, még tesztelni kellene.
Nekem meg vannak elég szép számmal olyan projectek, ahol komoly kár vagy elmaradt haszon keletkezik, ha gond van.

Múltkor egyik projectnél 3 féle pic volt a buszon, mert volt, ahova a 18lábú is bőven elég volt, volt, ahol pedig 80 lábú kellett. Majd megőrültem (főleg a 80 lábúval), mire lelöttem az összes AD bemenetet, komparátort, párhuzamos portot meg mittudoménmitmég. Miért nem lehet egyszerűen azt csinálni, hogy legyen az összes multiplexelt láb alapból digitális bemenet?

A technika fejlődik, kell követni, de nem így, ahogy mostanában csinálják, szerintem. Lehetnének sokkal inkább egységesek a PIC-ek és ha összejön kellő számú változtatás, jobban átgondolni őket, letesztelni és úgy piacra dobni újabb családot.

Ja, ezt olvastam a régebbi hozzászólásaid között, és már elloptam az ötletet. Nekem közvetlenül a telefonon van egy 4700 uF. Így simán megy a 317-ről. Csak az autós dolgoktól félek egyelőre, mert egyrészt még sosem csináltam ilyet, másrészt a férjem hülyét kap, ha elszúrok valamit az új kocsinkon. (Néha kicsit úgy érzem, ha ez a kocsi tudna főzni, én elég hamar az utcára kerülnék... )

Elég csúnya áramokat tud rángatni egy telefon, főleg amikor hívják vagy amikor hív. Ami tovább rontja a dolgot, hogy keskeny tüskékben vesz fel nagy áramokat. Pont egy C35-ön kisérleteztünk annakidején, és az LM317-el épített, 4V-ra beállított tápról is kikapcsolt, ha hosszú volt a drót, és a drót telefon felőli végénél nem volt pufferelve a táp 2200uF elkóval. Ha kapott puffert, akkor stabilan működött. Ha a táp közelebb van, akkor nem kell akkora elkó, de azért nem ártana, ha mégis lenne. Így jobban belegondolva, egy 2200uF/10V-os elkó nem nagy cucc, és ne ezen múljon az áramkör stabilitása.

Ez a terhelés nehéz dolog, mert a C35 nálam 30 mA-t vett fel standbyban, de gondolom, ez térerőtől is függ, nem? Ha rosszabb a vétel, a mobil növeli az adóteljesítményt, és nő az áramfelvétel.

Ha félünk attól, hogy a feszültségesés kárt tehet a stabilizátorban vagy a pic-ben, akkor lehet tenni diódát. De mivel a túlfeszültség szokott kárt tenni, ezért a dióda felesleges. Helyette inkább egy ellenállást érdemes tenni, hogy RC szűrőt kapjunk, és esetleg a disszipáció egy részét átadjuk az ellenállásnak. Az ellenállást természetesen a terhelés függvényében kell meghatározni.

és az elkó elő pedig egy diódát, hogy az elkó ne a teljes tápot szűrje, hanem csak a pic oldalát.

A tápnak én még tennék egy elkót is a 7805 elé. A bemenetekre, ha távolabbról veszik a jelet, akkor azokra is kellene valami szűrés. De ez a helyzettől, jelforrástól, stb. függ.

Még egy kérdés, bár lehet, hogy itt kicsit offtopic, de végül is PIC. Ha autóba teszem a PIC-es áramkört, mire kell figyelni? Egy 7805-ről kapja az 5 V-ot, előtte, utána az adatlapnak megfelelő kondenzátor van. Elég ennyi? Vagy legyen előtte még valami? Kondenzátor, induktivitás? Vannak nagy tranziensek egy autóban? Vagy a 7805 ezeket elintézi annyira, hogy a PIC-nek már elég legyen?

Óóóó, és tényleg megy. Igaz, nekem 1k sok volt, de 500 ohmmal már bekapcsolt. A 7-es lábat húztam a földre. Köszönöm a tanácsot, végre be tudom kapcsolni.

Potyonak: én egy adatkábelből csináltam, ott az összes láb benne volt a csatlakozóban.

Na, akkor indulhat az ebédgyártás, mert szegény családom már totál ki van akadva. Puszi mindenkinek.

Kati

Általában 2 töltőcsatiból össze lehet rakni egy komplettet. Ugye a tüskék kiszedhetők, átrakhatók. 3 tüske van egy töltőben, ebből csak 2 van bekötve. Ha nincs több töltőcsati, akkor marad a drótból érintkező hajtogatás...

Én azt kérdezném, hogy hogyan kötitek rá a telefon lábaira a vezetékeket? Van olyan csatlakozó, amelyiken megvan az összes kivezetés, vagy beforrasztjátok? Vagy valami más módszer?

Közben megtaláltam:
GSM-SmS alarm topic: http://forum.terminal.hu/viewtopic.php? ... c&start=50

Tehát az akkucsatlakozón 4 V és GND, az alsó csatlakozó 1-es lábán GND, és a 3-asra 2 mp-ig 1k-n 5 V? Más láb nincs bekötve? (RX-en és TX-en kívül persze.)

Én PIC lábáról egy soros 1k-val kapcsoltam a táp bekapcsolás után egy 2mp-es impulzussal.

És az IGN lábra 5 V menjen a diódán+ellenálláson? Folyamatosan? Vagy még a táp előtt kell neki?

Igen, működik ez a bekapcsolás, csak valamelyik lábat le kell még húzni GND-re. (azt hiszem valamelyik headset kivezetést) Előtúram a régi cuccaimat, de nem találtam meg a pontos leírást, de az biztos, hogy valaki itt a fórumon mondta.

Régebben próbálkoztak sokan PIC+Siemens C35 összeházasításából, és felmerült, hogy lehet bekapcsolni a telefont a PIC-ről. Ezt sikerült megoldani? Volt belinkelve egy kép, hogy a DTR egy diódán és egy 2k2 ellenálláson keresztül a C35 3-as lábára van kötve, de ez ment valakinek a gyakorlatban? Gondolkoztam, hogy kiszedem a bekapcsológombot, és ráforrasztok két drótot, de csak van normálisabb megoldás.

Nekem nincs semmi bajom a jelenlegiekkel, így nemis akarok másmilyent.



Ha meg 256kB memória kell, akkor meg 22 bitesre, stb. Tehát leszögezhetjük, hogy nincs olyan, hogy elég.



Az USB-hez hasonlóan megfelel az igényeknek. Ha lenne igény "jobb"-ra, akkor nyilván gyártanának olyant is.

1. állod a fejlesztés és piacra bevezetés költségeit?

2. költői kérdés volt? Talán akkor, amibe beleférnek az adat és programcímek. Ha 4kB-os a memória, akkor 12bit + utasításnak kódhossza ami még kb. 4 bit. Az előrelátás miatt azonban érdemes arra gondolni, hogy később nagyobb lesz a memória, mondjuk 64kB, ahhoz 16bit szükséges, így 20bitesre lett volna érdemes felvenni az utasításhosszt.

3. tehát itt sem a tetszés, nemtetszés határozza meg lehetőségeket, hanem (az usb-hez hasonlóan) ez van és kész. Ha lenne jobb, akkor nyiván azt használnák.

Tiéd a pálya, tervezz és gyárts jobbat. Aztán majd a piac megmondja, hogy szükség van-e rá.



Mennyi lenne a nem rövid utasításhossz?



Ha nem tetszik ez a felépítésű kontroller, akkor nem muszáj használni. Az, hogy a bankváltás valós teljesítménycsökkenést okoz, az tény. De az is tény, hogy a kontroller maximális órajelen történő járatására is ritkán van szükség, vagyis a bankváltások, programmemóriaolvasás, stb. miatt bekerülő "plusz" utasítások vesztesége simán ellensúlyozható valamivel magasabb órajellel. És ez nem szociológusok és filozófusok által elméletben kitalált dolog, hanem több száz vagy több ezer készüléket maguk mögött tudó fejlesztők gyakorlati tapasztalata. Ha nem felel meg az adott kontroller, akkor nézni kell egy olyant, ami megfelel. Minden kontroller számára megvan az alkalmazási terület. Úgytűnik, az ilyen-olyan pic-ek és velük azonos kategóriába tartalmazó más gyártók kontrollereinek igen széles az alkalmazási területük. Vajon azért, mert megfelelnek az igényeknek, vagy azért, mert nincs jobb?



A hasonlat nagyon sántít, mert a kontroller az egy áramköri elem, nem egy komplett készülék. A mosógép viszont egy komplett készülék. A fűtőszál vagy a motor ott sem szokott mindig a másikhoz passzolni!

Erre meg nemis reagálok, mondtam, hogy csak tipp volt.

Micsoda vitát indítottam el.

Azt hiszem felül kell vizsgálnom az összes működő projectemet, mert úgy néz ki, PIC-el nem működhet, és nekem sem szabadna azt éreznem, hogy milyen jók ezek a kontrollerek, mert T68m felsorolt fél tucat dolgot, ami neki nem tetszik, ezért másnak sem tetszhet, hogy ilyen, amilyen, tehát úgy kell vele bánni, hogy még is az történjen amit mi szeretnénk!
(azt hiszem nekem kezd elegem lenni ebből az egész fórumból. De ezt csak csendben mondom, hogy ne lepődjön meg senki, ha átadom a terepet a mindent tökéletesen tudó, tévedhetetlen párosnak!)

a titanicot sem amatőrök fejlesztették, mégis elsüllyedt, ennyit erről az érvelésről. Abból, hogy rengeteg használják nem az következik, hogy jó vagy rossz, hanem az, hogy nincs nála lényegesen
jobb. Remélem tudod mi a jó és a jobb közötti különbség!

1. nem a harVard architektúráról volt szó, ne terelj. Arról volt szó, hogy olyan rövid az utasításhossz, hogy nem férnek bele az (adat és program) címek egészükben. Ha nem érted, hogy ez mit jelent, akkor ne próbálj rá válaszolni!

3. fejtsd ki pontosan, hogy ezt hogy érted. Attól, hogy utasítások tömkelegeivel le lehet kérni a programmemória tartalmát (pl. 16f688, 16f690) az nem egyenértékű a közvetlen hozzáféréssel. Sem sebesség, sem programhossz, sem semmilyen szempontból.

4. nem nevezhető sok utasításnak a feltételes ugrások bevezetését. Itt nem a LFTEXMAMOC (Load Frame Table Entry of Extended Expanded Memory with Auxiliary Memory Overflow bit Clear) utasításról van szó, hanem a meglévő utasítás optimális kihasználásáról. Aminek csak az az akadálya, hogy a rövid (hibásan megválasztott) utasításhossz miatt az ugrás címe nem fér bele az utasításba.

5. tudom, hogy nem hallottál még a "kompatibilitás" kifejezésről, nézz utána a szótárban! És szeretném, ha új háztartási gépet vásárolsz, az mindig különböző feszültségre legyen tervezve. Az eladó pedig közölje veled: tessék megfelelően adaptálni a berendezést, nem amatőrök végzik a fejlesztést, világszerte megelégedéssel használják a termékeinket, Önben van a hiba, ha ez magának nem tetszik.

6. világos. Tehát a gyakorlati életben 1% alatti alkalmazás miatt kell a 99%-nak bonyolultabbnak lennie.

Miért kellene a tényeket cáfolni, amikor ezek tények? A Microchipnél nem amatőrök végzik a kontrollerek fejlesztését, és a világon rengetegen megelégedéssel használják azokat, akkor vajon kiben lehet a hiba, ha neked nem tetszik? Mindenbe bele lehet kötni, csak talán nem mindenbe érdemes.

1. és 2. A PIC harvard architektúrájú (ugyanúgy, mint a mikrovezérlők túlnyomó többsége). Ebből kifolyólag a programmemória és az adatmemória szélessége nincs fixen rögzítve egymáshoz. Akármilyen felállást csinálsz, mindig bele lehet kötni, hogy ezért vagy azért nem jó.

3. fejlettebb változatokban van közvetlen hozzáférés a programmemóriához.

4. sok utasítás = széles programmemória = sok hibalehetőség. Mellesleg az MPLAB-ban vannak előre definiált makrók BNC, BC, BNZ, BZ, stb. néven, amik pont azt csinálják, amit te akarsz.

5. ha más chipre költöztetjük a programot, akkor annak jó eséllyel nem azért van más neve, mert a gyártónál épp részegek voltak a feliratozók, és szórakozásból más jelzéssel látták el, hanem mert a chip tényleg másmilyen. Ha más a chip, akkor tessék a programot hozzáállítani. Egy családon belül egyébként is ugyanazon a címen helyezkednek el az ugyanarra a célra szolgáló regiszterek. Pl. a mid range családban a PORTB mindig a 0x06 címen helyezkedik el. A microchipnél elég jó a visszefelé kompatibilitás, pl. 16F84-ről 16F627-re váltáskor is általában elég csak a komparátorokat letiltani.

6. csak tipp, de talán azért, hogy két nyomógombban tudd finomhangolni az értékét?

Értem, tehát ha a tényeket nem tudod cáfolni, akkor "frappáns szellemességgel" tereled el a szót, úgy, hogy közben a másikat próbálod nevetségesnek beállítani. Belátom, ez a stílus van akinél bejön (potyo).

A PIC C nehezebb, mint az AVR C
A PIC assembly nehezebb, mint az AVR assembly

Ennek magyarazata a PIC-ek T68m altal vazolt hianyossagai es korlatai.

BUEK!

Inkább így szól az a mondás: nem a víz a hülye, ha a kacsa nem tud úszni...

T68m
Hallottál már egy olyan mondást, hogy ha úgy veszed észre, hogy körültötted minden "kiba*túl elb*tt" , akkor lehet, hogy benned van a hiba?
BUÉK!

Ezt hogy lehet így összehasonlítani?
PIC-et is tudsz C-ben programozni...

ja, hacsak nincs mögötted egy rutingyűjtemény, amit csak hivogatni kell a megoldáshoz. Tehát programozni nem a C-től lesz könnyebb, vagy nehezebb, hanem attól, hogy milyen háttérre támaszkodik az ember. Pl. delphiben sem azért könnyű megírni egy ablakos programot, mert a delphi pascal más, mint a hagyományos pascal - mert gyakorlatilag ugyanaz, nem a nyelvben van eltérés.

Viszont a PIC uC programozás szempontjából kiba*túl elb*tt.

1. rövid utasításhossz, nem fér bele a teljes UTASÍTÁScímhossz, pl. call vagy goto nem szólhat akárhova. A hiányosság kerülgetése programból jelentős hibaforrás;

2. rövid utasításhossz, nem fér bele a teljes ADATcímhossz, így adateléréshez (sőt, regisztereléréshez is) lapozgatni kell a memóriát. Jelentősen, feleslegesen növeli a programméretet, lassítja a futást, hibaforrás;

3. nincs közvetlen hozzáférés a programmemóriához és nincs támogatás arra nézva, hogy a literálok(konstansok) átkerüljenek a programmemóriából az adatmemóriába, emiatt a stringliterálok kezelése kifejezetten kényelmetlen. Ráadásul az 1. pont miatt erősen korlátozott is;

4. nincsenek feltételes ugrások (szintén az 1. pont miatt), melyekkel tetszőleges helyre lehetne ugrani statusbitek alapján. Ehelyett "átugrások" vannak, melyek lassítanak és feleslegesen bonyolítják a kódot;

5. átgondolatlan, nem konzekvens, memóriába ágyazott vezérlése a lábaknak:
- mivel memóriába ágyazott, ezért az egyes tipusokon működő program, az ott szabadon használható memóriaregiszterek használatával érdekes eredményre vezethet más tipuson - inkompatibilitás;
- mivel nem konzekvens, ezért még úgy is felléphet inkompatibilitás, hogy más tipuson másképp kell a lábakat felprogramozni és/vagy újabb (régebbi program által nem várt) funkciók előre be vannak kapcsolva;

6. osccal nem a flashben helyezkedik el;

Ezen is lehetne hosszasan vitázni. Szerintem a C sokszor jobban hátráltatott, mint az asm. Asm nélkül nem tudnék C-ben sem hatékonyan programozni.
Az asm ismerete egyenlő a uC ismeretével. C-ben sem lehet "könnyen" programozni, ha nem ismered a hardvert.

Akkor úgy mondom, hogy programnyelvtől függ, hogy mennyire nehéz.
A PIC Assembly nehezebb, mint az AVR C.
A C egyébként se idegen számomra, az utasításai is könnyebben tanulhatóak.

Közben találtam egy égetőt, összeraktam, semmi. A PIC-nek vége, újat már nem veszek bele, mert úgy se fogom használni.

Szerinted. Szerintem meg ez nem uC függő, úgyhogy remélem nem fogsz meglepődni, hogy egy program nem attól lesz bonyolult, vagy sem, hogy mire írod!


Ha úgy gondolod, hogy a nagyfesz csapta agyon, akkor annak annyi.


Már megint "egyszerű"! Én bármikor levegőben összeforrasztom az LPT-s égetőmet, és nekem tök egyszerű...

A JDM-es cikked már olvastam.
Ennek már nem nagy kér, ha tönkremegy, úgy sem használnám, mert áttérek az AVR-re, szerintem sokkal egyszerűbb programot írni rá, mint PIC-re. A PICkit2-t meg nincs szívem kidobni, hátha még menthető.

Megnéztem az égetőket.
Valami egyszerűbb nincs, amiben csak pár alkatrész van?
AVR-re találtam olyat, amiben 9 alkatrész volt. (http://electronics-diy.com/avr_programmer.php)
A PICkit2 nekem jó volt, csak msot egy darabig nem volt rá szükségem, betettem a TV alatti szekrénybe, amikor elővettem úgy viselkedett, mintha nem lenne benne PIC, vagy nem lenne benne szoftver.
Azért gondoltam, hogy a TV-től mehetett tönkre, mert a képcsöve fel van töltődve.

Ezekkel a programozókkal(JDM klónok) akár tönkre is teheted a PIC-et.
Nézz fel az oldalamra, ott leírom a miérteket is.

Ha már ott vagy, akkor találhatsz több olyan programozót és hivatkozásokat is, ami LPT-ről megy.
Ha nincs LPT-d, akkor van soros is.
Valamilyen PIC nélküli kivitel minenképpen szükséges, mert előbb utóbb a PICKit2-ben megsérül a program, még ha nem is attól, hogy a TV mellett tárolod(mert attól 1000%-hogy nem.) Ezért ne halogasd, és építs egyet!

Üdv,

16F225-hez szeretnék programozót építeni soros portra.
Csak egyszeri programozásról lenne szó, a PICkit2-mben a PIC, vagy a programja ment tönkre. Valószínű azért, mert a TV mellett tároltam.
Milyet ajánlotok?
Találtam egyet: http://www.freeweb.hu/fairco/pic/programmers/Com84.gif
De ez szerintem csak 84-hez jó.