Порты 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.
У меня есть свой хорошо работающий автомат записи.

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

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

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

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

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

Если Вас не затруднит ответьте таки конкретно на 2 моих вопроса из поста №37.

Вопросов я там нашел два: 1)Где там использовать встроенные функции. Да, согласен, я не обратил внимание на 200-500 мкс, что меньше, чем время записи. Согласен, что в этом случае надо использовать самописные функци. Но, извините, а вы эти данные только пишете, и никогда не читаете? Если все же читаете, то что мешает использовать простые и удобные встроенные возможности компилятора?
Ваш вопрос номер два - про ресурс. Мне кажется, я на него ответил исчерпывающе - если ресурса хватает с запасом (а это наиболее частый случай, как в примере - при хранении конфигурации) то не имеет смысла тратить усилия на его экономию. Если он важен - можно сделать побайтовую запись с анализом.

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

В том, что встроенная поддержка данных в eeprom и flash не вредное (как вы утверждаете), а напротив очень полезное и удобное (первое вытекает из второго) расширение компилятора.

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

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

[Qwertty]

Вопросов я там нашел два: 1)Где там использовать встроенные функции. Да, согласен, я не обратил внимание на 200-500 мкс, что меньше, чем время записи. Согласен, что в этом случае надо использовать самописные функци.

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

[Proton]

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

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