Sziasztok! Segítséget kell kérnem, mert már teljesen tanácstalan vagyok. Egy ideje próbálkozom rotary encoderrel MikroC-ben. Próbáltam már sima bemenet figyeléssel, próbáltam megszakítással, de nem értem el normális eredményt. Próbáltam már 5 féle enkóderrel, ezek közt volt egy optikai is. A neten fellelhető táblázatok alapján egyáltalán nem működik a dolog. Én az elején azt hittem, hogy az ezen a képen t1, t2, t3, t4-gyel jelölt időpontok ott vannak, ahol megáll az enkóder. De már csak műszerrel mérve sem ez az eredmény, léptetés közben változik a kimeneti jelalak, de ha áll az enkóder, állandóan szakadást mérek rajt. Számtalan videót és leírást megnéztem, mindenkinek olyan könnyedén megy ezt felprogramozni. Lehet, hogy már a ötödik rossz enkódert fogom ki? Ebből 3 vadi új volt, az egyik az optikai. Van valakinek egy tutira működő programja erre MikroC-ben? Legalább kipróbálni őket, hogy hol a hiba..
Köszönöm!

Nem valószínű, hogy rosszak az encoderekEbben a cikkben az optokapukról szóló részben van C kód. A két egymás után elhelyezett optó működésének az analógiája ráhúzható az encoderre is. Sőt az optikai encoder tulajdonképpen az is. A bekötés egyébként tuti jó?

Közhasználatban, hobbistáknál alapvetően két típusú enkóder forog közkézen: Bővebben: Link. Ha Gray kód szerinti kimenetű az enkóder, akkor két Interrupt On Change kell, egyébként elég egy is.

Nem biztos, hogy kezdő kérdés, de elfér itt.
A PIC32 SPI TX-bufferébe ha enhanched mode 32bit-ben megy, hogy kellene beletöltenem az adatokat, hogy működjön is. Egy 4x1 byte-os tömböt sem tudom beletölteni, hogy működjön. Mindig csak az első byte jön ki a kimeneten.
XC32, de nem a beépített spi rutin, sajátot szeretnék létrehozni.

Update: Egy 32byte méretű adat kimegy, de a 4 elemű elemenként 8 byte-os tömbnek csak az első byte-ja.

Nem tudom, hogy segít-e, de hátha.

SPIxCON ON = 0-nál kell írni az ENHBUF-ot
és addig írsz SPIxBUF-ba amíg az SPIxSTAT SPITBF = 0

Köszönöm, ezekkel tisztában vagyok. Megpróbálom érthetően megfogalmazni.
Ha egy uint32-t töltök az SPIBUF-ba az kimegy.
Viszont én valami ilyesmit szeretnék.
pl:
unsigned char array = {13,13,13,1};
Na ez nem ment be egyben. Ezt szerettem volna etetni vele egy 32 bites adatként, mondjuk pointerekkel de eddig nem sikerüt. Gondoltam mivel a tömb elemeit egymás után rakja, legalábbis az MPLAB egymás utáni címeket mutat, akkor be tudom neki adni. Valószínűleg én csinélok valamit rosszul, mert feltételezem megoldható, hogy egy tömb 4 egymás utáni elemét 32 bites egységként kezelje. És itt értem anélkül, hogy a 4x8 bitet összeraknám egy másik változóba shiftelgetéssel. Lehet esetleg struktúrában kellene?
Vagy ez így nem megoldható?

Enhbuf nélkül kimegy a 32bit? (MODE be van állítva?)
Esetleg a tömb elé tegély a volatile-t hátha.

ENH nélkül sem megy ki. Mode be van állítva.
Voltaile-t kipróbálom, köszi.

Na most teszt céljából szétszedtem 8 bites adatokra normál módban. Most meg elveszik az utolsó 3 bit.
Pl ha ez alábbit küldözgetem végtelen ciklusban

akkor a 73-as utolsó 3 bije lemarad. Ez vajon miért van?

Korábban kiment mind a 8 bit?
SPI konfigurációból nem adódhat?
Meg ugye R/W bit, address bit, ilyesmi lehet az első byte végén.
Ha minden Írásod új írásnak veszi valamiért, akkor ezek a bitek befolyásolhatják a küldött adatot.

Nekem nem volt ilyen problémám soha 2 dolog amit próbálj ki.
- SPITBF helyett SPIBUSY-t nézz (csak itt a normal mode-ban)
- SPITBF helyett SPIRBF-et (amíg 0-a addig nem engedsz új írást, nem tudom, hogy default-ban 1-ben van-e lehet az első byte-ot cikluson kívül kell küldeni)

Erre közben rájöttem. A k-t elírtam.
Most teszthez jó lesz, de a 32 bit módot még ki kell deítenem hogy tudom megoldani.

Pakold egy voltatile uint32_t-be a 4byte-ot ENHBUF =0 és MODE=32bit-el és nézd meg elvileg így ki kéne menjen a 32 bit egyszerre.

Ok,kipróblom, köszi. Még egy kérdés. Hogy tudom rávenni, hogy 0-kat is küldjön.
X ideig alacsonyan kellene tartanom. Framed mode nélkül is megoldható?

Csak egy észrevétel, de nem biztos, hogy sokat segít:

Ha az arr[] tömb 12 elemü akkor nem inkább az kellene legyen a for-ban, hogy k<12?
Mert másképp sose ér el az utolsó elemhez...

Igen tudom. A következő hozzászólásomban írtam is hogy megtaláltam az elírást.

Köszönöm! Így már értem az egészet. Azért ránéztem egy logikai analizátorral, sokkal előbb kellett volna megtennem. Így igazából kezelni is sokkal egyszerűbb.

Van egy RF távirányítóm aminek a jeleit szeretném PIC-el különböző funkciókra rakni.
A kódolása valami NRZ-féleség. Először azt hittem Manchester, de nem 1:2 arányú az "1"-k és a "0"-k száma hanem 1:3.
Ilyesmi sorozat: 1000 1000 1110 .stb.
Minden gombra 20 adategységnyi bit tehát 20x4 "0" és "1" ami minden gombhoz azonos, majd 5 egység gombazonosítás, majd kb 6 egységnyi azaz 6x4 "0" szünetet ad a vevő. Ha folyamatosan nyomom a gombot ezek ismétlődnek.
A kérdés az, hogy lehet ezt legegyszerűbben megoldani.
Valószínűleg külön PIC-nek kell dekódolni, mert nem hiszem, hogy ezt valamelyik periféria kezelni tudná, azaz főciklusban kell lekérdeznem és bufferelnem. Vagy esetleg az SPI-vel tudom valahogy szinkronizálni s azzal venni?
Folyamatosan meg azért kell lekérdezni, mert a vevőn nemcsak gombnyomáskor jön adat, hanem előtte is mindenféle katyvasz. Bármi ötletet szívesen meghallgatok.

Mondjuk nem értem a négyes szorzó hogy jön a bitekhez, de ez legyen az én bajom.
A helyedben egy cirkuláris puffert használnék, ami kicsit nagyobb az adatsorozatnál, új időszelet utáni bit bejövetelekor végigellenőrizném az aktuális pozíciótól megszakításban, gombra maszkolva. Magyarán először kihagynám a gomb bitjeit, csak hogy a header és az adat után jövő szünet megvan-e.
Nem tudom, mekkora a frissítési freki, de szerintem a megszakítás simán elviszi.

12 C 508A uC-hez van a hex fordítva.

Nekem 12 F 508A uC-erem van.

Ez okozhat gondot a F uC működésében ha a forrást C-sre írták ?

Szerintem nem, de ha tévedek majd kijavítanak.

Köszönöm válaszod. Ami a 4x szorzót illeti leírtam, hogy négybites a kódolás, 1000, 1110, innen a 4-es szorzó. Vagyis egy kódolt 1-es az 1110, a kódolt 0 pedig 1000 Ami nem annyira lényeges, csak mint infót adtam meg. Egy bit ~415-420us (~2,4kHz).
Én is ilyesmire gondoltam, csak a bitbeolvasást, ugye folyamatosan kell végezni, és a főgépésznek (PIC32MX274F256) lesz más dolga is, ezért gondoltam, hogy ez kap egy külön PIC-et, de még majd utánaszámolok kell-e.

Tisztelt szakértők valaki le tudná nekem ezt az http://www.hobbielektronika.hu/kapcsolasok/files/97/nixie.asm fájlt 16f84-es picre fordítani. Segítségeteket előre is köszönöm.

Mottó: Egy tengerészgyalogos türelmetlenül kéri a rádióján a légi támogatást... Nemsokára jön is egy repülő, de csak egy reklám feliratot húz: "Meg tudod csinálni!"

Végy egy MpLab ASM fordítót (a Microchip oldaláról) és fűszerezd meg a két adatlappal.
Cseréld ki a következő két sort

erre
Módosítsd a __CONFIG sort a 16F84 adatlap 8.1 fejezete szerint.

Végezetül csak az idétlenül megírt változó definíciókat kell átírni, hogy a címek a 0x0C - 0x4F közöttiek legyenek.

Köszönöm,megpróbálom.Remélem sikerül.

Üdv. Ha egy PIC kimeneti jelét össze akarom kötni egy másik PIC bemenetével, akkor kell közzé valaki fel-lehúzó ellenállás, csak csak egyensen össze lehet kötni?

Minden további nélkül összeköthető a kettő. Akkor kell a felhúzó ellenállás, ha az a kimenet nyitott kollektoros, vagy annak van konfigurálva. Biztos ami biztos alapont felhúzónak használj egy 1 kΩ-os ellenállst.

Gond akkor lehet, ha mindkét láb kimenet és ellentétes kimentű jellel versenyeznek egymással. Ha nem vagy biztos a dolgodban, a két láb közé egy soros, 1 kΩ-os ellenállást tervezz.

Gond még akkor is lehet, ha az egyik kontroller kap tápfeszültséget, a másik pedig nem. Ha a küldő nem kap tápfeszültséget, akkor alacsony szintet érzékel a vevő. Ha a vevő nem kap tápfeszültséget és van a lábon belső védődióda, azon keresztül kap tápfeszültséget.
További probléma lehet a tápfeszültség eltérő értéke.

Ezzel gond nem lesz, mert egy tápról fog menni. Akkor végül igykább ne egyenesen kössem össze a lábakat, hanem egy soros 1K ellenállással?