<html><body>EMEM je skutečně jen pro informaci jak se mají alokovat adresy.<div>Na přístup jsou různé funkce typu eeprom_blabla(pointer ...)</div><div><br></div><div>Lépe je to vyřešené jen v CodeVisionAVR, tam se deklaruje:</div><div>eeprom int eBla=0;</div><div>a už lze psát </div><div>x = y + eBla;</div><div><br></div><div>Tam vůbec není problém udělat v eeprom pole pointerů do flash a ty pak normálně používat, nebo ty různé paměťové přístupy jakkoli jinak kombinovat. Teda samozřejmě nejde dát do struktury prvky v různých pamětech. Ale jinak všechno co má smysl, tak jde:-) </div><div><br></div><div>Vždycky když používám EEPROM v Atmel studiu, trpím, protože jsem zvyklý psát i dost dlouhé vzorce, kde je víc proměnných v EEPROM.</div><div><br></div><div>PH<br><div><br><aside>

---------- Původní e-mail ----------<br>

Od: Admin HWnews <hwnews@cncnet.info></aside><blockquote data-email="hwnews@cncnet.info">Dne 06.01.2022 v 20:49 Jan Waclawek napsal(a):

> No tak ja som asi nepochopil, co vlastne bola povodna otazka.

<br>> 

> Ale myslim si, ze zakladny problem je v tom, ze mas privelke ocakavania.

> Ten C prekladac nie je o nic chytrejsi ako ten Pascalovsky prekladac.

<br>

<br>no me mate prave to rozsireni EEMEM, ktere rika prekladaci, ze ma tu 

<br>promennou umistit do EEPROM...tak jsem zavahal, ze treba je pak 

<br>cteni/zapis transparentni via nejake rozsireni...mimochodem cekal jsem 

<br>treba ze aspon cteni (prirazeni) by byl takovej bonbonek co by chodit mohlo

<br>

<br>> 

<br>>> moje predstava je, ze nadefinuji pole struktur. Jedna

<br>>> cast bude ulozena normalne v kodu tedy ve flash pameti (to jsou data,

<br>>> ktera jsou znama v dobe kompilace) a pak bych rad mel jeste druhou sadu,

<br>>> ktera bude uzivatelsky definovatelna ...treba 10 polozek pole (podle

>> toho co se vejde do EEPROM).

<br>> 

<br>> Ak bola Tvoja predstava ta, ze to bude jedno pole, ktoreho cast bude vo

> FLASH a cast v EEPROM, tak... nie, to nejde.

<br>

<br>neeee to samozrejme je mi jasne, ze je scifi

<br>

<br>> 

<br>> Takze asi najrozumnejsie riesenie je mat dve polia, jedno vo FLASH a jedno

<br>> v EEPROM, a tiez dve sady funkcii, ktore z tych poli citaju/zapisuju (teda

<br>> zapisuju len v pripade EEPROM). A mat v RAM jednu "pracovnu" kopiu tej

<br>> struktury, do nej si nacitat z FLASH alebo EEPROM podla potreby, a ked

> pride na zapis, tak zapisat znova podla toho, kam to ide. Ano, otrocky.

> Kompilator tu nijako nepomoze.

<br>

<br>Ano tak to bude...abych to priblizil...jedna se o dvoukanalovy DA 

<br>prevodnik, ktery po pripojeni cidla (MODBUS a FINET) dotazem zjisti o 

<br>jake cidlo se jedna a na zaklade toho vyhleda konfiguraci, kde ma mimo 

<br>jine napsano jakym zpusobem se mapuje rozsah merene veliciny cidla na 

<br>klasicky proudovy vystup 4-20mA. Vystupni kanaly jsou dva v pripade ze 

<br>cidlo meri dve veliciny. V kodu jsou napevno zname konfigurace 

<br>existujicich cidel a v eeprom bud alternativni konfigurace a nebo 

konfigurace ulozena uzivatelem, ktera nebyla v dobe kompilace znama.

<br>

<br>Takze nejdriv prosmejdim konfigurace ulozene v eeprom a kdyz nenajdu tak 

budu hledat ty ve flash.

<br>

<br>> 

<br>> Mimochodom, neprezradil si, o ktory prekladac ide, a tak som trocha

<br>> guglil... a klucove slovo EEMEM je... zda sa... ze avr-gcc, premenovany

<br>> Microchipom na XC8. Takze ide o AVR, je to tak? Ak ano, tak bohuzial, na

> citanie/zapis EEPROM nie je ina cesta ako pouzivat obezlicky/funkcie.

<br>

<br>Ano je to tak...xc8 a mcu je ATmega328...vsechno je pro me bohuzel uplne 

nove.

<br>> 

<br>> 

<br>>> Tady ale netusim jaky vyznam ma definovat neco v EEPROM...stejne se s

<br>>> tim neda primo pracovat...stejne budu muset pouzit neco takoveho:

<br>>>

<br>>> eeprom_write_block(&DA485_par, &DA485_par_EE, sizeof(DA485_struct));

<br>>>

>> coz mi prijde v podstate uplne to same...

<br>> 

<br>> Ano, v podstate je to uplne to iste ako ked si si v Pascale tie adresy

<br>> pocital. Toto som popisoval v poslednom odstavci toho dlheho textu

<br>> ("Rozdiel medzi...").

<br>> 

<br>> Mimochodom, presne tymto istym vyvojom som prechadzal onoho casu aj ja,

<br>> tiez som si len s nechutou pripustal, ze ta automatizacia, ktoru prekladac

> v tomto smere ponuka, je viacmenej ziadna...

<br>

<br>no evidentne zazraky se nedeji...a dekuji za obsahle komenty ;-)

<br>

<br>RV

<br>_______________________________________________

<br>HW-list mailing list  -  sponsored by www.HW.cz

<br>Hw-list@list.hw.cz

<br>http://list.hw.cz/mailman/listinfo/hw-list

<br></blockquote></div></div></body></html>