Порты AVR и компиляция Опции

[allexmor]

Очень долго работал с разными МК(51, в основном ARM) решил попробовать AVR вопросы:
У этих AVR что нет удобного побитового доступа к портам?
Какой компилятор делает наиболее красивый код?

[SasaVitebsk]

Есть ещё один момент для WinAvr. Только за последних пару лет его пересобирали раз десять. Регулярно что-то меняли в том числе координальное. Так что насчёт совместимости и большого количества проектов это не вся правда. Править придётся. То там то тут выскакивают сообщения - пересобрал - неработает. Работать с ним отнюдь не легче чем с IARом. Хотя и IAR к числу лёгких в освоении пакетов не относится. Документация разбросана по всему интернету. Никакой упорядоченности. Что-то надо - полез искать. Чаще всего если и найдёшь, то в каком нибудь FAQе.

Короче очень геморойная вещь. Ясно что если освоил, то тогда нормально.

Выпад по поводу данных в EEPROM и FLASH - явно бредовый. Удобная вещь - она всегда удобная.

Зачем мне для обращения к Flash переменной обращаться ч/з подпрограмму? А если у меня в одной формуле/операторе используются переменные Flash и RAM? Например знакогенератор в видеоозу вывожу. IAR отличный код генерит и прекрасно оптимизирует такие места. А чтобы по ошибке не использовать переменные EEPROM, выход простой. defunct его фактически указал. Обзавите переменную eeMyInt. И всё для вас будет ясно.

Это просто яркий пример как можно всё с ног на голову поставить.

[singlskv]

Выпад по поводу данных в EEPROM и FLASH - явно бредовый. Удобная вещь - она всегда удобная.

Зачем мне для обращения к Flash переменной обращаться ч/з подпрограмму?

Это просто яркий пример как можно всё с ног на голову поставить.

Давайте посмотрим, на Вашем любимом IAR:

Код

#include <string.h>

__eeprom char eeString[]="Prived !";
char String[10]="ABCDEFGHIJ";

int main(void)
{
  memcpy(String,  (void const *)eeString, 10);
  memcpy((void *)eeString, String, 10);
  return 0;
}

Скомпилируйте этот код и пройдитесь по нему отладчиком,
я думаю что результат Вас сильно порадует, особенно второй memcpy

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

[defunct]

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

Ок, аналогичный пример:

Код

char Str[]="Hello";
char SomeChar;
int main(void)
{
     memcpy( (void *)SomeChar, Str, sizeof(Str));
}

Проблема здесь та же самая что и в вашем примере, и даже без переменных в eeprom.
Поэтому можете также вместе с доктором ковырять и этот код. Ибо когда нет понимания, что происходит в программе и что может происходить - забудьте про (void *).

[singlskv]

Ок, аналогичный пример:

Код

....................

Проблема здесь та же самая что и в вашем примере, и даже без переменных в eeprom.

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

Насколько я знаю, в стандарте С вобще нет такого типа void __eeprom *

А вот теперь представьте себе:

Код

__eeprom char eeString[]="Prived !";
char String[10]="ABCDEFGHI";
int Int=1;
long Long=2;

typedef struct
{
    void *ptr;
    int  size;
} SomeData;

SomeData* MassivHrenZnaetSKakimiDannimy[10];
......................
  {
    MassivHrenZnaetSKakimiDannimy[0].ptr = eeString;
    MassivHrenZnaetSKakimiDannimy[0].size = sizeof(eeString);
    MassivHrenZnaetSKakimiDannimy[1].ptr = String;
    MassivHrenZnaetSKakimiDannimy[1].size = sizeof(String);
    MassivHrenZnaetSKakimiDannimy[2].ptr = &Int;
    MassivHrenZnaetSKakimiDannimy[2].size = sizeof(Int);
    MassivHrenZnaetSKakimiDannimy[3].ptr = &Long;
    MassivHrenZnaetSKakimiDannimy[3].size = sizeof(Long);
.............................
.............................
.............................
    memcpy(KudatoTam,  MassivHrenZnaetSKakimiDannimy[x].ptr, MassivHrenZnaetSKakimiDannimy[x].size);
..........................
..........................
  }

Хрен знает какие данные оказались не совсем хрен знает какими, а все по тому что
кое кто придумал свой новый тип данных... __eeprom xxx

[Сергей Борщ]

Насколько я знаю, в стандарте С вобще нет такого типа void __eeprom *

Мы не обсуждали портируемость. В других компиляторах нет eeprom_write_byte();, а в некоторых процессорах нет eeprom

А вот теперь представьте себе:

Код

    MassivHrenZnaetSKakimiDannimy[0].ptr = eeString;

Получаем ошибку компилятора о несоответствии типов. Ту самую, которую в предыдущем примере вы задавили явным приведением к (void *). Ту самую, которую вы получите в WinAVR, если попытаетесь присвоть (void *) переменную типа (void EEMEM *) или prog_void.

Где в этой проге можно написать cfg_EE = cfg_RAM ?

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

Но лучше (надеюсь, грамотные люди со мной согласятся) для конкретной задачи шевеления ногой писать макросы или online функции типа led_busy_on(), led_busy_off() и в коде использовать уже их. led_busy = 1, IMHO, хуже, разве что led_busy = ON ...

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

[singlskv]

Получаем ошибку компилятора о несоответствии типов. Ту самую, которую в предыдущем примере вы задавили явным приведением к (void *). Ту самую, которую вы получите в WinAVR, если попытаетесь присвоть (void *) переменную типа (void EEMEM *) или prog_void.

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

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

Упс..., это где это я агитировал за использование eeprom_write_byte() ?
Я этим ни разу не пользовался У меня свои функции.
Если Вас не затруднит ответьте таки конкретно на 2 моих вопроса из поста №37.



Все равно не понимаю в чем Вы пытаетесь меня убедить.

Код

/* Wait for completion of previous write */
while(EECR & (1<<EEWE));

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

Код

//==============================================================
// Автомат записи в EEPROM
//==============================================================
void EepromRun()
{

  if (EECR & (1<<EEWE)) return;                // идет запись ? да, тогда отваливаем (другие дела)

  if (CurrState == EE_FREE)
  {
     ...................................
     ...................................

}

Запись заканчивается не сразу после засылки адреса и данных

а после АППАРАТНОЙ записи - для мега16 это 8.5 ms типовое значение. Или Вы хотите сказать, что, буквы EEMEM автоматом вдруг делают неожидающей встроенную функцию
static inline void __attribute__ ((always_inline))
eeprom_write_byte (uint8_t *addr,uint8_t value);
? (Может, она случайно и неожидающая, но тогда ею пользоваться низзя) А не пробовали посмотреть, во что раскладывается аналогичная операция у IAR? Дык тоже инлайновый вариант.
Если не используем встроенные функции или модификаторы, а боремся за отсутствие ожиданий при работе с EEPROM, то пример задачи не к месту - в обоих случаях нужно писать СВОЁ.

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

[defunct]

Упс..., это где это я агитировал за использование eeprom_write_byte() ?
Я этим ни разу не пользовался У меня свои функции.

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

Код

void EEPROM_Dispatch(void)
{
    if (EECR & (1<<EEWE))
        return;
    ....
    if (*(__eeprom U8 *)адрес != data to write)
        *(__eeprom U8 *)адрес = data to write;
}

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

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

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

[singlskv]

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

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

Код

__eeprom unsigned char a=1;
unsigned char b;

void SomeFunc()
{
  b=2;
}

void EEPROM_Run()
{
  if (EECR & (1<<EEWE)) return;
  if (a != b) a=b;
}

int main(void)
{
  SomeFunc();
  EEPROM_Run();

  return 0;
}

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

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

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

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

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

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

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

Ну, раз вы агитируете за WinAVR и доступ функциями, раз вы нигде до этого не упомянули, что вами используется закат солнца вручную - телепатически я сделал вывод, что вы агитиреуте за реализованный в avr-libc метод.

Согласен, нужно было не расчитывать на телепатию собеседников и чуть
пораньше объяснить что я имею в виду.
А "закат солнца вручную" иногда очень эфективный метод

Это является расширением языка. Нормальные типы, ибо поддерживают все операции над данными - арифметику, присваивание, взятие адреса, обращение по указателю. Указатели на эти типы полностью аналогичны указателям на данные с __attribute__(("progmem")) и __attribute__(("EEPROM")), против которых (так получается) вы нас агитируете. Причем последние, в отличие от ИАРовских, не являются полноценными типами, ибо поддерживают только операцию взятия адреса и арифметику указателей.

ИМХО, это не нормальные типы, и мои примеры это показали.
Невозможность автоматического приведения указателя на такой тип к void* говорит
именно о том что тип неполноценен.
Считаю подход WinAvr(Gcc) в данном случае просто более честным.

Но, извините, а вы эти данные только пишете, и никогда не читаете?

Чаще конечно пишу, чтение в основном при первоначальной загрузке параметров.
Но иногда нужно и чтение в процессе работы, поэтому чтение тоже интегрированно в
этот автомат.

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

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

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

У меня такие случаи в каждом первом проекте.
Всегда нужно чего-нить писать во время основной работы...

[Сергей Борщ]

А "закат солнца вручную" иногда очень эфективный метод

Согласен, если выбора нет. А если он есть - смотря какой именно из парамеров оптимизировать

Невозможность автоматического приведения указателя на такой тип к void* говорит именно о том что тип неполноценен.

Не готов сразу ответить. "Чистый" С вообще не знает про разные адресные пространства. Да и как вы физически представляете приведение указателя на одно адресное пространство к указателю на другое? Только используя __generic указатели, что хоть и влечет дикий оверхед, но тем не менее реализовано в IAR.

Считаю подход WinAvr(Gcc) в данном случае просто более честным.

На самом деле он просто не доделан А пока он не только не честный, но как раз наоборот:

Код

uint8_t EEMEM EE_data;
uint8_t PROGMEM Const[] = "Tipa test";
void Test()
{
    uint8_t Tmp;
    Tmp = Const[0];
    EE_data = Tmp;
}

На фоне того, что такое компилируется молча и без ошибок тот факт, что на самом деле копирование происходит из ОЗУ в ОЗУ по совпадающим адресам кажется несущественным. Допустить такую ошибку гораздо проще (сам наступал), чем нарваться на случай, когда критично время записи в eeprom или ее ресурс. Тут четко видна недоделанность, ибо попытка присвоить что-либо Const все же вызывает сообщение об ошибке "попытка записи в read-only".

Чаще конечно пишу, чтение в основном при первоначальной загрузке параметров.

И при этом данные, которые вы читаете, всегда представляют набор байтов? Не int, long, float, структуры, а именно голые байты? Если же данные осмысленны, то почему не воспользоваться предоставляемыми компилятором средствами?

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

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

А зачем мне плодить сущности и увеличивать код ?

Ну хорошо, наэкономите 40 байт памяти, а смысл, если ее все равно осталось полкило а то и больше? Читаемость упала, возможностей оптимизации у компилятора меньше. Ясное дело, если утаптываем, то резать придется везде.

У меня такие случаи в каждом первом проекте. Всегда нужно чего-нить писать во время основной работы...

"У каждого есть свои маленькие недостатки" (с)"В джазе только девушки".

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

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

[singlskv]

На самом деле он просто не доделан А пока он не только не честный, но как раз наоборот:[code] EEMEM
PROGMEM
На фоне того, что такое компилируется молча и без ошибок тот факт, что на самом деле копирование происходит из ОЗУ в ОЗУ по совпадающим адресам кажется несущественным. Допустить такую ошибку гораздо проще (сам наступал), чем нарваться на случай, когда критично время записи в eeprom или ее ресурс. Тут четко видна недоделанность, ибо попытка присвоить что-либо Const все же вызывает сообщение об ошибке "попытка записи в read-only".

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

И при этом данные, которые вы читаете, всегда представляют набор байтов? Не int, long, float, структуры, а именно голые байты?

Автомат оперирует на уровне блока байтов + CRC.

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

Ну видимо у нас все-таки сильно разные задачки...

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

Кстати о портируемости , мой вариант кода эквивалентный коду из поста №54
скомпилировался без вопросов и на Gcc и на IAR