Адреса в EEPROM, Можно ли назначить адреса в EEPROM Опции

[at90]

В кодэвижене есть такая штука как переменная типа EEPROM.
Можно ли присваивать переменным типа eeprom адреса вручную.
Чтобя я знал адреса и мог обратится по адресу к переменной.

[solidreg]

Нет, не возможно.

Сделайте функцию для чтентя/писания с EEPROM'a.

[haker_fox]

Нет, не возможно.

Сделайте функцию для чтентя/писания с EEPROM'a.

А смысл? Ведь можно будет только писать/читать по определенным адресам... а переменная будет размещена там, где ее разместит линкер... сорри, если я не прав

В IARE например можно написать так:
__eeprom unsigned int stat_rec_point@0x10; //размещает переменную в EEPROM по адресу 0x10
Может все-таки есть такая возможность и в CodeVision? Может в хелпе есть?

[IgorKossak]

К переменной при желании можно обратиться по указателю или ссылке.
Где бы она ни находилась.
Обращение по конкретному адресу - это архаизм, переносимый в языки высокого уровня от опыта программирования на плохих ассемблерах, т к в хороших ассемблерах адрес переменной также знать незачем.

[arttab]

Ну значит я любитель анахранизмов. У нас требуется получить на комп блок данных и записать результат обработки во флешь мк. Операция однократная. Интересно, как с точки зрения передового чела это реализавать не зная куда писать?

Если зотите знать где ваши переменные лежит, посмотрите про объявления масива, сегмента. Должны быть нужные дерективы.

[andr2000]

я в таких случаях создаю струкутру, в которую входят _все_ переменные
которые должны лежать в еепром. тогда вся эта струкутра будет размещена
с начала сегмента еепром если объявить ее с __еепром
при необходимости я читаю всю структуру из еепром, передаю в пк,
модифицирую и прописываю всю струкутру назад.
таким образом я могу модифицировать все что мне нужно в еепром
не боясь потерять адреса и т.д.
хотя, возможно, в вашем случае это будет немного неудобно

[arttab]

я не говорил про только eeprom. мы и во flash пишим. а целеком ее перешивить.... нет уж. Это сама прога в мк делает, но адреса мы знаем.

[vet]

at90,
да оч. просто

Код

#asm(".eseg")
#asm(".org 0x80")
eeprom struct SETTINGS my_settings;

[IgorKossak]

Ну значит я любитель анахранизмов. У нас требуется получить на комп блок данных и записать результат обработки во флешь мк. Операция однократная. Интересно, как с точки зрения передового чела это реализавать не зная куда писать?

Передовой чел, как правило, не станет делать свой проект зависимым от знания адресов ещё на этапе постановки задачи, чтобы потом не задавать подобных вопросов и козырять подобными примерами.

я не говорил про только eeprom. мы и во flash пишим. а целеком ее перешивить.... нет уж. Это сама прога в мк делает, но адреса мы знаем.

Если воспользоваться относительной адресацией, то с таким же успехом адреса можно и не знать.
Кроме того и сам протокол связи получится более переносимым.

[Petka]

В кодэвижене есть такая штука как переменная типа EEPROM.
Можно ли присваивать переменным типа eeprom адреса вручную.
Чтобя я знал адреса и мог обратится по адресу к переменной.

Конечно можно, если вам действительно это нужно (например для чтения калибровочного байта, записанного в конкретный адрес, например с помошью AVREAL, с последующей записью его в OSCCAL).
Делается это так:

Код

eeprom unsigned char dummy; // заводим переменную, зарезервировав память. (на всяк случай =) )
unsigned char eeprom *ep;
..........
..........
..........
ep=0; // сюда записываем собственно адрес.
OSCCAL=ep[0];

[arttab]

Ну значит я любитель анахранизмов. У нас требуется получить на комп блок данных и записать результат обработки во флешь мк. Операция однократная. Интересно, как с точки зрения передового чела это реализавать не зная куда писать?

Передовой чел, как правило, не станет делать свой проект зависимым от знания адресов ещё на этапе постановки задачи, чтобы потом не задавать подобных вопросов и козырять подобными примерами.

я не говорил про только eeprom. мы и во flash пишим. а целеком ее перешивить.... нет уж. Это сама прога в мк делает, но адреса мы знаем.

Если воспользоваться относительной адресацией, то с таким же успехом адреса можно и не знать.
Кроме того и сам протокол связи получится более переносимым.

Звучит категорично.
Можете считать что мне лень в случае необходимости разобраться какае данные использует программа, сначала выяснять какая это версия и по каким адресам в ней расположились важные константы. При объеме около штуки приборов в месяц и переодическими дополнениями в код (не часто) доп. проблем не хочется создавать.

[BVU]

Ну значит я любитель анахранизмов. У нас требуется получить на комп блок данных и записать результат обработки во флешь мк. Операция однократная. Интересно, как с точки зрения передового чела это реализавать не зная куда писать?

Передовой чел, как правило, не станет делать свой проект зависимым от знания адресов ещё на этапе постановки задачи, чтобы потом не задавать подобных вопросов и козырять подобными примерами.

я не говорил про только eeprom. мы и во flash пишим. а целеком ее перешивить.... нет уж. Это сама прога в мк делает, но адреса мы знаем.

Если воспользоваться относительной адресацией, то с таким же успехом адреса можно и не знать.
Кроме того и сам протокол связи получится более переносимым.

Какие бы аргументы не приводились в пользу другой 'методологии', по большому счету IgorKossak прав! Одно из великих достижений стиля современного программирования это переносимость кода из одного проекта в другой с очень маленькой вероятностью переделок (адаптации). Иными словами портирование части кода (старого) во вновь создаваемый целесообразно с точки зрения качества создаваемой продукции. Если аудитория незнакома с принципами 'Capability Maturity Model® for Software (SW-CMM®)' что либо обьяснять дальше бессмысленно...
Обьясню это несколько примитивней: если вы имеете уже созданный код, который работает 100% удовлетворяя требования предьявляемые к его функционированию. Недопустимой роскошью является разработка и создание такового - заново. Любая фирма производитель цениться именно своим накопленным положительным опытом, который может быть использован в дальнейшем без излишних трудовых и финансовых затрат.
Далее о том что изначально говорилось в вопросе...
Подобные вещи хранящиеся в eeprom имеют данные определяющие в основном конфигурацию системы либо какие-то долговременные (редко изменяемые) параметры. Где-то это называется code-plug, в каких-то других системах flex-data и т.п. Так вот таковые представляются в виде таблиц, естественно упорядоченных, конечно удобней всего их описать, как говорилось выше - структурой, где переменные имеют размер (тип), а начало такой структуры всегда при прошивке и дальнейшего использования можно привязать к конкретному адресу. С символическими именами программисту работать комфортнее. Работа же с абсодютными адресами имеет древние корни машинного языка, когда отсутствовали программные средства (и не могли быть в силу ограниченности той техники) позволяющие использовать такие принципы програмирования.
Вывод - программирование на современном этапе обьединяет в себе множество ипостасий и такие, как технология и культура программирования. И умение их использовать обеспечивает положительный результат.

[Igor26]

Ну значит я любитель анахранизмов. У нас требуется получить на комп блок данных и записать результат обработки во флешь мк. Операция однократная. Интересно, как с точки зрения передового чела это реализавать не зная куда писать?

Передовой чел, как правило, не станет делать свой проект зависимым от знания адресов ещё на этапе постановки задачи, чтобы потом не задавать подобных вопросов и козырять подобными примерами.

я не говорил про только eeprom. мы и во flash пишим. а целеком ее перешивить.... нет уж. Это сама прога в мк делает, но адреса мы знаем.

Если воспользоваться относительной адресацией, то с таким же успехом адреса можно и не знать.
Кроме того и сам протокол связи получится более переносимым.

Какие бы аргументы не приводились в пользу другой 'методологии', по большому счету IgorKossak прав! Одно из великих достижений стиля современного программирования это переносимость кода из одного проекта в другой с очень маленькой вероятностью переделок (адаптации). Иными словами портирование части кода (старого) во вновь создаваемый целесообразно с точки зрения качества создаваемой продукции. Если аудитория незнакома с принципами 'Capability Maturity Model® for Software (SW-CMM®)' что либо обьяснять дальше бессмысленно...
Обьясню это несколько примитивней: если вы имеете уже созданный код, который работает 100% удовлетворяя требования предьявляемые к его функционированию. Недопустимой роскошью является разработка и создание такового - заново. Любая фирма производитель цениться именно своим накопленным положительным опытом, который может быть использован в дальнейшем без излишних трудовых и финансовых затрат.
Далее о том что изначально говорилось в вопросе...
Подобные вещи хранящиеся в eeprom имеют данные определяющие в основном конфигурацию системы либо какие-то долговременные (редко изменяемые) параметры. Где-то это называется code-plug, в каких-то других системах flex-data и т.п. Так вот таковые представляются в виде таблиц, естественно упорядоченных, конечно удобней всего их описать, как говорилось выше - структурой, где переменные имеют размер (тип), а начало такой структуры всегда при прошивке и дальнейшего использования можно привязать к конкретному адресу. С символическими именами программисту работать комфортнее. Работа же с абсодютными адресами имеет древние корни машинного языка, когда отсутствовали программные средства (и не могли быть в силу ограниченности той техники) позволяющие использовать такие принципы програмирования.
Вывод - программирование на современном этапе обьединяет в себе множество ипостасий и такие, как технология и культура программирования. И умение их использовать обеспечивает положительный результат.

Убийственно!

[arttab]

Во зацепило!
С таким бы пылом ответ бы дать на поставленный вопрос....
А мнений о необходимости и допустимости at90 получил много.
Опять же выскажу свое мнение. Пытаюсь узнать о разных свойствах и возможностях чего угодно. Даже если они мне и не пригодятся.
Офтопик. Вчере реализовывал расчет коэффициента и корекцию порогов при изменении входного напряжения. Коэф. в районе 1. Нужно учитывать 2 знака после запятой. Через float + 1500 байт. Выкрутился целочисленными переменными. Теперь знаю как оно трогать float и что можно без него. Опыт...

[BVU]

Во зацепило!
С таким бы пылом ответ бы дать на поставленный вопрос....
А мнений о необходимости и допустимости at90 получил много.
Опять же выскажу свое мнение. Пытаюсь узнать о разных свойствах и возможностях чего угодно. Даже если они мне и не пригодятся.
Офтопик. Вчере реализовывал расчет коэффициента и корекцию порогов при изменении входного напряжения. Коэф. в районе 1. Нужно учитывать 2 знака после запятой. Через float + 1500 байт. Выкрутился целочисленными переменными. Теперь знаю как оно трогать float и что можно без него. Опыт...

Ответ на для at90 на поставленный вопрос был дан и даже исчерпывающе (что следует не только из моего. но и из сообщений других участников. Толочь воду в ступе не есть хороший пример для обсуждения). Жаль, что Вы несумели понять (содержание моего ответа)... А уж может человек реализовать данные ему рекомендации это все зависит не только от опыта, но и от квалификации.