[elektro] ARM megint

[Horvath Janos]

Szia!

> Az igaz, hogy 8 bites procira is van lebegőpontos könyvtár, de
> nem szeretnék vele bajlódni. A hw bufferelési támogatása pl.
> nagyon  jól jön, ha mondjuk 128k-val csorog be az adat folyamatosan és
> formátumot, CRC-t kell számolni, kiértékelni. Itt nem 100 karakterről
> van   szó.   A  legfőbb  ok  az  ár/flash  méret  szokott  lenni.  ARM

> hátrányaként a megszakítások kezelése ami hw nyűg, mig 8bitesen
> kis időeltolással biztosan jön és direkte vannak utasítások amik a
> flaget nem változtatja (ide  nagyon  pöpec), addig az ARM rakás
> regisztert ment, viszonylag sok hwidőt kíván.
Ahogy kezdő pupákként nézegettem, elég kiélezett INT kiszolgálásnál
jelenthet szerintem hátrányt. 6 órajel alatt push-ol.
Ami talán érdekes volt nekem, hogy ha magasabb INT alatt befut
egy alacsonyabb, akkor a magasabb végrehajtása után POP nélkül
egyből elkezdi végrehajtani azt is (INTbe fut a másik INT)
és majd a végén POP-ol. Azért általában használok pár regisztert,
úgy is PUSH-olni kellene...ha csak nem 1 portbit gyors billenése
a cél.

> Ezután a gyártmányokba a flash védelem/lekódolhatóság, és a belső
> újraprogramozhatóság ami számít. 8bitesen fix területek vannak,
> én speciel nem szoktam beleférni :), ARM-nél dinamikusabban
> kezelhető. A perifériák szolgáltatása is bővebb, fejletebb.
> Nem igazán van idő bittologatásra fejlesztések alatt, pedig imádom.
Nem tudom, PIC32-nél hogy van, de ARM-nél nekem nagyon
tetszik az alsó 32MB bitcímezhetősége, ej, amikor PLC-t szobortam,
milyen jól jött volna egy ilyen.


> Ja, és az ARMnél a kis tokosak is felhúzhatóak soksok MHz-re, több
> fajta ébresztési móddal. Persze ez már összehasonlítás kérdése.
> A lábkonfignál nekem nagyon bejött a konfigolható fel-le húzás,
> opendrain, vagy nemistom hogy hívják...amikor ott tartja a bemenetet
> aktívan.
Bus-hold... asszem...

> Hátránya, hogy egy hw timer OD kimenetét pl nemtom
> visszaolvasni (DS18xx kezelés),
Ez mi ez? (csak kérdezem... okosodni akarok)

> viszont az RS485 irányváltásáról
> kapok megszakítást. Szóval nézőpont kérdése. :)
>> Kérlek benneteket, ne indítsunk hitvitát, tényleg komolyan kérdezem,
>> miért ARM, amikor látszólag egy PIC bőven tudja ezeket? Mi az, amit csak
>> az ARM tud?

Cimbora váltott PIC32-re, beültető automatát ácsol,
nagyon meg van elégedve  80MHz-en, ott mindenre elég.
(eddig)
Pedig Őt is a hideg rázta, ha meghallotta, hogy PIC.
Szóval nehéz dönteni, adott feladatnál lehetne
összehasonlítást csinálni (ár/munkaóra/szívás az errata-k
miatt, fordító bugok stb.)

JAni



>> Vagy inkább úgy kérdeném, ha valaki beleásta magát egy-egy
>> gyártmányféleségbe, írja már meg, mi az, ami különlegessé teszi a
>> többihez képest? Bizonyára többen is örülnénk egy ilyen összehasonlítási
>> lehetőségnek.
>
>> Köszönettel
>> pi
>
>
>> ----- Original Message -----
>> From: "Fuzesi Arnold" <arnold.fuzesi.lista at gmail.com>
>> To: <elektro at tesla.hu>
>> Sent: Tuesday, September 17, 2013 7:52 PM
>> Subject: Re: [elektro] ARM megint
>
>
>> Csecse, thx, alakul! :) Megbujt ezzel az eeprom emulalas dologgal.. de
>> vegul is
>> az is teljesen jo.
>
>> Mondjuk az hogy 1db SPI-je van még mindig visszalépés az atmel-nel az
>> usart-bol
>> is lehet buta SPI-t csinalni dologhoz kepest...
>
>> De legalabb van clockout (ami lehet megsem olyan mint kene legyen, de
>> egyelore
>> nem akarom lehuzni :), meg RC osc, ami eleg ritka okossag.
>> Meg csomo klassz plussz feature, mint FIFO, DMA, egyedi ID stb.
>
>> Egesz hasznalhato darabnak tunik... de meg mindig nem felhőtlen az
>> örömöm, atmel
>> úgy tűnik nagyon bebiztosította magát nálam azzal, hogy 1-2 klassz
>> dolgot csak ő
>> tud. Van jopar alkalmazas ahol nem tudnam ARM-mel kivaltani, kellene
>> melle
>> plussz cucc, ami elkeserit kicsit.
>
>> A.
>
>
>> -----------------------------------------
>>            elektro[-flame|-etc]
>
> -----------------------------------------
>            elektro[-flame|-etc]
>