[elektro] ARM ugrás

Ábrahám Gábor agabor2 at freemail.hu
Mon Jan 25 23:51:38 CET 2016 

Szia!

Albacomp nekünk elég sok 1mm-es meg 1,24-es osztásút ültetett, nem volt 
velük probléma.
A sűrűbbnél sem a BGA a gond, hanem a hozzá kapcsolódó többi alkatrész.
Pl. egy 0.8-as CPU alá kötelezően lerakandó passzív elemek.
Sem a beszerzés, sem az ültetés nem egyszerű.

Mi sokáig használtunk X86 alapú ETX-es modulokat.
ARM-ban is  biztos valami modulban gondolkodnék, ha néhányezer darabnál
kisebb a széria.

Pl.
http://www.emcraft.com/products/413
http://processors.wiki.ti.com/index.php/Sitara_ARM_MPU_SOM/SBC

Gábor





----- Eredeti üzenet ----- 
From: fi F
Sent: Monday, January 25, 2016 10:58 PM
To: elektro at tesla.hu
Subject: Re: [elektro] ARM ugrás

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]

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

-----
A(z)  üzenetben nem található vírus.
Ellenőrizte: AVG - www.avg.com
Verzió: 2016.0.7303 / Vírus adatbázis: 4522/11485 - Kiadás dátuma: 
2016.01.25.

More information about the Elektro mailing list