[elektro] C

[hg12345]

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