Hat igen, ez a ket jel kozt eltelt ido max lassu fordulatnal jon be. Lattam mar olyat, hogy nem ketto, hanem tobb jel kozotti idot mernek -- ugyan az a dolog, csak megnoveled az intervallumot igy pontosabb eredmenyt kapsz. De az altalanos az amit leirtam, hogy inkabb fix idokozonkent szamlaljak meg, hogy hanyszor kapcsol a szenzor.

Amugy ez egy mechanikus encoder? Most nezem a kepeket, es nagyon ugy tunik, hogy az a ker1.jpg a bouncingot (prell / perges) mutatja. Szoval lehet meg egy prellmentesito funkciot is be kell epitened?

A Capture modullal próbáltad mérni? Minden 16 odik élre mérni talán egész hihető eredményt ad, viszont a prellezés ebben az esetben nagyon bezavar... De mérhetsz minden élre és akkor a megszakításban egy pár ms-os delay talán.

Igen, mechanikus. Meg ha rákerül a véglegesnek szánt optikai szenzor (sima optokapu), az sem lesz pillanatnyi jel. Eddig úgy tudtam, hogy a felmenő élre reagál a program, és mindegy neki, hogy utána meddig van magasan a láb. Bár ez a nyomógomboknál sem így történt...
Pergésmentesítésnek az input pin_akármi után be szoktak tenni egy delayt nem? Csak itt nem tudom, hogy mennyi legyen az a delay, hogy ne vigyen el túl sok időt. Vagy hardveresen kéne megoldani?

A 2db capture/compare/PWM modul használatban van, azok vezérlik a motorokat, közben nemigen tudnám vele számláltatni a dolgokat. (az itt kirakott kóddal csak arra igyekszem rájönni, hogy használható-e a mért érték, ehhez elég volt így megforgatni a motort)

Én ezzel az interrupttal gondban vagyok...
Ez a CCSC honlapjáról bányászott mintakód kicsit átalakítva az én órajelemhez, de semmi nem történik.
Csak egy lednek kéne benne villognia, de az sem megy.
Ez javítható, esetleg van valakinek akármilyen működő mintaprogramja?

Ket alapveto hiba van a programban. Az elso, hogy azt a valtozot ami alapjan eldontod a LED-et kellene-e villogtatni nem is noveled vagy csokkented az interrupt kezeloben.

A masik, hogy az interrupt es a valtozod felicializalasat egy vegtelen ciklusban csinalod. Tehat meg ha bele is tenned annak a valtozonak az inkrementaciojat vagy dekrementaciojat, akkor sem mukodhetne ez igy, mivel egyfolytaban feltoltod a kezdo ertekkel.

Teendok:
1. Valtozo ertekenek novelese vagy csokkentese az ISR-en belul

2. A vegtelen cikluson kivulre rakni az inicializalasat -- ebben az esetben a vegtelen ciklusnak teljesen uresnek kell maradnia!

Igen, így jó:


Köszi!
(Az if (--high_count==0) stb résznél mit csinál a "--"?)

Dekrementalja a high_countot. Vedd meg szerintem a Kernighan & Ritchie fele C konyvet, szerintem megeri.

Újra megakadtam.
Van itt egy cikk a rádiómodulok használatáról, ahhoz van egy példaprogram, amit módosítottam a saját dolgaimhoz. Egy PIC16f877A 4Mhz kavrccal, és egy 16F887 20Mhz kvarccal kéne hogy társalogjon. Lefordítottam mindkettőre, az LCD megy szépen, de a próba üzenet nem jön meg. Próbáltam simán összekötni az adó és a vevő lábakat (meg persze a GND-t) 20cm vezetékkel, ekkor zagyvalék érkezett csak. Valami adatátvitel tehát van, de köze nincs a valósághoz. Az "INVERT" opciót kivettem az RS232 beállításokból, mivel a modul vevőjének data lába alapból magasan van, jelre pedig földre ugrik (az adón lévő lefutó élre). Sima összedrótozáskor is invert nélkül kell ha jól tudom.
Az adó és a vevő programját is csatolom, ha abban van a hiba, derítsük ki mi lehet az. A m_manchester.c érintetlen, olyan ahogy Topi megírta.

Sziasztok!
Nagyon kezdő vagyok pic-ekben de szeretnék egy órát csinálni megvan hozzá a PIC16F628 és a program is egy HEX fileben csak nekem nincs programozóm.
Debrecen környékén nem tudtok valakit aki ezzel foglakozik csak annyi kéne hogy feltölteni rá a programot.

Üdv.

Van egy konkrétabb kérdésem: A feljebb látható m_manchester.c-ben a keyhit_delay értéke megfelelő (hogyan számítható)?
Valami nincs rendben ezzel; küld adatot, a másik pic fogadja, és nem érez hibát, de nem értelmes ami átjön. Biztosan jó? Ha simán vezetéken küldöm, ugyanaz ér oda, mint rádión keresztül. Tehát nem a modul kergült meg, hanem maga a kódolás-dekódolás kell, hogy rossz legyen. Ha kiveszem a kódolást, és simán elküldöm sorosan, akkor odaér a megfelelő üzenet (vezetéken). Csak arra tudok következtetni, hogy a kódolás nem megfelelő. Én értem, hogy mi a manchester kódolás, de ez a program valahogy tömény nekem...

Az egész adás-vételre van egy másik megoldás:
Bővebben: Link és Bővebben: Link és még ez is: Bővebben: Link

Igen, ezzel én is találkoztam, csak gondoltam ha ki van rakva egy cikkbe ez a kód, akkor működni is fog... Tetszett, hogy elvileg csak beírom a szöveget, és küldi is
Ha esetleg van valami megosztható példád arra, hogy hogy fog ez hosszabb karakterláncot elküldeni, sokat segítenél (oké, hogy megszakítással, de ötletem sincs, hogy a "boci boci tarka" betűiből hogy csinálok külön-külön elküldendő csomagokat). Az 1db karakter elküldését nagyjából átlátom, holnap konkrétan kipróbálom.
Köszi az eddigi infót!

Kidobtam az eredeti kódolást, és azt raktam be az eredeti helyére. Így a kódolt adat egészen hihető, de a dekódolás most sem megy.
A dekódolás: (a változókat jól adom meg?)

Amivel meghívom a kódolást:

amelyben a timed_getch() a következő (jó benne a delay? nem ez okozza a gondokat?)

A PICkit2 saját programjával próbáltad már?

Szerk.:
Itt van a PICkit2 által hivatalosan támogatott eszközök listája, ezen szerepel a 16F84A. Az más kérdés, hogy az MPLAB kezeli-e ezt a típust, de maga a programozó tudja.

Bővebben: Link

Most találtam meg neten, az felismerte. Köszi a gyors választ Már két éve megvan a pickitem, azóta héba-hóba volt csak használva. Szóval a lényeg, hogy Pickit 2 Programmerrel megy. Bár még mindig nem értem, hogy MPLAB-bal miért nem, ezt Microchipnél biztos jobban tudják

Szerk: Igen én is azt néztem, de a lényeg, hogy megoldódott. Köszi

Sziasztok!

Van néhány érthetetlen dolog a kezelt típusok körében:
- A MpLab PicKit2 programozási lehetősége miért nem kezel minden olyan típust, amit a PicKit2 saját programja kezel?
- Miért nem kezeli a PicKit2 a néhai legelterjedtebb típusokat: 16C83, 16C84, 16F83, 16F84 stb? Ezek programozása alig tér el a 16F84A -tól...

Sziasztok

Sziasztok!

PIC égetési gondom van. Még nagyon régen kaptam egy Tait féle programozót, ezt szeretném 16F84A-hoz és 16F828-hoz használni. Kapcsirajza csatolva. A rajta lévő felirat szerint csak 16C84-et tud progizni, de ha jól olvastam, tudnia kéne az F sorozatot is.
ICProg-ot használok. Minden szépen be van állítva, ki is mértem minden vonalat a hw tesztnél, minden feszültség stimmel (illetve nem baj ha a Vpp ~12.5V?). Beleégetem a programot, de ellenőrzésnél a szokásos hibát írja ki. Visszaolvasásnál látszik, hogy nagy része stimmel a kódnak, de vannak benne hibák.
Van valakinek javaslata, miért nem megy?

Köszi,
FreeX

Próbáld másik programmal. Ha nem megy, akkor a PC és a programok együttműködése a hibás(feltéve, hogy az áramkör rendben van!)

Hali,

Köszi a segítséget, sikerült az égetés.
Próbálkoztam kb. 4 féle jdm égetővel, meg 2 lpt portossal, többek közt egy tait félével és eggyel, amit az oldalad alapján építettem meg. A gond az volt, hogy először egy xp-s laptoppal próbálkoztam, amin soros port nem lévén usb-soros átalakítót használtam. Ezzel a gyatra jelszintek miatt nem működött. Következő lépésben egy hp vékonykliensen próbálkoztam, azon xp embedded van. Ezzel sem jártam sikerrel, sem a jdm-mel sem lpt portossal. Ezek után vettem a bátorságot, az Ubuntus asztali pc-mről wine alatt ic-prog-gal és jdm égetővel simán beégettem a programot. Tehát a megoldás a másik pc-ben volt, ami megfelelő szinteket ad ki a portjain az égetéshez.

Üdv és köszi.

Nálam már 2 db originál Pickit 2 hibásodott már meg.
Nem tudom mitől. A nyákon sérülésnyomok nem látszanak.
Járt-e már valaki így, és megtudta-e javítani ?
Mitől mehetett tönkre, mert tudomásom és tapasztalataim szerint, a véletlen fordított csatlakoztatást ki kellene bírni és az áramkörben történő programozás sem gond. (lehet,hogy tévedek)
A kapcsolási rajza meg van. Neki kellene gyürkőznöm, de egy-két indulási tippet elfogadnék.

Kösz.

Nem (csak) a jelszintek miatt, hanem azért, mert az időzítés is egészen más, mivel a PC nem fér közvetlenül hozzá a lábakhoz, hanem üzeneteket küld az USB adatvonalon (szépen bekeretezve, fejléccel meg CRC ellenőrző összeggel), s aztán ezt az átalakító végén egy mikrovezérlő értelmezi, és végrehatja, amit kell.

És ebben az esetben pont nem azt, amit kell!

Javaslom, hogy ezügyben ezt a topicot válaszd!
PICKit2 klón építése
Igazából tudom, hogy ez nem klón, de azért sok hasznos dolog derülhet ki a javítása során, ami sokaknak segíthet a klón építésekor is.

1. PICkit2 nem termelesi programozo (nem tudom hogy mondjak pontosabban magyarul, nem production programmer), meg csak nem is fejlesztoi, csupan egy nagyon klassz hobby eszkoz

2. Tonkre mehet, minden tonkre mehet -- csak kerdes mi az ami tonkre ment benne, meg a jelenseget sem irtad le?

3. A leg tamadhatobb pont talan a 6 pin header, amivel az aramkorodet csatlakoztatod a PICkit2-hoz. Az aramkorodrol johetnek esetleg tranziens jelek vagy nagy feszultseg, negativ aram stb amik haza vaghatjak -- mint emlitettem nem bomba biztos az aramkor, nem is erre a celra keszult. Ha vigyazol akkor annak nem lehet baja

4. Ha nem jo a geped, vagy nincs foldelve rendesen, vagy a kulso aramkorod es a PC kozt a fold szintje nem azonos, akkor az is okozhat problemakat

5. Es vegul amivel eddig nekem problemam volt: Neha firmware frissites kozben eldobja magat, es akkor csak nagy kuzdelem aran lehet ratenni az uj firmware-t. Extrem esetben akar manualisan kell vissza rakni ra a bootloadert es a firmware-t (ilyen nekem meg egyszer sem fordult elo az evek soran)

Sziasztok!

Egy tapasztalat:
Ha a PicKit2 saját kezelő programjával az uart tool, a logic tool vagy a logic analyzer funkciót használjuk és a megtalált hiba miatt az MpLab-ot indítjuk (olyan project-tel, amiben a PicKit2 a beállított programozó), az MpLab úgy érzékeli, hogy nem jó a PicKit2 firmware-je. Ha nem figyelünk oda, megkezdi a letöltést, de az nem sikerül.....

Sziasztok

Illyenkor működik a BTFSC helyesen? Illetve változik a STATUS Z bite? Mert már megint valamit elszúrtam és erre gyanakodok, de elvileg a MOVF utasítás hatással van a STATUS zero bitére

Így egyszerűbb:


Az adatlap szerint a MOVF utasítás a Z és N jelzőbiteket állítja be a mozgatott tartalom szerint. A BTFSC STATUS,Z pedig Z=0 estén (az adat nem nulla) lép át egy utasítást. (Ugye, még mindig PIC18-ról van szó?)

Akkor valahol máshol van a hiba, először én is így irtam be.
Igen, még mindig 18F1320-at programozok.

Bemásol már ide, hátha valaki meglátja benne a hibát, bár kétlem hogy van benne.


A lényeg: binárisan ki kéne neki írnia LCD-re a két változó értékét. Próbaképp értéket adtam a két változónak ( SZAMLALO_INFO_ELSO meg a második...) , persze csak nullákat ír ki. Viszont ha 255-öt adok neki akkor kiírja a 8db 1-est.
A KIIR_EGY eljárás egy '1'-et ír ki az LCD-re, a nulla meg értelemszerűen egy nullát.