roboforum.ru

Ежели кто не знает - релиз WinAVR 20100110 был последним в том виде как мы его знаем. Последующие релизы будут выпускаться уже Atmel, вероятно, в составе AVR Studio. Эрик Уедингтон (Eric Weddington), основатель и майтейнер проекта, уже давно работает на Atmel.

Как это ни парадоксально, WinAVR включал новейшие патчи раньше, чем тулчейны в составе дистрибутивов Linux.

Ссылки по теме:
http://lists.nongnu.org/archive/html/av ... 00015.html
http://www.avrfreaks.net/index.php?name ... 0&highligh

на мой взгляд хорошее слияние будет... еще бы нормальный редактор с подсветкой и старт визард как у CodeVisionAVR было бы вообще прелесть...

А меня, честно говоря, пугает такое стремительное, но экстенсивное развитие.
(впрочем я это во многих проектах наблюдаю).
Что принципиально нового добавилось в последних версиях (ну кроме поддержки новых чипов)?

Я вижу реально, что код становится с каждым разом все объемнее и тормознее (например если
сравнивать с древним ГЦЦ 2.9)... Некоторые невнятные моменты (не то чтобы ошибки, просто "странности" компилятора) продолжают поворяться из версии в версию... И такое ощущение,
что разработчикам все больше и больше наплевать на качество генерируемого кода...

С другой стороны, а что появилось принципиально нового, может поддержка плюсов? или реентерабельные библиотеки? - фига с маслом!...
Из более-менее значительного со времен 2.9 (а это оч давно) пожалуй припомню только:
- Изменились соглашения о регистрах для аргументов и результатов функций (примерно в 3.10)
- Появилась в библиотеках прямая поддержка регистров ввода-вывода
(и некоторые алиасы для совместимости с IAR)
- Начали генериться нормальные coff, а потом и студия стала поддерживать elf

Но при чем здесь падение качества кода???

Добавлено спустя 20 минут 8 секунд:

blindman писал(а):Как это ни парадоксально, WinAVR включал новейшие патчи раньше, чем тулчейны в составе

Тут нет никакого парадокса.
Если вы посмотрите незамыленным реальным взглядом, то вы увидите,
что набор средств разработки под винду изначально был гораздо богаче
(компиляторов, программаторов, симуляторов, кадов, сред для ФПГА и т.п.)
В том числе и бесплатных, и условно-бесплатных...
И разработчик по факту сидел (и во многих случаях продолжает сидеть) под виндами.
Да, есть, правда, огромный класс встроенных осей с пра-линуксовым ядром,
но одно другому не мешает - потому что от кросс-компиляции так и так никуда не денешься.

Да, в последнее время немножко (совсем чуть-чуть) стали двигаться
удобные средства для никсов... Но, имхо, им еще плясать и плясать...
Про высокоинтегрированные среды (типа протеуса, например) я просто молчу.

WinAVR это хорошо. Каковы его недостатки ?

Michael_K писал(а):Тут нет никакого парадокса.
Если вы посмотрите незамыленным реальным взглядом, то вы увидите,
что набор средств разработки под винду изначально был гораздо богаче

При чем тут это? Весь тулчейн - изначально никсовый, его чтобы просто собрать под windows нужны костыли типа mingw

Разработчики сидят под виндами и заинтересованность пользователей в виндовой версии гораздо выше.

Вопросы по WinAVR В коде старинном вот такая фигня:

static inline uint16_t time( void )
{
return __inw_atomic ( TCNT1L );
}

в доке 2002 года написано что это в io.h было, в новом нет конечно теперь в
#include <util/atomic.h>

Как мне написать это в современном варианте ? Вот наметка:

static inline uint16_t time( void )
{
uint16_t temp;
ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
temp = ((uint16_t) TCNT1L) | ((uint16_t)TCNT1H <<8);
}
return temp;
}

Как то коряво.

1) можно ли return засунуть в атомик блок и написать сразу без применения temp
return (((uint16_t) TCNT1L) | ((uint16_t)TCNT1H <<8));

2) нужны ли прведения типов тут ?

3) как красиво написать ?

4) решено где посмотреть, найти старую io.h или исходник её - чтоб посмотреть как там было. Есть где то архив GCC 3.01
Dead подсказал что архив WinAVR там - http://sourceforge.net/projects/winavr/files/

1. Да
2. Нужны перед сдвигом - потому что сдвиг 8-битного значения на 8 разрядов не имеет смысла
3.

Код: Выделить всё

uint16_t time(void)
{
   ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
   {
      return TCNT1;
   }
}


Большое спасибо за помощь, так напишу.

Блиндман, а разве при таком ретерне рестор отработает?

Отработает. Переменная для сохранения состояния макросом объявляется с атрибутом __cleanup__(__iRestore), в __iRestore восстанавливается SREG

Какая опция оптимизации в WinAVR на максимальную скорость ? Размер кода совсем не важен.

-O2 хотя для авр не редко -Os оказывается быстрей.
Во всяком случае для gcc < 4.5.

Вообще максимальная оптимизация по скорости — -O3, но не всегда она оправдана.

Спасибо. Я как-то интуитивно тыкнул посередке -О2 Потом погоняю с разными - замерю.

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