отладка программы для микроконтроллера.

[zuuuuk]

Вопрос для специалистов по микроконтроллерам и не только.

я использую gcc и для отладки gdb.
где можно почитать про отладочную информацию, которую помещает компилятор в программу? (gcc -g ..)

[Dale]

А что именно интересует? Полной информации у меня нет, но какие-то отдельные детали вроде были.

И еще вопрос: для какой цели? Может, эта задача проще решается? Я всегда обходился без этой информации.

[zuuuuk]

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

[Dale]

Вот пока попался на глаза формат исполняемого файла ELF. Там есть формат символьных таблиц. Вот здесь есть обзор DWARF: http://code.google.com/p/deebug/wiki/DwarfIntro .

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

какая отладочная информация передается с контроллера в компьютер?

Вот этот пункт вообще не понял, уточните, пожалуйста.

[zuuuuk]

какая отладочная информация передается с контроллера в компьютер?

Вот этот пункт вообще не понял, уточните, пожалуйста.

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

поясни, пожалуйста, что такое "среда модульного тестирования Unity"

[Dale]

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

Имеется в виду отладка при помощи JTAG и подобных интерфейсов?

Дело в том, что контроллер не понимает C. Пошаговая отладка ведется на двоичном уровне. Компьютер задает адрес точки останова, соответствующий оператору C, и передает эти данные эмулятору. Контроллер останавливается в этой точке, и эмулятор затем передает в компьютер состояние регистров, ячеек памяти и т.п. Отладчик на компьютере показывает эти данные в виде переменных/регистров МК.

Похоже, вас интересует протокол JTAG? Именно по этому протоколу идет обмен данными между компьютером и МК, но там нет никакой отладочной информации, порожденной компилятором. Вся эта информация остается на компьютере.

поясни, пожалуйста, что такое "среда модульного тестирования Unity"

Это довольно большая тема.

Если в двух словах: есть такое течение в современной программной инженерии, которое утверждает, что программный код, не подвергшийся тестированию, не может рассматриваться как качественный. Для тестирования отдельных программных модулей применяется модульное (юнит-) тестирование.

Наилучшие результаты такой подход дает, если тесты пишутся раньше, чем код. Однако для микроконтроллеров с этим не все так просто. Я когда-то пришел на форум именно с этим вопросом.

Попробуйте почитать пару моих переводов: https://club.shelek.ru/viewart.php?id=335 и https://club.shelek.ru/viewart.php?id=337 . Я именно с них начал разбираться в этой проблеме. Если возникнут вопросы, обсудим дальше.

[Dale]

И еще пару слов об отладке МК.

Я работаю с МК семействоа AVR. Для них есть компиляторы C гораздо более высокого качества, чем GCC, например, от IAR. Я выбрал GCC по той причине, что он реализован на массе платформ, в том числе на IBM PC под *nix и Windows. А это значит, что бОльшую часть кода можно безо всяких изменений отладить на компьютере, не загружая его в МК. То же касается и юнит-тестов.

Я в свое время запасся платой Atmel Dragon для отладки через JTAG, но так ни разу ее и не подключил - не было необходимости. Хорошо протестированный код и так работает без проблем.

[zuuuuk]

большое спасибо вы очень доходчиво мне все объяснили.

я бы хотел уточнить о unit test.
ты создаешь тесты  для каждого программного  модуля (функции) в микроконтроллере?
Т. е. фактически ты создаешь программную модель платы и тестируешь там свой код для микроконтроллера?

[Dale]

Идея юнит-тестирования пришла из объектно-ориентированных языков. Сейчас весьма популярно семейство фреймворков xUnit, реализованное на многих языках программирования. Лично я имел дело с JUnit для Java и NUnit для C#.

Юнит-тесты пишутся таким образом, чтобы протестировать интерфейс класса. Тестируется каждый метод, желательно иметь тест для каждого класса эквивалентности входных параметров. Впрочем, об этом сейчас довольно много пишут, литературы хватает с избытком.

Поскольку язык C не относится к объектно-ориентированным, напрямую применить эти методики к нему проблематично. Впрочем, при должном умении и на С вполне можно писать объектно-ориентированные программы, а значит, и юнит-тесты для них.

Хорошие результаты дает тестирование программ для МК на компьютере. На первый взгляд кажется, что это невозможно, ведь в составе МК есть масса периферии (таймеры, АЦП, различные интерфейсы), которых нет на ПК. К тому же при работе с ними используются специфические для МК конструкции языка C. На самом деле проблема решаема при правильном подходе. В программу вводится уровень абстракции от аппаратных средств (HAL, Hardware Abstraction Layer), и все взаимодействие с аппаратурой программа производит через него. Идея HAL не нова, она издавна примняется в мобильных операционных системах. В версии программы для компьютера широко используются объекты-дублеры (заглушки, моки, шпионы и т.д.), позволяющие производить полное тестирование кода. В целевой версии для МК остается лишь реализовать HAL, который компактен и прост.

[zuuuuk]

я прошу прощения что немного сместил тему форума. но тестирование кода для мк моя больная тема.

В целом я понял что HAL пишется на комп. и компилируется.
в место кода мк вставляются заглушки.
Потом mock заменяется настоящим кодом для мк. И что все это компилировать одним компилятором?
ведь для мк я буду использовать другой компилятор (iar, winAVR итд) чем для компа.

[Dale]

я прошу прощения что немного сместил тему форума. но тестирование кода для мк моя больная тема.

Эта тема волнует всех, кто хочет производить качественный софт. Ведь на реальных примерах оттестировать программу можно далеко не всегда. К тому же, если тестирование будет требовать применения ручного труда и затрат рабочего времени, его будут стараться проводить пореже, а это значит, что ошибки находить будут в основном пользователи.

Если хотите, можно начать новую тему о тестировании встроенных систем. Там тоже есть о чем поговорить.

В целом я понял что HAL пишется на комп. и компилируется.
в место кода мк вставляются заглушки.

Да, в общем правильно. Только не обязательно заглушки. В общем это называется "тестовые дублеры", а заглушки и моки - это их частные случаи. У дублеров есть довольно много разновидностей для разных целей.

А вообще стратегия именно такая. Если, например, наш контроллер должен читать ввод с клавишной матрицы и зажигать светодиоды, мы можем вынести в HAL абстрактные функции readKey() и setLightOn (Off). Для МК это будут реальные функции чтения/записи регистров, подавления дребезга и т.п., а для компьютера мы будем читать ввод с клавиатуры и выводить состояние индикаторов на экран. Это позволит нам протестировать логику программы, не загружая ее в МК и даже без симуляции.

Потом mock заменяется настоящим кодом для мк. И что все это компилировать одним компилятором?
ведь для мк я буду использовать другой компилятор (iar, winAVR итд) чем для компа.

Я именно поэтому и выбрал WinAVR, что он является клоном GCC, а значит, бОльшая часть кода будет компилироваться одинаково и для МК, и для компьютера. Не скомпилируется на компьютере только та часть, которая использует особенности МК, т.е. взаимодействует с аппаратурой. Но мы договорились выносить эту часть в HAL, поэтому вся нестандартная часть кода будет локализована, а не раскидана по программе. Именно поэтому я и не выбрал, скажем, IAR, который заточен под МК и дает лучший код и больше удобств - потеряю совместимость. Ну и попутно в перспективе проще будет переходить на другой МК, если возникнет необходимость.

[Dale]

Вот пример. Предположим, нам нужна простейшая программа, которая зажигает светодиод, когда мы нажимаем кнопку, и гасит его, когда мы отпускаем ее. Протестируем по всем правилам.

Сначала проектируем абстрактный интерфейс с оборудованием (как часть HAL) (примеры набраны наспех и не проверялись компиляwbtq, причем работа с консолью взята из MS VC++, поэтому совместимость с библиотекой GCC не гарантирую, просто показываю сам принцип):

Код: (C)

// iodriver.h

extern unsigned char readKey(void);
extern void setLightOn(void);
extern void setLightOn(void);

Затем реализуем заглушку для прогона на компьютере:

Код: (C)

// iodriverStub.c

#include "iodriver.h"
#include <conio.h>
#include <stdio.h>

unsigned char readKey(void)
{
  if (!_kbhit)
    return 0;
  return (unsigned char)_getch();
}

void setLightOn(void)
{
  printf("Light is on\n");
}

void setLightOff(void)
{
  printf("Light is off\n");
}

Теперь основная программа:

Код: (C)

// main.c

#include "iodriver.h"
...
void main (void)
{
  ...
  for (;;)
  {
    if (readkey())
      setLightOn();
    else
      setLightOff();
  }
}

Компонуем main.o с iodriverStub.o, запускаем, наслаждаемся. Затем реализуем iodriver.c, в котором собрана вся работа с оборудованием, и компилируем версию для МК. Заметьте, что большинство исходных файлов не меняется, включая заголовок iodriver.h, а они уже оттестированы на компьютере.

Конечно, на самом деле это не тестирование, а скорее простенькая демонстрация выполнения программы для МК на компьютере. Тестирование - это отдельная глубокая тема. Здесь я лишь постарался показать на примере, как можно написать программу для МК так, чтобы ее можно было выполнить на компьютере с минимальными переделками кода.

[Sla]

А теперь ПИД- регулятор...

[Dale]

А теперь ПИД- регулятор...

Да в принципе то же самое, только деталей побольше

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