Szia
először is kis magyarázat megint, 1 db vezetékről jön a jel, csak nem tudni hogy a másik végét éppen hova dugják, magyarán éppen milyen adat jön róla . Ezt kéne PIC-el felismertetni, vagy ha áramköri megoldás van rá akkor az is jó lenne és akkor jogos h nem kapcsolodik a PIC témakörhöz. Lényeg h több féle protokollal működő program íródik a PIC-ben de valahogy elkéne döntenie h éppen melyiket kell használnia. Ehhez kéne felismertetni az 1 db vezetéken jövő adatot, és persze ez alapján utána a megfelelő illesztőkre vezetni h a megfelelő kommunikáció is kialakulhasson.

Amíg nem tudod, hogy a másik végét hová dugták, addig azt sem tudod, hogy az egyik végét hová dughatod (mert a kábel mindkét vége egymással összeillő szintillesztővel kell, hogy találkozzon). Ha pedig ez kiderült, akkor már nem gond egy DIP-Swich beállítása. Ha a kezelő "elfelejti" a beállítást, az nem tragédia. Észre fogja venni, hogy nem működik...

A rákapcsolódó eszközök nem tudnak azonosítást küldeni? Az USART bájtokat fogad, ha el tudnád dönteni, hogy melyik eszköz küldött bejelentkezést, akkor a dolog meg lenne oldva.
Ha nem tudnak ilyet az eszközök, akkor olyan aljzatok kellenek típusonként eltérő kivitellel, amiken van visszajelző érintkező. A kezelő a megfelelő csatlakozóba dugja be a hozzá illeszkedő dugót. A dugó érintkezője pedig jelzi a PIC-nek, hogy melyik kimeneti puffert kell bekapcsolnia és milyen protokolt kell használnia.

Majd írd meg kérlek tanulságként, hogy mennyi elgörbült, letörött lábú PIC-et dobsz majd ki az elkövetkezendő fejlesztéseid során!
Aztán ha meguntad, olvasd el az oldalamon mi az az ICSP, hogy kell használni, tervezni vele, mire találták ki!
Még had jegyezzem meg, hogy az ilyen fajta megoldás láttán a PICKit2 megálmodói tenyerükbe temetik az arcukat!

Sajnos, nincs egyedül. Szerintem egymástól lesik el a jó példát...Bővebben: Link

Ez a modszer eleg elterjedt amugy, pl:

Velleman ICSP programozoja

De ezert azt erdemes megfigyelni, hogy ok legalab azt a rugos erintkezost hasznaljak a kerek helyett -- legalabbis en azt jobban szeretem. Valoszinuleg a legjobb a ZIF foglalat, nade ha az arat is megnezi az ember akkor mar elgondolkodtato

Amugy abban tokeletesen egyet ertunk, hogy mikor teszteles es fejlesztes van akkor sokkal jobb az ICSP mivel nem kell minden masodpercben kirangatni az IC-t az aramkorbol majd vissza... Ha mas nem akkor egy programozo headert kell gyartani a celra ha az aramkorbe nincs bele tervezve a programozoi tuske.

Vak vezet világtalant.

Sziasztok!

A legújabb megoldás a programozó csatlakoztatására... Azt hiszem sokan nem fognak áttérni rá az otthoni munkáknál - túl finom rajzolat, aranyozott érintkező felület....

Egy egész korszakot végig feljesztettem a dip tokos áramkörökkel (M68000 - dip64, TRW1010 - dip64, Am2903 - dip48, Z80, I2920, I8751 és 27xx EProm - amit a törléshez ki kellett venni a foglalatból..., stb) egyetlen lábat sem sikerült letörnöm közel 25 év alatt...

Igen, ezek a pogo pines megoldasok nagyon jok. Rengeteg kinai gyartmanyban hasznalnak ilyeneket, de ez a Microchipes azert tetszik, mert egyreszt polarizalt masreszt a muanyag kapcsok be is kattannak es igy a helyukon tartjak a csatlakozot. Ugye ICD3-at debuggolaskoz is lehet hasznalni, ott meg eleg kenyelmetlen lenne ha folyamatosan ra kellene nyomni a csatlakozot

Ja, "Velleman ICSP programozoja" helyett "* JDM *"-et akartam irni!

Nekem még olyan is volt, hogy beleállt az újjamba.
De gondolom ezzel nem azt akarod mondani, hogy az ICSP felesleges, építsünk foglalatos égetőket és rakosgassuk ide oda a PIC-eket minden apró módosításnál!?

Arra gondoltam, hogy mivel multiplex üzemben fog dolgozni, így a PWM jelet talán rátehetném a mátrixnak a sorvezérlő portjára, így egyszerre az egész sor megkapja a jelet, de csak az fog világítani, amelyik az oszlop vezérlőt is megkapja. Ezzel csak az a baj, hogy egyszerre nem lehet eösíteni az egyiket, a másikat pedig gyengíteni. Egyébként a PIC-nek csak ez a dolga. Ez egy látvány kapcsolás lesz. És azért sem jó a Knight rider, mert itt csak egyszer fog végigfutni a "csóva". Utána más effektek következnek. Azért a kondenzátoros megoldás esetleg szóba jöhet, csak nem tudom a Pic mit szól hozzá, és hogy ebben az esetben hogyan nézne ki a kapcsolás.

Mar irtam, hogy egy invertalo ill egy nem-invertalo buffer kell amit ugyanaz a jel hajt meg. Igy mig az egyik erosodik a masik epp gyengul...



Arra kell vigyazni mindig, hogy a PIC kimenete ne legyen tulterhelve. Ezert kell a buffer. Kondi eseten is, ill egy ellenallassal korlatozhato az aramfelvetel amig a kondi toltodik, es egyben ezzel a felerosodes is megoldodik... Szamoldd ki 5V/20mA mekkora ellenallas kell, es probaldd ki a kapcsolast PIC nelkul eloszor...

Valóban nincs köztük, pedig az MPLAB szerint támogatja...

Szia! Én írtam ilyen programot 16F877-esre, de átírni nem tart sokáig. Ha érdekel elküldhetem.

8.56-os MPLAB-ot használok, a PICkit2 verzióját hol találom meg?

Köszönöm, jöhet!
Nem is kell átírtni, mert ő az egyik jelöltem.

A jelek szerint nem. Esetleg PICkit3-mal...

Szia!

Meg kellene említeni, hogy át kell olvasni a megcélzott kontroller errata dokumentumait is. Sok tétel van bennük, ami főleg a megszakítások hibáinál kínos...
- Több kontroller nem jó tartalmakat állít vissza a HW regiszterekből, ha a megszakítás a movff utasítás alatt következik be és a cél regiszter a STATUS, WREG vagy a BSR - 18F2550, 18F2580.

Ez a program azt csinálja, hogy ha megnyomod a PORTA 0-ra kötött nyomógombját, akkor folyamatosan növeli a PWM kitöltési tényezőjét és miután elérte maximális értékét (ami átírható a programban: "MAX"), akkor a gomb újbóli megnyomásakor lassan csökken a PWM kitöltési tényezője egészen a "MIN" nevű változó értékéig, majd mehet előről. Az időzítés szoftveres szubrutinnal oldottam meg annó(most nem írom át hardveres timerre és megszakításra, de úgy is lehetne) DE, szerintem ilyen egyszerű feladatra kisebb pic is elég. Használd egészséggel.

És PICkit 3-mal biztosan jó lenne? (fontos lenne, hogy ezt a picet használjam) Köszönöm eddigi segítséged.

Erre vonatkozó listát (Supported devices) nem találtam.

Pedig van.
http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit_3_User_Guide_51795A.pdf
18-as oldal

Ebben nincs.

a lapszámozás szerint 13-14-es oldal.

Csak az a probléma, hogy nem ezt keressük, hanem egy olyan listát, amelyen tételesen fel van sorolva mindazon mikrovezérlők, amelyeket támogatja a PICkit3 ÉS az MPLAB.

Ott van a lista a C:/Program Files/Microchip/MPLAB IDE/Readmes/Device Support.html -ben...

A PicKit3 maskepp mukodik, mint a 2-es, a FW nem tartalmazza az osszes eszkozt, hanem mikor az ember chip-et valt, akkor az MPLAB latolti a pk3 reszere az adott chip programozoi specifikaciojat - minden alkalommal! Emiatt nem soroljak fel a pk3 doksiban, hanem az MPLAB-eban, mivel igy a pk3 FW-t nem is kell frissiteni soha, csak az MPLAB-ot.

UI: Csatoltam... (ha nincs csatolva akkor elnezest, akkor a HE nem tamogatja zip file-ok csatolasat)

Valamint a PICKit3 -at 10000 letöltés után... Esetleg egyből több példányt beszerezni a különböző kontroller családokhoz...

Na latod ezen mar en is elgondolkodtam, de meg nem neztem utana mi a helyzet. Tehat ha a program memoriaba toltene el a programozoi adatokat, akkor igen, 10ezer chip valtas utan lehet pk3-at kidobni. Nem tudom ki hanyszor valtotat chipet, de talan meg ez is elviselheto, hisz az eszkoz olcso. Azonban meglehet, hogy eeprom-ban tarolja az infot, hisz van neki kulso eepromja is. Akkor pedig 1 millio chip valtas minimum... De az uj letoltes csak valtaskor tortenik meg, nem pedig programozasokkent!

Jo lenne ezeknek utana nezni, csak a pk3 annyira nem erdekelt mivel voltak ezek a kezdeti betegsegei, hogy nem neztem meg. Ha vennek valamit akkor inkabb raaldoznek az ICD3-ra, azt mindenki csak dicseri, igaz 2x vagy 3x dragabb, mint a pk3...

Hehe, nálam még a PICkit3 sem támogatott! (v8.15)

Köszönöm az információt, Gamedavid ennek alapján már meg tudja nézni magának, ha legfrissebb MPLAB-ot felrakja.