[elektro] C

[Lajos Rancz]

Hello!

Ami valaszt ad az a metodologia: C++ rugalmassagban, atlathatosagban,
skalazhatosagban _sokkal_ jobb mint a C.

Udv

2011/2/14 hg12345 <hg12345 at freemail.hu>

> Szia,
> hát a rövidítések soha nem voltak az erősségeim.
> Utána keresek, hátha sikerül.
>
> Adattárolás... Nem szeretek semmilyen konstans értéket RAM-ban tárolni,
> föleg úgy ahogy a C csinálja, (init alatt betölti! :-()
> Amiröl tudom hogy konstans és ezt már fordítás alatt is tudom, annak a
> helye a nagy energiával átírható memóriában van ellenörzőösszeggel védve.
> Ezt a legtöbb C/C++ nem szereti, hogy igazuk van vagy nincs ezen nem
> érdemes vitatkozni. Nagysebességű rendszereknél a dolog nem kétséges, de ha
> van CACHE a rendszerben akkor már talán elgondolkodtató. Kis sebességű
> rendszerek esetén mint a <80MHz alatti rendszereknél ahol kis buffer
> keresztül olvassa uC a FLASH-t, A cimzés ugyan úgy történik mint a RAMban,
> itt egyértelmű, hogy a FLASH-ban van a konstansok helye, nem pedig
> inicializáláskor betöltöm a RAM-ba.
>
> A fordítok egyrésze a const ide teszi, amelyik nem ahhoz van attributum.
> (pontosabban "const tipus const name"  ez egyik a tárolás helyére
> vonatkozik mig a másik, hogy nem írható.....)
>
> De ez nem ad megoldást a problémámra..... (UI-ra)
>
> Egy EMI/EMC grade A berendezés esetén minden apróságra érdemes odafigyelni.
>
>
>
>
>
> Lajos Rancz <lajos.rancz at gmail.com> írta:
> >Hello!>
> >
> UI == User Interface, ennek egy fajtaja a GUI ami a Graphical User>
> Interface.>
>  Ezt az adattarolast nem ertem teljesen tisztan, arra gondolsz hogy egy>
> const erteket (pl string) at akar masolni RAM-ba? Ha ez az alapertelmezes>
> akkor biztosan vmilyen fordito specifikus direktiva.>
> >
> Udv>
> Lajos>
> >
> 2011/2/14 hg12345 <hg12345 at freemail.hu>>
> >
> > Hi!>
> > Az UI rövídítéssel még nbem találkoztam, mit takar mert szívesen>
> > utánanéznék.>
> > A C++ azért lennének fentartásaim, mert a maga a C  de  tudtommal a C++
> még>
> > inkább nem támogatja a FLASH-ban elhelyezkedő adatokat...>
> >>
> > Lajos Rancz <lajos.rancz at gmail.com> írta:>
> > >Hello!>>
> > >>
> > Hat :) Erdekes kerdes, en azt mondom, hogy C++, az mindazt tudja amit
> te>>
> > szeretnel. Ott eleg jol ki vannak talalva a technikak UI epitesre, nagy>>
> > irodalma van, sok mintat lehet latni. Nem veletlen, hogy a UI-ok vagy>>
> > teljesen kod alapuak (pl MFC, Qt) vagy leiro nyelv+script (webes>>
> > alkalmazasok). Ilyen tablazatos jellegu megoldast mar en is csinaltam,
> de>>
> > karbantarthatatlan es kenyelmetlen. A C++ nem fog tobb memoriat kerni,>>
> > raadasul egyre tobb embedded platform tamogatja, IAR es gcc tuti.>>
> > >>
> > Udv>>
> > Lajos>>
> > >>
> > 2011/2/11 hg12345 <hg12345 at freemail.hu>>>
> > >>
> > > Köszönöm a válaszokat.>>
> > >>>
> > > A futtatási időben való inicializálás, bármennyire szimpatikus
> számomra>>
> > > kizárt. (számomra ez külön probléma C-ben, hogy mindent RAM-ban akar>>
> > > tárolni, még a konstansokat is, én meg nem!!!)>>
> > >>>
> > > PICC18-nál nem próbáltam, de C30(GNUC) esetén müködött, nem
> tökéletesen,>
> > de>>
> > > kézbentartható volt. Az itt lefordult programot szerettem volna
> áttenni>
> > KEIL>>
> > > C-re, és itt a gond. Ezért érdeklődtem a különböző C szabványoknak
> való>>
> > > megfelelőségről.>>
> > >>>
> > > Sajnos a legtöbb fordító a pointer arithmetika esetén két problémába>>
> > > ütközik.>>
> > > Ha egy fordítási egységen belül kezeli a pointert akkor elég sok
> dolgok>>
> > > képes elvégezni, de ha már a linkerre kell bíznia ezeket a müveleteket>
> > az>>
> > > erősen szűkíti a lehetőségeket. De mindezek alól kivétel a függvény>
> > pointert>>
> > > amivel semmilyen müveletet nem hajlandó végezni. Ez alapból tiltva van
> a>>
> > > C*ben, sokszor még a castolása is probléma. (nálam okosabbak azt
> mondák,>
> > ez>>
> > > azért van, hogy védjék a programot, mert ezekkel lehet a legtöbb
> hibát>>
> > > elkövetni..., szerintem inkább oktatni kell, mint fékeket rakni a>>
> > > rendszerben, ez olyan mintha egy kocsiba csak gázpedált építenék be,
> vagy>
> > a>>
> > > sebváltót 2 felett tiltanák :-(...>>
> > >>>
> > > -------------------------------------------------------------->>
> > >>>
> > > Nem rég egy kolléga körkérdést tett fel C-vel kapcsolatban, nekem is>
> > lenne>>
> > > egy hasonló, de egy program megvalósítással kapcsolatban.>>
> > >>>
> > > Hogyan oldjátok meg a MENÜ kezelések egy készüléken belül?>>
> > > Ez a feladattal fog ki rajtam C :-(, de lehet hogy nem is igy kéne>>
> > > csinálni!>>
> > >>>
> > > Elég speciálisak az igényeim, a következő feltételeket kéne
> teljesíteni>
> > a>>
> > > MENÜ-nek, ime a lista:>>
> > >>>
> > > - a fordító fordítási időben generálja a menű leírást (ez lényeges
> mert>
> > az>>
> > > öröklődési függvények cimeít nem tudja tárolni)>>
> > > - senzitiv / selectiv legyen (a mindenkori konfigurációtól függenek a>
> > menük>>
> > > elérhetősége és viselkedés)>>
> > > - lineárisan címezhető, (előnyös ha cimeket mint egy enum sor>
> > előállítja)>>
> > >  ((( számítógépes elérés, MMI elérés és a programok is ezen ketesztül>>
> > > férnek az adatokhoz)))>>
> > > - szövegesen szerkeszthető legyen, lehetőleg C forrásban (esetleg>>
> > > makrokkal...)>>
> > > - mindenképpen FLASH-ban legyen tárolva>>
> > > - a MENU leírók tegyék lehetővé, TREE, STACKED és MATRIX elrendezést>>
> > > - minden menű elem tartalmazza minden adatát!>>
> > >  1, memória hivakozási cím (külső(E2PROM), belső(RAM), speciális)>>
> > >  2, megjelenítési név, string>>
> > >  3, kétszeres indexálást (ez módosíthatja a memória címet , és a>>
> > > megjelenítési nevet)>>
> > >  4, inicializálási értéket (FACTORY setting, gyári visszaállítási>
> > értéket)>>
> > >  5, állíthatóságot, tizedespont elhelyezkedéset>>
> > >  6, hozzáférési jogot (állítható, olvasható, nem látható, nem
> elérhető,>
> > nem>>
> > > létezik, stb....)>>
> > > - a fenti megadások öröklödéssel való generálásának lehetőségét,( egy>>
> > > programmal helyettesítését.)>>
> > >>>
> > > Ami még elég fontos, minél tömörebben, mert igen jelentős számú menü>>
> > > bejegyzés lehet egy készülékben. (100-6000). A FLASH méretét szeretném>
> > 64K>>
> > > max.128K-ban korlátozni.>>
> > >>>
> > > Sajnos nem találtam a neten megoldást, kis cél rendszerek ritkán>>
> > > rendelkeznek ilyen igényekkel.>>
> > >>>
> > >  üdv>>
> > >>>
> > > ----------------------------------------->>
> > >          elektro[-flame|-etc]>>
> > >>>
> > ----------------------------------------->>
> >          elektro[-flame|-etc]>>
> >>
> > ----------------------------------------->
> >          elektro[-flame|-etc]>
> >>
> ----------------------------------------->
>          elektro[-flame|-etc]>
>
> -----------------------------------------
>          elektro[-flame|-etc]
>