Fórum témák
» Több friss téma |
Mégegy, a TRACE az kell calamire, ha jól látom az mégegy 20 pólusú csati.
Nem elég a JTAG/SWD a normál programozás/debugolás-hoz?
Elég. A TRACE extra debuggolási lehetőséget ad (én 4 vagy 5 extra lábra emlékszem a standard JTAG-en felül).
Viszont azt nem tudom, hogy milyen szoftver és illesztő kell hozzá.
Sziasztok!
Keresek ARM hardvert, ami kb egy átlagos okostelefon képességeivel rendelkezik. Kamera, GPS, SIM/GSM kezelés és van lehetőség kb. 4db GPIO kezelésére. Nincs szükség kijelzőre és 3D képességekre. Szóba jöhet komplett telefon is, csak a GPIO miatt nem tudom, hogy mennyire hozzáférhetőek a külvilág számára a doksik. Szoftver oldalon inkább egy pure linux, mint Android a befutó. Valaki foglalkozott már ilyen készülék kereséssel? Üdv Zsolt
De kijönnek az alkatrészárak 24 EUR-ból, mert sokkal olcsóbbak az alkatrészárak nagy tételben és nem raktak rá nagy árrést (volt szerencsém Nokia telefonokat gyártani ipari mennyiségben).
Emellett le a kalappal a Raspberry gyártónak a kis árrésért.
Kedves ARM-osok, a málnabokor teljes egészében áttelepítve ide:
Raspberry Pi - Málnatopik A hozzászólás módosítva: Máj 6, 2013
ARM alapismeretek elsajátításához:
Scherer Balazs, Csordas Peter Nagyteljesitmenyő mikrovezérlők Cor... mag
Üdv!
Remélem jó topicba írom, valaki esetleg nem tud valami használható elsősorban api leírást a ChibiOS-hez? Nagyon megtetszett, de az a doxigen-es cucc amit adnak leírás gyanánt, nekem nem sokat ér. ![]() Ennyi erővel a forráskódból is kihámozhatnám, hogy mit hogyan kell, de addigra kinőne a szakállam.
Biztos sok borotvád elkopik mire ezt mind megérted!
ChibiOS Documentation and Guides
Hát igen, ezt én is megtaláltam, de pont azért lenne jó ez az OS, mert HAL layer is van benne, de nem sokat mond a doksija.
Pl. A minap az STM32F4-en az RTC-t akartam beüzemelni és másfél napig kínlódtam, mire összelapátoltam, hogy akkor a sok közül melyik függvényt milyen paraméterezéssel kell meghívnom. És mindezt úgy sikerült, hogy azért volt hozzá valami minimál tesztkód. Szóval úgy kell elképzelni, mintha a printf függvénynek megadnák, hogy milyen paramétereket vár, de mondjuk nem lenne leírva, hogy a formatstring-be mit kell beírni és melyik paraméter milyen hatást vált ki. (jó nehéz lenne használni). A freertos-sem rossz, de ott HAL egyáltalán nincs integrálva, azt nekem kellene megírni.
Nem egészen értem a problémádat?
Van, mondjuk 2 féle elindulási irányelv. 1.: Van munkád, és pénzt akarsz keresni? Megveszed a neked tetsző OSt. Sujos 100 ezrekért! Így biztosan mindent megkapsz készen! 2.: Csak hobbista vagy? És sosem térül meg a befektetésed! Kénytelen vagy beérni valami olcsó OS-al! Ami sajnos korántsem annyira tökéletes! Ha tovább mész az előzőleg linkelt ágon megtalálod, amit keresel. Utasítások ismertetése: http://chibios.sourceforge.net/docs/hal_stm32f4xx_rm/files.html rtc.c RTC Driver code http://chibios.sourceforge.net/docs/hal_stm32f4xx_rm/rtc_8c.html Detailed Description RTC Driver code.
Ajánlott kód:
Kezdésnek a másfél nap egészen jó eredmény! Aminek jó része gondolom a teszteléssel telttel? ![]()
Ajánlott kód:
RTC Driver code: http://chibios.sourceforge.net/docs/hal_stm32f4xx_rm/rtc_8c_source.html Minden lényeges kifejezés értelmezése, (ami kékkel van megjelenítve), tovább vizsgálható ha rákattintasz! Kel ennél jobb Help? ![]() A hozzászólás módosítva: Máj 12, 2013
Linket javítottam.
A hozzászólás módosítva: Máj 12, 2013
Én FreeRTOS-t használom, HAL -nak pedig az ST standard peripheral library -jét. Szerintem nincsen arra szükség, hogy a kettő egy kézből jöjjön.
Aztán hiába van HAL, az adatlapot így is úgyis fel kell néha lapozni. Mellékesen szerintem az ST standard peripheral library remek példákkal jön.
Ilyen JTAG ketyerét próbált már valaki? Azt állítják, hogy az ARM Cortex-M akáráhány mellett a Renesas RX mikrovezérlőket is programozza/debugolja. De gyanús, hogy se szoftver se leírás nincs mellé.
Szerintem az egy Segger J-Link termék klónja, azért nem raknak mellé szoftvert... az eredeti gyártó szoftverét lehet használni.
![]() A hozzászólás módosítva: Máj 22, 2013
Sziasztok!
A segítségeteket szeretném kérni, egy új projekthez keresek olyan fejlesztőpanelt, ami tartalmaz több MB memóriát, vagy inkább néhányszor 10 MB-ot - különösebben nem számít, hogy SRAM, SD/DDR RAM vagy valami más. Sajnos az STM32F4 discovery, ami kéznél van, kicsi lesz erre a feladatra.. Ezen felül túl sok megkötés nincs, személy szerint a Cortex M3, M4, M4+M0 változatok között keresgéltem. Előny, ha Magyarországon is megvásárolható. Eddig az alábbiakat találtam: www.hotmcu.com NXP LPC4357-EVB Freescale TWR-K70F120M Másik oldalról az ARMv6/ARMv7-A valamely változatával szerelt mikroprocesszoros rendszerek olcsóbban kaphatóak nagy memóriával, de ezekkel nincs tapasztalatom. Mennyire nehéz megoldani, hogy pl. SPI vonalon adatot fogadjon és tároljon el? Előre is köszönöm a válaszokat. Idézet: Na, ezzel kapcsolatban is vannak kétségeim, de ebbe már tényleg ne menjünk bele. „az eredeti gyártó szoftverét lehet használni.”
Én a hotmcu LPC1788 board-ját használom 32Mx32bit SDRAM-al, 1Gbit NAND, meg NOR Flash. Szerintem jó. És mivel Cortex-M3, ezért szerintem nem is bonyolult.
![]()
Sziasztok!
Ismét kéne egy kis segítség, még mindíg a NAND/NOR/SRAM/TFT vel vacilálok. STM32F407Discovery boardra rákötöttem a TFT kijelzőt FSMC buszra (FSMC_Bank1_NORSRAM1) A kijelző működik, de a megjelenítendő képeket valahol tárolnom kellene, erre lenne a vásárolt tárolók valamelyike: NOR vagy NAND flash. A kérdés az, hogy melyiket lenne érdemes ilyen célra használn? Mind a kettő kéznél van, de nem tudom, hogy melyiket és milyen módon lehetne használni (bekötés). Illetve, hogy lekezeli e ezeket a kijelzővel együtt a 407-es? Van még egy SRAM om is, ez esetleg jó lenne framebuffer-nek, de a 407-es adatlapjában nem találtam hogy SRAM és TFT is mehetne együtt. Nem kis káosz van a fejemben azzel kapcsolatban. A flash-romokra szokás vagy van e valami butított fájlrendszer, hogy mégis könyebb legyen elérni az adatokat? Idézet: „A kérdés az, hogy melyiket lenne érdemes ilyen célra használn?” Ha V-s (100lábú) tokod van, akkor csak egy SRAM/NOR flash bankja van + egy NAND flash bankja. Ebből a TFT elviszi az SRAM/NOR flash bankot, ergó csak NAND flasht tudnál mellé pakolni, abból is csak egyet. Az SRAM-nak így már egyáltalán nem jutna hely. Alternatív megoldás, hogy az egy szem SRAM/NOR flash bankot felosztod, és egy extra 74LVC138/139 dekóderrel a felső címbitek állapota szerint dekódolod, hogy éppen melyik chipet szeretnéd kiválasztani - de ezt mintha már egyszer leírtam volna... A hozzászólás módosítva: Jún 1, 2013
Nekem a Nand is jó lenne.
Most egy másik probléma ütötte fel a fejét (miért ne) Az tft kijelző projektem működik külön, és egy USB host projekt is működik külön projektben(pendrive írás olvasás). A kettőt összefésűltem és a következő történik: 1. SystemInit(); et nem hívom meg akkor megy a kijelző, de az usb halott. 2. SystemInit(); et meghívom akkor a TFT lehel ,de megy az usb. Most mi lehet ez? A SystemInit(); a system_stm32f4xx.c fájlban van és elvileg a regisztereket helyezi alapállapotba. Nem tudom miért nem megy egyszerre a kettő, láb ütközés nincs. A hozzászólás módosítva: Jún 1, 2013
Azt gondolnám (anélkül, hogy különösebben ismerném ezt a függvénykönyvtárat), hogy a SystemInit-tel együtt is kéne működnie az USB projektnek, tehát ott keresgélnék először.
Az FSMC-időzítéseken módosítottam és így működik, de nem értem a logikát benne.
Olyan mintha a SystemInit-tel nagyobb lenne az FSMC órajele (vagy épp akkor normális). Gyanús is volt, hogy az LCD projektben nem használtam a System Init-et és ha minden késleltetést és időzítést minimálisra vettem az FSMC-init-nél akkor sem tudtam kiütni az LCD-t holott elvileg ilyenkor 60Mhz buszsebesség van.
Én ezt amit mondasz már komplett megcsináltam. STM32F207. FSMC buszon SRRAM + SSD1963. SRAM-ból a kijelzőre Memory-memory copy-ba DMA-val 800x480 kijelzőre ment az adat legszorosabb időzítéssel olyan 40FPS 120 helyett 155MHz-en hajtva. Csak mivel az én board-omon nem volt NAND, ezért váltottam egy másikra.
A szűk keresztmetszet az SRAM, az SSD bírja sokkal gyorsabban. Egy külföldi ismerősöm a 168MHz helyett 240-el tekert 417-el se tudta az SSD-t kiakasztani. Én sosem használtam a SystemInit(); részt. Lefut az az elején magától is a startup file végén van behozva, ha jól emlékszem. Viszont akárhogy is, az USB 48MHz-ét azt tartani kell. SSD-nél azt tudom tanácsolni, hogy FSMC busz sebességet hagyd 60MHz-en, aztán a CPU órajelet kell túltolni, ha kevés a teljesítmény. És a projectet támogasd meg a DMA-val. A hozzászólás módosítva: Jún 2, 2013
Értem, de most akkor ellentmondás van, mert _vl_ azt mondta hogy:
Idézet: tehát a 407-nél kijelző + SRAM felejtős.„Az SRAM-nak így már egyáltalán nem jutna hely” Nekem SSD1289-es 3,2-es kijelzőm van, de nam valami fürge. Megkérdezhetem, hogy hol lehet az általad használt 800x480-as kijelzőt venni, gondolom 4,3-as? A DMA-n gondolgodtam én is de hogy tudnám az adatokat DMA-val küldeni, mikor az lcd-nek hol parancs, hol adat módban kell küldeni az információt. Gondolom, úgy kell, hogy az sramból folyamatosan frissül a kijelző, és az sram-ba rajzolok? És akkor nem kell kurzort léptetni, meg ilyenek? (gondolom erre utal a memory-memory copy). És akkor így a kijelző az egy ram területté válik nem? Tudnál ebben segíteni, hogy hogyan oldjam meg a DMA-s működést? A nand flasht próbálom most belőni, de a vezérlő lábakat nem tudom hová kell kötni a WE, RE, CE lábak helyét nem lelem. A flash-hoz használsz valami fájlrendszert?
Van hely. Tudom, mert működik
A kijelzőm 7-es Flash-t még nem használtam, de nem fogok file rendszert használni TFTRAM[384000] az SRAM területre definiált színmélységnek megfelelő szélességű tömb. DMA használata egyszerű: Példa: 800x480 pixel = 384000 DMA tud maximum 65535 adatot. A kijelzőm 6 vízszintes egyenlő részre van osztva. Command: X = 0-800, Y=0-79 (ez = 64000 pixel) Data (DMAval): TFTRAM [0] - TFTRAM[63999] Lejár a 64000, szól a DMA interrupt: Command: X = 0-800, Y=80-159 (ez = 64000 pixel) Data (DMAval): TFTRAM [64000] - TFTRAM[127999] stb stb. Tehát az utasításokat a DMA interrupt handleren belül izomból adod, ki, de utána az adatok ömlesztve már DMA támogatással memory-memory copy-ba folynak, SRAM-ból az SSD-be. Nekem nincs kurzor. Ha ez az automatizmus fut a kijelzőre rajzolás annyi hogy a TFTRAM[] tömbbe kell írni, aztán a következő frissítésnél a DMA automatizmusa miatt meg is jelenik a kijelzőn. Persze ha a DMA számláló 32 bites lenne nem csak 16 akkor egyszerűbb lenne a dolog. A hozzászólás módosítva: Jún 3, 2013
Nincs ellentmondás, ha
- neki a Z-tokozású 144-lábú modellje van, esetleg I-s 176-lábú, azokban van több chip select kivezetve, ráadásul nem kell a multiplexált buszokkal se erőlködni, - vagy egy dekóderrel ugyanarra a chip selectre több periféria van bekötve. Ahogy néztem, se az SRAM-od, se a NOR flashed nem tudja magától a multiplexált busz kezelését, szóval kell majd oda még meghajtó a címvonalaknak is (ugye V-s chiped van). Idézet: „A nand flasht próbálom most belőni, de a vezérlő lábakat nem tudom hová kell kötni a WE, RE, CE lábak helyét nem lelem.” Ez benne van a doksiban. A V-tokozás esetén csak NCE2-van, NCE3 nincs. A hozzászólás módosítva: Jún 3, 2013
|
Bejelentkezés
Hirdetés |