Порты 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();

[Непомнящий Евген...]

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

Код

#define _clrL(port,bit)         do { port |= (1 << bit); } while(0)

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

Код

#define _clrL(port,bit)         port |= (1 << bit)

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

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

Код

#define _clrL(port,bit)         do { port |= (1 << bit); } while(0)

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

Код

#define _clrL(port,bit)         port |= (1 << bit)

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

[defunct]

Конечно, если пользоваться только С++, то можно реализовать то же самое при помощи static inline функций, но пропадет универсальность в виде совместимости с С.

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