Anno írtad, kedvenceid a texas instruments arm-ok, gondoltam, azokat nézegetem akkor.

http://processors.wiki.ti.com/index.php/AM335x_Power_Consumption_Summary

Más, szintén ti arm, kicsi assembly:

Rpu unitban asm-ből van rá valami egyszerű mód timert használni (lennének folyamatos 476 uSec ciklusaim, és tudni szeretném, "mennyi az idő", ciklus végén nullázni és előlről), vagy tipikusan külső órajelet kell beküldeni valamelyik rpu gpi lábon, és programból számolgatni ?

Ha 10 mhz+ tartományban kell illeszteni 1.8V / 3.3V, vannak arra célirányos ic-k, vagy kb a fet az egyetlen eszköz?

Rpu asm kérdés törölve, cortex-m szériákban ilyesmi nincsen, majd kotorászom adatlapokból..

Szerintem vannak. A TI-nél láttam végtelen mennyiségű különféle buszmeghajtót, végig se bírtam nézni a product selectorban megjelenő fajtákat, annyi volt (kérdés persze, hogy ezek közül mit lehet értelmesen beszerezni).
Bővebben: Link

Amit belinkeltél az egy A8-as felsőkategoriás ARM
Van pár nekem is, de macera panelt csinálni hozzájuk (BGA)
A sima cortexM3-ak (luminary) több mint 100 féle a perifériák variálásával, mind azonos lábkiosztásuak (periféria variálással) és 3.3V a tápfesz, a PLL core-hez kell 2.5V de ahhoz van belső LDO
703. oldal
A GPIO-k meg 5V tolerant!

Ha valami kraftos processzorral szeretnétek kísérletezni, szerintem mindenképp érdemes a Pandaboard-ot vagy a Beagleboard-ot megnézni. Főleg ha a Raspberry-hez hasonló kell. A pandán van HDMI és DVI kimenet, és minden finomság. Van rá Android ICS, Linuxok stb és elég jó a community is hozzá. Nem ingyen van de kb 200 dolláros az ára és a legújabb telók és tabletek hardver kiépítését kapod egy devboardon.

Valamiért a többi része eltűnt a postnak.
Szóval egyel alacsonyabb kategórában pl az említett ARM1808-hoz mi LogicPD által gyártott boardot használunk. Egy egyszerű nyákra rá tudod a modulokat tenni, nem kell 8 réteg.

A Cortex kategóriájában meg már az M3 M4 procik 120-180Mhz-et tudnak. Pl az ATM32F20x vagy 40x sorozathoz az olimexnél de a neten általában rengeteg féle panelt lehet kapni. Szerintem az a számítási kapacitás azért elég sok mindenre elég.

Valahol ugye el kell kezdeni, és valószínűleg készen fogok venni valami darabot eljátszadozni - megfogadom ez irányú tanácsodat. Most valahogy neten a csapból is az a8 folyik, nem a cortex-m. A beagle bone-ban van ilyen szöcske, és éppen nézegetem, hogy ha saját kézbe is szeretném venni a procit, hányféle lesz a probléma. BGA tok, na igen..

A cortex-m-et sokkal könnyebb lenne kézbe venni, de kezdésnek valami játéknak jobban örülnék. Ami ebben a beagle-ban van, gyakorlatilag 3 magos cpu, és linux kernel driverrel saját kézbe vehető a fő cpu melletti másik 2 mag. Egykori printer portos játékok új ruhában

A TI leltárban akadnak fesz-kapcsolók szép számmal, ettől úgy tűnik indokolatlanul féltem. Köszönöm _vl_ !


Amit jelenleg keresgélek az a boot flash-ek feltöltése. Egykoron a cpu-ban volt benne a flash, jtag-al azt lehetett feltölteni. Ami a8-ast néztem, annak a TI leírása is figyelmeztetett, hogy nyista flash a cpu-ban. Boot rom van, ami különféle perifériákról huzigálja be a boot image-et. Még nem találtam meg a jelenleg szokványos eljárást, hogyan is szokás egy panelra proci mellé felforrasztott pld nor flash-t átprogramozni. Nem hinném, hogy kötelezően előbb programozzák, utána forrasztják, és végleg úgy marad. Pld ha behúzott rendszerről újraírás közben valami elszáll, akkor lehet leforrasztani, vagy kuka az egész modul? Ami link-nek a TI lapon erre kellene vonatkoznia, az pld üres oldalra visz ("Sorry..."). Egyenlőre nem találtam arra vonatkozó leírást, hogy a cpu-hoz külsőleg kötött boot flash-t is fel lehetne tölteni jtag-al.

(http://processors.wiki.ti.com/index.php/AM335x_Hardware_Design_Guide fentről a 3. blokk "Selecting the Boot Mode"-ban a link halott)

Megnézem majd a pandát is. Egyenlőre elmásztam a ti lapra, és ott a beagle-ra volt link. Ha van róla olyan híred, hogy soványka lenne a supportja, az érdekelne - még nem vettem meg. Az árakra vonatkozóan azt pld 100 usd-be adják.

Van rajta jumper csatlakozó kivezetett jelekkel. Amúgy nekem is az jár a fejemben, hogy valami jumper csatlakozóval (ami mindkét irányban tűs csatlakozó) beledugom egy dugasz panelbe, és arra már ráépíthetem a többit. A pandának egyenlőre nem tudom, milyen a kivitelezése, keresem...

Ha tippelnem (vagy ötletelni) kéne, akkor azt mondanám, hogy SD slot. CPU szemszögből nézve nem sokban különbözik egy soros flash-től (egyszerű, mint a faék), ergó valószínűleg tudnak róla bootolni.

SD kártyára gondolsz? Van arra is support (SD/MMC is ott van a boot support listában), csak azt nem tudom, hogy ezek az sd slotok mennyire bírják a gyűrődést úgymond. Az oké, hogy pld a mobil telefonodban is ott a slot, amiből kiveszed / berakod a kicsi kártyát, és az egyszerűnek hangzik, de gyanítom, ezek a csatlakozók nem arra vannak kitalálva, hogy pld kísérletezési időszakban naponta ezt valaki 30x eljátszadozza. Szerintem mechanikailag ilyesmitől az sd slotok egyszerűen csak kinyúvadnak. Mobil telefonosok is panaszkodnak alkalmasint, hogy kontakt hibás a kártya csatlakozójuk, és párszot rá kell csapkodni, pedig ők összesen ha 2-3x nyúlnak hozzá évek alatt. Mindössze ebből gondoltam, hogy gyengusz az az MMC slot.

Pld ha gyakorlati felhasználásra kerülne egy ilyen cuccos, mittudomén autó elektronika. Folyamatos környezeti rezonancia + erős hőmérséklet változások együtt. Fogalmam sincs, mennyit bírna.

De ha van direkt mechanikai bravúrnak tervezett mmc slot, az tényleg tuti lenne. Létezik olyan?



Gory:
Néztem a pandaboard-ot. High-end kategóriás multimédia játéknak lett tervezve, nem ledes játéknak. Videózni / renderelni én már tényleg nem terveztem. Szerintem beérem egy beagle-el.

Létezik "ráhajtható" fedeles, reteszelt microSD slot.
Másrészt szerintem ezt "fallback" megoldásnak érdemes tekinteni, amikor az ember elpusztítja a rendes flashbe rakott bootloadert. Normál fejlesztésnél nincs arra szükség, hogy a bootloadert újraírja az ember minden alkalommal, ezért ha csak 1000 alkalmat bír egy ilyen slot, az is bőven elég - szerintem.
Azt viszont nem tudom, hogy pl. egy sima push-push SD slot mennyire "fogja meg" a kártyát, és mit csinálna egy autóban... az autó amúgy sok szempontból nagyon extrém környezet.

Olyan microSD slotokról tudsz adni linket? Az ilyesmi nekem mindig csemege.

A boot device-ok között szerintem is nyugodtan bent hagyhattak volna legalább egy akkora eeprom-ot, mint a belső sram. Ez most olybá tűnik, mint egyfajta politikai döntés, amivel végleg kiiktatták a jtag-ot, mint kötelező felszerelést. Nekem sincs róla gőzöm sem, miért fájt a ti-nek egy belső flash, amit beraknak a boot sorrend legvégére, és gyárilag abba rakják bele a dead loop-ot utolsó választásként. Esetleg úgy kitömték azt a szerencsétlen a8-at belülről, hogy már egy 64k-s flash-nek sem maradt elég hely?

Gondolom annyira azért nem olcsó mindenféle memóriákat csak úgy beletenni. Amúgy meg egyszer beleraksz pl egy uboot-ot a proci melletti memóriába, és onnantól kezdve mondjuk ethernetről azzal bootolsz vagy bármi más alkalmasról.

A Cortex azért nem folyik a csapból, mert azt másra használják, nem telefonokba meg multimédiára és nem olyan látványos. Ettől függetlenül jó cucc. Attól függ mire akarod használni. Hozzám például közelebb állnak, sokkal hardver közelibb dolgokra használják mint az application processzorokat. Egy A8-ra vagy A9-re ráraksz egy linuxot és abban fejlesztessz. Egy Cortex M3 más világ, teljesen más megközelítés. El kell dönteni mi a cél és ahhoz kell a procit megválasztani.

Bővebben: Link
Bővebben: Link

Ne vicceljünk már... Ha egy magyar boltban a 16Mbites (2MB) soros flash nettó 140 forintért megvehető kiskerben, akkor nehogymár 128-512KB-nyi flasht rárakni pluszban $.10USD-t meghaladó költségként jelentkezzen a chipgyártónál...
Az inkább magyarázat lehet, hogy egyszerűen azt gondolják, nincs rá szükség, annyi perifériáról tudnak amúgy is bootolni.

Lehet, hogy csak 1 cent, de ha nem feltétlen kell bele, az is felesleges költség. Másrészt egy tokozott tucat flash felhasználói árából én nem vonnék le messzemenő következtetést arra vonatkozólag, hogy valójában mekkora költség is a sziliciumra rátervezni azt a plusz memóriát. De ez off topic.

Linkek köszönöm! (Cool!)

Nand flash-t illetően az a sanda gyanúm van, hogy amúgy is szeretnek a nand bitek billegni (nem a semmiért van teletömve hibajavítóval az a szerencsétlen), és ez csak tovább romlik egy olyan szöcske belsejében, ami amúgy is 960 mhz-et "tart kéznél" usb 2.0-t clockolni. De nem utolsó sorban minden belső periféria fél ghz környékén ketyeg. Van rá egyáltalán bárhol is példa, hogy működőképesre meg lehet csinálni ?

Más, Cortex adatlap.

Ilyesmit találtam rajta, hogy "I/F" és "SCR2". Az "I/F"-ről sejtem, hogy az "interface" szleng-rövidítése az angolban, de az scr2-t sehol sem lelem. Valami only processzoron belüli adat átviteli perifériának kell lennie. Tudni lehet erről a rejtélyes adatátviteli közegről, hogy kb hol lehet az átlagos adatátviteli képessége kategóriában? Kbit/s, mbit/s, gbit/s, mégtöbb?

Arm-ban még túlságosan kezdő vagyok véres pengét megfogni. Alapvető dolgokkal is csak lassan jövök tisztába adatlapok olvasgatása közepette (így is szanaszét van fáradva az agyam, ennél is gyorsabban nem tudok új ismereteket befele tömni a szellemi egészség peremfeltétele mellett). Sok lenne az nekem még. De ami azt illeti, a száznyi periféria között a cortex-m kategóriában éppen csak a pruss (http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_...system) hiányzik, és perpill még ez (és vonatkozatai) kötik le minden figyelmemet. A fene tudja, ez az egy valahogy nagyon csemegének tűnik.

Hát ez megint attól függ szerintem milyen célra akarod alkalmazni. Mint említettem a Cortex M sorozat egész más célra van mint az A, vagy a linkben is emlegetett AM1808. Annyi a közük kb hogy az ARM fejleszti az architektúrát. De még gyártónkként is vannak különbségek például perifériák tekintetében az azonos core-ra épülő családok közt. Egy másik alapvető különbség az Application processzorok javára hogy MMU (memory managemnet unit) sincs a cortexekben ahhoz, hogy egy WinCE vagy Linux OS tisztességgel fusson rajta. (Most nem uCLinux és hasonló beágyazott Linuxokra gondolok) Nem tudom ezt a PRUS-t mire használnád. De gyanítom, ha nem szeretnél oprendszert írni vagy portolni ezekre a processzorokra, akkor nem feltétlen lesz szükséged arra hogy a processzor magokat regiszter szinten baszogasd.
Ha a realtime viselkedés a célod, azt viszont egy cortex is tudja, vannak RT OS-ek dögivel rá. Szóval először találd ki az irányt és utána kezdj bele szerintem az adatlapok regiszter szintű "megtanulásába".

Az a dögivel van rá dolog érdekelne ethernet stack vonatkozásában. Ami azt illeti, azt az rtos dolgot talán hagyjuk is ki belőle, mert az nem kell. Ha magát a magot fogom meg, nem szeretem a liba-sza*t.

Sima open source stack kellene az internal emac-hez. Valami phy majd lesz mellé, gondolom a stack-ben opcionális. Pic platformon simán csak ott az mc free open source stack, de arm platformra is kellene egy olyan - ha csak nem akarom az emac-et kukába dobni és spi-vel csatolni az arm szöcskéhez is az encx24-est. Viccesen mutatna.

Én nem vetném el egy OS használatát. Nem tudom mit akarsz magán a magon megfogni, vagy egyáltalán mit értessz alatta. IP stackre ami ingyenes és van stand-alone meg OS fölé való változata az például az LwIP. STM32-es procikra van az biztos és szerintem egész jól használható. A nagyobb kategóriás procikra ugye van Linux, amiben van ethernet stack, azokat nem emlegetem.

Eth stack-ekből megtaláltam az lw-t, de hiányzik belőle legalább egy egész mappa ("netif/" ott van az include-okban, de a zip csomagban nincs). Éppen abban van az output().

Találtam egy uIP-t, amiről régebbi net cikkek áradoztak, de most sehol nem találok download linket, csak egy híreket, hogy valami contiki-be be lett építve.

Valami nitche stack-re is ráakadtam, de letöltésnél csak elkérte az adataimat, és azt mondta 404, cool..

Innen töltötted le? (pl. Iwip-1.4.0.zip)

Az uip-1.0.tar.gz névre keress rá. Talán itt lesz... Már nem emlékszem, hogy honnan tudtam letölteni.

Igen, onnét. És ne aggódj a uip link miatt sem (nem működik). Szóval ez egy kicsit döcög. Esetleg vissza a kályhához. Mondjuk kicsit hagyjuk félre a community stack-eket. Feltételezem, ha emac van egy arm szöcskében, akkor van a gyártónak supportja legalább raw packet kezeléshez. Nem olyan bonyolult dolog egy ethernet. Felconfigolni a regisztereket, aztán stream befele fogadja a csomagokat / kirakja valahova memória bufferbe, stream kifele nyomja a csomagokat valahonnét memóriából. Buta kicsi csomagok preamble, sync, dest addr, source addr, packet lenght, data, checksum, slussz. Első körben legyen csak ipv4 és hagyjuk az emacs extra szolgáltatásokat. Csak sys init és suttyó buta raw packetek. Tuti nem az első ember vagyok a világon, aki ilyesmi után kotorászik.

Pld van a Stellaris Cortex-M3-ban is ethernet (ott még a phy-t is integrálták), gyanítom, kompatibilis minőség. Ott hogyan szokás beéleszteni a netet?

Van a TI-nek media Wiki-je, de oda beírtam egy kereső kérdést, és 63 ezer találatot dobott ki - halom szemetet. Van arm platformhoz valami support fórum / rendezettebb tudásbázis valamerre neten ?

De abban benne van az általad hiányolt netif mappa. Akkor mi hiányzik?
Innen lejött (a zöld animált nyilakra kattintva).

A Free-RTOS TCP/IP demók is UIP-t vagy lwIP-t használnak. A főbb kategóriákra (ATMEL, Freescale és különféle Cortex-M3-ra vannak TCP-IP demók). Ott is érdemes szétnézni.

Ehhez van egyrészt az előző hozzászólásomban említett Free-FRTOS demó, másrészt van a Micrium uP/TCP-IP demo amihez letölthető könyvet is találsz. Valami svédség azért van, talán a uC/OS-II vagy uC/OS-III könyvet vagy valami hasonlót nem kapsz meg ingyér...

Mea culpa, az én scriptjeim hibáztak, azt meg nem tudom, miért nem láttam a szememtől, amikor kerestem a netif-et.

Az adott linkről lejött a uip stack, köszönöm.

Hi!

STM32F207VG Keil 4.53, és ULINK2. Miért van az, hogy Debug-ot indítva megáll ugyan a main függvénynél, de amint az első soron single step lenne, megcsinál vagy 5 utasítást egy lépésben, majd párszor megy a single step ahogy kell aztán megint 2-3 utasítás egyben.
A programom egyébként a szokásos nagyon egyszerű, a = 1, b = 2, c = a +b csak hogy lássam működni. A program system_stm32f2xx.c-vel kezdődik, HSE és a PLL rendesen beálltva 120MHz-el fut a mag, szóval minden ahogy a nagykönyvben. Közben ugyan ez a móriczka program gond nélkül single step egy LPC1768-on... Ötletek?

Nekem ez optimalizációnak tűnik.