ARM7TDMI
(дневник освоения ARM)
Выбор остановил на продукции Atmel. Причины примерно такие... ПРИВЫК к названию :), за все время "общения" НИ ОДНОЙ "битой" детали (микросхемы/контроллера). В "соперниках" был PHILIPS с LPC2xxx. Чтение форума помогло мало. Сравнить LPC2xxx с AT91SAM7Sxxx без знаний архитектуры, основываяь на сведениях о AVR весьма затруднительно...
Из описаний на русском языке:
- для LPC - книга (есть и в продаже, и в Инете)
- для AT91SAM7 - описание/перевод (но не полный!!!) datasheet на GAW.ru
По цене и доступности примерно одинаковы. Си компиляторы поддерживают и LPC, и AT91... ну и т.д.
Для скорейшего (быстрого) старта решил приобрести отладочную плату. Выбор остановил на модуле uSAM-R от Оrion-micro . От общения с компанией только приятные впечатления, да и цены разумные...
Модуль готов к немедленной эксплуатации. Достаточно подключить его к USB разъему.
Скачал с сайта Atmel SAM-BA и SAM-Prog и с успехом прошил прогамму через втроенный в ARM загрузчик (через USB, кстати, USB шнур входит в комплект поставки модуля).
Неудобство "самостоятельной" (отдельной) эксплуатации модуля и экспериментов "с нуля" состоит в том, что для того чтобы подготовить ARM для очередной прошивки, т.е. стереть старую и "активизировать" (перенести из ROM во FLASH) втроенный загрузчик, необходимо коммутировать перемычку (какую и куда, как собственно и сама перемычка все подпобно написано в "Инструкции..." к модулю).
Потому был изготовлен Wiggler:
Для изготовления макетной платы создал библ.элемент. модуля uSAM-R. Только будьте внимательны, этот элемент соответсвует модулю uSAM-R v.1.0. Для других модификаций проверка не производилась.
Выбор компилятора прозводился между Keil и IAR. Пытался разобраться (изменить программу на "свой лад") в примере "Blink" (такой пример есть в обоих компи-рах). В Keil'е этого сделать так и не получилось. (это отнюдь не характеризует Keil как "непонятный". Не получилось имеено у меня, да и как только получилось в IAR'е, попытки разобраться с Keil'лом были оставлены). "Религиозные рассуждения" о производительности и удобности компиляторов в расчет я не примал. В итоге, остановил свой выбор на IAR.
Wiggler к IAR'у подключил через H-JTAG. Программирую через Н-Flasher. Кстати, Н-Flasher "принимает" hex-файлы, то есть переводить в bin не нужно.
Теперь о неточностях, которые уже втретились:
- в примере от IAR
//*--------------------------------------------------------------------------------------
//* Function Name : change_speed
//* Object : Adjust "LedSpeed" value depending on SW1 and SW2 are pressed or not
//* Input Parameters : none
//* Output Parameters : Update of LedSpeed value.
//*--------------------------------------------------------------------------------------
void change_speed ( void )
{//* Begin
if ( (AT91F_PIO_GetInput(AT91C_BASE_PIOA) & SW1_MASK) == 0 )
{
if ( LedSpeed > SPEED ) LedSpeed -=SPEED ;
}
if ( (AT91F_PIO_GetInput(AT91C_BASE_PIOA) & SW3_MASK) == 0 )
{
if ( LedSpeed < MCK ) LedSpeed +=SPEED ;
}
}//* End
, т.е. в описании функции указывается одна кнопка, а в теле функции обрабатывается другая. Понятно, что ни "на скорость", ни на "точность стрельбы" это не влияет. Но на мой взгляд, такие неточности не допустимы.
- на GAW в разделе описания контроллера параллельного ввода-вывода (28.5.1 Управление подтягивающими резисторами):
написано: "... Записью в эти регистры производится запись 1 или 0 в соответствующие биты регистра состояния PIO_PUSR. Чтение 1 означает, что соответствующий подтягивающий резистор разрешен, а 0 - запрещен...."
хотя в первоисточнике:"....Reading a 1 in PIO_PUSR means the pull-up is disabled and reading a 0 means the pull-up is enabled..."
... "А если бы он вез патроны?" (с)
Для отладки программы удобно пользоваться вот таким решением:
"...Это разновидность brute force debugging - то есть отладки с модификацией своей программы.
Обычно пишется своя функция putchar (или putc, не помню, читайте доку по вашей libc) и подключается к библиотечной функции printf. Эта putchar выводит в уарт контроллера заданый символ.
Потом пишется макрос #define DEBUG_PRINTF(...) printf(__VA_ARGS__) и вставляется в некий serialdebug.h, который подключается как #include везде где только можно.
И после этого в вашей программе в любом месте (ну желательно не в обработчике прерывания и подобных критичных по времени местах) пишется например DEBUG_PRINTF("Елки, оно ж сюда вообще заходить не должно!!! x=%p, y=%d",x,y). И при выполнении этого участка программы на экране вашего компьютера, подключенного COM-портом через MAX232 или аналогичный конвертор к упомянутому уарту МК вы увидите надпись.
Преимущество метода в том что программа ваша не останавливается при отладке (иногда это лучший метод понять что происходит), недостаток - в том что если нужно посмотреть другую переменную или что-то поменять - нужно пересобирать и заново заливать в контроллер программу. В общем - каждому свое.
Да, после того как ваша программа достаточно приблизилась к идеалу - заменяете дефайн на пустой #define DEBUG_PRINTF(...) и все эти задержки на вывод отладочной инфы пропадают........." (с) boez
25.12.07г. В примере использования UART от IAR используется DMA. Что значительно этокомит как ресурсы камня, так и упрощает вывод, в сравнении с использованием printf()-подобных функций. При выводе строки функция printf() сначала форматирует эту строку в соответствии с указанными аргументами, а затем выводит посимвольно через putchar(). Что медленнее потокового вывода, да и для работы требует большого стека (по отдельным "источникам" до 500 байт).
Если пренебречь форматным выводом (то есть будет нельзя вывести сообщение типа: "Значение переменной X равно /значение/."), то функция вывода получается весьма тривиальной (при использовании примеров от IAR конечно ;-) )
... в подключаемой библиотеке функций (lib_AT91SAM7S256.h) есть две готовые функции: AT91F_US_PutChar(...) - вывод символа в порт (просто записывает символ в порт передатчика) и AT91F_US_SendFrame(...) - вывод двух массивом памяти в порт, с использованием DMA.
Создал, как и рекомендовано на форуме, да и в Help'e, свой файл с макросом:
#include <string.h> // для функции strlen
#if DEBUG
#define DEB_PRN(Buffer) AT91F_US_SendFrame(AT91C_BASE_US1,Buffer,strlen(Buffer),0,0)
#else
#define DEB_PRN(Buffer)
#endif
, этот файл "подключаю" там/туда где использую сообщения отладки, а в начале main() определяю DEBUG ... 1 или 0, в зависимости от того нужны или нет сообщения отладки.
Вместе с тем, отсутствие форматного вывода весьма ограничивает информативность сообщений отладки. Есть "механизм" форматированного вывода в строку (vsprintf()), а не в сразу в порт, но при этом все "особенности" printf() "возвращаются" (стек, посимвольный вывод в формируемую строку, необходимость наличия буфера для строки и т.д.)....
Продолжение следует...
(C)STAS633
12.12.07г.-25.12.07г.
