[elektro] C

hg12345 hg12345 at freemail.hu
Mon Feb 14 13:40:47 CET 2011


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]>



More information about the Elektro mailing list