Программирование и JTAG-отладка микроконтроллера Atmega16 на языке C в среде IAR, часть 1

[@dcoder_mm]

Не у всех AVR есть JTAG, а так — можно.
easyelectronics.ru/ft2232d-i-avr-proshivka-i-otladka-po-jtag.html

[@DIHALT]

В avr я jtag почти не использую. Он там пригоден только для изучения. На серьезную отладку не тянет. Так как не очень стабильно работает на длинных прогонах. Теряет связь.

[@DIHALT]

А шить по нему можно. Более того это самый быстрый способ.

[@love_energy]

При каждой отладке JTAG-отладчик, по сути, зашивает Flash-память, если не выбрано обратного. Если потом выйти из отладки, микроконтроллер так и останется зашитым. Иначе была бы невозможна внутрисхемная отладка. Но если вы хотите только
зашить Flash-память, то из IAR это можно сделать так:

Показать скриншот

/spoiler>
Ну и через AVR Studio 4 можно JTAGICE'ом.

[@Int_13h]

Если инструмента нет, его надо написать, особенно для любителей опенсорса :) В протоколе тайны нет никакой:
www.atmel.com/images/doc2524.pdf
www.atmel.com/images/doc2587.pdf

[@Deranged]

Тут проблема в том, что это описание протокола обмена отладчика со студией. А JTAG-команды для отладки чипов засекречены. Энтузиасты надампили обмен с живыми девайсами, в результате чего появился HappyJTAG. А Atmel в ответ на это выпилило поддержку не юсбишного JTAG ICE из Atmel Studio 6. О чем, к слову, нигде на Хабре и на Easyelectronics не упоминается. Т.е. Atmel как бы говорит «НЕТ!» в сторону самопальных дебаггеров.
После некоторых мучений, попыток накатать кода для отладки через FTDI, как эмулируемый USB JTAG ICE, плюнул, и решил раз и навсегда перейти на изучение STM32 с их копеечным ST-Link'ом и дополнительными плюшками, при сопоставимых или меньших ценах на железки.

[@mnemoLinux]

Так купите за 2-3$ на ebay нормальный китайский usb isp. ;)

[@MadLord]

А нет, случайно, примеров для Renesas SH?

[@love_energy]

Работал только с Renesas RX. При знакомстве использовал примеры, идущие к библиотеке периферии. А что вам мешает почитать даташит и сделать такие примеры самому? Поверьте это проще, чем кажется. Вся задача во многом сводится к изучению регистров периферии. Чтобы микроконтроллер что-то сделал нужно настроить управляющие регистры, записывать и считывать данные из регистров данных, опрашивать флаги в регистрах статуса. Это без прерываний. Если используются прерываниями, то добавить обработчики событий предварительно разрешив их тоже в регистрах. Принцип везде один и тот же. Поймете его один раз и сможете любое семейство легко освоить. Уже в каком-то посте писал, про вот эти лекции Джеймса Конрада. Очень вам и всем остальным рекомендую. В них есть именно необходимые общие принципы и подходы к данному вопросу.

[@kegf]

Ничем не отличается. Но Е1 программатор/отладчик у них стоит космических денег ~$200.

Грубо помигать светодиодом (у меня на руках rl78/l12):
main.c

#include "iodefine.h"
#include "r_cg_macrodriver.h"
#include "main.h"
void Delay(volatile uint32_t nCount) {
    for (; nCount !=0; nCount--);
}

int main(void)
{
  LED2 = 0;
  LED2_DIR = 0;
  while(1)
  {
     LED2_DIR = ~LED2_DIR;
     Delay(0x7FFFF);
  }
  return 0;
}

main.h

#ifndef main
#define main

/* LEDs */
#define LED1                     P2_bit.no1
#define LED2                     P12_bit.no5

/* LEDs Port Direction */
#define LED1_DIR                 PM2_bit.no1
#define LED2_DIR                 PM12_bit.no5
#endif

[@gleb_l]

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

И здесь Си сам по себе сильно не помогает, так как обычно большинство реализуемой на МК программной логики так или иначе завязано на взаимодействие с периферией (напрямую, или с использованием макросов и подпрограмм из фирменных оберток). Если ресурсы позволяют, то хорошим дополнением к писанию на Си может быть использование какой-нибудь RTOS, имеющий платформонезависимый (ну, почти) HAL. Я в последнее время смотрю в сторону ChibiOS

[@love_energy]

То что вы пишите про переферию это верно и справедливо. Каждый новый микроконтроллер это новый набор переферийных блоков, их регистров. С этим я с вами полностью согласен. Но представьте на секунду, что у вас нет языка C. Тогда пришлось бы осваивать каждый раз ассемблер нового семейства. А у каждого микроконтроллерного ядра он свой. Вот примеры системы команд для MSP430, AVR, Cortex-M3. Хоть пересечения и есть, все равно тяжело быстро перейти от одного к другому. Для такой задачи обычно используется макроассемблер. В частности, создателям IAR приходится решать такую задачу.
По поводу ОСРВ(RTOS). Я работал с embOS, FreeRTOS, uC/OS-II. Щас работаю с uC/OS-II, но самой красивой по реализации инструментов межзадачного взаимодействия считаю embOS. FreeRTOS бесплатна, проста и удобна.
Все они завязаны на периферийный блок таймера, который выполняет функцию системного таймер ОСРВ. У каждого семейства это блок будет реализован в плане управляющих регистров по своему. Если используется USART для трасировщика, то тут та же история. Трасировщик для FreeRTOS, правда, уже и по JTAG работает.

[@gleb_l]

Я же совсем не против Си в процессе освоения новой для разработчика архитектуры — я всего лишь говорил, что Си закрывает только половину проблемы, а другую можно было бы закрыть кроссплатформенной RTOS — тогда «цена входа» была бы заметно ниже.

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

Из этого вывод — хотите 100% представлять и осознавать, что делает контроллер, выполняя вашу программу — начинайте изучение с уровня ассемблера. Потом для экономии времени можно будет перейти на Си. Хотите начать с более общего уровня — начинайте с Си, причем периферию и библиотеки производителя можно скрыть RTOS'ом — будет проще и легче — но не факт, что вы когда-нибудь доберетесь до полного понимания деталей/особенностей архитектуры.

[@love_energy]

причем периферию и библиотеки производителя можно скрыть RTOS'ом

Можете более подробно рассказать, что вы здесь имеете в виду?

[@gleb_l]

Прошу прощения — неправильно выразился — следует читать не «скрыть RTOS'ом», а «скрыть HAL'ом кросплатформенного RTOSа».

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

Конечно, такой слой абстракции может чего-то стоить в плане объема кода и производительности, но может быть и абсолютно бесплатным — если сделан на макросах/условной компиляции

[@Rulin]

Нужна такая же статья, только построенная полностью на использовании opensource решений

[@love_energy]

Вы только про среду разработки?

[@Eddy_Em]

Япона ж мать! Люди, ну сколько ж можно глумиться над атмелями? Померли — и фиг с ними! Нет, тащут зачем-то везде этих гигантских уродцев!!!

// Еще и в мастдайке… Ну полный /0!

[@Eddy_Em]

Оно ж места занимает — мама, не горюй!
А тем временем полным-полно микроконтроллеров в TSSOP-корпусах. Да еще и намного более дешевых и обладающих более приличной периферией!

[@Eddy_Em]

> что может быть дешевле какого-нито ATTiny, что у китайцев по полбакса за штуку в рознице?

Советую посмотреть, сколько стоит STM8S003! И какая там периферия!

[@alecv]

А в чем сейчас прогрессивная публика отлаживает/прошивает 2560? (Про mk2 не надо, имеется в виду «наколенное» решение).
А то лежит платка.