[elektro] MCHIP kontra ATMEL

Lajos Rancz lajos.rancz at gmail.com
Tue Jan 19 07:20:48 CET 2016


Helló!

Én értettem eddig is amit mondtál; de még mindig nem magyaráztad meg, hogy
a sok periféria + RISC + tömör kód hogy mond ellent? Vagy azt javaslod amit
a Szabolcs írt, hogy mindenre legyen külön utasítás memóriába ágyazás
helyett? Ennek sem látom nagy előnyét.

Üdv

2016. január 18. 17:04 L. Pásztor írta, <seasoft at invitel.hu>:

> Nem azt mondtam, h a nem RISC-nek van előnye a RISC-el szemben, azt
> mondtam, h a nagyszámú behuzalozott periféria, a RISC és a tömör kód
> egymásnak ellentmondanak.
> Meg azt, h ha rajtam múlna a RISC architektúrát hagynám el a másik kettő
> javára.
>
> ----------------------
> L.  Pásztor
> ----------------------
>
>
>
> 1/18/2016 3:48 PM keltezéssel, hg12345 írta:
> > "L. Pásztor" <seasoft at invitel.hu> írta:
> >> És én a sok behuzalozott periférában látom a hatékonyságot.
> >> A sok behuzalozott periféria, a RISC, és a tömör kód ellentmondanak
> >> egymásnak.
> >> Én a RISC-et hagynám el ...
> > azért kiváncsi vagyok mi előnye van egy nem RISC uC-nek?
> >
> >
> >> ---------------------
> >> L. Pásztor
> >> ---------------------
> >>
> >>
> >> 1/18/2016 3:07 PM keltezéssel, Lajos Rancz írta:
> >>> Helló!
> >>>
> >>> Akkor egyetértünk: kb senkit nem érdekel az architektúra csak a chip
> >>> tervezőket és a compiler írókat. RISC-re könnyebb sok minden (v.ö.
> Single
> >>> Instruction Computer:
> >>> https://en.wikipedia.org/wiki/One_instruction_set_computer).
> >>>
> >>> Üdv
> >>>
> >>> 2016. január 18. 15:02 L. Pásztor írta, <seasoft at invitel.hu>:
> >>>
> >>>> Én úgy értem:  ma már nem az a hatékony, ami kis memóriában elfér és
> >>>> gyorsan fut.  Amiben kezdtünk, a 8 megás órajel és 8k-s memória
> >>>> világának lassan vége ... az idő lett a legértékesebb.
> >>>> Lehet ezért sokan megköpködnek, de sztem az 512k memória világában, és
> >>>> 150MHz-es órajelek mellett tökmindegy mennyire "hatékony" v "kicsi" a
> >>>> lefordult kód, vagy mennyire az a compiler, ha az egyébként helyesen
> >>>> fordít. Nálam (és úgy látom sok más helyen is) a hatékonyság kezdi azt
> >>>> jelenti, h 1-1 project mennyi idő alatt van kész, és összesen mennyibe
> >>>> kerül ...
> >>>>
> >>>> ----------------------
> >>>> L. Pásztor
> >>>> ----------------------
> >>>>
> >>>>
> >>>>
> >>>> 1/18/2016 2:52 PM keltezéssel, Lajos Rancz írta:
> >>>>> Hi!
> >>>>>
> >>>>> A "nem RISC-es"-t abszolút nem értem. Fordított (nem assembly) nyelv
> alá
> >>>> az
> >>>>> a hatékony.
> >>>>>
> >>>>> üdv
> >>>>>
> >>>>> 2016. január 18. 14:02 L. Pásztor írta, <seasoft at invitel.hu>:
> >>>>>
> >>>>>> Ok, ok, csak azt nem tudom örüljek-e ennek ...
> >>>>>> Egyébként 5letem sincs minek kell nekik az Atmel?
> >>>>>> - az Atmel-hez kell-e majd az MPLAB ?
> >>>>>> - vagy az Atmel memórát is lapozhatóvá teszik ?
> >>>>>> - esetleg a mikrocsip lesz majd Atmel-árfekvésű ?
> >>>>>> :(((
> >>>>>>
> >>>>>> Sztem kéne már egy egészen új, de nem RISC-es controller, sokféle
> >>>>>> tokban, sok behuzalozott funkcióval, jó RTOS-sel, jó IDE-vel és jó
> >>>>>> compilerrel.
> >>>>>> Amin és amivel gyorsan lehetne fejleszteni, mert a málna és tsai
> csak
> >>>>>> játékok, nem megoldás és nem is alternatíva egy jó controller és
> >>>>>> környezete helyett ...
> >>>>>>
> >>>>>> --------------------
> >>>>>> L. Pásztor
> >>>>>> --------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 1/18/2016 1:39 PM keltezéssel, hg12345 írta:
> >>>>>>> Megoldódik... MCHIP felvásárlási ajánlatot tett az ATMEL-re :-)
> >>>>>>>
> >>>>>>> -----------------------------------------
> >>>>>>>               elektro[-flame|-etc]
> >>>>>> -----------------------------------------
> >>>>>>              elektro[-flame|-etc]
> >>>>>>
> >>>>> -----------------------------------------
> >>>>>              elektro[-flame|-etc]
> >>>> -----------------------------------------
> >>>>             elektro[-flame|-etc]
> >>>>
> >>> -----------------------------------------
> >>>             elektro[-flame|-etc]
> >> -----------------------------------------
> >>           elektro[-flame|-etc]
> > -----------------------------------------
> >            elektro[-flame|-etc]
>
> -----------------------------------------
>           elektro[-flame|-etc]


More information about the Elektro mailing list