Fórum témák
» Több friss téma |
A board ez: Bővebben: Link
A bal oldalon látható hogy az okos tervező (nem én) ugy csinálta a sűrű JTAG csatit hogy 180fokkal elforgatva is bele megy a mini JTAG dugó. => 1 es Vcc láb lehet 20(GND) és 20(GND) lehet 1(Vcc). Mivel ez nem hülye biztos én voltam olyan hülye hogy forditva dugtam bele a csatiba, igy negativ tápnak tűnik elsőre. Érdekes felprogramozni hibátlanul lehet, ULINK2 látja. Lehetséges hogy a fordított táp csak "kis" részben ölte meg? Pl csupán ennyire?
Probléma megoldva. File-onként össze vissza volt állítva az Optimization level, másfelől érdekes most csak SWJ-be hajlandó menni az ULINK2, JTAG módban nem látja az STM32-t... Rejtély, viszont legalább működik...
Szerintem ez nem ölné meg, és mennie kéne JTAG-el is. Itt lesz még valami más esetleg beállítási parája.
Egyenlőre örülök hogy működik.
 3 napja google-zok, de nem találok semmit Keil + C pointerek használatához. Úgy értem van egy struktúrám ami GPS.Latitude, GPS.Longitude, GPS.UTCDate, GPS.UTCTime stb stb. Ennek egyes elemeire mutatnék rá egy mutató tömbbel, a GPS-ből kieső különféle NMEA stringek szerint. Tehát ez mért nem működik? A tömb az jó, és hibátlan.
Sziasztok!
Pár hete elkezdtem építeni egy AM1705 procira épülő digitális oszcilloszkópot diplomamunkaként. Sajnos már rögtön az elején nehézségekbe ütköztem. Programozáshoz IAR+H-jtag+Wiggler-t használok. Az ARM megkapja az 1,3V-ot (dc-dc után kis tüskékkel)és a 3,3V-ot. Az oszcillátor szkópon mérve szépen ketyeg 30MHz-en. (Nincs semmi zárlat vagy szakadás, már többször is átellenőriztem mindent) Viszont amikor programozni akarom Jtag-en keresztül, akkor a H-jtag azt írja, hogy "unknow device" később pedig miután a TAP beállításokban valamit véletlen szerűen variáltam, a H-jtag 0x000000f-ot olvasott ki id-ként. A kérdéseim a következők lennének: Mi okozhatja ezt a hibát? Hogy kell értelmezni ezt a TAP beállítást? Milyen TAP beállítással próbálkozzak az AM1705 procimnál? Lehetséges, hogy túlmelegítettem ARM-ot? Válaszokat előre is köszönöm! Üdvözlettel, Peti
Nem olyan könnyű ezeket kinyírni.
Megnézted, hogy mind a 2 resetláb fel van húzva 10K-val?
Köszönöm a gyors választ!
Igen, fel van húzva, az TRST-t a wiggler egy tranzisztoron keresztül le tudja húzni a GND-re. Az SRST-t meg én tudom egy nyomógombbal. Üdv, Peti
És mi a nem jó? Mi a hibaüzenet? Amúgy az első 9-es nekem kicsit fucsa, ha char-ra mutató pointernek szánod. Akkor a tömböd első eleme gyakorlatilag a 0x0009 címre mutat a memóriában.
Annyi ma kiderült hogy a bcdGPS struktúra összes tömbmutatójához kell a [0], azaz &bcdGPS.Latitude[0]. Ez egy külömbség pl a MplabC32-höz képest. A "9" az az elemszámot mutatja azaz az adott GPS karakter láncban a GPGGA-ban 9db hasznos adat van UTCtime, Latitude, North/South stb stb. Más láncokban több van, másokban kevesebb. Szóval annak ellenére hogy a 0x0009 címre mutat az az egy elem nem mint mutató lett felhasználva anno a PIC32MX795F814-ben.
Aztán az is kiderült hogy a C32-vel ellentétben a mutató tömb nem akar bevenni (definiálással egy időben legalábbis) numerikus adatot, csak &-al jelölt változókat. Pedig az mutatótömb 0. elemeként nagyon kellene nekem oda az elemszám...
A 9 helyett (unsigned char *)9 kéne az inicializáláshoz, és akkor a compilernek sem kéne pampognia - rendes compilernek a cast nélkül viszont illik pampognia:
"warning: initialization makes pointer from integer without a cast" Másrészt mi a bcdGPS.UTCtime típusa, hogy &bcdGPS.UTCtime az unsigned char *-ot ad? Mert csak unsigned char lehetne, ha jó lenne a kódod, de az meg nagyrészt ki van zárva, mivel unsigned char-ban nem lehet utctime-ot tárolni...
Egy arm proci pin muxing-jával pepecselek, és a legnagyobb bajom, hogy magát az összerendelési elvet nem ismerem - és leírva sem találom. Ebben kérnék egy kis segítséget.
TI AM335x-hez van egy "pinmux" program ( http://www.ti.com/tool/pinmuxtool ), ahol választgathatok, mit szeretnék, és mit nem. Van itt a pozíció pin-ekre mode0..mode7 választás, mindegyik modeX egy teljes oszlop (minden pin-re). Konfignál ezek közül a mode-ok közül kell választanom egyet, és akkor mindegyik pozíció pin azt a funkciót veszi fel kötelezően, ami ahhoz a mode-hoz tartozik, vagy pin-enként választhatok egy mode-ot mindegyiknek külön-külön? Ha valaki esetleg ismeri a szóban forgó programot is, és tud róla egy nagyon szájbarágós leírást is tipikusan olyanoknak, akik nem évek óta használják, az nagyon tuti lenne.
A bejövő NMEA stringek amik a GPSből jönnek ASCII karakterek. Ennek megfelelően a bcdGPS minden egyes tagja unsigned char típusú tömb. Ez jelenleg igy néz ki:
Jobban mondva mindegyik egy tömb az adott adat hosszának specifikusan. Azért igy csináltam mert úgy olvastam még PIC32 idején hogy a C-ben nincs string csak (mivel ascii 8 bites) char típusú tömb. Mesélnél kicsit erről a (unsigned char*)9-ről? stm32f2xx.h file-ba is ezt a formát rengeteget látom, de sehol nem találtam hozzá leírást hogy ez igy mit is csinál, pl programon belül egy értékadásnál... A hibaüzenet amit irtál nekem kb ua. csak error én nem warning.
Csináltam egy képernyő mentést, paint-be pirossal Még bekommentezve. Mi a gond? Nem értem. 2 hibaüzenet is van egy sorra.
Koppantsd be légyszi a vonatkozó program sorokat is, mert így csak általánosságban tudok válaszolni a kérdésekre.
Ha valami 8 bites érték, és a 0x0009 memória címen van, azt általában úgy használják C-ben, hogy "készítenek" egy pointert, ami a kért memória címre mutat, és azon keresztül kiolvasható / beírható az érték. Pld: void* p1; //ez egy pointer unsigned char c1; //ez egy 8 bites konstans p1= 0x0009; //beállítod a pointer címet c1= *(unsigned char*)p1; //kiolvasod a byte-ot a címről //vagy: *(unsigned char*)p1= c1; //vagy betöltöd oda Ami a hibaüzeneteidet illeti (167 és 513. ssorok), az egyik esetben összekeverted a void pointer (fentebb a példát direkt azért úgy értem), és az unsigned char használatát, valamint a char pointer és az integer kezelését is.
Okay, csak fentebb írtam hogy a 0x0009 az hiába van pointer array-ben nem mint pointer-t használom csak mint lefelé számlálót. Tehát hiába mutat a 0x0009 memória címre, magához a memóriához nem lesz hozzányúlva, csak és kizárólag az értékhez. Azaz 9,8,7 stb.
Jelenleg a képen az összes programsor látszik, soronként veszem át a C32 programomat. Most ott vagyok elakadva hogy a memchr funkció nem működik valamiért. 167 és 513 az nem programsor, mert nincs annyi, hanem a hibaüzenet kódja. a hiba a main.c 44-es sora
Ez a sor a probléma:
"a" változó unsigned int. memchr definíciója:
Ebből én azt látom hogy a keresendő string "const void" lehet. Amit nem értek, mert pl ugyan ez az strlen függvénynél const char. A hibaüzenet egyébként: main.c(46): error: #513: a value of type "void *" cannot be assigned to an entity of type "unsigned int" C24, C32-ben nagyon sokféle dolgot meg tudok csinálni, de ezek itt RV-ben nekem nagyon kínai egyenlőre.
Meg van a megoldás:
"a" változónak pointernek kell lennie mert a memchr, strchr függvény nem a string változóban elfoglalt helyet adja meg (ellenben C32-vel), hanem a memóriában az abszolút pozíciót. Igy ha U1RXin változó 0x100on kezdődik, az első "," benne az 5. akkor memchr 0x105 eredményt ad, azaz memóriára mutat.
Sziasztok!
Még mindig nincs meg a megoldás. Tudna valaki segíteni? üdv,Peti
Én ARM-be még very kopasz vagyok, én sajna nem...
Ha mindenképp tárolni akarod az elemek számát, készíts egy struktúrát. Azt PIC32-re is úgy lett volna érdemes. Az egyik tagja legyen az elem szám, a másik meg az a tömb. Sokkal kezelhetőbb, mint így belegányolni a hosszát. És akkor ilyet kell kezelned, hogy GPSstruc.count meg GPSstruct.data vagy hasonló, ahol értelem szerűen a GPSstruct a struktúrád, a count az elemszám, a data pedig a tömböd.
Ha tippelnem kéne, elsőként valami táp környéki gebaszra tippelnék. Valami nincs bekötve, valahova nem a megfelelő táp került, esetleg a kondik hiányoznak/nem látják el funkciójukat, netán a táp maga gyengus és egy-egy csúcsnál lerogyik.
Valami gyári fejlesztőpanelt használsz, vagy magad gyártottad a panelt? Ez utóbbi esetén fokozottan érvényesek a fentiek.
Van arra valami kínálkozó lehetőség, hogy arm prociban lévő L2 cache tartalmát befolyásolni tudjam? Pld van 256kbyte L2 cache egy arm prociban, és én konkrétan adott végrehajtható kód + memória tartalmat szeretnék oda beszedetni a procival, és azt lockoltatni benne (ne változzon meg, amíg én azt akarom benne tartani).
Írásra bánom is én write back vagy write through, az mindegy. Olvasásra (végrehajtás, vagy adat regiszterbe töltése) legyen fixen kéznél L3 művelet nélkül, amire szükségem van, erre lenne szükségem. Van erre bármi gyakorlati esélyem?
Köszönöm, az ötleteket!
Saját nyákkal dolgozom. Még ma megvizsgálom a tápot részletesebben! Sokat mértem skóppal a feszültségeket, és nemrég egy rc szűrőt is beépítettem az 1.3V-os áramkörbe, mostmár teljesen "sima" a tápfeszültség amit ARM kap,de még mindig fennáll a probléma. Próbáltam más sorrendben is rákapcsolni a feszültségeket, és a RESET áramkört is nagyobb időállandóval késleltetem, de nem segít. Esetleg valami a TAP beállításoknál nem lehet gond? Az egyik GPIO-ra kötöttem egy Led-et, és az halványan világít, amikor az ARM megkapja a 3.3V-os tápot. A BOOT lábakon 2V körüli feszültséget mérek mikor felhúzom őket 10k-n keresztül 3.3V-ra, és még egy érdekes jelenség, hogy ha az ARM csak az 1.3V-os tápot kapja meg, akkor a RESET lábon, hiába húzom le, egy szinuszos feszültséget mutat a szkóp. Üdv, Peti
Szia, az 1,8V-os tápról még nem írtál semmit. Az adatlap sajnos nem konzisztens önmagával: az egyik helyen kiemeli, hogy ha nem használod az USB eszközt, az USB0_VDDA33 elhagyható (a USB0_VDDA18-ról nem írja ezt), míg a következő fejezetben mindkettőt elhagyhatónak jelöli.
A tápod zaja egyszerűen kizárható, egy NiMH cellával a 375MHz-es verzió esetén.
Esetleg még valami. PIC-eknél van Analóg Vdd, és analóg Vss. Ha ezek nincsenek bekötve a PIC használhatatlan. Teljesen. Szóval esetleg meg kellene nézni hogy minden rendben van e bekötve. Mint a legtöbb ARM gondolom a tied is belső oszcillátorral indul, ergó ha tápok rendben és a reset is ok, akkor kutya kötelessége menni. Elvileg.
Hi!
Tudna valaki a string.h "strtok" lelkivilágában segíteni? Addig jutottam hogy egy "delimiter" mentén ami nekem a NMEA stringben a vessző szét tudja darabolni a stringet egy tömbre mutató pointer segítségével, ami nekem pont jó tökéletes lenne. A kód amit találtam:
weblapja: STRTOK
A dietlibc nevű csomagban így implementálták:
Igen, az USB táplálásánál nekem is szemet szúrt ez az ellentmondás. Végül nem kötöttem be sem az USB0_VDDA12-t sem USB0_VDDA18-t sem USB0_VDDA33-t. Az mivel az adatlapban egy táblázatban ez van összefoglalva és ezt vettem alapul. Remélem nem ez a probléma, végső esetben majd odaforrasztok egy vékony vezetéket az ARM lábához.
Ennél az ARM-nál, én nem találok analog táplálást. De vannak más lábak, pl. az RVDD láb, ami az áramkörtervezőmben jól be van kötve, a nyákon meg még ellenőriznem kell. Az okozhat problémát, hogy az ugyanazon funkciójú lábakból mint pl. a CVDD-k nem kötöttem be mindet?
Idézet: „Az okozhat problémát, hogy az ugyanazon funkciójú lábakból mint pl. a CVDD-k nem kötöttem be mindet?” Igen. Ez alap: ugyanolyan nevű tápokat egyformán mindet be kell kötni, ez gyakorlatilag minden általam ismert CPU-típusnál így van. Továbbá, hacsak nincs leírva a doksiban explicite, hogy az adott táp bekötése nélkül is üzemel a chip, akkor az is alap, hogy mindegyik táp kell az IC-nek. Az általam nézett ARM926 doksikban még az is benne volt eddig, hogy milyen sorrendiséggel lehet neki a tápokat adni. AM1705 doksi, 38. oldal, 5.3.1-es pont. A 5.4 azt is tartalmazza, hogy az USB nélkül miket nem kötelező bekötni. |
Bejelentkezés
Hirdetés |
