www.elektronik.si

[.]

Brisana vsebina odstranjenega uporabnika.

[Proteus]

Nekako nimam v malih požganih povezave C++ skupaj z mikrokontrolerji.

Razkošje, ki ga nudi ARM, seveda nudi nekaj več umetniške svobode, bojim se samo, da se nam ne bo zgodila nova Windows - PC verižna reakcija.

start:
nov SW (rabi zmogljivejši HW)
nov HW (kar kliče po novem SW)
goto start

Če samo pogledam, kako se je razpasel Delphi.

[Sokrat]

Mikrokontroler je precej raztegljiv pojem - od braindead malih igrack, ki sluzijo priziganju LEDic ob pritisku tipke do (vsaj) 64-bitnih zverin, ki so za faktor ~1000 mocnejse, oborozene z vso mogoco navlako (razni communications controllerji, pa krama za PDAje, itd.). Za slednje se uporabljajo cisto zaresni OSi (Linux, LynxOS, itd.) na katerih delujejo cisto zaresni prevajalniki in nanje lahko prikljucis cisto zaresen monitor na katerem se prikazuje precej zaresen GUI. Tam zna to biti kar prakticno, da lahko program napises z manj truda (bo ze HW prezvecil nekoliko manj ucinkovito kodo) ... za malcke se mi pa to zdi pretiran "bloat". Pri vecjih je temu tako, ker ne more en sam clovek (ali ena sama razvojna ekipa) narediti cisto vsega in je zato potrebno poenostaviti in razdeliti delo; eni sestavijo HW in naredijo driverje, drugi naredijo APIje, tretji pa to uporabijo za aplikacije in tam je cisto jasno, da jih ne bodo pisali v assemblerju; za vse ostalo je pa C++ (oz. pripadajoce knjiznice) precej "masiven".

[Proteus]

Se popolnoma strinjam, toda poglejmo vso stvar z drugega zornega kota, govorimo o ARM-ju, 8031 in raznih "picah".

Še do nedavnega je na forumih tekla debata ASM vs C. Glavna kritika C-ju je bila prav njegova "počasnost" v primerjavi z ASM. Keil je postal tako priljubljen prav zaradi dobrega optimiranja kode.

Podobno je sedaj pri ARM-ju. ASM je sicer že v osnovi pase, toda GNU C-ju gre glavna zamera prav zaradi "nemarno" napisanih knjižnic, ki so dolge in počasne.
Kakorkoli gledam, toda C program pišem na 8031 bistveno drugače, kot pa na kakšnem PC-ju. Optimiranje na vseh koncih je tukaj bolj ali manj nujno, sicer hitro ostaneš brez ram-a ali se pa vsa stvar vleče kot polž.

ARM je korak naprej, ki dopušča več svobode, osnovno vprašanje pa je kaj rabiš.
V trenutku ko rabim OS, podporo za TCP/IP itd... potem jaz še vedno ne razmišljam o ARM-ju, temveč kakšnem starem PC-ju ali kakšnem mini PC-ju na katerega naložiš vso šaro. Praktično si integrator in ne programer. Da o prihranku na časa ne govorim.

Mobilni telefoni, PDA-ji itd... pa so druga zgodba, ki jo tozadevno nisem imel v mislih.

[.]

Brisana vsebina odstranjenega uporabnika.

[Proteus]

Na netu najdeš bistveno bolj obsežno kodo (v C-ju), kot jo lahko kdajkoli strpaš interno v en sam CPU, pa jo kljub temu razvija kup ljudi. Tako da to nebi štel ravno kot razlog za uporabo.

Stvari se bodo drastično spremenile šele, ko boš lahko na ARM-ju vrtel kakšnega od operacijskih sistemov. Takrat se bom, vsaj jaz, začel spraševati, kako naprej.

Problem dinamično kreiranih struktur v memoriji je tudi to, da jih težko nadzoruješ. Kako veš, koliko rama zasedaš, še posebej če operiraš s knjižnicami tretjih oseb. Takoj se ti pripelje dodatna koda samo zaradi varnosti.

V neki aplikaciji, ki je samo črna škatla s par led diodami in kupom drotov v ozadju se ti nenadoma pojavi problem. Že videno in to pri profesioanlni aplikaciji komunikacijskega vmesnika. "Memory overflov" ti lahko pri takih aplikacijah posivi lase. Še posebej ko doma vse lepo dela na terenu, bogu izza leđa pa $%#/"

Pa ne me razumet, da sem proti, kajti to je definitivno prihodnost, toda malce previdnosti le ni odveč. Neka razlika je le med PC-jem, ki ga v najslabšem primeru resetiraš in črno škatlo, ki krmili n.pr. proces in mora delovati, tudi v nepredvidenih situacijah na vhodih.