Не очень понял что Вы хотели этим сказать.
Мои варианты/предположения:
- нельзя прервать потому что нельзя
- нельзя прерывать потому что кто-то еще захочет записать в EEPROM (из прерывания например)
- нельзя прерывать потому что запись в EEPROM требует остановки всех процессов
.....................
.....................
- нельзя пользоваться таким вариантом записи в EEPROM (поддерживаю!)
Вы бы уточнили о каких АППАРАТНЫХ ОГРАНИЧЕНИЯХ идет речь...
Если Вы о необходимости вот этого:
asm("cli");
EECR |= (1<<EEMWE);
EECR |= (1<<EEWE);
asm("sei");
то там речь идет о паре тактов проца... и при грамотном проектировании проги даже эти
cli и sei не понадобятся.

Мы не обсуждали портируемость. В других компиляторах нет eeprom_write_byte();, а в некоторых процессорах нет eeprom Получаем ошибку компилятора о несоответствии типов. Ту самую, которую в предыдущем примере вы задавили явным приведением к (void *). Ту самую, которую вы получите в WinAVR, если попытаетесь присвоть (void *) переменную типа (void EEMEM *) или prog_void.Не поверите - именно там, где надо сохранить данные. Компилятор подставит для каждого байта вызов __eeput8_16, в котором именно там, где это необходимо будет запрет/разрешение прерываний. Поверьте, код будет практически идентичен eeprom_write_byte(), за которую вы агитируете. Для очень редких случаев есть вариант *((uint8_t *)&cfg_EE.Config.ParamA)[2] = byte; Что касается ресурса eeprom, то я не случайно взял конфиг - как наиболее общий случай, когда ресурса хватит даже самому пытливому пользователю. И не пытайтесь меня убедить, что я должен потратить лишнее время чтобы экономить ресурс там, где его и так с запасом - это все равно что агитировать писать на асме (со всеми вытекающими недостатками), чтобы втиснуть програму в 2к памяти при 8к на борту. Если же есть какие-либо специальные требования (ресурс, необходимость отслеживать окончание по прерыванию) - думать головой никто не отменял.

Почти согласен. Но писать для каждой ноги xxx_on(), xxx_off() - да, конечно так и делал раньше. Но теперь - on(LED); off(FLASH_CS); if(signal(KEY)) - тоже абсолютно портируемо на любой С-компилятор. И сгенеренный код будет идентичен тому, который надо написать вручную для xxx_on(); xxx_off();

Я даже и не сомневался что именно Вы укажите на это несоответствие ,
этот код я даже и не пытался скомпилировать потому что очевидно одно из двух,
если компилятор пропустит такой код, то все очень плохо и пользоваться __eeprom
просто нельзя ни при каких обстоятельствах, а если не пропустит, то это говорит
о том что типы которые придумал IAR(__eeprom xxx), Эээ... ну мягко говоря не
являются таки типами..., по крайней мере в понимании С.
Упс..., это где это я агитировал за использование eeprom_write_byte() ?
Я этим ни разу не пользовался У меня свои функции.
Если Вас не затруднит ответьте таки конкретно на 2 моих вопроса из поста №37.



Все равно не понимаю в чем Вы пытаетесь меня убедить.
В том что я обязан висеть в этом цикле пока не закончится запись ?
У меня это выглядит примерно так:


Я НЕ пользуюсь ни IARовским ни каким другим вариантом доступа к EEPROM.
У меня есть свой хорошо работающий автомат записи.

Обчитался после, что Вы не используете встроенные возможности и удалил пост нафиг.
Если Вы предлагаете для всех случаев применения EEPROM не использовать встроенные функции/модификаторы, то это не повод рассказывать, что они не годятся. Аргументы, ИМХО, сомнительны.
Задачи, конечно, разные бывают. Сам для записи во внешнюю последовательную память целую артиллерию из очередей выстраиваю, но константы, хранимые во __flash никуда не деваются и удобно используются. Встроенную EEPROM у нас юзают исключительно как описывал defunct, потому как реально для наших логов (архивов) маловато будет - для хранилищ обычно ставим FRAM и DataFlash.

Если речь идет о задаче-драйвере записи eeprom, то что мешает внутри нее использовать уже готовые механизмы компиляторов, e.g.:



Если вы даже не удосужились посмотреть и разобраться с кодом eeprom_read_byte()/eeprom_write_byte() пакета в котором работаете, и начали сразу городить что-то свое, то спорить с вами о возможностях IAR просто бесполезная трата времени.


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

Это является расширением языка. Нормальные типы, ибо поддерживают все операции над данными - арифметику, присваивание, взятие адреса, обращение по указателю. Указатели на эти типы полностью аналогичны указателям на данные с __attribute__(("progmem")) и __attribute__(("EEPROM")), против которых (так получается) вы нас агитируете. Причем последние, в отличие от ИАРовских, не являются полноценными типами, ибо поддерживают только операцию взятия адреса и арифметику указателей.Ну, раз вы агитируете за WinAVR и доступ функциями, раз вы нигде до этого не упомянули, что вами используется закат солнца вручную - телепатически я сделал вывод, что вы агитиреуте за реализованный в avr-libc метод.Вопросов я там нашел два: 1)Где там использовать встроенные функции. Да, согласен, я не обратил внимание на 200-500 мкс, что меньше, чем время записи. Согласен, что в этом случае надо использовать самописные функци. Но, извините, а вы эти данные только пишете, и никогда не читаете? Если все же читаете, то что мешает использовать простые и удобные встроенные возможности компилятора?
Ваш вопрос номер два - про ресурс. Мне кажется, я на него ответил исчерпывающе - если ресурса хватает с запасом (а это наиболее частый случай, как в примере - при хранении конфигурации) то не имеет смысла тратить усилия на его экономию. Если он важен - можно сделать побайтовую запись с анализом.В том, что встроенная поддержка данных в eeprom и flash не вредное (как вы утверждаете), а напротив очень полезное и удобное (первое вытекает из второго) расширение компилятора.Так я же и писал, что бывают случаи, когда надо работать головой и использовать нештатные решения. Но это не повод отказываться от удобных возможностей в остальных случаях.

Собственно об этом и речь. Простое присваивание не заостряет на себе внимание, в отличии от вызова функции, и ведет к ошибкам от банальной невнимательности. Понятно, что в результате оба метода, и в ИАРе и в ГЦЦ одинаково эффективны. Но все же работа с ЕЕПРОМ у ГЦЦ больше напоминает обращение к внешней памяти, с ее неизбежными задержками, что помогает избегать глупых ошибок. Но тут уж видимо вопрос вкуса. Меня встроенные функции avr-libs вполне устраивают. Но вот никто почему-то не говорит о лицензионной чистоте используемого программного продукта....

А зачем об этом говорить если это не влияет на функциональность и качество компиляции?

Воспользовался Вашим советом:


IAR, получил 81 такт на выполнение EEPROM_Run().
Написал тоже самое(по функциональности) "ручками", скомпилировал на WinAvr и на IAR,
и там и там получил 33 такта. (во всех случаях использовалась максимальная оптимизация)

Если Вас устраивает такой оверхед - пользуйтесь, меня не устраивает.

У меня для этого автомата максимальное время каждой стадии его работы чуть боле 100 тактов,
при этом поддерживается запись в два блока памяти(копии) и попутно подсчет/сравнение
СRC16 c уведомлением основной проги если были ошибки...

Вы знаете, именно так и поступаю, сначала ознакомление со штатными средствами,
если меня устраивает, пользуюсь штатными, если нет, пишу свою реализацию.
Кстати вот вам и примерчик:
CRC16 и CRC8
CRC16 - пользуюсь встроенным, поскольку после изучения кода стало понятно что я просто ничего
не смогу выиграть.
CRC8 - очень медленно (для моих задач) , пользуюсь своим вариантом, причем их 2 на выбор,
если памяти много - табличный, мало - другой быстрый вариант.

Понятнее...,но в 2,5 раза медленнее
Принципы здесь не при чем.

Согласен, нужно было не расчитывать на телепатию собеседников и чуть
пораньше объяснить что я имею в виду.
А "закат солнца вручную" иногда очень эфективный метод
ИМХО, это не нормальные типы, и мои примеры это показали.
Невозможность автоматического приведения указателя на такой тип к void* говорит
именно о том что тип неполноценен.
Считаю подход WinAvr(Gcc) в данном случае просто более честным.
Чаще конечно пишу, чтение в основном при первоначальной загрузке параметров.
Но иногда нужно и чтение в процессе работы, поэтому чтение тоже интегрированно в
этот автомат.
Когда нужно быстро, пользоваться своим, а когда нужно медленно, то пользоваться библиотекой ?
А зачем мне плодить сущности и увеличивать код ?
У меня такие случаи в каждом первом проекте.
Всегда нужно чего-нить писать во время основной работы...

Спасибо за примерчик. Я по старинке пишу ON_LED; без скобок, чтобы помнить, что это макрос. Не особенно нравится, но вот думаю, а стоит ли менять?
Я даже стараюсь писать unsigned int вместо uint или word, как это теперь обычно делается. Пока кнопочки жамкаешь, голова и работает (или отдыхает, что тоже неплохо).
Не загоняем ли мы себя в угол, раскручивая конвейер?

Вы имеете в виду IAR vs Gcc ?

Об этом говорят вам все. Я, defunct, Сергей Борщ. IAR не запрещает работать вам так, как вы желаете. О чём и свидетельствуют написанные вами строчки. Другое дело если бы кроме как ч/з __eeprom компилятор не позволил бы добраться по другому к данной памяти. Но это к счастью не так.

Если вам так тяжело пережить эти спецификаторы, то рассматривайте их как факультативные и не используйте их.


По поводу "оверхеда".
Оптимизацию целесообразно делать там, где она даст желаемый эффект. Если привести доступный пример, то целесообразно вылизывать п/программу которая вызывается 1000 раз в секунду и совершенно не целесообразно если она вызывается 1 раз во время старта программы. По скольку EEPROM используется, как правило для хранения конфига и т.п., читается редко а записывается ещё реже (иначе используют внешнюю память, доступ к которой будет быстрее в разы), то для меня __eeprom является преимуществом. Использую я его где надо и по назначению и никаких проблем это у меня не вызывает.


В ближайшее время пойдёт xmega. Как уже объявлено, там будет память EEPROM в общем адресном пространстве. Я думаю IAR сохранит __eeprom. Таким образом портируемость программ у тех, кто использовал __eeprom - не пострадает.




Давайте всёже не забывать что мы с однокристалками работаем.

С одной стороны uint8_t это тоже стандарт
ISO/IEC 9899:1999 7.18 Integer types <stdint.h>

С другой стороны приведу пример. Я сделал проект на m640. Сейчас планирую перенести его на LPC2106. У меня там большое количество структур и указателей. И представьте себе если бы там стоял стандартный "int" вместо int16_t. Это же лопатить не перелопатить.

Ну а если глобально подходить, то да. Человечество давно само себя загоняет в угол по всем направлениям.
Долой машины - дорога к счастью - назад на деревья.

Согласен, если выбора нет. А если он есть - смотря какой именно из парамеров оптимизировать Не готов сразу ответить. "Чистый" С вообще не знает про разные адресные пространства. Да и как вы физически представляете приведение указателя на одно адресное пространство к указателю на другое? Только используя __generic указатели, что хоть и влечет дикий оверхед, но тем не менее реализовано в IAR.На самом деле он просто не доделан А пока он не только не честный, но как раз наоборот:На фоне того, что такое компилируется молча и без ошибок тот факт, что на самом деле копирование происходит из ОЗУ в ОЗУ по совпадающим адресам кажется несущественным. Допустить такую ошибку гораздо проще (сам наступал), чем нарваться на случай, когда критично время записи в eeprom или ее ресурс. Тут четко видна недоделанность, ибо попытка присвоить что-либо Const все же вызывает сообщение об ошибке "попытка записи в read-only".И при этом данные, которые вы читаете, всегда представляют набор байтов? Не int, long, float, структуры, а именно голые байты? Если же данные осмысленны, то почему не воспользоваться предоставляемыми компилятором средствами?Честно говоря, так бы и поступил. Ибо встроенные методы дают более читаемый код. И чем больше читаемого кода в программе, тем меньше вероятность ошибки.
Ну хорошо, наэкономите 40 байт памяти, а смысл, если ее все равно осталось полкило а то и больше? Читаемость упала, возможностей оптимизации у компилятора меньше. Ясное дело, если утаптываем, то резать придется везде."У каждого есть свои маленькие недостатки" (с)"В джазе только девушки".


Даже если не сохранит - портируемость достигнется добавлением строчки #define __eeprom

Здесь мы видимо принципиально по разному подходим к вопросу.
EEMEM, PROGMEM я типами данных просто не считаю.
Это, по моему мнению, просто те расширения компилятора которые позволяют
отводить/инициализировать область в eeprom/flash. + взятие адреса для выяснения куда писать.
Все. Собственно в описании к avr-lib их тока так и предполагается использовать.
Автомат оперирует на уровне блока байтов + CRC.
Ну видимо у нас все-таки сильно разные задачки...
Кстати о портируемости , мой вариант кода эквивалентный коду из поста №54
скомпилировался без вопросов и на Gcc и на IAR

Напрасно, т.к. int это платформено-зависимый тип, который подходит сугубо для возврата кода ошибки и то не всегда.