Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Fordítsd "konfliktuskezelés"-nek! A konfliktushelyzet akkor jön létre, ha egyszerre többen versengenek a busz birtoklásáért.
Ha nem akarsz járművekbe, biztonsági rendszerekbe fejleszteni akkor semmi gond
 Egyébként elfogadott, szigorú alaptétel. Lásd: MISRA C.
Mi lenne a gond ebben? A program végül így is, úgy is pontosan azt fogja csinálni, amit kell.
A fordító megengedi a váltást a szabványos és nem szabványos C között. Konkrétan az integer promotions szabályokról van szó, amit killbill is említett.
Bővebben: Link
Szerintem itt elbeszélünk egymás mellett. Túl van ez tárgyalva...
Köszönöm a jó szándékot, anno én is végignéztem minden tipuskonverziós trükköt, de sajnos ilyenkor pl a bájtokból intet csinál, és két intet szoroz össze, 1 intté. Általában szigorú feladataim vannak, nincs erre gépidő. Mondom, mindezt úgy, hogy a lib-ben lévő szorzó rutin tökéletes, de azt "elrontja" a fordító. Egyébként úgy szoktam becsapni hogy a*b. Semmi egyenlőség. Aztán az access mező regisztereiből, ahova a rutin lerakja az eredményt, kiveszem. Tökéletes, de nem szép.
Idézet: Viszont ügyes! „Tökéletes, de nem szép.”
Írhatsz magadnak asm-ben saját szorzó rutint, és csinálhatsz belőle függvényt / makrót.
Sokáig valóban saját rutinnal szoroztam, de a C18-as rutinok is elég jól meg vannak írva. Néhány utasításidő különbség volt csak.
A makróval viszont igazad van ! Egyszer régen már elvetettem, mert volt egy bizonyos probléma vele,de most rájöttem hogyan kerüljem meg ! Köszi!
Ha az embernek meg kell küzdeni minden usec-ért, kénytelen kitalálni valamit
Ilyenkor érdemesebb nagyobb teljesítményű PIC-et választani.
Csak azt magyarazd el nekem, hogy az egyenloseg hianyatol miert fog kimaradni az 'a' es 'b' valtozok int-re konvertalasa. Mert, ahogy te is irod, elobb a byte-okbol intet kell csinalni, azatn szorozni. Es ez teljesen fuggetlen attol, hogy a szorzattal mit csinalsz.
Mérőrendszereket tervezek, 18f46k80-nal dolgozom. Ez a tipus az egyetlen amiben szimmetrikus bemenetű 12bites AD konverter van, azaz megspórolok egy csomó alkatrészt általa(kivonó erősítők, szintillesztő, referencia kiegyenlítés, a nyákon speciális vezetékezések a zajcsökkentésre stb). Amikor egy éve néztem, már volt ilyen AD-vel valamilyen dsPICs is, de olyan új, hogy még nem működik az AD-je, hosszabb az erratája mint a karom
Ha tudnám a választ erre, nem kellett volna kérdeznem. Számomra irtózatosan illogikus, mert matematikailag tisztán az történik, hogy 8bx8b=16b, 16x8=24, 16x16=32. A math könyvtárban meg lehet nézni a rutinokat, mit csinálnak. A disassemblyben meg azt, hogy hogyan nem használja ezeket, vagy ha igen, akkor hogyan rontja el...
 Az a*b-nél érdekes mód minden oké, csak a hülye __aargbx neveket kell megszokni, meg hogy nem a 0 az LSB(ez is milyen már...) Még valami: osztásnál a maradék a __rembx-ben egyből előáll, erre is nagy szükség szokott lenni. Nem kell kétszer, / és % is. Én még assemblyben kezdtem, 8085-ön és 8051-en, oda ezt mind meg kellett írni. Most meg körülírni kell. Hát, ezért ez is valami fejlődés... .
Tényleg furcsa, hogy a 32 bitesekben is csak 10 bites AD van, de mintha anno valami olyasmivel indokolták egy blogban, hogy a 10 bit már egyébként is ezrelékes pontosságú (0.1%). Amennyi szórása szokott lenni egy átlag pic-es áramkörnek, a gyakorlatban annál pontosabbra számítanod nem különösebben érdemes. Már a 0.1% is inkább csak elmélet lesz, mint gyakorlat. Mászkálni fognak a bitek a pic és egyéb alkatrészek saját hibájából (gyártási szórás, hőfokfüggés, fehérzaj), és az egyéb gyakorlati környezeti tényezők is ott lesznek rábrummogni a vonalakra. Leméred ugyan azt az értéket laborban 10 különböző egységgel, és 10 különböző értéket kapsz már 10 biten is. Én 6-7 bitre akarnék számítani a gyakorlatban egy nagyon jó esetben, annál többre biztosan nem. Mindezzel csak arra akarok kilyukadni, hogy ha a matematikai számolással időszűkében vagy, és az sokat nyom a latban, nyugodtan hagyhatod éppen azt a pic-et a fenébe, és használhatsz valami 32 bites cuccot nagyobb órajelen, a gyakorlati mérési pontosságod ugyan az fog maradni.
A hozzászólás módosítva: Júl 9, 2017
Sajnos a PIC32 errata -k tele vannak A/D -ra vonatkozó bejegyzésekkel.
A rendszeres hibák ellen kalibrálással (pl. ofszet kompenzálással) a véletlen hibák ellen több mérési eredmény átlagolásával lehet védekezni.
Lehet, hogy meglepő, de nem használom a PIC-ek AD-it. Külső AD-kkel mindig megbízható eredményt kapok, míg a PIC-ekkel csak a szívás van a táp miatti és a belső zavarok miatt. Én a könnyebb, de kicsivel drágább megoldást választom. Nem állítom, hogy nem lehet PIC-el is megmérni valamit, de pl. hőelemhez már nem alkalmas, de már 4-20mA távadókhoz sem szívesen használom...
Nyilván jobb egy külső AD, de azért nekem a PIC-ek AD-i is szépen működnek. Az említett 46k80-é különösen. Persze jó nyák(földvezetékezés) kell a zavarok ellen, és jó helyeken hidegítőkondik. A belső referenciafeszültségeket el kell felejteni, a hőfüggésük vicc. Külső ref kell, a ref bemeneten RC taggal (100R-2u2).
A hozzászólás módosítva: Júl 14, 2017
Hali!
nálunk 16f1789 szériában bukott ki, hogy egyes(nem is kevés) darabok AD-je nem az igazi, potméter van rajta, és a potit nullára letekerve, vagy akár rövidrezárva a bemenetet, az AD nem nullát ad vissza, ha nem (felső)8bites-ként nézve kb 7-8-at ad, nem zajos, mindig ugyanannyit.
Sok PIC errata dosijában le van írva ez a hiba, mint offset hiba. A megoldás a kalibrálás. Lábat GND-re és amit ad az ADC, az az offset, ezt minden mérés eredményéből ki kell vonni.
Nem feltétlen haladó, de 32MZ-hez kell nem akartam kezdőbe
Sziasztok! Gombokról lenne a kérdés. Ha a maximális gomb PIC távolság 2m maradhat még a belső pull-up? Csak hogy a belső pull-up a "pic nyakában" van, de a "hosszabb" vezeték miatt nem szed össze jobban zavart egy külső 10k ellenállással szemben? Vagy csal túlságosan aggódok?
Ennek majdnem a PIC-hez sincs köze... Adott a kérdés hogy két méter hosszú lebegő vezetéken mi a jobb a zavarvédelem szempontjából: egy nagyobb vagy kisebb impedancia? költőinek tűnik. Szerintem az sem mindegy, melyik végén alkalmazod a felhúzást. Mellette kellhet soros ellenállás, és kondi zavarszűrés, és a felhúzó egyszer a belső, és a vezeték másik végén a gombnál a másik felhúzó, az meg inkább 4,7k vagy kisebb.
A kondi gondolom a gomb "nyakába" a 4,7k elég lesz szerintem a 2m az a nagyon rossz közelítéssel a leghosszabb vezeték szerintem ilyen 60-80 cm között fog mozogni (csak nem a nyákon).
Az előtét 100 Ohmos vagy kilós nagyságrend? És a gomb és gnd közé vagy gomb és PIC közé tegyem?
Ha teheted, tegyél 1k-t mint felhúzó ellenállás, 5V-on 5mA folyik, de ez csak amikor megnyomod a gombot. Ez már megfelelően zavarvédett szerintem.
Én elosztanám, a vezeték mindkét végére raknék 2k2-t. A kondit a pic-hez, hogy a nyák tartsa. Vagy azt is elosztod. Bajt nem okoz. Én 2x10nF-2x100nF-ot használnék. A hozzászólás módosítva: Júl 16, 2017
Találtam egy digikey-es leírást ami mindent leír ami nekem kell (Bővebben: Link)
Köszi a segítséget!
Részemről 2m vezeték miatt még nem aggódnék. A sztatikus terhelés az igazi gond, ha messzire viszel valamit, nem a távolság maga. A távolságot illetően 20 méterrel sincsen semmi gond. Azzal van gond, hogy műszálas pulcsiban fészeklődsz a gumi szőnyegen tartott poliészter ülésen egy órát, ami teljesen másik sztatikus feltöltődésekkel teli környezet, mint ahol a pic van, és akkor nyomod meg a gombot (egyáltalán hozzáérsz), ami elvezeti majd azt a töltés löketet is a pic felé.
Üdv Mindenkinek!
Kérnék egy kis segítséget. PIC32MX170F256B procival játszadozom, most végre sikerült működésre bírnom a Microchip oldaláról letöltött I2C-EEPROM mintaprogramot. Volt benne hiba, a plib.h doksijából kinézett - már újabb (?) függvényekkel írt mintaprogram - alapján kitotóztam, mi hiányzott a régebbi mintából. Viszont felmerült néhány kérdésem, amiket ugyan itt-ott talált minták alapján megoldottam, de azért rákérdezek, hogy jól okoskodtam-e? Az angollal nem állok túl jól, és nyugdíjasként (67,5) ez már nem nagyon fog változni, ezért kérek választ a hozzáértőktől. - Találtam a neten leírást, mit hogyan állítsak, hogy az órajel a processoromnak megfelelő 40 MHz legyen. Hogy aztán tényleg annyi-e... lehet ezt ellenőrizni valahogy? Akár annyi, akár nem, a továbbiakban a program a (mintákban látott) következő sor alapján számol:
- Azt sikerült kiokoskodnom, hogy a periféria busz a "systemClock" felével illik hogy menjen, korrekt ez így? Minden órajel mellett érvényes ez az állítás? - Az I2C frekvencia beállításra ez volt a mintaprogramban:
Ezzel kapcsolatban két kérdésem lenne: - Különböző sebességgel elérhető "perifériáknál" lehet-e ezt menet közben változtatni, illetve ha lehet, érdemes-e? - Valójában mit ellenőriz a beállítás utáni vizsgálat? És egy technikai kérdés: itt a "code"-on belüli szövegben lehet-e úgy új sorba kerülni, hogy ne tegyen be üres sort?
Szia!
Ha az angol nem megy, valójában sokkal több problémád is lesz, nem csak a mostani, és fogalmam sincs, hogyan fogod mindet megoldani. Az órajellel persze ki tudunk segíteni. Az a bizonyos "GetSystemClock()" egy mezei define, amit _te_ állítasz be olyan értékre, hogy az egyezzen a tényleges órajellel. Azt az értéket a többi define használja olyan esetekben, amikor pld adva van egy felülről korlátos érték némelyik perifériának, és a periféria órajelből azt automatikusan számolja ki a program modul, ami beconfigolja a perifériát. Annak az első define-nak semmi köze nincsen a tényleges órajel beállításhoz. A perifériák órajelét átállíthatod működés közben is, adva vannak hozzá a szabályok (pld kikapcsolod előbb a perifériát, és újraconfigolod), jellemzően nem szokás olyat tenni, a lehetőség persze adott. A tényleges rendszer órajelet úgy állítod be, hogy van egy bemeneti órajeled (kristály? belső rc? kellene egy kapcsrajz!), azt beküldöd egy osztóba, és leosztod annyival, hogy a szorzó bemenetére végül 4..5 Mhz kerüljön. Az osztási érték configolható. Utána felszorzod tetszés szerint. A szorzási érték configolható. A szorzó kimenetét még újra leoszthatod annyival, hogy a végső érték az elfogadható korlátok közé kerüljön. Az osztási érték configolható. A rendszer órajelből a periféria órajelet osztó állítja elő. Az osztási érték configolható. Hogy 50 Mhz-es példányt vettél-e, azt neked kell tudnod (van az a leírt típusjel egy kicsit tovább is), ha nem, a rendszer órajeled max 40 Mhz lehet. A periféria órajelet beállíthatod a rendszer órajeleddel azonosra is, de azt jellemzően nem szokás, hatékonynak sem hatékony. Ha 1:1 osztó van beállítva, csomó esetben külön wait ciklusok lesznek beiktatva, és néhány periféria vezérlésnél extra megszorítások is vannak, amire a program vezérlésben is oda kell figyelni (az egyes perifériáknál az adatlap külön kitér rá). Az alapértelmezett osztó 8-as, és nem véletlenül. Csak akkor érdemes kisebbre venni, ha nagyon muszáj pld 20 Mhz-es SPI-t használni, és egyébként a nyák is olyan, hogy vinni tudja a 20 Mhz-et (nem szokás mx1/2-vel olyat csinálni, de éppenséggel lehet). Emlékeztető: kellene a kapcsrajz, vagy legalább írd le, hogyan van az órajel elsődleges forrása kitalálva. A hozzászólás módosítva: Júl 19, 2017
Sziasztok!
Hogyan szokás megoldani az ilyesmit? Van egy Debug(char* str); függvényem, melynek egyetlen bemeneti paramétere egy karakterlánc. A függvény annyit csinál hogy a paraméterében megkapott sztringet kiküldi UART-on. A dolog tökéletesen működik, míg a függvényt a main-ben hívom meg. Azonban szükség lenne arra, hogy a megszakításból is meg legyen hívogatva. Ha viszont meghívom a megszakításból, akkor a PIC újraindul! Valószínűsítem hogy a probléma forrása ott lehet, hogy akkor történik a megszakításban a függvényhívás amikor egyébként a főprogram is épp ugyan ebben a függvényben van. Lehet hogy ilyenkor összezavarodik a verem? Azért van egyébként szükség hogy a megszakításban is meg legyen hívva a küldő függvény, mert a PIC-kel a soros porton lehet beszélgetni. Azaz egyrészt ha küldünk neki valamit akkor azt echo-ként visszaküldi rögtön, másrészt ha az üzenet végén sortörést észlel akkor feldolgozza az üzenetet és ha abban értelmes parancs van akkor azt végrehajtja, majd a végén visszaküld egy nyugtázó üzenetet. A karakterek vétele nyilvánvalóan az UART periféria vételi megszakításában történik, ezért az üzenetvégi sortörés ellenőrzése, majd a parancs feldolgozása és rá a nyugta elküldése is szükségszerűen mind a megszakításban megy végbe. A főprogram végtelen ciklusa másodpercenként küld ki diagnosztikai üzeneteket folyamatosan, ezért gondolom hogy „összeakad” a főprogram és a megszakítás, és ez okozza a mikrovezérlő újraindulását. Létrehozhatok egy szemafort amit a megszakításban meghívott küldő függvény belépéskor 1-be állít, kilépés előtt pedig vissza nullába, a főprogramban való meghíváskor pedig ugyan ez a szemafor figyelése történne, amíg ezt a megszakításban meghívott függvény vissza nem állítja, addig egy Nop()-on pöröghet a főprogram. A gond csak az hogy fordítva ez nem működhet, azaz ha a főprogram hívja meg előbb a függvényt, a megszakítás nem várakozhat… |
Bejelentkezés
Hirdetés |
