Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Üdv!
Vannak fejlemények, de sajnos nem jók. Egyszerűen nem jó az ADC. Timer3-interruptban hívnám meg és mérnék. Elvileg ez meg is történik, de az adatok nem jók. Ennek a 12 bite módnak vannak sample A és sample B bitjei. Ha az ALTS-t 0-ra állítom, akkor a legjobb eredmény az, hogy 1 minta jó, a másik 4095, majd megint jó, megint 4095. Na ekkor jutott eszembe, hogy ok, szándékosan legyen ALTS=1,hogy váltakozzon a sample A és a sample B között. Ekkor, ha definiáltam a CH0SA-t és CH0SB-t is, pozitív és negatív pinekkel mindennel, akkor a legjobb eredményem a következő volt: 1 mérés, legyen a sampl A, kiadja a szinuszt, de csak fele minavétellel. A sample B is kiadja a szinuszt, de 180 fokos fázistolással, szintén fele mintavétellel. Hol lehet a hiba? DMA máshogy tölti fel? Időzítési probléma? Van valaki akinek ez sikerült rendesen? dsPIC128MC802.
A hozzászólás módosítva: Nov 2, 2023
Itt van két kép. Mindegyikben csak a_van definiálva, az egyikben az ALTS=1, ekkor a van adat, 4095, van adat, 4095 stb látszódik. Ha ALTS=0, akkor csak a SampeleA van, de kaotikus az eredmény. Most jöttem rá, hogy ez ugyanaz az eset, mintha a sample B-t is beállítanám és ALTS=1 lenne. Azaz a kép olyan, mintha két mérés lenne egymáshoz képest 180 fokkal eltolva.
A hozzászólás módosítva: Nov 2, 2023
Excelből az adatok, ha ALTS=1 és
AD1CHS0bits.CH0SA=0b00100; AD1CHS0bits.CH0NA=0; //channel 0 negatív ref VREF- láb AD1CHS0bits.CH0SB=0b00100; AD1CHS0bits.CH0NB=0; //channel 0 negatív ref VREF- láb Valamint, hogy el legynek különítve minden második adatból 10000 ki van vonva. Így látszik pontosan a fázistolás is. Lehet máshol van a gond? Idő elcsúszik és éppen úgy mintavételezne, hogy épen 180 fok tolás lenne? De ekkor sem értem mi a baj. Az input 500Hz. A mintavétel 5000/s, a timer_3 interrupja jó időben van. Igaz memóriába is írok SPI-n, de azt kimértem, bele kell férnie a t3 interrupton belül. Időzítés hibáraazért isgondolok, mert 500Hz jel esetén, 5000 minta/s mellett, 100 mintánál 10 periódusnak kellene lennie, de csak 7 van, ha jól látom. Ez az időcsúszás éppen 500Hz egész és egy fél periódus lenne? Mert ugye N=0,1,2 stb és egy fél esetén lenne éppen ekkora az időcsúszás. 1/500 =2 ms. Ha jól sejtem, akkor 0.5, 1.5, 2.5, 3.5 stb ms csúszés okoz éppen ilyen eltolást kapnék. De ekkorát késne az ADC? A hozzászólás módosítva: Nov 2, 2023
Vagy éppen alul van mintavételezve? 16 Buffere van, lehet 16x mér egy helyett? De akkor a timer3 interrupt is komolyan nem menne. Nem értem én ezt, miért nem jó. Egyszerően 1 db csatornét kell mintavételeznem 5000 minta/s -el, a jel az AN4-en van, a referencia feszültségek pedig a Vref-, Vref+-on vannak, az input negatívja meg legyen Vref-. Ez nem akar összejönni. Kicsit körülményesebb, mint az analogread() arduino-ban!
A PC-re átküldés tuti, hogy tökéletes? Nem írja esetleg felül a következő mérési kör az értékeket miközben csorognak az adatok UART-on át?
A dsPIC33F/PIC24H Family Reference Manual Section 16. Analog-to-Digital Converter (ADC) szerint:
Idézet: „For devices with DMA, the ADC module is connected to a single-word result buffer. However, multiple conversion results can be stored in a DMA RAM buffer with no CPU overhead when DMA is used with the ADC module. Each conversion result is converted to one of four 16-bit output formats when it is read from the buffer”
Szia!
Nem, mert az uart csak akkor fut le, ha már megtörtént 100 mintavétel. A RAM-ból azután történik a kiolvasás és küldés UART-on. SPI-n megy elég gyorsan minden, lemértem a timer3-al a konverziót is, a végén UART-on ki tudom küldeni azt is. Átírtam a kódot úgy is korábban, hogy csak 1 mintát vesz és a timer tick értékeit kiküldi uarton. Ebbe simán belefér.
Szia!
Ezt nem értem. Gondoltam ilyesmi hibára is, de nem tudom ilyenkor hol is van a hiba pontosan? A sample A-ban kiolvasott jó, a sample B-ből már nem. (Mindkét megoldás lehetséges, azaz az ALTS=1, és a AD1CHS0bits.CH0SA=0b00100; AD1CHS0bits.CH0SB=0b00100; stb is lehet ugyanazon a bemeneten, de nem értem ekkor mit, hogyan értelmezve kell kiolvasnom a sample B esetén. Nekem az a megoldás is jó,ha az ALTS=0, és csak az A-ra van konfigurálva. Kérlek áruld el, hol a hiba pontoan, mert belebolondulok! Idézet: „Minden konverziós eredmény a négy 16 bites kimeneti formátum egyikére konvertálódik, amikor kiolvassák a pufferből.” De ezt állítom be a formátummal ha jól értem. AD1CON1bits.FORM = 0; // Data Output Format: integer//Signed Fraction (Q15 format) Idézet: „„DMA-val rendelkező eszközök esetén az ADC modul egyszavas eredménypufferhez csatlakozik. Azonban több konverziós eredmény is tárolható egy DMA RAM pufferben CPU többletterhelés nélkül, ha DMA-t használunk az ADC modullal.” Máshol vannak a helyes sorrendű adatok? Ugye 16Buffer van. Ha sample B-t keresem, akkor esetleg az a ADC1BUF1;-ben lenne? Azt meg nem érem el...  Legalábbis eddig nem sikerült, mert hibára futott az MPLAB.A tárolás miatt ilyen? return ADC1BUF0; Ebbe keveredik össze valahogy? Azt hittem ide másolódnak az eredmények minden esetben, ha csak 1 csatornát használok. A sample A ALTS=0 esetén ide íródik minden esetben nem? Vagy a BUF1- stb is bekavar kicsit? Rossz helyről olvasom az eredményeket?
Naná, hogy nem itt volt a hiba!!!
Persze minden regisztert végignéztem, megtanultam, kiagyaltam magam, erre hol a hiba? Na hol? Hát a timer3 init-ben overflow esemény.... Hát kész. 1 perc sem volt átírni, erre 2 nap ment el. Bár legalább lassan az ADC-ben expert leszek. Fejből nyomom már az összes regiszert lassan... Mert szebbé tettem a kódot... Hát sikerült elálítanom. Erre rájöhettem volna, mert a jel nem megfelelő időközönként volt mintavételezve. Persze most már állíthatom ahogy akarom, megy minden variációban.... A hozzászólás módosítva: Nov 3, 2023
A problémádhoz nem tudok hozzászólni, de a readADC() függvényben az
után tegyél be egy NOP-ot, mielőtt tesztelni kezdenéd a bitet, mert az okosok szerint némi időbe telik, amíg a bit ténylegesen törlődik! Bővebben: Link
És még betettem egy AD1CON1bits.DONE=0; sort is elé, mert a leírás szerint ez nem törlődik automatikusan, mert most manuálisan van indítva.
Ok, egy gyors kérsés, biztos ami biztos, mielőtt élesben kipróbálnám.
A Vref+, és Vref- lébak között van kondenzátor már, de nem tudom, hogy kell-e ilyenkor áram korlátozó ellenállás, vagy direktben mehet rájuk? Nem szeretném elföstölni, még akkor sem, ha elvileg nem kell, azaz több helyen azt mondták, hogy nem kell. Vagy kell-e valami plusz beállítás a dsPIC33Fj-ben, azaz a pint megfelelően konfigurálni kell-e ekkor. A másik, hogy az analóg bemenet A4 lenne, de ekkor oda is kell korlátozó ellenállás, nem? Nem foglalkoztam eddig analóg lábakkal, csak digitáliskkal, ott kell ere figyelni. 2mA körülire korlátoztam mindegyik digitális lábat. (lehet mindegyikben eleve van korlátozó ellenállás, de nem vagyok biztos benne) Köszönöm!
Felesleges az ellenállás, csak ront a pontosságon (vagy lassítod az ADC mérést). Adatlap tartalmazza, maximum milyen (belső) ellenállású lehet a forrásfeszültség. PIC18F27Q43 esetében pl. 10 kΩ az ajánlott maximális ellenállás, de hasonló értékre emlékszem több adatlapból is.
Szia!
Köszönöm! Erre jutottam én is, mert átgondoltam, a mintavétel/tartó kondenzátornak sem jó, ha nagy az ellenállás, meg szórt kapacitásokkal nagy ellenállás szűrhet. Végül rákötöttem, van eredmény, de nem túl jó. A jel bejön, de nem jó, bár látszódik a szinusz jel, de frekiben sem jó, meg a megjelenítő programomban is van hiba még. De! A szimuláció megint nincs összhangban a valósággal. Rákötöttem a Pickit-3-at, debug, és megáll.... Minden megy, tesztkódok, amik RAM-ba írnak, olvasnak, stb, de itt while (!AD1CON1bits.DONE);-nál megáll. Legalábbis az én kódomban. Másik példával nem áll meg, de akkor a szimulációban van hiba az adatokban. A valóság és a szimuláció között van némi defekt.
A szimuláció és a valóság közötti szakadék volt megint a hiba. Kicsit megkerültem a dolgot, mert interrupt-ok összeakadnak, és a DONE bit soha nem lesz 1. A kód valójában működik, csak a szimulációban is ment, míg a valóságban nem. De ennek más oka volt. Most már sebességet is lehet mérni, miden jó.
Hát ebből is lehet tanulni, de nekem ráment pár hajszálam, és a szókincsem is bővült kicsit.
Sziasztok! Én jó ideje a PIC16F877-es típust használom (CCS-C fordítóval MPLAB IDE v8.9-el és PIC kit2-vel), de itt tudtam meg, hogy ennek a 18F -es leváltója (teljesen lábkompatibilis elvileg) a PIC18F45K22. Ha minden igaz akkor ezt így fogom tudni használni: CCS-C fordítóval, MPLAB IDE v8.9-el és PIC kit3-al vagy ICD2-vel, ebben meg tud valaki erősíteni hogy ezekkel használható?
Másik kérdésem az lenne, hogy valaki tudna nekem küldeni ehhez a PIC18F45K22 -hez 18F45K22.h header fájlt? (Nem ASM-hez hanem C-hez, konkrétan CCS-C fordítót használok). Sajnos nem találtam sehol 20perc keresgéléssel sem. Illetve amit találtam az ez 18LF45K22.h, elképzeklhető hogy ez is jó hozzá? Köszi szépen! És BUÉK!
Sziasztok!
PIC16F18446 (curiosity), I2C host mode, MSSP1 hardveres megszakítással, DS3231 RTC modullal. Problémám a következő. Ha írok az RTC-be I2C1_Write(clientAddr, transmitData, writeLength) utasítással vagy olvasok I2C1_WriteRead vagy I2C1_Read utasítással akkor szépen működik. Azonban ha a I2C1_Write után bármelyik (WriteRead vagy Read) utasításokat használom akkor a Write-ot végrehajtja, STOP-ot kiküldi, SCL és SDA vonalakat elengedi és "elfelejti" a következő utasítást (WriteRead vagy Read) végrehajtani. Azonban ha a Write után teszek 10msec-nál hosszabb késleltetést akkor szépen működik, csakhát, az időveszteség... Találkozott már valaki ezzel a problémával?
Nem értem a logikát, miért jó azonnal olvasni egy RTC IC-t közvetlen írás után, de talán nem ez a lényeg.
Az "I2C1_Write", "I2C1_WriteRead" vagy "I2C1_Read" utasítás tulajdonképpen egy utasítás csoport, ami mögött húzódhat bármi, azok ismerete nélkül még tippelni is nehéz. Gyaníthatóan az "I2C1_Write" makróból akkor tér vissza a program, amikor az I2C modul még elfoglalt valamivel, valószínűleg a Stop végrehajtásával. A makró utasítja az I2C modult, hogy küldje ki a Stop folyamatot, de nem várja meg, hogy az be is fejeződjön. Azonnal ugrik a "Read" makróba, abban pedig van vizsgálat, szabad-e az I2C modul. Mivel nem, mert még nem fejezte be az előző feladatot, a koplett utasítássort kikerüli egy feltételes vizsgálat miatt. Ez "külső" szemlélőnek úgy tűnhet, hogy nem hajtja végre a parancsokat (makróban lévő utasításokat). Ez leginkább akkor tettenérhető, ha az I2C 100 kHz-en ketyeg, de a CPU-t 32 MHz-en járatod. Könnyen kideríthető a dolog egy logikai analizátorral, ha van szabad láb. I2C1_Write(....); LATAbits.LATA0=1; //pl. RA0 láb H szintre billentése I2C1_Read(....); Ha a kimenet előbb vált magas szintre, mint ahogy az I2C modul végezne az adással, akkor az a helyzet, amit vázoltam, remélhetőleg érthetően. A hozzászólás módosítva: Jan 10, 2024
Való igaz, lehet, hogy nem "életszerű" az írás utáni közvetlen olvasás. Hardveres MSSP-t nem használtam/konfiguráltam még és kíváncsi voltam, jelen esetben mennyire "sikerült" megoldania a gyártónak. Előtte 16F690-nel próbálkoztam, de ott sok helyen azt írták, hogy a hardveres MSSP kezelés nem igazán sikerült a Microchipnek és a szoftvereset ajánlják azon. Kiprópáltam 16F18446-on és egyből "belenyúltam" egy általam vélt hibának. (...mert nem tudom még lekezelni
)Logikai analizátorom van, 32 csatornás. ...csak 300km-rel "arrébb". Egyébként a buszt 100kHz-en hajtom és 4MHz-en 2-es osztóval. Azért alacsony az órajel mert fontos a minél kisebb áramfelvétel. Terepi működés 3db AA-s elemről. Köszönöm a tippet, megnézem majd. Idézet: Van itt egy-két dolog. Az, hogy egy előre megírt funkciót használsz és az nem felel meg az igényeidnek, nem biztos, hogy a gyártó hibája. Ha egyedi igényeid vannak, akkor írnod kell magadnak MSSP kezelő funkciót, amiben ez a hiba (már ha annak nevezzük) kezelve van. Nem egy nagy durranás, hétvégén tudok neked feltölteni élő, működő példákat, azon majd látni fogod, mennyire nem éri meg ilyen alap dolgok kezelését másra bízni.„mennyire "sikerült" megoldania a gyártónak.” Egy rakás ilyen problémával lehet találkozni pl. Ardunio környezetben is. Előre, más által megírt könyvtárak, amelyek nem mindenkinél működnek úgy, ahogy azok használója szeretné.
Erről a kódról beszéltem korábban:
Ebben a program futása akkor tér vissza a funkcióból, ha az adott feladatot letudta az I2C (MSSP) modul. DS3231 idő kiolvasása:
Ennyi, ez van az adatlapban is, lásd melléklet. Az IC automatikusan növeli íráskor vagy olvasáskor a belső mutatót (hogy éppen melyik regisztert írod vagy olvasod), azzal neked külön nem kell foglalkoznod. Ezt nem mindig és minden IC végzi el, adatlapot kell megnézni. Viszont, olvasás előtt be kell állítani, honnan is kezdődjön az olvasás, a restart előtti részen látható a dolog. Természetesen nem kötelező az "elejétől" olvasni az IC-t, ha a 3. sorban lévő nulla értéket kicseréled a neked tetszőre (pl. 0x0E: Control regiszter), akkor az olvasási folyamat onnan kezdődik. A hozzászólás módosítva: Jan 12, 2024
Tiszteletem minden PIC értő mesternek!
Adott az alábbi projekt amit már sok éve egyszer megépítettem, hibátlanul működik azóta is a régi autómban. Most újra összeraktam, ugyanarra a nyákra, ugyanolyan LCD-vel. Sajnos azt csinálja, hogy 7,4V-ig normálisan méri a feszültséget, a fölött a képek szerinti bolondulás van. Lehet, hogy az eBay-es PIC hamisítvány, amit most rendeltem? Bár ez elég fura lenne, hogy x szintig jól mér az adc, fölötte meg nem? Előre is köszi ha van valami tippetek. Amit idáig mértem; stabil a PIC-en a tápfesz, az ADC nem kap többet, mint 5V.
Próbáld meg a kijelzőhöz tartozó vezetékeket széthúzni egymástól, a kijelző táplábaira pedig rakj egy 4.7 - 10 µF-os, valamint egy 100 nF-os kondenzátort.
Ok, holnap csekkolom, köszi. A PCB-n rommá van szűrve minden 100n-val, de hátha. Beszámolok majd, hogy mi lett.
Próbáld meg maszkolni az ADC eredmény 10.-15. bitjeit! Múltkor futottam be egy ilyen hülyeségbe, hogy fél feszültség fölött a nem használt bitek mind 1-be álltak.
Ok, lehet az lesz, csak amit nem értek, hogy hogy a bánatba működött ez a hex 10 évvel ezelőtt hibátlanul, ugyanezzel az égetővel, ugyanezen a nyákon, minden ugyanaz. Még a nyákon lévő alkatrészek is ugyanazok, akkor kettőt építettem belőle, de csak az egyik kapott lcd-t és pic-et, a másik azóta egy dobozban pihent idáig. Most meg az őrületbe kerget...
Szia!
Szerintem az áramkörnek is vannak kisebb hibái, jobban mondva másik PIC-nél kicsit más megoldásokat javasoltak, de ha ezzel is mennie kellene, akkor ok. Elektrolit kondik 10 év alatt nem mentek gallyra? Forrasztások is mindenhol jók? A teszteket hogyan végzed? Kell ide közös föld? 10 évvel ezelőtt nem történhetett meg, hogy másik program került rá? A PIC teljesen ugyanolyan? Mármint 16F864 -A/B/C akármi?
Ebben a postban van egy forrás, nem tudom, hogy ezt használod-e:
RawBattery a 10 bites ADC értéke, 0..1023 között A WORD típus előjel nélkül 2 byte. 0...65535 amit tárolni tud. Volts=RawBattery * Rt = max értéke 1023 * 30000 = 30 690 000 Ez már régen nem fér bele a Volts-ba, de picbasicben (nem értek hozzá, csak most olvastam ITT), hogy a szorzás után közvetlen végrehajtott DIV32 nem a Volts-ban tárolt alsó 16 bittel, hanem az előtte lévő szorzás teljes 32 (helyett valójában 31) bittel számol. Ez jól működik, ha nincs közötte IT, de itt nincs letiltva az IT a művelet idejére. Ez okozhat problémát. (A főprogramban nem látok IT-t de valamelyik include-ban ettől használhat, mert egy helyen már letiltja/engedelyezi.) Próbáld ki az alábbiak közé tenni a számítás ezen részét, ahol DIV32-ot használ:
És a többi helyen is a szorzást és az azt követő DIV32-őt tedd GIE=0 majd GIE=1 közé.
Sziasztok!
Köszönöm mindenkinek, aki próbált segíteni, a megoldás egyszerű; vegyél eredeti PIC-et, ne gagyit az eBay-ről, mint én. Egyből ment normálisan a régi HEX-el, mindenféle ráolvasás, esőtánc és egyéb nélkül. |
Bejelentkezés
Hirdetés |
