Fórum témák
» Több friss téma |
Cross51: Ott a pont! Viszont van egy library, amivel elvileg megvalósítható a 9 bites küldés, a paritás bit speciális felhasználásával. Ennek az élesztése van most valószínűleg folyamatban
 Babakush: Nincs mit! remélem sikerül összehozni
Sziasztok!
Megint én.... Sajnos nem sikerül összehozni, hogy PI-ről is fogadja az adatokat. Kimértem mind két jelet és teljesen tanácstalan vagyok, mivel szerintem ugyan olyanokat. PIC-ről tökéletesen dolgozik a cím byte-al és fogadja utána az adatot is. Viszont, ha PI-ről csinálom ugyanezt, még az Rx interrupt se hívódik meg. Kipróbáltam PI-PIC kommunikációt 8bites UART-al úgy tökéletesen működik minden. Valamiért a 9bitesnél száll el pedig, szerintem megegyezik a PIC-nél kiadott jelekkel. Remélem csak nagyon benézek valamit és ti tudtok segíteni . (0x02 a cím byte mindkét esetben és 0x06 az adat) Kipróbáltam más baudrate-en is, de semmi A hozzászólás módosítva: Szept 24, 2021
pic0x02.PNG - 44 időegység, rpi0x02.PNG - 40 időegység.
Akkor a Pi nem is 9bitet küld ki magából?
Miért nem 0x55 vagy 0xAA adatokkal tesztelsz? Ott látszanának a bitek, legalábbis egyszerűbb lenne megszámolni és eldönteni, hogy 8 vagy 9 bitet küld ki.
Idézet: „Akkor a Pi nem is 9bitet küld ki magából?” Ezt írtam 10 hozzászólással korábban (21:37)
Sikerült rájönni mi a probléma csak megoldás még nincs rá. Jefflynn ötletét felhasználva, sikerült megnézni, hogy hány bit is jön ki belőle. meg van a 9. A hiba C++ programban van, rosszul billentgeti a mark/space parity bitet
A hozzászólás módosítva: Szept 25, 2021
Csak belevau, de nem lehet hogy a paritást a soros bájtnak megfelelően állítja automatikusan, és nem a te kivánságod szerint ?
Nem tudom, hogy ez segít-e valamit: Bővebben: Link
Köszönöm mindenkinek a segítő tanácsokat. A héten nem volt nagyon időm rá, hogy foglalkozzak vele, de ma neki ültem tiszta fejjel és sikerült. Ezt csak azért írom le, hogy legyen tanulsága a kálváriámnak, illetve hátha segít valakinek a jövőben. Első körben,aki ezzel próbálkozna Bővebben: Link, nálam nem működött, szerintem QT SDK nem jól kezeli jól a paritás bitet. Így visszatértem az alapokhoz és megírtam c-ben. A kulcs az egészben, amikor mark/space paritást szeretne váltani az ember( tio.c_cflag &= ~PARODD vagy tio.c_cflag |= PARODD) a paritás beállítása utána frissíteni kell a terminos struktúrát ezzel a függvénnyel tcsetattr() különben nem érvényes a paritás váltás
Sziasztok!
Abban tudnátok segíteni, hogy a k értékét miért nem tudom kiíratni LCD-re? A szöveges rész szépen megjelenik. Köszönöm!
Az LCD a 0x03 kóddal a felhasználó által definiálható 4. karaktert azonosítja. A 3 számjegy kiíratásához a 0x33 = 51 kódot kell küldeni.
char k='3';
Köszönöm szépen. És ha ez a k egy fuggvennyel folyamatosan változik pl. k++;.Akkor ahhoz mit kell beirnom?
A '3' és a 3 között az a különbség, hogy az első egy ASCII karakter és az értéke 51, a második egy bájt, értéke 3. Lásd: ASCII tábla.
Ha k számot tárol (3), akkor karakterré kell alakítani, hogy meg tudd jeleníteni. Ha karaktert ('3'), akkor egy az egyben ki tud menni. Ez itt nem egy szép és nem is túl optimális megoldás, de azt talán megmutatja, hogy miről van szó.
Ez is jó megoldás, de vannak limitációi, próbáld ki ezt és látni fogod:
A hozzászólás módosítva: Jan 13, 2022
Sziasztok!
Egy különös(legalábbis számomra) problémával fordulnék hozzátok. Feltöltök egy tömböt az uarton bejövő adatokkal, aztán ezt a stringet feldarabolom és egyes részeit berakom egy 2D-s tömbbe. Utána pedig egy struktúrában szereplő stringekkel szeretném összehasonlítani ebben a 2D-s tömbben szereplő stringeket. Free run módban még az első lefutásnál még úgy viselkedik a kód, ahogy szeretném, de következőknél már nem. Elkezdtem kidebugolni, hogy mégis mi szerepelhet a ezekben a tömbökben és azt vettem észre, hogy ha beteszek egy breakpointot akkor, tökéletesen működik minden, akárhányszor is hívom meg ezeket a függvényeket. Viszont, ha nem teszek vagy egy bizonyos sor után teszem a breakpointot ugyanúgy viselkedik a program, mintha free run módban futna. Debugolásnál ilyenkor látszik, hogy valamiért memória szeméttel tölti fel a 2D-s tömbömet. Csatoltam két képet, hátha segít megérteni az esetlegesen felvázolt problémámat. PIC18fF26k83 MPLABX IDE 5.50 XC8 (V2.32)
Hibás esetben az rxbuffer első byte-ja 0, az strtok erre NULL-t ad vissza, de azt nem ellenőrized, hanem növeled mint pointer, és így a memória 0x0001-es címéről olvasol, és onnan dolgozol tovább. Ezért van az command-ban szemét. Azt kell megállapítanod, hogy miért van 0 az rxbuffer elején, illetve ellenőrizni az strtok visszatérési értékét, ha nulla van akkor se legyen hiba.
Igen, de egyelőre nem tudtam kideríteni, mivel ha az uart beolvasás után teszem közvetlenül a breakpointot, nem kerül bele az elejére az a 0 érték. Ezaz, amit nagyon nem értek, hogy miért számít, hova teszem a breakpointot. A többi észrevételt, amúgy köszönöm, ezek valóban hibás részek. Amúgy a pointer preinkrementálás a SOH miatt van, hogy azt már ne tegye át a másik tömbbe, de ahogy mondtad, a hibás esetben nem megfelelő ez a logika.
Én egyébként kerülöm az strtok-ot, mert manipulálja a buffert. Meg lehet oldani anélkül is, ha egy ciklussal végigmész, és másolod a byte-okat amíg elválasztó karaktert nem találsz, vagy a buffer végére nem értél, vagy a célbuffer vége-1-re nem értél. stb. Az sem bonyolultabb, és hibatűrőbbre meg lehet csinálni.
Az strcpy is egy erősen kerülendő függvény. Semmi nem garantálja, hogy nem írod túl a célbuffert, ha nem ellenőrzöd le magad előtte a forrás hosszát. Helyette lehet használni az strncpy-t, ha van ebben a környezetben. És mit csinál addig a soros vételed, amíg az adatokat feldolgozod? Letiltod vagy továbbra is oda veszi a következő byte-ot? Mi alapján kezdi a buffer elején megint? A hozzászólás módosítva: Feb 17, 2022
Az strtok megírtam kézzel. Csak ugye úgymond random lesz az első értékem így az összehasonlít elég nehéz, de úgy valóban nem lesz szemét benne csak néha ott a 0 érték néha nem... Köszi! Utána nézek ennek az strncpy-nek(őszintén szólva nem ismertem). Nincs letiltva, de le lesz, erősen teszt fázisban van a kód, de én küldöm ki kézzel neki az adatot uarton szóval, addig nem érkezik semmi, amíg a feldolgozás le nem ment. Közben úgy néz ki sikerült megkerülni a problémát, mivel az elején úgyis mindig ott a SOH, ezért egyszerűen nem rakok be semmit az rxbufferben, amíg be nem olvastam a SOH-ot.
Ui.: Ettől függeetlenül érdekelne, hogy mi okozza az alap problémát, ha találok rá választ, megosztom. A hozzászólás módosítva: Feb 17, 2022
Van 1 lezáró karakterem a kiküldött stringem végén és ha az megérkezett akkor nullázom a buffer számlálót illetve feldolgozás utána memsettel nullákkal töltöm fel.
Sziasztok!
Tudtok ajánlani írásokat azzal kapcsolatban,hogy hogyan kell problémákat megoldani programozásban. Pl.:pwm jelet hogyan kell létrehozni és azt kimenetre küldeni. Köszönöm!
Sziasztok,
Tudna valaki segíteni. A PIC18F47Q10 típusú kontrollerrel gyűlt meg a bajom. A TIMER1 16bites számláló legfelső bitjét kéne "1"-be állítani, de valamiért nem működnek az eddigi megszokott dolgok (bit_set(Timer1H, 7), #bit, ..) csak a set_timer1(32768); és nem tudom mi a gond. Az adatlap szerint - ami új ismeret - eleve be lehet állítani, hogy 8 vagy 16 bites működési módja legyen (RD1 bit) a számlálónak. Lehet, hogy ez a gond, mert hiába próbálom beállítani a 0x0FCD regiszter (TIMER1H) 7. bitjét, az sehogy se sikerül... Ha valaki tud használható segítséget adni azt nagyon megköszönném... Köszönöm.
Leírtad a kérdést és a megoldást.
Igen, kapcsold 16 bites módba a timert, ha 16 bitesként szeretnéd használni. Ha ezt nem teszed meg, akkor 8 bites módban működik.
A 8 bites PIC-ek timer-ének 16 bites mód haszálatakor a felső byte történő írása két részletben történik meg. A pdf 19.6 Timer1 16-Bit Read/Write Mode (és a Figure 19-3. Timer1 16-Bit Read/Write Mode Block Diagram ábra) leírja, ill. szemlélteti ezt. Az MSB ténylegesen csak akkor íródik be, ha utána az LSB-t is írod.
16 bites módban a TMR1H regiszter bufferen keresztül érhető el. Ha a TMR1L regisztert olvassák, a timer belső TMR1H regiszterének értéke a bufferbe kerül, és innen olvasható ki a mentett érték. Ha a TMR1L regisztert írják a TMR1H buffer regiszterbe előkészített érték másolódik a belső regiszterbe.
8 bites módban mennie kellene a TMR1H direkt módosításának.
Bocsi,
akkor rosszul (vagy félreérthetően) írtam valamit. Maga a regiszter mindíg 16bit-es csak az írás/olvasása történik 16, vagy 8 bites móban (!!?). Sajna megnérztem a fordító álltal generált asembly file-t és a normál start utasítás (setup_timer_1(T1_EXTERNAL|T1_DIV_BY_1); 16bites módba indítja a számlálót. Köszi az ötletet, megpróbálom a megkeresni a buffer regisztert és azt írni. Köszönöm a segítséget... ha valami nem megy akkor jövök még egy fordulóra. Köszönöm. |
Bejelentkezés
Hirdetés |
