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

[defunct]

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

В вашем примере баг абсолютно такой же как и в моем.
Ибо нефиг несовместимый тип приводить к PVOID.

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

В AVR три адресных пространства. Насколько это удобно или неудобно не вам судить, и не мне. Они просто есть, IAR дает нам простой инструмент доступа к этим адресным пространствам, если вам такой способ доступа не подходит - пользуйтесь другим, более сложным.

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

Кому что.. Меня как правило интересует конечный результат, если воспользовавшись фичей X я смогу добиться конечного результата меньшим числом строк кода и не в ущерб наглядности, читабельности программы и скорости испольнения, то обязательно ей воспользуюсь (по крайней мере подумаю об ее использовании). Минусом будет только "Портируемость" внутри семейства и на другие многоадресные семейства МК, а на "протируемость" на одноадресные МК (напр ARM) оно вообще никак не повлияет.

Да и палку вы здесь перегибаете. Что может быть понятнее присваивания?
x = y;

[singlskv]

Да и палку вы здесь перегибаете. Что может быть понятнее присваивания?
x = y;

Хорошо, будем говорить тока за себя,
лично мне очень не нравится ситуация когда
x=y; выполняется несколько сот наносекунд, а
e=k; (где e - eeprom) выполняется несколько миллисекунд.

Ну и остальные отрицательные стороны использования EEPROM как переменных я
уже описал выше.

[defunct]

e=k; (где e - eeprom) выполняется несколько миллисекунд.
Ну и остальные отрицательные стороны использования EEPROM как переменных я
уже описал выше.

Ну и что?! У eeprom еще и ресурс ограничен, такова уж особенность этой памяти.
100k раз запишете дальше пойдут сбои.
Какое это имеет отношение к удобному механизму обращения к этой памяти?

Не нравится медленный внутренний eeprom используйте RAM или ставте быстрый внешний FRAM, но удобного способа доступа к нему средствами компилятора уже не будет, придется писать драйвер.

[singlskv]

Ну и что?! У eeprom еще и ресурс ограничен, такова уж особенность этой памяти.
100k раз запишете дальше пойдут сбои.
Какое это имеет отношение к удобному механизму обращения к этой памяти?

Похоже Вы невнимательно читаете мои посты,
перечитайте пожалуйста №37, и если Вас не затруднит,
ответьте на 2 поставленных мной вопроса,
продублирую их на всякий случай:

НО, объясните мне как Вы будете пользоваться такими присвоениями в следующей
ситуации:
Есть прога:
- все события(опросы) синхронизированны(системный тик) например с тактом 200-500мкс
- есть одно или несколько прерываний которые получают данные
- есть основной цикл который ведет обработку полученных в прерывании данных
- НУЖНО, не прерывая обработку, писать некоторые изменения соcтояния проги в EEPROM

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

.......................
Как Вы думаете, в среднем, какой вариант общения с EEPROM будет более
быстрым и более надежным(в смысле ресурса EEPROM) ?

[defunct]

[i]НО, объясните мне как Вы будете пользоваться такими присвоениями в следующей
ситуации:
Есть прога:
- все события(опросы) синхронизированны(системный тик) например с тактом 200-500мкс
- есть одно или несколько прерываний которые получают данные
- есть основной цикл который ведет обработку полученных в прерывании данных
- НУЖНО, не прерывая обработку, писать некоторые изменения соcтояния проги в EEPROM

Для этой задачи я поставлю исключительно внешний eeprom либо NVRAM и не буду даже морочиться с внутренним, которого судя по условию задачи просто не хватит для хранения какого либо существенного объема статистики.
Внутренний eeprom лично я использую только для: хранения параметров конфигурации устройства, хранения информации о рестартах + дамп критических структур в случае перезагрузки по WDT.

Как Вы думаете, в среднем, какой вариант общения с EEPROM будет более
быстрым и более надежным(в смысле ресурса EEPROM) ?

Я думаю, что вариант общения должен быть обдуманным, т.е. надо минимизировать число записей. При этом инструмент которым непосредственно производится запись/чтение может быть каким угодно, но желательно простым, что нам и дает IAR.