Én valahogy ilyesmi módon gondoltam:

Persze nyilván a stuktúra elemeit nem lehet ezekkel feltölteni, ez itt a gondom. A stuktúra elemeinek típusának is csak azért írtam char-t hogy legyen oda írva valami.

Az enkóder-kezelő függvény a megszakításban van meghívva, az enkóder A és B felének le és felfutási megszakításai okán hívódik meg. Azért is kell neki átadni a portláb beolvasásának mikéntjén felül a megszakítási dolgokat is (flag, él és engedélyezés).

Bocsi a buta kérdésért, de mi a bánat az a rotációs enkóder? Mit rotál és mit enkódol?

Egy tetszoleges szamban, szabadon korbeforgathato tekerogomb, ami a tekeres sebesseget es iranyat adja. Elve egy ket impulzussorozatos kimeneti negyszogjel, ahol a jelek egymastol fel fazissal el vannak tolva. Igy a beerkezo szintekbol az irany kikalkulalhato, a sebesseg pedig ertelemszeruen a frekibol. Az impulzusok darabszama a lepesek szamat jelenti, a finomsagot a gyartaskor hatarozzak meg hardverszinten.
A belso szekezete altalaban mechanikus, egyszeruen egy forgo tarcsa, amin ket erintkezo van es a palya szakaszonkent megszakitott. Igy a ket erintkezo idonkent kap, idonkent nem kontaktust. Letezik belole magneses gyurus, ilyenkor hall-szenzorral veszik az impulzusokat.
Tekereskor eros poziciokba allasok erezhetok, mert ugy alakitjak ki a hardvert.

pelda ra mondjuk a digitalis mikrok tekeros idozitoje.

A beállításokat rosszul írtam, így a jó:

Azt nem inkább érintkező tripletekkel csinálják? Csak abból gondolom, hogy mechanikailag kedvezőbb lehet úgy. Ha érintkező duplet van mondjuk a forgó részen, és szimpla vezető felületek az álló részen, akkor szénkefézni kell a forgó részt. Ha a forgó részre tesznek csak egyetlen vezetősávot, az álló részre pedig érintkező tüske tripletet, akkor a forgatás irányát is ki lehet találni pld jobb-közép összeérintve utána mindhárom összeérintve, vagy előbb bal-közép összeérintve, és utána a három együtt. Ha úgy csinálják, nem kell a forgó részt szénkefézni, mechanikailag időt állóbb lehet. Vagy éppen az a cél, hogy bonyolultabb legyen, és romoljon csak L ?

Bővebben: Link

Láttam már 3 fázisú enkódert, autórádió hangerőszabalyozója, de nagyon nincs elterjedve csak a két fázisú.

A megszaításos kezelés elég megbízhatatlan lesz, ha az éritkezők prellegnek. Még akkor is lehet érzékelési bizonytalanság miatt prell, ha optikai az érzékelő, de a pozíció pont a váltás határán van. Ha élvezérelt megszakítást használsz a prell ideje alatt előre - hátra lépkedni fok egy pozíciót.
Hogyan akasz mondjuk 8 encoder -t kezelni, ha a kontrollernek nincs 16 megszakítás bemenete?

Egy műanyag tárcsa forog, a felületén két pályán van a Gray kódú fémezés. Az A és a B kivezekés a két pályára kapcsolódik, a harmadik pedig mindkettőre. Csak 4 apró érinkező rugó... Tönkre is megy kb. egy év alatt az olcsó egerek görgőjénél.

A függvény a gyakorlatban így ahogy van teljesen jól működik a megszakításban. Ki lett próbálva. A prellegést is leköveti, épp ez a dolga neki. Nem tud olyan gyorsan prellegni hogy a 70MIPS-el ne tudja követni a PIC. De most hogy rákérdeztél megnézem digit szkóppal is, kíváncsi vagyok mennyi időt tölt a megszakításban pontosan...
Nyolc enkódert nem akarok, de kettőt mindenképp jó lenne! Négy INT lába viszont van a PIC-nek, plusz ott az "Interrupt-On-Change". De valójában ez mindegy is mert a kérdés nem az enkóder működésére, vagy az enkódert kezelő függvény működésére irányult, hanem csupán arra hogy hogyan lehetne több kitüntetett-regiszter bitet kezelni ugyan azzal az egy függvénnyel. Igazából itt most irreleváns hogy a függvény mit csinál.

Csak az lehetséges, hogy regisztercímet és maszkot adsz át.

R-C taggal és/vagy IC-vel nagyon szépen meg lehet oldani ezt a problémát. Legalábbis nekem anno sikerült.

Attila86:
Nem tudom, létre lehet-e hozni bitstruktúrát, de ha nem akkor szerintem a bit maszkolásos byte struktúra jó megoldás, csak "sokat" kell írni.
Szóval az Enkoder egy byte tömb, aminek a 0. eleme ugyebár az egyik enkóder, aminek van a két csatornána (A, B). Egy enkóderhez ugye pont 8 bit kell, miknek úgy adsz értéket, hogy először kinullázod, majd maszkolva beállítod (VAGY művelettel) az egyes biteket (pl jobbról balra: maszkolás előtt rotálod őket: először nem is rotálsz, utána egyet balra, majd kettőt balra ... és így tovább 7-ig).
Szerk.: most látom, már írtad a bitenkénti verziót. Akkor nem szóltam.

Rendesen kódolva még akkor sem igazán ciki, ha már stabilnak kellene lennie az előző érintkező jelének, amikor még mindig prelleg, és már a következő is prellegni kezdett. Még akkor is lehet modellezni az állapotukat, mint például stabil volt X msec ideig, akkor az egy állapot volt, és ha utána egyáltalán prellegni kezdett, akkor az az ellenkező állapotba váltás eseménye. Csak egy ötlet.

Én rontok el valamit, vagy az atof() függvény működik rosszul?
Korábban hibát találtam a gyári Microchipes strstr() függvényben is (Bővebben: Link) úgyhogy nem lepne meg ha ez is hibás lenne...

Sziasztok!
Harmony-val játszok, veszem fel egymás után a Drivereket. Egy SD FAT (SPI) -vel kezdtem, majd egy USB HID-et építettem rá, már ekkor is néha lefagyott, nem foglalkoztam vele, ritkán történt, gondoltam csak időpocsékolás lenne elmerülni az ok keresésében. Aztán felvettem a HTTP Servert is és így együtt el is indul, server fut, SD fut, USB HID konnektál. Aztán amikor egy adatot küldök az USB-n, lefagy a System Timer. Régen is volt hasonló gondom, kikerültem, mert akkor én írtam az egész kódot az elejétől, de a harmony tele van ennek használatával, így félek nem tudom kikerülni, de ezt ma meglátom, ha hazaértem.
Naszóval a kérdésem, nem találkozot valaki infóval arról, hogy a SYS_TMR_TickCountGet(), ami a System Timer számláló értékével tér elvileg vissza (ha jól tudom), hogyan adhat vissza azonos értékeket? Nyílván nem fog futni az Stack-ek időzítése sem... Érdekes, hogy csak az ethernet fagy le, az USB és az SD tovább fut (másképp vannak időzítve a belső elemek, gondolom). A timer megszakításokkal is gond van ilyenkor, mert a TMR_Stack-ek nem törlik a megszakítás IF-eket, és roszz értékekkel térnek vissza, beragasztják a szálat a megszakításba. Remélem megtalálom a megoldást, de várom a segítségeteket is! Köszönöm!

Sziasztok.
Watchdogot szertném konfigurálni, úgy, hogy csak az inicializálás után induljon el. Adatlap szerint ez lehetséges FWDTEN kinfigurációs bit segítségével.

A kérdésem az lenne, hogy ennek a bitnek az értékét hogyan lehet változtatni C forráskódbol futásidőben?
Megj: dsPIC33EP512MU810-et használok, xc16-os kompilerrel.

Config bitet nem tudsz átírni futási időben. Ha a flash programozás segít is benne, az device resetkor már shadow registerbe van másolva, ergo az induláskori értéke akkor is megmarad.

Az RCON register-ben az SWDTEN bitet tudod átírni futás időben, az adatlapon megtalálod (DS70616G-page 143).

Mint ahogy azt is megtalálod, hogy az FWDTEN configurációs bit (DS70616G-page 477, DS70616G-page 478, DS70616G-page 482).

A device pragma-k között nézz szét, milyen néven van definiálva a config bit változtatása, azt hirtelen most nem találtam meg.

A mechanizmus úgy néz ki, hogy default esetben configból kikapcsolva van, és akkor szoftveresen bekapcsolhatod, ha akarod. Ha configból bekapcsolod, akkor szoftveresen már letiltani sem tudod.

Köszönöm a segítséged, így már müködik.

CCS-C ben járatos emberek segítségét kérném!

soros protra küldök ki adatokat:


Ha a soros portnál beállítom, hogy legyen adási puffer

akkor a Homerseklet_alapjelet többnyire hibásan küldi ki a portra. Ciklikusan ismétlődnek a hibás adatok, de minden 6.-ra helyesen küldi ki. Ha nincs adási puffer akkor mindig hibátlanul küldi az adatokat. A Lakas1_homerseklet mindig hibátlanul megy.

Ez mitől lehet?

Milyen típusú a Lakas1_homerseklet és a Homerseklet_alapjel változó?
Idézet a Manual -ból:

A felsorol formátumok között nem találok lf -et, a float -nél nincs utalás a bevezető 0 -ra.

Homerseklet_alapjel: unsigned int16
Lakas1_homerseklet: float

Próbáld meg így:

Próbáltam, nem lett jó.
De nem is ezzel, hanem a Homerseklet_alapjel kiírással van gond. És azzal is csak akkor ha adási puffer van beállítva ( és akkor a főciklusból az fputc_send(UART_PORT2); parancs küldi ki az adatot)

Gondolom elcsúszik vagy a géped, vagy a uC a megadott baud rate-től, ez okozza, hogy mindig ugyanott van a hiba. Mire odaér, addigra pont annyi hiba összegyűlik, hogy bajt okoz.

Ennek elentmondani látszik az a tény hogy a %...f sorokat hibátlanul küldi, a %...w adatoknál viszont 70-80% -ban hibásan küldi az adatokat. Logikai analizátorral nézve, automatikus baud rate-val is hibás az adat. (Az analizátor szerint 9592 Baud a sebesség)

Azért holnap kipróbálom, hogy más sorrendben küldöm ki az adatokat, ha igaz a feltevésed, akkor másik adatnál kell jelentkezzen a hiba.

Üdv! Egy olyan programot keresnek ami projectorhoz való, úgy nevezett lampa timer reset kene, sajnos amit csatoltam kepet az levan vedve igy nem tudom kiolvasnia programot.

PLC-WXU 300
Pic16f688
lámpa Timer reset ??

Átírtam a sorrendet, sajnos ugyan azt az adatot küldi ki hibásan.

Van egy programrész ahol 11db float típust küldök ki, mind hibátlanul megérkezik. Ezt a rész átírtam, hogy az unsigned int16-okat küldje ki ... 11-ből 2-3 jó a többi hibás!

Ha nincs beállítva buffer minden adat hibátlan!

Milyen összefüggés lehet egy szám átkonvertálása és a soros port bufferelése között?

Ha LCD kijelzőre küldöm az adatot (azonos formátumban) az minden esetben hibátlan.

Ha ismered az elektronikai környezetet, és le tudod írni precízen, milyen feltételekkel mi legyen a felhasználói élmény, egyszerűbb a nulláról felépíteni egyet, mint meglévőkkel kísérletezni.

Rakj az adatvezetékekre logikai analizátort, azzal kb. minden kideríthető.