Fórum témák
» Több friss téma |
A lentebb ajánlott link szerint pontosan így csináltam, ahogy Te is írtad és érthetően működik is!
Köszönöm mindenkinek a gyors segítséget! 
Ismerkednék a DMA modullal C30 ban és persze a C vel is...
 . Az alábbi kód második sora hibával fordul.
error: argument to _builtin_dmaoffset() is not the address of an object in a dma section the object must not be qualified with any form of index Mi lehet a hiba oka? A hozzászólás módosítva: Nov 28, 2015
Én még csak az ADC-hez használtam DMA-t. Az egyik példaprogramot átnézve, úgy látom, hogy az __attribute__(space(dma)) mellett az igazítás is számíthat, s még egy aligned(8) attribútum is kellhet.
A hozzászólás módosítva: Nov 29, 2015
Gyanús, hogy a Microchip-nek sem tetszett az a verzió, mert az archívumban v3.38 után v3.40 következik.
Az a "vicc" hogy nekem pedig pont azért kéne ez a verzió, mert ebben még nincs benne ez a hiba:
Idézet: „E:\3.46\pic18-lt\cxx-framework\src\traditional\proc\p18f46k22.asm” Ez konkrétan a p18f46k22.lib fájlban van, annak ellenére, hogy nincs is "E:" meghajtóm, és teljesen máshova telepítettem a fordítót. Egyébként ilyen bejegyzés még 2635x szerepel ebben a LIB fájlban. A programok hiba nélkül lefordulnak, azonban a COF fájlt nem lehet használni (pl. Proteus szimuláció), mert a forrásfájlokat az "E:" meghajtón keresné a LIB miatt... És úgy néz ki, hogy a 3.40 körüli, és azutáni LIB-eknél létezik ez a probléma, azt nem tudom hogy az összes LIB-nél, vagy csak ennél, mert már így is megkukultam, mire rájöttem hogy hol van a kutya elásva. Most ezt a bugot úgy "patkoltam meg", hogy sikerült leszedni egy 3.36-os LIB-et, amivel felülírtam a mostanit (most 3.35-ös compiler van fent), azonban ott is más útvonalak vannak a LIB-ben, de azt legalább létre tudtam hozni. Na ez így most lehet kicsit zagyva, de ráment egy napom arra, hogy elkezdhessem írni a progit... Ha ez nem lett volna, akkor lehet átpártolok C-re, de így tuti csak akkor írok C-re, ha nagyon muszáj. Ez a bajom igazából szinte az összes magasabb szintű fejlesztőkörnyezettel: mindig kalapálni kell valamit, mert magától semmi sem működik (persze vannak kivételek).
Sziasztok!
Mi a probléma ezzel a paraméter átadással:
Hogy lehetséges az, hogy a függvényben a ConMask = 0x0A? Szerk.: (PIC24EP... + XC16 tehát az uInt 16 bites.) A hozzászólás módosítva: Nov 29, 2015
Szerintem egyszerűbb és jobb megoldás, ha újrafordítod a p18f46k22.lib fájlt.
Ha a C:\MCC18-ba telepítetted/másoltad/linkelted a C18 cuccait, akkor feltehetőleg nem lesz benne az E: meghajtóra történő hivatkozás.
A PIC-kwik oldalt ismerem, és jó referenciának tartom.
Sajnos nem oldódott meg a probléma, az aligned(8) attribútum sem segített. Érdekes hogy a Microchip ajánlása sem említi, az alábbiak szerint jár el, persze nem megy.  Idézet: „ For example: int result; char buffer[256] __attribute__((space(dma))); result = __builtin_dmaoffset(buffer); Might generate: mov #dmaoffset(buffer), w0 Prototype: int __builtin_dmaoffset(int buffer); Argument: buffer DMA address value Return Value: Returns the offset to an accumulator. Error Messages An error message will be displayed if the result is not an accumulator register. ” Nem tudom mire gondoltál az igazítást illetően. Ha lenne új ötlet azt is szívesen venném. Idézet: Bocs, elnéztem a változótípust! Tegyél még egy próbát aligned(16)-tal, az int típusú tömbelemekre való tekintettel... „Sajnos nem oldódott meg a probléma, az aligned(8) attribútum sem segített.”
az aligned(16)-tal sem megy.
A tömbelemek egyébként unsigned int ek.
Nálam ez lefordul (PIC24HJ128GP502-t választottam ki). A forráskód természetesen így nem jó semmire, csak fordítási próba!
ez viszont lefordult.
Most már csak tudni kell mi az oka.
uint16_t típussal megy, unsigned int el pedig nem. Nem értem miért, miközben mindkettő 16 bit széles típus. megj: Az aligned jelenléte nélkül is lefordul, ha szükség van is rá nem érteném a funkcióját. A hozzászólás módosítva: Nov 29, 2015
Az aligned(16) azt jelenti, hogy a változó helyfoglalása 16-tal osztható címen kezdődjön, s többek között a DMA vagy a DSP címzéseknél lehet rá szükség.
Idézet: „A közvetlen memóriaelérés (Direct Memory Access, DMA) hatékony mechanizmust nyújt a perifériák speciális funkciójú regiszterei és a RAM adatmemória közötti, minimális CPU beavatkozást igénylő adatátvitelre. A DMA vezérlő komplett adatblokkok mozgatására képes, s mivel saját buszt használ az átvitelhez, cikluslopásra sincs szükség, nem gátolja a CPU programfuttatását. A DMA által mozgatott adatok eléréséhez a program által használt buffereket vagy változókat a DMA vezérlő által is kezelt kettős hozzáférésű RAM területen kell elhelyezni. A PIC24HJ128GP502 mikrovezérlőnél ez a RAM memória 0x2000 - 0x27FF címtartományába esik, lásd a bevezető fejezet "Az_adattároló_memória_szervezése" c. szakaszát!. A DMA RAM területen történő elhelyezéshez a változók deklarálásakor az __attribute__((space(dma), aligned(nnnn)) módosítót kell használni, ahol nnnn a DMA átvitel során mozgatott bájtok száma (kettő hatványa legyen!). A DMA átvitel részleteit a PIC24H Family Reference kézikönyv Direct Memory Access (DMA) című fejezete írja le, s mintapéldákat is találunk benne. ”
Akkor valamit keverek, mert én
DMA0CNT = 7; regiszterben megadott érték alapján gondoltam ezt. Korábban is olvastam az általad idézett sorokat, kissé akkor is zavaros volt a dolog. Idézet: „ DMAxCNT reg: This register contains the transfer count. DMAxCNT + 1 represents the number of DMA requests the channel must service before the data block transfer is considered complete. That is, a DMAxCNT value of ‘0’ will transfer one element. The value of the DMAxCNT register is independent of the transfer data size (SIZE bit in the DMAxCON register). Writes to this register while the orresponding DMA channel is enabled (i.e., active) may result in unpredictable behavior and should be voided ” És továbbra sem értem miért lehet az uint16_t és az unsigned int el eltérő működés. A hozzászólás módosítva: Nov 29, 2015
Kissé későn reagálva, de ezt kipróbálva se javult a helyzet, marad a "kalapálás". Ha lenne rá időm, utánajárnék a dolgoknak alaposabban, de "jó ez így is".
Sziasztok!
Miért lehet az, hogy működik a programom normálisan, viszont ha egy függvényen belül a már meglévők mellé új változót deklarálok, akkor pedig hibásan. Értem: van egy alap menüm, ami induláskor megjelenítődik, de ha létrehozom a változót, akkor az egyik almenüpontja jelenítődik meg induláskor. A létrehozott változónak semmi, köze a menükezeléshez. Ha static-ként deklarálom, akkor megint megy helyesen. PIC16F1716-ot használok, Program space: 52% Data space: 29% (fordításnál ezeket látom), a fordító XC8 v1.35.
A kód látása nélkül pl. valamit túlindexelsz vagy hibásan castolsz valamit. De ezek csak tippek, mutass kódrészletet
Valóban van egy túl indexelés, viszont kipróbálni majd csak holnap tudom. Köszi szépen.
Lokalis valtozok a stack-en allokalodnak. Ha static, akkor nem. Nem lehet, hogy egyszeruen stack tulcsordulasod van?
Erre is gondoltam, de engedélyeztem a reset-et, ha stackoverflow van, és induláskor ellenőrzöm is és kiíratom amennyiben előfordult.
Üdv!
Egy olyan táblázatot szeretnék megvalósítani, ahol a bemenet egy értéktartományához tartozik egy adott kimeneti érték. Konkrétabban, ha az ADC-vel 700mV és 710mV között mérek, a kimenet értéke legyen 50. Lookup table néven kerestem, de nem találtam számomra megfelelő megoldást. Előre is köszönöm, ha valaki tud segíteni.
Szia!
Milyen nyelven akarod elkövetni ? szerk.: Bocs, most nézem a topic címét  !
A hatar1, stb-t a megfelelő kóddal helyettesíted, amit adott értéknél kapsz ! A hozzászólás módosítva: Jan 11, 2016
Köszönöm.
 50db ertek-em lenne, nem jelent problémát, vagy nem csúnya megoldás ennyi elágazás?
Valahogy szelektálnod kell... vagy egy függvény segítségével kapod meg a kívánt értéket, vagy egy táblázatból olvasod ki 8 de akkor tudnod kell a sorszámot
!) vagy így megnézed, hogy melyik sorra igaz... !Nem tudok jobbat, ha tartományokról van szó, ill. ha pl. 10 bites AD-t használsz, akkor az AD értékét használod egy tömbben a címzéshez, az értékek pedig a tömbben vannak, akkor nem kell szelektálni, csak egy nagy tömb kell ( akár a ROM-ban is lehet!) ! Így érthető vagy részletezzem még ?! A hozzászólás módosítva: Jan 11, 2016
Nagyjából érthető
Egyelőre nekifutok az általad ajánlott if-es megoldással.  Köszönöm még egyszer.
A tömbös se rossz: 10 bitnél
Így viszont meg kell adnod az összes bemeneti értékhez (ADC) tartozó kimeneti értékeket, ami a tartományok miatt többször is ugyanaz lesz ! A hozzászólás módosítva: Jan 11, 2016
Ha lineáris az eloszlás, akkor eloszthatod az ADC értékét egy konstanssal, és akkor arányosan kisebb táblázat is elég lesz. Esetleg mivel az osztás sok erőforrást emészt, ezért szorzásra és jobbra shiftelésre cserélhető.
Pl.:
Ez a megoldás is tetszik, viszont 12bites ADC-t használok.
Az már egy kicsit nagy tömb lenne. Az If-es megoldással szépen működik, egyelőre marad az, aztán ha később kedvet kapok, majd kísérletezek. potyo:Köszönöm, sajnos egyáltalán nem lineáris az eloszlás, így maradtam a fent említett megoldásnál. Viszont tanulságos, később jól jöhet ez a megoldás. Üdv, Ati |
Bejelentkezés
Hirdetés |
