gray code...

... hogy az is egy kellemes erzes mikor kiderul ~fel nap debuggolas utan hogy a gray code -> binaris konverzio elott nem lehet csak ugy ad hoc negalni az osszes bitet :) Avagy: legkozelebb ne doljunk be az "ah, open collectoros a gray-enkoder kimenete, tokmindegy hogy hogy vesszuk le azokat a biteket" dolognak!

( Hiena v | 2018. 03. 22., cs – 11:46 )

Öööö, tessék?

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( uid_6201 v | 2018. 03. 22., cs – 17:37 )

Ezzel nincs sok probléma. Ha akarsz a hardverben invertálni, akkor ahogy bevitted a jelet, invertájl szoftverből is és az így kapott inverz inverze mehet tovább a gray dekódolásra.

( locsemege v | 2018. 03. 22., cs – 23:36 )

Pozíció jeladóval küzdesz? Vagy mit csinálsz épp? Picit bővebben írhatnál róla, így csak te tudod, miről beszélsz. Hiába értem minden szavad, nem tiszta, mit, hogyan néztél el, mi volt a probléma, mi lett a megoldás. Hardware fejlesztőként nyilván érdekel. Tanulni is jó ezekből a történetekből.

Időközben elolvastam újra. Tehát valami ilyesmit írtál - már, ha PIC assembly:

movf PORTB, W

S ezt kellett volna, mert alacsony szintre aktív a meghajtód:

comf PORTB, W

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, ez itten konkretan egy egyfordulatos, 8 bites, abszolut, gray code kimenetu forgasi enkoder. A 8 bitnyi adat parhuzamosan, tobbminden vackon (az open collector-os meghajtason tul meg egy optikai levalaszton is) megy bele a mikrokontrollerbe, es ezek a vackok persze itt-ott invertalnak. En balga meg azt hittem hogy "ah, semmi baj, invertaljanak csak nyugodtan, a gray -> binaris konverzional ez nem szamit, ugyanugy monoton lesz a kimenet". Hat, nem :)