[elektro] C
Lajos Rancz
lajos.rancz at gmail.com
Mon Feb 14 13:49:20 CET 2011
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]
>
More information about the Elektro
mailing list