Hali!

Mindenképpen azonos családot szeretnék. A xilinx nekem nagyon elvont, nem áll kézre. Mivel párhuzamosan tanulom C, ezért lehet azt csinálom hogy az ARM9-es változatra teszek egy WinCE-t, arra PC programot írok, a perifériákra meg teljesen saját programot. Majd kiderül. Az ilyen Beagleboard nekem azért nem jó, mert nem illeszkerig a cél áramkörbe, ellenben ARM9 Samsung amivel az áramkör "legnehezebben kivitelezhető" része le lenne tudva. Egyébként 800x480 mellett 24b nem fontos, 9 vagy 16 is bőven elég.

Na.

Megjött a 599119 hozzászólásomban a kijelző a Touch nélküli. Megrendeltem továbbá az előtte említett 85$-os ebay-es LPC 2478 panelt a hozzá való Ulink kompatibilis USB-s debuggerrel. Meglátjuk mire jutunk. Persze még vagy sehová mert a barátnőm álltal küldött képeken tudom bambulni a cuccokat itt Ázsiában.

Mért ilyen döglött ez a fórum?

Az ARM9-est meg valószínűleg későbbre hagyom.
Kezdésképp 250$ beleinvesztálás az új technikába elég...

S.

Odahaza az amatőrök körében sajnos eléggé alulreprezentált az ARM-architektúra, remélem ezen majd változtat az olcsó Cortex-M0 család. Ha megnézed pl. a PIC-es témákkal Dunát lehetne rekeszteni. Vagy ez azért van mert a PIC-kel sokkal több a probléma?

Gratulálok a cuccodhoz, sok sikert hozzá! Majd azért számolj be légyszi hogy miképp haladsz...

Hát nem tudom... Nekem nem igazán voltak gondok PIC-el. Mindig mindent meg tudtam vele csinálni. ARM-el most még egy ideig fizikailag nem tudok foglalkozni, mert nem vagyok otthon, majd márciustól élesedik a dolog, addig meg uVision4, próbálgatom a C-t ami nekem isten csapása, meg van egy jó könyvem amiben ARM - ASM van. ASM nekem nagyon megy PIC24-en is azt használtam és tényleg a legbonyolultabb dolgokat is összekalapáltam vele.

A kijelző se lesz kispálya, nézve az adatlapján elés sok még negatív tápfesz is kell neki. Így visszagondolva lehet sok ez a cucc, ahhoz képest hogy FriendlyARM www.arm9.net ami ebay-en is van, 140$ a 7colos kijelzővel és minen kivezetve (RS-232, RJ-45, stb stb)

Érdemes mihamarabb barátságot kötnöd a C-vel. Egyrészt előbb-utóbb egyszerűen kevés lesz az ASM, másrészt bizonyos rutinok és algoritmusok leginkább C nyelven érhetőek el.
Gondold csak végig: az az eszköz amit készíteni szándékozol egyszerre több feladatot kell ellásson, a felhasználási terület miatt pedig garantált válaszidőkre van szükséged. Ezt pedig csak valamegy real-time kernellel tudod elérni, mint pl a FreeRTOS.
Az eszköz bonyolultsága miatt nem vállalhatsz minden feladatot magadra és a kód is áttekinthetőbb, ha bevezetsz egy bizonyos absztrakciós szintet és nem mindent gépi kódban írsz meg.

valaki esetleg épített már ARM-JTAG-ICE-t?
Esetleg tud valaki után építéshez elérhető leírást?
olimexes is elég drága. nincs kedvem 20eFt-t adni érte, ha 5-ből megvan.
már egyet találtam
Bővebben: Link
ám sajnos nem találkoztam még egyik webshopban sem a USBN9604 IC vel.
tud valaki segíteni?
sajnos nem kezeli a sima avrJTAG-ICE az ARM procikat
És USB-s nek kellene lennie, vagy soros-portnak, mert egyik gépemen sincs paralel port


végső megoldásként egy régi gépet, amin van paralel port, felélesztek és az lesz a mcu programozó gép

jobb lenne mobilnak lenni(noti).
avr-ekkel barátságban vagyok, csak érdekelnek a komolyabb játékszerek is
ez a cucc sajna szükséges hogy meg tudjam csinálni.
prockóm is van már hozzá, pcb-t is már nagyjából megterveztem.

A TME-ben kapható: Link

Próbálkoztál már a "sima" FT2232 -féle openocd-s jtag-al?
Sokan használják, elméletileg bevált dolog.Link

Nekem sajnos nem működött, ezért maradok az LPT-s megoldásnál. Szerencsére a jó öreg T40P-n van LPT De tuti hogy nemsokára rászánom magam egy USB-s jtag beüzemelésére.

Esetleg egy ilyen is szóba jöhet:Link

Egy gond van ezzel az usbprog-os cuccal, azt írja a szerző hogy a 32K flash beégetési ideje kb. 200 másodperc ! Az pedig elég sok idő...
Beleőszülsz a fejlesztésbe

Ennél még a beépített SAM-BA bootloader is gyorsabb, még ha bele is vesszük az ezzel járó tortúra idejét.

szia, köszi a választ, de EZT az oldalt néztem, és ARM-hoz nem jó, ugyan ezt ajánlja, mint amit linkeltem először.
"RTCK (return clock) JTAG signal offered by some ARM controllers, e.g. the Oki 67Q4xxx, is not supported."(lehet rosszul fordítok, vessetek rá egy pillantást.)
a többi sem támogatja az armokat, kivéve az EBAY os cucc.
Valóban a 200 sec 32k-hoz az pöppet sok.
főleg hogy 128k-t kell beégetnem

mind1, akkor marad az lpt portos, amihez élesztek egy gépet. ha sikerül megjavítanom egy p3mas notit, akkor lesz egy parallelportos notebookom jee
fatertól elkunyeráltam.

azért, ha tud valaki egy jó kapcsolási rajzot az szólhat

olimex-től a tiny annyiba lenne mint idehaza megrendelni a kínait, ha lesz pénzem lehet megveszem inkább, és annak jó a sebessége is.
bruttó 15e Ft környéke..+posta

Egy kicsit olvass utána a dolognak, nem hogy nem jó ARM-hoz, hanem ezt az openocd-s dolgot kb. az ARM keltette életre...

Tényleg..
Az angoltudásom kicsit hiányos, ezeket az e.g. meg i.e.-et em ismerem
akkor pöpec, csak egy ilyen ic-t kell beszerezni
FT2232.
Köszi szépen!!

Érdekes ez az egész. PIC-et az istennek nem akartam programozni C-ben. Van egy könyvem ami ARM7-et szintén ASM-ben tanít programozni. PIC-en USB kivételével szinte mindent megcsináltam asm-ben még Dual ECAN rutint is ASM-ben nyomtam az OSI mind a 7 rétegén keresztül, és teljesen hibátlanul működött. Pont az ASM miatt tudtam garantált időzítésekkel dolgozni, elvégre az isten se tudja hogy egyik másik C sor hány asm-re lesz átfordítva. ASM-nél bezzeg tudtam hogy minden egyes sor pl 25ns, persze ugrásokat kivéve. Tizen akárhány év alatt "sajnos" annyira gépközeli lettem hogy a magas szintű programnyelvek már nem állnak közel hozzám, nem esnek kézre, pedig anno még DOS alatt QBasic-el is játszottam....

Tudna nekem küldeni valaki egy olyan "üres" C file-t (main.c) amiben a szükséges kezdő sorok benne vannak, include stb stb, amit vázként tudnék használni kiindulás képpen? Ha ez egy kopmlett uVision project könyvtár az se baj, LPC2478 include legyen benne.

Köszi.

Az alap dolgokat először a gyártó oldalán érdemes meglesni: http://www.nxp.com/#/pip/pip=[pip=LPC2478_1]|pp=[t=pip,i=LPC2478_1] , oldal alja. ( a [] karakterek miatt nem jó a link funkció..)

Ez is egy jó kiindulási pont: Bővebben: Link

Nézz rá az olimexes LPC2478-as board demo kódjára, abban sanszos hogy megtalálod, amit keresel.

Vannak URL-rövidtő szolgáltatások, pl. a href.hu vagy a tinyurl.com, amivel a hosszú és fura karaktereket tartalmazó linkeket fórum-kompatibilissé tudod tenni

Hali!

Sikerült már valakinek Keil uVision4-et licencelnie? Nekem Debug indításnál licence hibát ír ki, pedig a táblázatban mutatja hogy expiration 2012...
Mi lehet?

S.

Kroy!

Ma jött meg a cuccom ebay-ről amit előbbiekben írtam. Még pár nap és hozzájutok itt a vadkeleten. Írtad a hivatkozott hozzászólásban hogy buszterhelés, az LCD mérete, és színmélysége függvényében. Letöltöttem. Ok, nézem de egyenlőre ez nekem nem sokat mond. Fűznél hozzá egy kis magyarázatot? Közben állandóan az LPC2478 adatlapot olvasom, gőzerővel haladok, meg Keil4-et is, de annyira sok az infó hogy lassan Stack Overflow

Szia!

A magyarázat viszonylag egyszerű: ismered az LCD-d frissítési frekvenciáját, mondjuk 60Hz. Ismered a felbontását, legyen 800x480, illetve a színmélységet, mondjuk 24 bit.

Ezen adatok alapján az xls kiszámolja neked, hogy
- mekkora memóriára van szükséged a frame buffer-hez (itt 1500KB)
- mekkora sebességre van szükséged, hogy azt az adatmennyiséget adott gyakorisággal (pl. 60Hz) átvidd a buszon.

Itt el kell döntened, hogy frame buffer céljára milyen memóriatípus áll rendelkezésedre. Az SRAM gyorsabb, de drágább, az SDRAM olcsóbb, de lassabb.

Ha megadod a memóriakonfigurációdat (adatbusz szélessége és a különböző időzítési értékek) és a processzorod órajelét, akkor megkapod, hogy az adott órajel által biztosított buszsebességnek hány százalékát fogod elhasználni ahhoz, hogy az processzor LCD-kontrollere folyamatosan stabil képet tudjon kitenni a kijelződre.

Akkor van baj, ha ez az érték 100% fölött van, akkor semmi esetben nem fogsz szép képet kapni. Ha 100% alatt van, akkor még mindíg előfordulhat, hogy a RAM-ból futtatott kód bezavar. Ha belefér a kódod a belső flash-be, akkor elméletileg mehet a dolog: ha jól emlékszem a flash és a külső memória kontrollere külön buszt használ belül az LPC24xx-nél, de nem vagyok biztos benne.

Amit tehetsz az az, hogy
- Átteszed a frame buffert statikus RAM-ba, ezzel néhány százalékot nyerhetsz.
- Csökkented a képfrissítési frekvenciát, ennek fizikai korlátai vannak, az LCD-d adatlapján megtalálod a minimum és maximum értékeket.
- Növeled az órajelet (ha pl. eredetileg nem 72MHz-cel számoltál).
- Csökkented a színmélységet. Ezzel fel fog szabadulni néhány láb is.

Végezetül gondolj arra is, hogy egy kép kirajzolásához azt elő is kell állítani. Ikonok, szövegek kirajzolása megintcsak igénybeveszi a buszt, animációk esetén (pl. egy rajzolt analóg műszer mutatójának mozgatása) a DoubleBuffer módszer szintén sávszélességgyilkos.

Teszteltem jópár TFT LCD-t, bár az ideális az a 60Hz, de mind megy alacsonyabb frissítéssel is.
Legtöbb adatlapban minimál érték sincs.
Tapasztalat szerint 20Hz felett nem villog, stabil. Alatta LCD függő, van amelyik villog, van amelyik 10Hz-ig stabil...
Színmélységben ilyen LCD-nek "pazarlás" a 24 bit. A szabványos 565 RGB azaz 16 bites felbontás teljessen megfelelő. 444 RGB 12 bit már nem szép és macerás is, a 8 bites meg ronda...
teszt 480x272 5" 8biten kb 10fps
Az RGB565 is 2/3-a adatbusz terhelés jelent, minősége teljessen jó.

Helló!

16 bit is bőven elég lesz.
Hogy milyen a memória? Van mindkettő típus ahogy a fentebb mutatott LPC2478-as panelt néztem, amit ebay-ről rendeltem. Egyébként egy csoda folytán holnap már a kezembe van.

Úgy látom elég aktív leszek itt "sajnos" a saját "szerencsétlenségem" miatt:

Tudok bármely regiszternek komplett értéket adni C-ben:

[code=c]PCONP = 0x1;[/OFF]

De mi van ha pl én csak a 12. bitet akarom 1-re állítani, hogy az ECAN1 modult kapcsoljam be? (Nem biztos hogy a 12. csak rémlik). Microchip PIC24 C-ben (amit sose használtam mert ASM őrült vagyok):

[code=c]C1RXF0SIDbits.SID = 0x01D0;[/OFF]

ahol a SID a C1RXF0SID regiszter valahányadik bitje melynek neve SID.

Na valami ilyet szeretnék ARM7-el, Keil4 alatt. Más is úgy gondolja hogy Keil-nek teljesen használhatatlan a help-je? Bármire keresek pl "include": semmi értelmeset nem dob ki...

Ezt ugy erted, hogy a regiszter beallitasa maradjon meg amellett hogy a 12. bitet ki/be kapcsolod?
Miert a Keil mellett dontottel? Nem lett volna jo a gcc?

Nos:

Pontosan ezt szeretném. valahogy úgy ahogy PIC24 assembly-ben:

bset PCONP, #12

Keil mellett azért (egyenlőre) mert amikor a panelt meg a programozót rendeltem mindkettőt egy "boltból" tudtam rendelni, tehát komplett és a progizóhoz nagyon ki volt emelve hogy Keil uVision. Kezdőként mindenből a gyári megoldást szerettem, mert az komplett, kompakt, és egybe van.
Bitwise operations

Közben találtam a fenti oldalt a gondomra.
Kérésem lenne: C progi nekem lefordul. Megtenné e valaki hogy küld nekem zip-be egy becsomagolt project könyvtárat, ugyanis nekem ASM program nem fordul le. Mindig van valami gondja. Tényleg csak egy üres váz kellene benne egy daram "nop" utasítás (PIC24 ben van ilyen legalábbis) amiben aztán elkezdhetem kipróbálni az ARM7 ASM részét is. Nagyon idegest hogy Keil - Help nem segít... Merthogy nem fordul le.... A csatolt file-ról lenne szó, az utasítások benne szinte nem is lényegesek, valami az elejéről hiányzik...

Hali!

Megoldódott az ASM problémám. A szemem jojózik, a fejem zakatol, holnap Mission, de akkor is megvan.

Tehát. A Startup kód, másnéven pl. nálam LPC2400.s kódból a legvégén van egy rész ami már a képernyőmön féretéve, letárolva van a tároló.txt file-ként. Na egy kell kivágni a végéről, elvégre semmiféle C kódba nincs "entering" hisz ASM-ről van szó.
Ezek után kell 3 sor az ASM file elejére és mehet a móka.

Simi

Sziasztok!

A minap váltottam xp-ről win7(x64)-re, és sajnos nem igazán akar működni a 32bites gcc. Keresgettem, de nem igazán találtam megoldást(x64-es gcc). Egyébként eclipse-ot használok, eabi-arm-gcc -vel. Egyébként hiba nélkül működik x32-es win7 alatt.

Van valakinek ötlete az x64-re ?

Hawkboard-dal találkozott már valaki? Milyen ingyenes szoftverfejlesztői környezettel lehet ezen legkönnyebben eredményre jutni, ha mondjuk nem kell grafikus kezelői felület, csak vezetékes kommunikáció (soros, USB, Ethernet)?

Hali!
Egy Olimex L9260 fejlesztőpanellel szenvedek amin Atmel at91sam9260 proci van. Az a nagy problémám, hogy már egy hete nem tudom feléleszteni a TWI-t . Gyári atmel-es example-t próbálok futtatni (fordul is meg feltöltődik ezekkel nincs is baj), de a külső EEPROM-ot sehogy sem éri el (folyamatosan timeout keletkezik .. kb semmi kommunikáció nincs a proci oldaláról)

HW-esen a példakörnyezettől csak annyiban tér el hogy nem atmel EEPROM-ot használok, hanem egy ST24C02-est (címet és a lapok méretét állítottam át)
Már többször is átnéztem, hogy milyen regisztereket kell állítani, bár gyári kódról lévén szó szerintem az jó .. szval nem tudom mivel próbálkozzak, tegnap már AVR-el próbálkoztam, azzal persze elsőre sikerült )

Aki érzi magában a tudást, ne fojtsa el! Előre köszi!

Csak egy tipp:
Input High Voltage (SCL, SDA) min:0.7*VCC max:VCC + 1 V
ha 5v ról hajtod:
5*0,7=3,5 ami > mint az atmeled 3,3v os VCC-je
így nem látja magas szintnek, az AVR ed 5v ról megy gondolom.

lehetséges megoldás: csökkentsd le a tápfeszt legalább 4...4,2v-ra az eepromodnak.Elméletileg menni fog.

Elöször is köszi a gyors választ!

Sajna az eeprom és a uC/uP is azonos tápfeszen van (AVR-nél 5V, ARM-nál 3,3V)
Most kaptam egy kis segítséget, és kipróbáltuk linux alól, ahonnan szépen működik a TWI (kiderült hogy a legalább 100 fordítás után 1-2x 1-2 bájt meg is lett írva, de igazából csak nagyritkán keletkezik valami szemét)

Próbáltam nagyobb TimeOut-ot is megadni, de az sem okozott számottevő javulást (néha nem dob timeout-ot, az írás, de visszaolvasva mégsincs a rom-ban semmi)

Sziasztok

Van pár különböző ARM Cortex-M3 (LM3S1776/LM3S6938...) microkontrollerem.
Foglalkozott-e már valaki ilyenekkel?
Milyen fordítót használtok hozzá?
Van-e hobbisoknak inyenes verzió?

thx