gray code...

 ( apal | 2018. március 22., csütörtök - 12:35 )

... 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!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Öööö, tessék?

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

Elferizett egy logikai áramkört.

ja igen, az allitmany lemaradt :)

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.

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 :)