1. среда разработки (компилятор/транслятор)

[ALexx 0]

Изначально пошел по пути CodeVision+VMLab, о чем еще ни разу не пожалел.

 

Кстати, для приверженцев VMLab: на сайте производителя доступна полная последняя бесплатная версия.

http://www.amctools.com/

[MakSV 0]

Использую IAR EWAVR 4.11A + AVRStudio, удобно и наглядно

[zltigo 2]

В качестве инструментария: пакет EWAVR + мощный сторонний программерский редактор SlickEdit. Сборка под управлением gnu make, от самого EWAVR используеются компилятор, асм, линкер, библы, ессно, ну, словом, все то, что необходимо для компиляции. Саму оболочку использую только для запуска C-SPY.

Абсолютно такой-же подход и набор, только редактор MultiEdit заметно переписанный за долгие годы

использования "под себя".

[artStinger 0]

Для написания использую MED - programmer's text editor , компилирую avrasm-ом, а отлаживаю в AVRStudio 4.11 + макетные платы....

[beer_warrior 0]

gcc адназначна.

1.полный тулчейн под avr msp arm win32 *nix etc.

2.нет привязки к системе/реестру - живет все на флэше.

3.Гарантированная лицензионная чистота

---

Special to Polaris - с тулзами юниксовского происхождения -

"Тяжело в учении - легко в бою"

[Old1 0]

Использую EWAVR 4.12 (evaluation) от IAR (компилятор + отладчик) + Proteus+JTAGICE(планирую использовать, сам девайс находится в стадии изготовления).

1)EWAVR: про сам компилятор уже говорено достаточно; отладчик C-SPY ИМХО практически ни чем не уступает студии (если не считать того, что не симулируются внутренняя периферия, но я это большим недостатком не считаю), радует то, что можно моделировать внешние воздействия при помощи системных макросов C-SPY, студия такой возможности не дает...

2)Proteus: использую его (несмотря на многочисленные глюки) для экономии времени; пока макет разрабатываемого девайса находится в стадии изготовления (а поскольку я его делаю обычно сам, процесс это длительный...), создаю модель этого девайса в proteuse и прогоняю код на ней, когда появляется девайс работаю уже с ним...

3)JTAGICE: пока еще не явлюсь счастливым обладателем этого эмулятора, но когда закончу его изготовление, планирую использовать его совместно с С-SPY, надеюсь, что все получится...

Замечание по использованию симуляторов. Мое ИМХО: иногда существуют ситуации когда когда при отладке больше толка от симулятора. Пример такой ситуации - разработка и отладка последовательного протокола обмена данными. Использование симулятора при отладке протокола позволяет, например прогнать процедуру приема(предачи) данных пошагово и побитно, что ИМХО проблематично сделать на "живом" девайсе даже с внутрисхемным эмулятором...

[defunct 0]

Пример такой ситуации - разработка и отладка последовательного протокола обмена данными. Использование симулятора при отладке протокола позволяет, например прогнать процедуру приема(предачи) данных пошагово и побитно, что ИМХО проблематично сделать на "живом" девайсе даже с внутрисхемным эмулятором...

 

Мне наоборот кажется, что здесь никаких проблем с внутрисхемной эмуляцией нет.

Внешняя периферия (UART/SPI и т.п.) работает на реальных скоростях, т.о. данные будут доставлены на целевое устройство даже если ведется пошаговая отладка. А если программная эмуляция протокола, тогда еще проще, можно даже уровни порта менять вручную.

 

У меня всё нормально (v3.20D - v4.12A). Попробуйте изменить скорость JTAG.

 

4.12A пока скачать не представилась возможность. Пробовал на 4.11A.

Понизил скорость JTAG до 28kHz, подвисать перестало, но теперь другая проблема, если девайс оставить на прогонку (под отладкой на 20-30 минут работы), то потом наблюдаются проблемы с остановом, JTAGICE теряет отлаживаемый девайс...

[Old1 0]

Пример такой ситуации - разработка и отладка последовательного протокола обмена данными. Использование симулятора при отладке протокола позволяет, например прогнать процедуру приема(предачи) данных пошагово и побитно, что ИМХО проблематично сделать на "живом" девайсе даже с внутрисхемным эмулятором...

 

Мне наоборот кажется, что здесь никаких проблем с внутрисхемной эмуляцией нет.

Внешняя периферия (UART/SPI и т.п.) работает на реальных скоростях, т.о. данные будут доставлены на целевое устройство даже если ведется пошаговая отладка. А если программная эмуляция протокола, тогда еще проще, можно даже уровни порта менять вручную.

Представьте ситуацию: вы написали процедуру приема/отправки байта в последовательном режиме (аппаратный УАРТ или другие уст-ва не используется), с внешнего устройства на отлаживаемый девайс приходит байт в последовательном коде (например по RS232, скорость 9600), задача пошагово пройти процедуру приема/отправки этого байта, т.е проверить как принимается/отправляется каждый бит принимаемого/отправляемого байта. Приемопередатчик внешнего устройства выкинет вам 10 бит, которые проскочат за ~1 мс, и что вы увидите в пошаговой отладке?... ИМХО если использовать точку останова, то можно проконтролировать 1 бит, остальные пролетят мимо, потому что передающую сторону остановить невозможно... А в симуляторе по крайней мере с этим проблем нет (но только с этим :))... Описанная ситуация редкая и примитивная, но иногда встречается.

[dxp 65]

Представьте ситуацию: вы написали процедуру приема/отправки байта в последовательном режиме (аппаратный УАРТ или другие уст-ва не используется), с внешнего устройства на отлаживаемый девайс приходит байт в последовательном коде (например по RS232, скорость 9600), задача пошагово пройти процедуру приема/отправки этого байта, т.е проверить как принимается/отправляется каждый бит принимаемого/отправляемого байта. Приемопередатчик внешнего устройства выкинет вам 10 бит, которые проскочат за ~1 мс, и что вы увидите в пошаговой отладке?... ИМХО если использовать точку останова, то можно проконтролировать 1 бит, остальные пролетят мимо, потому что передающую сторону остановить невозможно... А в симуляторе по крайней мере с этим проблем нет (но только с этим :))... Описанная ситуация редкая и примитивная, но иногда встречается.

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

[Old1 0]

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

Ну принял байт неправильно, а вот где неправильно бывает сразу невидно, причины почему не видно могут быть разные... (скажем "глаз замылился" :)), тогда взял и в симуляторе прогнал "больное" место...

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

Бывает и так. Я не предлагаю повсеместно использовать симуляторы, а только лишь в исключительных случаях...

[sseett 0]

Начинал с AVR-Studio (atmel-avr-asm), но случайно наткнулся на Algorithm Builder

http://home.tula.net/algrom/russian.html.

Первое впечатление - забавная игрушка.

Освоение шло туго, мешали сложившиеся стереотипы при использовании классического ассемблера.

Но заставил себя и не жалею. Выигрыш во времени потраченного на разработку проекта, как и обещал автор, составляет от 3 до 5 раз. Среда имеет удобный, приятный симулятор,

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

Динамичное развитие (до нескольких обновлений в месяц), хорошая поддержка (исправление ошибок, учет пожеланий пользователей).

К сожалению, среда заточена только под AVR. И соответственно запросто (по утверждениям любителей С) перенести проект на другой камень невозможно.

Развитие, модернизация, появление новых семейств MCU происходит бурными темпами,

и чтобы иметь богатство выбора, придется заставить себя осваивать С.

[IgorKossak 0]

... К сожалению, среда заточена только под AVR. И соответственно запросто (по утверждениям любителей С) перенести проект на другой камень невозможно.

Развитие, модернизация, появление новых семейств MCU происходит бурными темпами,

и чтобы иметь богатство выбора, придется заставить себя осваивать С.

B)

Как только освоите С, обнаружите, что время на разработку проекта ещё более сократится и тон безысходности пропадёт точно также, как и напряг от преодоление стереотипов в случае с Algorithm Builder.

[SapegoAL 0]

В прекрасном будущем :) хочу забодать JTAG...

 

Кстати на счёт Jtag2. Преобрёл. :) Деньги не малые. Но всё не так безоблачно, хотя в некоторых случаях спасает. Так радовался, что ввели останов по условию, - опять промашка "для 88 не работает". Если симулятором нормально пользоваться, впрочем как и др. инструментами, то очень помагает. Есть у меня примочка ещё одна аппаратная. Для отладки протоколов. Весь протокол сбрасываю в файл на живую. А потом прога у меня есть, - просматриваю типа осцил. запоминающего. Очень помогает! Прогой могу поделится, она моя.

[NightCat 0]

Можно глупый вопрос?

Есть какие-то еще "ну очень сильные стороны" IAR, из-за чего его так любят?

(Я новичек.)

Спасибо.

[defunct 0]

Есть какие-то еще "ну очень сильные стороны" IAR, из-за чего его так любят?

Cамая сильная сторона, как я понял поигравшись с IAR, - это лучший из имеющихся под AVR компилятор С. Кроме того к сильным сторонам можно причислить то, что это практически единственный компилятор с поддержкой 64-bit арифметики с плавающей точкой для AVR. Ну и дополнительный плюс - IAR'ом поддерживаются почти все популярные на сегодня семейства МК.