Это является расширением языка. Нормальные типы, ибо поддерживают все операции над данными - арифметику, присваивание, взятие адреса, обращение по указателю. Указатели на эти типы полностью аналогичны указателям на данные с __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 это платформено-зависимый тип, который подходит сугубо для возврата кода ошибки и то не всегда.

Потому и руками допиливаются обычные функции и из них появляются особенные - так кроме
int printf(const char *__fmt, ...);
имеем
int printf_P(const char *__fmt, ...);
ЗЫ. Я пробую каждую свежую версию WinAVR и могу заметить, что семимильными шагами движется он в сторону IAR. Проекты под портируемость сразу протачиваем. Но пока это "утомительное застирывание".

to Сергей Борщ
Подскажите, а зачем нужна обвязка из do/while?

Почему не так?

В данном конкретном случае она не нужна. Сила привычки. Началось с того, что увидел такую обвязку в исходниках линукса и задал такой же вопрос в ru.embedded. ReAl мне там ответил, что если внутри макроса будет более одной команды, то их придется заключать в {} чтобы такой макрос можно было использовать как единое выражение в циклах или в конструкциях if(условие) macros(); И все будет работать до тех пор, пока не появится желание сделать if(условие) macros(); else something; - получим ошибку компиляции. Обрамление же в do {}while(0) позволяет использовать такой макрос в любом месте, где допустим вызов обычной функции и не несет никаких дополнительных накладных расходов - сам цикл выбрасывается оптимизатором, остается только его тело. Ну а здесь я их обрамил по привычке, на случай если вдруг придется добавить внутрь еще одно или несколько выражений. Кончно, если пользоваться только С++, то можно реализовать то же самое при помощи static inline функций, но пропадет универсальность в виде совместимости с С.

Подробнее можно? Почему пропадет совместимость, если в C тоже допускаются static inline функции.

В C99. Но, к сожалению, не все компиляторы его поддерживают В С89 inline нет, а если и есть - это расширение конкретного компилятора. В общем "Это работает - не трогай!"

Действительно удобное решение.

Нет, я имел ввиду конвейер головного мозга. Это я так, философствую... Можно стремиться проще и короче выражать свои мысли, но действительно ли их так много, что это нужно делать?
Я только себя имел ввиду. И вообще - проехали

Кстати, между прочим, переделав eeprom.s90 например на работу с 24xxx получаем удобный инструмент хранения переменных во внешней епромке. Кстати, структуры там тоже отлично хранятся... и массивы...

С точки зрения singlskv это неудобный неиструмент, который может ввести тебя в заблуждение при написании программы и привести десяткам ... нет сотням ошибок. Трудно вылавливаемых ошибок.

Ээээ... А с Вашей?

Я оцениваю это положительно. Сам до такого не додумался. А мне кстати бы не помешало такое решение.
И вообще - всё что сделано - остаётся на годы.

Тут вообще, на мой взгляд бессмыслено оценивать. Раз Вы сделали - значит Вам это понадобилось и для Вас это оказалось удобным. Соответственно моя оценка или оценка другим человеком Вашего труда - будет весьма субъективной.

Я считаю, что фактически, это разработка какой-то базы под себя. И это позволит Вам следующий раз сделать проект быстрее. Соответственно это очень положительное качество. С годами Вы, возможно, переработаете детали и вылижите что-то. Или вообще что-то измените, но наверняка наработанные знания и опыт останутся с Вами навсегда.

А вообще, жалко, что нет штатных средств компилятора для создания таких адресных пространств под собственные нужды. Иногда очень бы упростило код и добавило бы красоты. Через епром - это конечно костыль, однако, с другой стороны, достаточно легко переносимый на другие платформы.

В принципе была еще одна идея, но это уже злой хак Как известно, ИАР умеет компилировать для моделей памяти с озу >64К. Была идея патчить кодегенератор, дабы он делал не OUT в RAMP?, а out в нужный порт. В результате, можно было бы увеличивать объем озу просто навесив дополнительные адреса на какой-либо порт и не думая о том, как выполнить этот маппинг програмно, все бы на себя взял компилятор. Правда, идея до реализации не дошла (уже не помню почему, кажется, отпала надобность).

Пытался. Используются несуществующие регистры RAMPx. Проблема (сомневаюсь, что показалось) нерешаема.

Rst7, А как Вы считаете, встраивание возможности чтения EEPROM перед ее записью(или
не записью, если там ничего не изменилось) в свой код(или библиотеку) является
правильным/нужным (для увеличения ресурса EEPROM) ?

Время от времени на электрониксе возникают темы типа:
Как сохранить текущую конфигурацию прибора при пропадании питания.

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

Может все-таки стоит в подобных ситуациях озаботиться возможностью
"ВСЕГДА" иметь правильную конфигурацию в EEPROM ?
Правда для этого(часто) придется написать свой код общения с EEPROM.

А давайте вспомним обычную файловую операцию - сохранение файла. Чтобы записываемый файл не убил ещё целый оригинал, нужно писать в другое место. Далее возникают остальные вопросы - как разгребаться с мусоркой и т.п. Файловые системы типа JFFS и новомодная ZFS именно то же делают -записывают на свободное место, а потом разбираются с мусоркой (в JFFS - garbage collection). Но оказывается задачи подобного рода - гарантированная запись некоего блока данных - возникали и раньше, например, в бесконтактных фискальных системах (карточки Mifare). Дык там это не пальцы загибать, а денюжки хранить. ЧТо придумывать будем?))

Не очень понял как это касается темы спора
встроенные vs собственные средства работы с EEPROM ?
Если вы о том что нужно таки аппаратными средствами обеспечить запись в eeprom,
то придумывать ничего нового не будем, уже все придумано.
Транзакция считается законченой когда записано обе копии данных в EEPROM.

Если бы Вы внимательно читали мои посты, например пост №54 то Вы бы заметили что
мой автомат апдейтит две копии данных и по ходу для каждой из них
сохраняет/проверяет CRC.

- я писал?
а это -

Озаботились кроме Вас ещё много людей и я Вам написал о том, что проблема не нова. И независимо от Вашего некоего "автомата" давно успешно решаема. Если Вы не знакомы с известными решениями, то это не повод рассказывать о том, что кроме Вашего решения (крохи которого Вы попытались громко показать) ничего иного нет))


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

Я и не пытаюсь себе присваивать пальму первенства, более того, я уверен что те
решения о которых я говорю применяются очень широко. Тока почему то на электрониксе
очень многим они не нравятся

Если Вас не убедило 33 такта против 81 на записи одного байта (да еще и в ситуации когда
цейтнот и питания осталось совсем мало), то я не смогу Вам объяснить чем мое решение лучше...

А если Вы действительно хотите разобраться со всеми нюансами сохранения правильной
конфигурации в EEPROM, то давайте это обсуждать, тока без вариантов типа в IAR это сделано
круто и ничего другого я знать не хочу,
и я думаю что тоже узнаю для себя что-то новое.

Да какая разница сколько тактов уйдет на sheduling записи одного байта. Операция записи длится 3-5ms, ответьте - сколько раз при этом будет осуществлен вызов вашего автомата и "отвал" по факту занятости eeprom, сколько тактов это сожрет? Не кажется ли вам, что разница 81-33 = 48 тактов просто мизерная и стремится к нулю на фоне постоянных накладных расходов автомата.
Кстати откуда 81 такт?
(eeprom char *)xxx = YY - это 14 инструкций с отключенной оптимизацией


что тут обсуждать. три основных момента - залог успеха:
1. пакетная организация,
2. CRC обязательно.
3. Дублировать записи.

Вы то хоть поняли что в IAR сделано? И как то, что сделано в IAR кореллирует с тем, что выставляете вы? Уровни же разные совершенно, вы хотите сопоставить пакетный уровень, байт уровню? Типа - да начерта нам эти сигналы всякие, биты, байты, вот IE с http прекрасно работает..

Если у меня правильная конфигурация (состояния автоматов) меняется примерно раз в минуту, то дырку я протру за 100К/60/24 = 70 дней. Если я растиражирую эту запись 10 раз - то за 700 дней. Правда, епром у меня используется впритык, и максимум, что я могу - это 3 копии. Т.е. 70*3 = 210 дней. Все равно мало. Поэтому приходится иметь парковку...

Кст, насчет спора собственные функции \ встроенные средства. Сам для епрома использую собственные - с автоматическим тиражированием, CRC и работающие в фоне. А вот для доступа к флэшу использую модификатор __flash. По моему, вполне удобно.

8.5 МИЛЛИСЕКУНД продолжается запись. Какие такты кого спасут? IMNHO, Вы путаете время записи адреса и данных для АППАРАТНОЙ записи с продолжительностью самой записи. И, кроме того, извините, но глядя на кусочек кода (вероятно это код Вашего автомата), не только у меня возникли сомнения в его корректности. Вопрос же о хранении и валидности данных касается более алгоритмов хранения, а не реализации их в конкретном драйвере, о котором кроме дифирамбов никакой инфы, кроме неиспользования штатных средств, толком и не было.

Ну я в IDA размотал этот кусок, где он генерирует комманду записи в RAMPx, ее можно там заменить, пропатчив экзешник конечно, штатными средствами не получится. Только что-то меня остановило, уже не помню что.

Уже не помню, но кроме адресации по смещению какие-то нюансы с регистрами передачи параметров в функции были.