Fórum témák
» Több friss téma |
Sziasztok!
Egy jó ideje programozok AVR mikrovezérlőket, és szeretnék ARM-l is foglalkozni. A problémám az, hogy amivel programozzák az a JTAG interfész, ez ugyanaz, mintha építenék egy JTAG ICE-t és ezzel próbálmám programozni? Vagy ha nem, akkor létezik olyan kapcsolás, ami USB-s és nem az FT2232 van benne? Üdv: Ant
Szia!
Mi a baj az FTDI-s JTAG interfésszel? Ha USB-s és nem FTDI-s, akkor általában saját protokolt használ, saját (leginkább fizetős) szoftverrel. Ez nem feltétlenül baj amúgy, a kezdőknek nagyon jól használható egyik legolcsóbb megoldás is ilyen: LPCXPRESSO - LPC1343 Ez olcsó (kb. 7000 Ft + ÁFA), egy Cortex M3-as kontroller és USB-s debugger is van rajta (amit egyébként saját áramkörhöz is nagyon jól használhatsz), az ingyenesen letölthető (max. 128kByte -ig használható) fejlesztőkörnyezet Windowson és Linuxon is fut.
Én úgy vagyok vele, hogy Keil + ULINK2 (40$) körül az Ebay-en, és minden frankó. Személy szerint én nem építenék debugger-t, mert ha nem sikerül elsőre akkor a második nekifutás már többe kerül mint megvenni elsőre.
Köszi, meggondolandó!
Értem, de ugyanaz, vagy nem?
Mi ugyan az?
Ugyanaz az AVR-hez való JTAG mint az ARM-hez való volt a kérdés. Bár most látom, hogy az egyiken van reset a másikon nincs...
AVR-hez nem értek. Állítólag a JTAG szabvány, tehát AVR JTAG-nak tudni kellene nyomatni a ARM-et, de hát a PIC32 C-t is 75%-ba újra kellett írnom ARM Cortex-M3-ra (C ->C), szóval kb ennyi az átjárhatóság. Jelen ismereteim szerint a két legszélesebb tudású JTAG a J-link, valamint a ULINK-2 (1, és Pro), ez utóbbiak a Keil gyári támogatásával is rendelkeznek, míg a J-Link-et külön kell telepíteni, a Segger oldaláról. Pl egy ST-Link meg csak STM-eket támogat. Én úgy tudom... Reset gomb meg annyira nem fontos, hiszen resetelni szoftverből is lehet.
Én nem csaz az AVR-hez, hanem az ARM-hoz sem értek, de úgy látom, hogy nagyon meg kell nézni a támogatási listát.
Például az U-link2 által támogatott MCU-k között nem látom az LPC1769-et (az LPC1768-at igen), s sem a Coocox IDE sem a RED Code IDE támogatási listáján nem látom az Ulinket. A Keil meg hobbi célra nem kifizetődő... Ha ilyesmibe kezdenék, valószínűleg az olcsó gyári megoldások (pl. LPC Xpresso, STM32 Discovery, Nutiny SDK) közül választanék először.
Az hogy mi és mennyire van támogatva érdekes dolog.
Utoljára amikor néztem STM32F207 nem volt a listában. Nekem mégis vígan ketyeg... És akkor a 407-ről szó sem esett. Viszont LPC1769 támogatva van, lásd mellékelt kép. Én azt vettem észre hogy aki komolyan fejleszt (cég pl) az a KEIL-t használja, tehát a KEIL-nem engedheti meg magának hogy az ő cucca ne támogassa nagyjából az elsők között azt ami kijön akárkinek is. Hobbi cél: Nos nekem az a véleményem hogy csak hardverért fizetek.  Így értettem a megéri-t.
én se értek még az armokhoz...
csak érdekességként megemlítem hogy ARM-ok két féle debug interfészzel jöhetnek: JTAG és/vagy SWD (értelem szerűen lehet mindkettő vagy csak egyik rajtuk)
Az SWD az mi pontosan? Úgy értem van valami összehasonlító SWD vs. JTAG?
úgy tudom hogy lábakat akartak spórolni ...
Bővebben: Link bár jobban megnézve ulink2 tudja mindkettőt
Idézet: Nem tudom, hogy ugyanarról beszélünk-e? Ennek szűkebb a listája. Mondjuk épeszű okot nem látok rá, hogy egy Jtag eszköz miért ne volna jó egy egyébként támogatott gyártmánycsalád fel nem sorolt tagjaihoz. Az is lehet, hogy egy évekkel ezelőtti listát másolgatnak frissités nélkül... „Viszont LPC1769 támogatva van, lásd mellékelt kép.”
Nem tudom, hogy feltűnt-e, de a belinkelt ebayes "hirdetés" location rovatában Shenzhen szerepel. Ami Kínában lakik. Ugye nem hiszed, hogy ezt a Keil nevű cég árulja (ami amúgy az ARM tulajdonában van), Kínából? Nyilván a ferdeszeműek nem igazán értenek hozzá, csak gyártják (másolják) és árulják az ebay-en, a leírást meg nyilván a lehető legritkább esetben frissítik...
Eleve az E-bay kínálatában kapható olcsó (max. $40) Ulink2-ről volt szó... Nyilvánvaló, hogy nem a Keil árulja.
Igen. Ezt nem a keil árulja. Viszont azzal eddigi tapasztalat szerint 100% kompatibilis, nem kell hozzá driver mint JLINK-hez. Igaz a firmware az enyémbe 1.47 frissitést mint lehetőséget nem találtam.
AVR JTAG - ARM JTAG
A JTAG nem más mint a uC-k programozói SPI portja. A JTAG egyszerű SPI kommunikáció, semmi varázslat. Mivel a PC-nek nincs SPI kimenete, ezért kell átalakítani és használni a lehetséges portokat (LPT UART USB) Vannak gyártói korlátozások, a nagyobb bevétel érdekében. De hogy ki gyártja le a JTAG programozót, az nem számít, a programozó szoftver (KEIL IAR AVRS) mondja meg milyen protokolt követel meg az átalakítóval. Ha ezt valaki ismeri, vagy dekódolja, akkor tud készíteni JTAG programozót. Pont a korlátok korlátozzák némely programozót. Pl AVR JTAGICE, nekem is van. programozza a M16 M48 M88, de nem programozza M168P M48P, pedig semmi extra különbség nincs, csak a proci ID más és "nem ismeri fel". Szóval ha a szoftver tudja az ID alapján a típust, flash méretét kezdetét, fuse bitek helyét tulajdonságait, akkor a JTAG bármely JTAGos procit fel tud programozni. (sebesség állítható) A DEBUG kicsit bonyolultabb, de tök ugyan ez. sztm
Arm-ban nincs valami olyasmi formátum, mint pld az intel .hex? Pic-ek ezt használják. Abban fix címek vannak. Config biteket ismerni a fordító dolga, és fordításkor már eleve azt másolja bele. Az intel hex egy 30+ éves valami. Arm-ban direkt nem csináltak volna ilyesmit, hogy lehessen zsidulni a programozókkal?
Ha csak spi kommunikáció kell, azt bárki össze tud rakni akár egy ftdi chip + pic összekötéssel, és máris lenne egy usbs programozója (és usb-n ott a táp vonal is). Ehhez képest akkor mi kerül 20-30 ezer hufokba? Idézet: „Ehhez képest akkor mi kerül 20-30 ezer hufokba?” Megpróbálok szemléletes lenni. Egy DVD ára néhány 10 forint. Ehhez képest akkor mi kerül 80 ezer Ft.-ba egy dobozos win 7 pro.-n? (A szoftver)
Oké, a nyers arm-ról nem vagyok ennyire képben. Szóval a "nagyon bonyolult" cortex-a szériás processzorok bebootolnak akár egy hulladék soros portról is, de ha egy "sokkal egyszerűbb" processzort akar valaki használni (pre arm11, cortex-m / r), akkor 100 ezer hufos felszerelés kell az égetéshez, és még akkor sem perfect az eredmény, mert valami működni fog, valami meg nem?
Idézet: „Az intel hex egy 30+ éves valami. Arm-ban direkt nem csináltak volna ilyesmit, hogy lehessen zsidulni a programozókkal?” Rendes rendszerek (platformok, programok) manapság jellemzően ELF formátumot használnak (korábban hasonlóan menő volt még a COFF, de az nagyjából kezd kihalni). Ez meglehetősen standardnak minősül. Nézd meg pl., hogy egy XC32 (leánykori nevén: gcc) fordítása után milyen formátumú bináris keletkezik, mielőtt abból a .hex legenerálódna...
Az, hogy egy adott kontrollert hogyan programozhatsz fel, kizárólag a gyártón múlik.
Például az NXP minden ARM kontrollere programozható egyszerűen soros portról, sőt egyes tipusok (pl. LPC1343) indíthatók olyan üzemmódban, hogy flash meghajtóként felismeri minden op.rendszer és a .bin fájlt egyszerűen rámásolod. Nyilván debuggolni nem ezzel a módszerrel kell, de a firmware frissítést baromi egyszerűvé teszi. ( amúgy a problémát eredetileg előhozó TI kontroller is bootolható soros portról )
Új fejlemény van az AM1705 körül. Kiváncsi voltam, feléled-e a processzor, és a válasz, igen. UART1 BOOT-ra állítottam, és a TXD lábat egy max IC-n keresztül a soros portra kötve, a "BOOTME" üzenet megjelenik minden RESET-nél. Ezek szerint tehát a bootloader működik, nincs baj a tápokkal sem, Egyedül valami gond a JTAG körül lehet.
Amit még megfigyeltem, hogy teljesen más kódokat küld a proci a TDO lábon más TAP beállításoknal, viszont a H-JTAG mindig ugyan azt a 0x000000f kódot olvassa. Gyanítom, hogy a H-JTAG körül lehet valami hiba, szerintem a TAP beállítások, de az is lehet, hogy nem tudja kiolvasni ennek a procinak az ID-ét. Ismer valaki esetleg valami más windowsos alkalmazást a H-JTAG-en kívül, amivel próbálkozhatnék?
Tegyük fel binárist gyártasz a procinak, és bebootolod soros portról. Még talán egy usb bootloader is fel tudsz írni a flashbe "belülről". Teljes siker esetén segítene ez bármit abban, hogy a jtag-ja nem válaszol?
Nem próbáltam, de fogom: OpenOCD Ha mindenáron Windows-ozni akarsz...
Na, örülök neki. Most legalább szűkítetted a lehetséges problémák számát.
Nem olvastam végig a témát, de nem lehet hogy csak simán elkötöttél valamit a JTAG bekötésénél? Minden lábat bekötöttél amit kell?
Köszönök minden segítséget!
"Teljes siker esetén segítene ez bármit abban, hogy a jtag-ja nem válaszol?" Nem hinném, hogy segítene, de mindenképp előrelépés, hogy tudom, hogy nem hardveres a hiba, hanem mostmár a szoftverek körül keresgélek. És meg is lett az eredménye, az OpenOCD egyből felismerte a procit, automatikusan beállíította a TAP-okat és végre jó DEVICE ID-t olvasott ki! Kicsit nehezen boldogulok még ezzel az OpenOCD-s környezettel. Sikerült a Hyperterminálon körösztül kapcsolatot létesíteni vele, de a parancsokat egyenlőre még nem ismerte fel. Egyenlőre a kérdésem az lenne, hogy mikrokontroller égetéséhez hasonlóan, itt is egy .hex fájt generálok az IAR-al, és azt égetem be a FLASH-be az OpenOCD-vel?
Inkább bináris kódot kapsz! Legalább is ez a default beállítás.
Még én is nagyon kezdő vagyok de, talán ez segit: Lecture 2 ? Bootloader.pdf : http://www.csie.nctu.edu.tw/~wjtsai/EmbeddedSystemDesign/Ch2-bootloader.pdf |
Bejelentkezés
Hirdetés |
