[elektro] ARM ugrás

Mon Jan 25 22:58:34 CET 2016

Szia!

Kb. én is ezen agyalok, hogy mennyivel lesz stabilabb az általam itthon gyártatott (pláne BGA-ás !!) kütyü.
És  most arra gondolok, hogy nem mi forrasztunk, hanem valamelyik ültető céggel.
(rossz tapasztalatunk, hogy egy pár 100 db-os szériában (természetesen ólom mentes) QFN tokok 20%-t újból kellet melegíteni) 
Sajnos ez a demoboard tartalmaz jó pár számunkra felesleges csatit, funkciót.
Illetve  az 1MB Flash kevésnek tűnik (képek / hangok), de itt ezt kompenzálhatja az SD kártya.
Viszont nem tudom, ha gyártatni kell a BGA-t tudják itthon ültetni?

A PIC32MX-t bajain már túlvagyunk, gondolom a PIC32MZ-is nyújt majd néhányat.
PIC32MX / MZ szimpatikus, hogy a 200Mhz ua. 80mA-t fogyaszt, mint a 80Mhz, ha jól látom.

Hát nem tudom, jó nagy dilemma, még van kb. 1/2 év agyalni rajta!

FI. 

-----Original Message-----
From: elektro-bounces at tesla.hu [mailto:elektro-bounces at tesla.hu] On Behalf Of elight
Sent: Monday, January 25, 2016 9:24 AM
To: elektro at tesla.hu
Subject: Re: [elektro] ARM ugrás

Szia,

én azt hallottam,

kapac touch-ot általában ipari környezetbe nem teszünk!
A többi része is gondolom oktatási kategóriájú..
de ettől még lehet jobb, kiforrottabb
mint az , amit az ember itthon össze tudna tákolni.

Üdv István

2016-01-24 09:58 keltezéssel, hg12345 írta:
> ingyenes pl.:
> https://developer.mbed.org/platforms/ST-Discovery-F746NG/
> Amúgy minden ARM-s fejlesztői környezet jó, amiről a listán szó volt.
>
> Nem tudom, és nem is akarom minősíteni ezeket a termékeket, de ezek DEMO boardok, ha ipari környezetben (masszívan nagy elektromos zajos környezet) a felépítéséből adódóan lehetnek problémák.
> Ezek valószínűsége csökkenthető a csatlakozási pontok megfelelő kiépítésével, de a nem kivezetett uC lábak miatt ez 100%-osan nem tüntethető el.
> Egy megfelelő környezeti tesztüzem próbán sok minden kiderülhet..
>
>
>
> fi F <flaist at gmail.com> írta:
>> Szia!
>>
>> http://hu.farnell.com/stmicroelectronics/stm32f746g-disco/dev-brd-stm
>> 32f746ng-cortex-m7/dp/2480961
>>
>> Nézem ezt a demó board-ot, nagyon brutál, az ár / tudás arány.
>> ~100-as szériánál  meg sem lehet közelíteni, saját gyártással.
>> Eddig PIC32MZ-t használtunk, de drágább a saját gyártású, kisebb tudású HW-ünk.
>> Most akartunk PIC32MZ-re átállni, de ha ezt kapni pár évig, akkor nem érdemes.
>>
>> Milyen környezet kell, hogy fejleszteni lehessen rá?
>>
>>
>> FI.
>>
>> -----Original Message-----
>> From: elektro-bounces at tesla.hu [mailto:elektro-bounces at tesla.hu] On 
>> Behalf Of elight
>> Sent: Friday, January 22, 2016 12:26 PM
>> To: elektro at tesla.hu
>> Subject: Re: [elektro] ARM ugrás
>>
>> Ne tedd.
>> ( mármint félre azt a kedvedet : )
>>
>> Helyette szerintem első lépésben,
>> úgy ismerkedésileg töltsd le:
>> http://www.mikroe.com/mikroc/arm/
>>
>> ingyenest, kezdetben elég lesz ez is
>> azután mehetsz tovább más IDE-k,
>> libraryk felé.
>>
>> Szerezz modnjuk egy kicsi discoveri modult:
>> http://www.aliexpress.com/store/product/STM32VLDISCOVERY-STM32F100RB-
>> STM32F100-STM32-Evaluation-Development-Board-Discovery-Kit-Embedded-S
>> T-Link/216233_699394601.html
>>
>>
>> Telepíts egy ST-link utilitit hozzá.
>> Én a proc leírását is átfutottam előtte, annyira , hogy képbe kerüljek kicsit.
>>
>> És már minimum szinten készülhet
>> a tanuló programod.
>> Tápot USB-ről kapja, csak kapcsolót , ledeket vagy displayt kell hozzákötnöd esetleg.
>>
>> De ha szükséges küldhetek mintát,
>> amelyik a protokat birizgálja,
>> és alap dolgok vannak benne
>> ( ja és hibátlanul elsőre betölthető, nem kell hozzá egyéb library 
>> meg bármi bűvészkedés. )
>>
>>
>> Üdv István
>>
>> 2016-01-22 11:44 keltezéssel, Karoly Kovacs írta:
>>> Srácok!
>>>
>>> Úgy belemásztatok az ARM finomságokba, hogy teljesen elment a kedvem.
>>> :)
>>>
>>> Komolyan: Ti már - úgy látom - nagyon szakik vagytok a témában, 
>>> nehéz követni, amit írtok. Ez persze annak köszönhető, hogy e téren 
>>> még igen zöldfülű vagyok (sőt, mind a két fülem zöld).
>>>
>>> Károly
>>>
>>> hg12345 wrote:
>>>> Hi
>>>> a probléma nagyon egyszerű, csak egy kicsit komplikáltan 
>>>> fogalmaztam,
>>>>
>>>> a legtöbb FLASH elérési sebesség 25-30MHz efelett már wait-ek kellenek a hozzáféréshez (kivéve valamelyik japán gyártóé, ahol ez a sebesség 60MHz). Amikor folyamatosan fut a program egy ennél nagyobb sebességű uC-ben akkor hiába nagy a kontroller sebessége a program lépésre várakozás lassítja az utasítás végrehajtását. Mivel az ARM load/store felépítésű eszköz, azok az utasítások amik a uC "kinyúlnak" mér több óra ciklust igényelnek, ilyen esetekben az a sebesség csökkenés nem lenne jelentős, de a belső utasítás végrehajtásoknál már igen.
>>>> Ennek áthidalására találták, ki hogy szélesebb FLASH eléréssel és két soros bufferen keresztül olvassák a memóriát. Így ez a megfogás szinte észrevehetetlen tehető.  A FLASH általában (64)128 bites vagyis egyszerre 4db 32 bites vagy 8db 16 bites utasítást olvas soronként bufferbe. A két buffer esetén az a duplája.... Így elenyésző sebesség csökkenéssel lehet a programot futtatni.  Persze minél nagyobb a különbség a uC és FLASH között annál nagyobb lehet a sebesség csökkenés, azoknál a programoknál ahol ez problémát okozhat, közvetlenül csatolt memóriában (RAM) lehet a programot tölteni és innen futtatni, ez a memória csak töredéke szokott lenni az eszközben találhatónak.
>>>> Szerintem egy 8 bites rendszerből fellépő alkalmazásnak ilyenre 
>>>> sohase lehet szükség :-()
>>>>
>>>> Az alkalmazásra több lehetőséged van,
>>>> - elvei erre a címterületre fordítod a programot és induláskor 
>>>> feltöltőd,
>>>> - olyan programot írsz ami memória független futású
>>>> - ha a rendszer tartalmaz MMU akkor bármely fizikai memória részhez akármilyen címet tudsz rendelni, így ha tudod, hogy a programod milyen címterületre lett fordítva az MMU-val alá rendeled a címeket.
>>>>
>>>> De a legjobban akkor jársz, ha veszel egy CORTEX  M7 ami már 1...4K 
>>>> memória CACHE rendelkezik, és emiatt szinte mindegy milyen 
>>>> területen található az éppen futó program
>>>>
>>>>
>>>>
>>>>
>>>> Moravcsik Szilard <levlista.mszilard at gmail.com> írta:
>>>>> Szia!
>>>>>
>>>>> Azt írod:
>>>>>
>>>>> "...mivel mindegyik csak RAM-ból képes közvetlen és teljes 
>>>>> sebességű utasítás végrehajtásra..."
>>>>>
>>>>> Ezek szerint ha teljes sebességű utasítás végrehajtást szeretnék, 
>>>>> akkor valahogy a lefordított és flash-ben (vagy valami háttér 
>>>>> táron) tárolt bináris kódot a RAM-ba kell másolni a boot során?
>>>>>
>>>>> De a belső RAM azért ehhez sokszor nem elegendő kapacitású.
>>>>> Ilyenkor teszel rá valamilyen külső RAM-ot és bootoláskor oda 
>>>>> másolod a kódot majd valahogy onnan indítod az utasítás 
>>>>> végrehajtást (ez a címbeli ARM ugrás :DDD)? Vagy hogy is van ez? 
>>>>> :)
>>>>>
>>>>> Egyelőre csak a kíváncsiság miatt kérdezem, mert látom, hogy nálam 
>>>>> sokkal többet tudsz az ARM-okról. Szóval ha majd lesz időd... :)
>>>>>
>>>>> Üdv:
>>>>> Szilárd
>>>>>
>>>>> 2016.01.22. 8:54 keltezéssel, hg12345 írta:
>>>>>> Hi,
>>>>>> igen, de LINKER nélkül egyik se működik, közvetlen memóriába fordítású asm-ról nem tudok.
>>>>>> Minden C fordítónak  GCC és a KEIL-s van önálló ASM fordítója.
>>>>>>
>>>>>> Ha kicsit összetettebb programot szeretnél írni, akkor inkább használj C-t!
>>>>>>
>>>>>> Biztos lehet tömörebb és gyorsabb kódot írni közvetlen programozással, de apró pénzért kapsz nagyobb memóriájú eszközt és hasonlóan gyorsabbat is. De a legtöbb ilyen uC 48Mhz-ről indul...
>>>>>> Ha nagyon sebességre hajtasz, akkor itt ez nem olyan egyszerű. mert ugyan az az utasítás címzéstől függően 1...6 óraciklus alatt mehet végbe, arról nem is beszélve, hogy mivel mindegyik csak RAM-ból képes közvetlen és teljes sebességű utasítás végrehajtásra, FLASH-ből csak bufferen keresztül, ezért amire számítasz az akár lassabban is történhet, és még a DMA miatt busz hozzáférés megosztás miatt futási sebesség változásról nem is beszéltünk.
>>>>>> Maga az ASM és az gépi kódú utasítások is elég összetettek, és nem homogének, a THUMB utasítás készlet hasonlóan a legtöbb 8 biteshez, két operandusos, míg a normál és THUMB32 bites utasítások 3 operandusossak, a legtöbb operandust még lehet indexelni, és post vagy pre-incrementálni, az növelés csökkentés szinkronban van a hozzáférés szélességével... A blokkos beolvasás és töltésnél regiszterenként lehet állítani, hogy melyik regiszterre legyen érvénye "16 univerziálisból" persze ebből 3 foglalt. A teljes méretű konstans megadás nem létezik (32bites), ezt általában PC relatív címzéssel olvassák be, a program részletek között tárolják.
>>>>>>
>>>>>> Szóval érdemes a C felé kacsingatni, sokkal gördülékenyebben lehet vele dolgozni.
>>>>>>
>>>>>> A CORTEX magokat úgy hirdetik, hogy nem kell hozzá ASM betét, és ez tényleg igaz!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> VFX <info at vfx.hu> írta:
>>>>>>> Hali!
>>>>>>>
>>>>>>>
>>>>>>> Engem meg az érdekelne, hogy ARM-re létezik-e önálló assembly fordító?
>>>>>>> Van-e olyan, hogy nem kell egy halom valamit feltelepíteni csak 
>>>>>>> 1 vagy 2 db exe és fordul is, hasonlóan, mint avr-hez az 
>>>>>>> avrasm2.exe
>>>>>>>
>>>>>>> ÜDV. VFX.
>>>>>>>
>>>>>>>
>>>>>>> 2016.01.21. 11:40 keltezéssel, elight írta:
>>>>>>>> Sziasztok...
>>>>>>>>
>>>>>>>> Nemrég írtátok , hogy előbb utóbb megugranátok az arm felé.
>>>>>>>>
>>>>>>> -----------------------------------------
>>>>>>>              elektro[-flame|-etc]
>>>>>>>
>>>>>> -----------------------------------------
>>>>>>               elektro[-flame|-etc]
>>>>>>
>>>>> ---
>>>>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>>>>> https://www.avast.com/antivirus
>>>>>
>>>>> -----------------------------------------
>>>>>             elektro[-flame|-etc]
>>>>>
>>>> -----------------------------------------
>>>>              elektro[-flame|-etc]
>>>>
>>> -----------------------------------------
>>>             elektro[-flame|-etc]
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]

-----------------------------------------
          elektro[-flame|-etc]