A HUP-on nem vagyok járatos, de körülnézek. Igazából nagyon alapvető dolgokkal kellene tisztába kerülni, tehát nem egy konkrét programozási probléma. Leírok pár kérdést, ami felmerült bennem, hogy világosabbá váljon, mi is érdekelne:

1. A disztribúcióhoz megtalálható, vagy a netről elérhető, különböző crosscompiler csomagok miben különböznek (arm-linux-gnueabi, arm-none-gnueabi, arm-uclibc-gnueabi)? Mit jelent az, hogy egy adott toolchain linux/glibc, linux/uClibc vagy éppen bare metal környezetre fordít?

2. A lefordított programba hogyan és milyen utalások kerülnek bele abból, hogy a fordításkor használt toolchain milyen környezetre volt elkészítve?

3. Linux kernel fordításánál is érdekes, hogy a crosscompiler milyen környezethez fordít?

4. Hülye kérdés: a kernel függ(het) a glibc-től?

5. Egy akármilyen környezethez előállított toolchain bare metal fordításhoz használható, ha parancssori kapcsolókkal kikapcsoljuk a standard library-kat?

Ugyanarra a CPU-ra több különféle módon lehet kódot fordítani, azaz a fordításnak vannak paraméterei is.
Ezeket a paramétereket együttesen ABI-nak hívják (application binary interface). A nem ugyanolyan ABI szerint fordított kódok (könyvtárak, object fájlok) általában nem linkelhetőek egy programmá egyszerűen, mert az interfészeik nem fognak passzolni. A "linkelésbe" itt a futtatható programmá linkelés is, és a futtatás során a shared libekkel és az operációs rendszerrel történő linkelés is beleértendő.

A legfontosabb egyik fordítási paraméter, hogy hogyan történik a függvények paramétereinek és visszatérési értékének átadása (pl. regiszterben vagy stacken), ill. hogy a függvények mely regiszterek értékét kötelesek megőrizni a visszatérés előtt.
Másik hasonlóan fontos paraméter a pointerek használata, azaz mekkorák a pointerek, van-e több fajta, stb. Ez flat-mode 32-bites CPU-knál mondjuk elég egyértelmű, de pl. egy 16-bites x86-on szegmentált memóriakörnyezetben, vagy egy 8-bites PIC esetén már nem annyira. A "relokálható" kódok (pl. shared libek) megvalósításának módja is az ABI-ba értendő (pl. hogy lehet megoldani, hogy a shared lib megtalálja a saját globális változóit).

Az ABI-t sokszor az operációs rendszerre vonatkozóan definiálják (pl. Linux 32-bit x86 ABI), és beleértik a rendszerhívások módját is (trap, interrupt, paraméterek átadása, stb.), ill. sok más egyéb, rokon dolgot, mint pl. hogy mi a végrehajtható programkód formátuma, amit az operációs rendszer be tud tölteni.

A gcc és haverjai fordításánál nemcsak a CPU típusát kell megadni, hanem azt is, hogy milyen "környezetbe" (ABI-ra) szeretnénk vele fordítani - persze általában van egy default, ami sokszor a "linux-gnu". Az, hogy az adott CPU platformon mennyiben térnek majd el a lefordított kódok a külöböző esetekben, azt nem lehet általánosságban megmondani.
Ami biztos, hogy a linux/glibc MMU-képes HW-t kíván, ergó tud benne lenni shared lib, míg a linux/uclibc emlékeim szerint MMU nélkül is megvan, tehát valószínűleg nincs benne shared lib, ill. a futtatandó exe betöltésének is másképp kell történnie.
A bare metalra fordító verzió - gondolom - arra van kitalálva, hogy a memóriában egy program fut, azt valamilyen módon betöltjük egy fix memóriacímre, és ennyi.

Bare metal célra általában lehet kódot generálni bármelyik fordítóverzióval, ha nem akarunk más verziókkal fordított külső libeket belinkelni (azaz mi fordítjuk az összes kódot). Arra oda kell figyelni (és ez a Linux kernelnél is lényeges), hogy ha assembly betétjeink vagy külön fordított assembly forrásaink is vannak, akkor a C fordító által megvalósított ABI befolyásolhatja, hogy az assembly részekkel milyen módon megy az interfészelés.

Nézegettem, olvasgattam, hogy mit lehetne.
Használt már valaki Lauterbach-ot és a hozzá tartozó Trace32 környezetet ARM-okhoz? Tapasztalatokra lennék kíváncsi.

Hi mindenkinek!

Egy nagyobb rápihenés után, effektív befejeztem a DMA-SRAM-SSD projectet, már ami a működtetésével kapcsolatos.
STM32F207, 10ns SRAM-al, 120 helyett 155MHz, és szorosra húzott FSMC timinggel 44-46 FPS egy bit toggle lábbal logikai analizátorral mérve. Ugyan ez 160MHz-el már a képernyő elkezdett szöszös lenni. Ja: felbontás 800x480 egy 7" Innolux kijelzővel.
A litván srác mondta hogy ő a gyári 407-es 160MHz helyett 242-ig tudta húzni, így nagyjából kijöhet az ő 60fps-e. Persze tudom hogy a 45 nem 25 és ez is alapvetően bőven ok lenne, de ez az érték megy lentebb amint a közös buszon lévő SRAM-ba elkezdek beírni adatokat akárhonnan, azaz ha változtatok a képernyő tartalmon. Szóval ez statikus kép-re az adat. Bízom benne elég lesz, hiszen egyszerre kis képernyő felület változik, nem TV lesz.

Helló!

Használt már valaki FAT16-ot uSD kártyával, SDIO módban valamilyen ARM-on? Tapasztalatok?

Sziasztok!

Először is elnézést a nem teljesen témába vágó kérdés miatt, de ezt találtam legjobb helynek. Olyan kérdésem lenne, hogy tud-e valaki olyan kütyüt (gyártó,típus) ajánlani, mint a Raspberry PI, csak kicsit erősebb procival? Mondjuk dupla mag 1GHz. És jó lenne olyan, ami Linux-ot tud futtatni.
Előre is köszi. És elnézést az off miatt!

A legerősebb modulokat eddig a ARM Kits oldalon találtam. GHz-es cuccok is vannak ott.

Ez nem annyira off azért.
Allwinner A10, A13
Bővebben: Link

Köszi a linkeket!

Olyannal még nem találkoztatok, ami dupla magos?

Ne legyünk ennyire igénytelenek! Van négymagos is: quad-core Samsung Exynos CPU

Na ez már emberi sebességgel megy. A Raspberry egy kicsit lassúnak tűnik Yutube-on. Már csak be kellene szerezni egyet

Nem kell értelmetlen programokkal teletömni. Annak idején MS DOS-sal a 33 MHz-es 486-os CPU is repesztett (tudományos számításokat végeztem rajta).

Persze egyértelmű. Linux alatt torrentezés, böngészés, filmnézés és zenehallgatás lenne a cél. Csak a Raspberry idegőrlően lassan tölt be a videókon.

Sziasztok!

LM3S9D96-os típusú Stellaris-on szeretnék timer-t használni és az adatlap alapján bennem nem tisztult le a periféria működése. 16 bites, up-count módban, előosztó használatával szeretném a Timer A-t használni. A problémám az az, hogy nem értem a megszakítási állapotokat. Elvileg van egy "timeout event" és közben definiálhatok egy köztes komparálási értéket. Jól vettem ki? A timeout-ot érzésem szerint a GPTMTnILR és a GPTMTnPR határozza meg, míg a köztes értéket a GPTMTmMATCH és a GPTMTnPMR, de az adatlap egymással ellentétes dolgokat említ:



Pár sorral lejjebb pedig...:



Tapasztaltabbak elmondanák, hogy hogy is működik ez? Melyik regiszter miért felelős? Én már meg vagyok zavarodva...

Én ís így vettem ki a leírásból. Bár az LM4F120h5QR adatlapját nézem, amiben valamivel egyértelműbb a leírás, de vélhetően nincs különbség a TimerA felépítésében. Itt a GPTMTnMARCHR regiszterrel való egyezés mint további megszakítás forrása szerepel, ami megfelel az értelmezésednek:

Köszönöm!
Eközben elkezdtem egy minta kódot írogatni, ami sajnos nem működik... A felfelé számlálást elvetettem, mert az errata-ban láttam, hogy 16 bites, up-count, módban az osztó nem működik , szóval maradt a lefelé számlálás...A kód valamennyire működik, a megszakítás megtörténik, de olyan, mintha az prescaler nem működne. A LED-ek (ugyanarra az I/O-ra ellentétes polaritással két LED van kötve) baromi gyorsan villognak.
Megkérhetnélek, hogy megnéznéd a kódomat a Launchpad-odon, hogy működik-e? Hogy kiderüljön, hogy én hibáztam-e vagy hardveres hiba van, bár az előbbit valószínűbbnek tartom... Csak a port beállítását kéne átírni, a többi kompatibilis, illetve .h-k include-jait, meg a startup.c-t, mert én IAR-t használok. Persze csak akkor, ha ráérsz és nincs jobb elfoglaltságod

Sjanos, most nagyon nem érek rá. Ebben a workbookban azonban találsz egy montapéldát (4. fejezet). Igaz, 32 bites módban csinálják, de a dallama naygjából hasonló, a többi meg már a Stellarisware dokumentációjából talán kisilabizálható.

Semmi gond, tényleg.
Köszi a workbook-ot, de ez alapján próbáltam meg összehozni. Majd még próbálkozok, de legközelebb sajnos csak csütörtökön tudok leülni újra ezzel foglalkozni.

Szia

A TIMER0 prescaler csak TIMER_CFG_16_BIT_PAIR üzemmodban megy.
Én is szívtam anno.

TimerConfigure(TIMER0_BASE, TIMER_CFG_16_BIT_PAIR | TIMER_CFG_A_PERIODIC);

Köszi a hasznos infót!
Sajnos most nincs itt a panelem, így nem tudom kipróbálni, de szerintem ez jó lesz, mert tényleg nem állítottam át 16 bites módba a Timer0-át.

Köszönöm, ez tényleg hasznos információ volt, mivel a dokumentáció enyhén szólva félreérthető, az eddig látott mintapéldákban 32 bites mód szerepelt.

Sziasztok!

Lenne egy kis problémám a stellaris lp rendelésével kapcsolatban. Anno, mikor icserny feltette ide a rendelési lehetőséget, rendeltem kettő darabot, kifizettem a ~10 dolcsit. Novemberi turnusra fértem be. Eddig minden rendben. Ma hajnalban viszont kaptam Texas-tól e-mailt, banktól meg sms-t. Megint levonták a rendelésemre a 10 dolcsit (sms), és az e-mailben meg a 9. hó 2-a a rendelés dátuma. Ez mi lenne?

Hello! Amikor megrendelted, nem vonták le a pénzt, csak "befoglalták". A fizikai levonás most történt meg. Nálam is u.e. a helyzet, de én már tudom, hogy a TI így csinálja ha nem vagy nyugodt, nézd meg online a banki forgalmadat, vagy irány a bank.

Neten még nem néztem utána, csak az sms-ben lévő tartalom alapján kétszer történt zárolás az aktuális árfolyamon.

A zárolás az nem számít fizetésnek Zárolják, hogy később biztosan a számládon legyen még amikor fizikailag levonják. Valószínűleg azért zárolták kétszer, mert az elsőnek már lejárt az érvényességi ideje, olyankor automatikusan feloldásra kerül.

Hogy milyen elvetemült emberek vannak! Ebben a bemutatóban az látható, hogy a 600 mil széles tokozású NXP LPC1114 mikrovezérlőt hogyan lehet 300 mil szélességűre karcsúsítani.

Csodálatos

Én még a múltszázadban olyat csináltam, hogy PIC SMD procit pasztik beléptetőkártyába "tömörítettem bele". 1.5 - 2 mm közötti vastagság kivezetékezve.
Kellett a mikroszkóp.

Nekem ma hozták meg a kilövőállomást.

Nekem is egy órája ért ide

Nekem is megérkezett a Sellaris board Már csak idő kéne hozzá