[elektro] dsPIC programozás assemblyben

[hg12345]

Hi,
hogy mi a drága az kérdéses, igazából a szilicium felület + tokozást + fejlesztési/licensz + forgalmazást fizeted meg az eszköz árában.
A mostani eszközöknél még a legkisebb tudásúaknál olyan mindegy hogy valamelyik sarokban mekkora helyet foglal a uC processzor része ez a felület kevesebb mint 10% a többi memória és a perifériák, ill feszültség konverterek a programozó debug interface.
Ezért sincs mérvadó különbség a hasonló tudású 8...32(64) bites eszközök között.

Nem véletlen, hogy az elmúlt 10 évben a 4 bites eszközök lassan kimúltak, a nagy sorozatokban is...  

A legkisebb feladatra is azt érdemes használni amihez megvan a tudás és fejlesztő gyártó, környezet. Az idő ami meghatározza az árat.

Ha esetleg befut egy nagyobb feladat, ami már teljesítményt igényel, akkor valószínűleg el kell  mozdulni a 32 bites eszközök felé, ha ez már megtörtént, akkor ez után meg nem érdemes visszalépni... Ebben a körben is sok fajta uC mag létezik természetesen, de nagy előny, hogy a sok gyártó használja az ARM-t, így egy megfelelő fejlesztő környezettel már bármelyik gyártó típusára lehet dolgozni. Azt nem mondom, hogy könnyű az áttérés az egyikről a másikra, (portolás), de nem lehetetlen. 

A kezdetektől (CHIPCAD-nél elsők között)  használtam a MChip termékeit, addig jó is voltak amíg könnyen lehet továbblépni  az eszközökben, de amikor saját magukkal nem voltak kompatibilisak a  reviziók,  és  12, 14, 16, 32 bit es eszközök még köszönő viszonyba sincsenek egymással szerencsére váltottam.  Nem bántam meg. Inkább használok egy $0.30...$0.50  cortex M0 -t TSSOP20-ban esetleg helyszűkében QFN32 4x4 , mint bármely 8 vagy 16 bitest. Szerencsére a termékben nem a kell $0.50 megspórolni. :-())

-------- Eredeti levél --------
Feladó: uprogc < uprogc at gmail.com (Link -> mailto:uprogc at gmail.com) >
Dátum: 2019 január 7 16:00:23
Tárgy: Re: [elektro] dsPIC programozás assemblyben
Címzett: elektro at tesla.hu (Link -> mailto:elektro at tesla.hu)
 
Koltseg dolgok.
Attol fugg milyen alkalmazas. Ha az alkalmazas nem fejlodik, mert nincs
ahova, pl egy sima PWM LED-lampavezerlo, vagy hasonlo, akkor ide nincs
amiert "draga" ARM-ot tenni.
De barmilyen nagyobb projekthez mar megeri dragabb es jobb, tobb
tartalekkal rendelkezo procit tenni, es ezt jo elore meggondolni, mar ha
van projekt terv, ha nem menetkozben alakul az. Mert idovel a portolassal
es kodatalakitassal eltoltott (eltokolt ) ido miatt sokkal nagyobb
veszteseg eri a "befektetot". Raadasul uj panel terv kell, stb.
Lassan vege a kismiska kontrollerek vilaganak, kiveve az emlitett esetet.
Sot lefordithato es konfiguralhato kontrollerek fele fog menni szerintem a
jovo. Igy hat nem erdemes mindenfele ocskavasakkal tolteni az idot. Nekem
is van mindenfele kontrollerem de csak bemutatodarabnak jo, idot nem
szannek ra, egy percet sem.
On Mon, Jan 7, 2019 at 4:43 PM elight <elight at gmail.hu> wrote:
> Jahh?
>
> Az még azért egy könnyű váltás.
> Csak végig kell olvasni betűről betűre
> mind a két adatlapot és egyeztetni ami kell.
> Meg az erratákat is.
>
> Én Pic-ről ARM-ra ugrottam egyszer kényszerből
> egy meló miatt. Meredek volt,
> rengeteg ismeretlen csapdával teletűzdelve.
> Szóval alaposan kifutottam a tervezett időből.
>
> Nemrég pl. pedig RASPI-n kellet megoldani
> egy külső videomemória kezelését.
> Ott sikerült elérnem 8 millió I/O/sec sebességet
> egy szerény programfutási időre.
> Ennél a legtöbbet az összes többi futásidejével
> (kordába tartás) kellet szöszölni
> hogy legyen elég időkeret.
> Mert párhuzamosan a display rutinoknak is kellet
> némi lehetőséget adni, minimum amennyit
> azok megkívánnak.
>
> Szóval lehet bíbelődni ilyesmivel is,
> és akadnak bőven lehetséges alternatívák.
> Igaz a mondás: ágyúval verébre se szokás,
> de ugyanakkor egy elhibázott költségoptimalizálás
> később programozói oldalról alaposan
> megszívathatja az ember.
>
> Üdv István
>
>
> 2019-01-07 15:25 keltezéssel, Pipi írta:
> >
> > 2019.01.07. 15:16 keltezéssel, elight írta:
> >> +1
> >>
> >> ha mégis,
> >> ...max. 3-4 inline sor ASM.
> >>
> >> És inkább használd ki maximálisan a hardver
> >> adottságokat, többszintű INT, DMA és egyéb finomságok...
> >> Vagy válassz egy nagyobb, gyorsabb MCU-t.
> >
> > Ja. Az alacsonyabb ár miatt most próbálunk áttérni a pic16f18876-ra,
> > van benne egy csomó csilivili (ami nekünk nem is kell) plusz funkció,
> > meg egy csomó új regiszter
> > és "megkönnyítendő az átállást" persze hogy még az azonos funkciójú
> > bitek jó része is más-más regiszterbe kerültek :(
> >
> >
> >
>
> -----------------------------------------
> elektro[-flame|-etc]
>
-----------------------------------------
elektro[-flame|-etc]