Пока особо в направлении работ по JTAG на базе платки FTDI не стал зпробираться.
Собственно самих микросхем не так уж и много, отладка «по старинке2 вполне устраивает… Да и саму платку с FTDI весьма жалко… Отложено на стадии превращения платки в «DIP модуль» - попозже может еще чего надумается.
КАПЛЯ ДЕГТЮ на "розовы мечты с колубой каёмочкой".В то же время перечитал подборку-книжу от DiHalta…
Особо часть из второй версии относительно работы с памятью программ.
Пресловутое PROGMEM.
Этот раздел работ с МК под СИ (как и указатели) весьма «смутно-узкое» место относительно имеющихся наработок под ассемблером.
Ежли с указателями еще так-сяк разобраться можно, то работа с массивами в ПЗУ для АВРок в СИ и в ассемблере явно не равноценны.
Да еще и относительно ардуины правописание совсем… МНДЯАА…
Хош аки говорят – «тот же GCC»…
Собственно базовое отличие от того, что у DiHalta заключается в обязательном префиксе CONST в начале строки описания массива.
Как указано в адуриньей референсе по PROGMEM допустимо объявление:
«…
const dataType variableName[] PROGMEM = {}; // use this form
const PROGMEM dataType variableName[] = {}; // or this form const dataType PROGMEM variableName[] = {}; // not this one…»
без указания «const» компилятор пошлет нас подальше. Отсюда и «мелкие нюансы», позднее выползающие в объявлениях/описании функций обработки тех массивов ПЗУ – обязательное указание типа указателя на массив как, к примеру, const byte *ptr …
При том, что и вариант byte *ptr также проходит и компилируется – но с парой – тройкой матюков/вармингов на возможное некорректное преобразование типов.
По крайней мере в моем примере (
) с массивом знакогенератора (не символьной строкой!)
при подобном удалении const из описания указателя на массив компилятор выдает:
…
Дополнительно та особенность, что указана у DiHalta –
Объявление и инициализация массивов в ПЗУ допускается только перед функциями MAIN – в случае с адуриньей это перед тандемом
Кстати… те массивы и компилируются в область между таблицей векторов прерываний и основной программой
(см. пример в архиве ).
В то же время (по крайней мере в ардуинке), непосредственная вставка в теле программы допустима лишь для строк типа char.
У ардуино это вариант F (вместо применяемого в GCC PSTR)
«…
Serial.print(F("Write something on the Serial Monitor that is stored in FLASH"));…»
Однако такой вариант для массива данных (тот же инлайн знакогенератор к примеру) не подходит…
Посему явно преимущество за ассемблером «в чистом виде» - там можно массивы данных в ПЗУ размещать в любом месте программы и с любой интерпретацией их (массивов данных) содержимого.
И «на закусь» для размышления любителям «нестандартных адурин».
Помимо стандартного «джентльменского набора», поставляемого в комплекте ардуино IDE существует и множество любительских «и не очень» дополнительных вариантов «инструмент – плата».
ВОТ…
У меня установдены и от DIY (похоже сейчас можно не найти)
(
https://raw.githubusercontent.com/sleem ... index.jsonhttps://raw.githubusercontent.com/sleem ... index.json)
И от иных разработчиков…
Воть и решил свой тест-проектик простейшей считалки секунд
http://img.radiokot.ru/files/20529/1txrpavvnn.jpgна них «прогнать» …
Ведь заявлены - то ОДИНАКОВЫЕ базовые платформы.
Воть чего из того теста получилось:
продолжаем тесты
ладно... ставлю
Далее еще интереснее:
Ставлю
Воть так фокус...
Значит «https://mcudude.github.io» мой тестик для "родной" 328й
сочло "недопустимым", а для 8515 - нормально схавало...
то же и в случае с 8535
в то же время большинство «mcudude.github.io» платформ выкидывают представленный выше
"типовой матюк"
(
collect2.exe: error: ld returned 5 exit status
exit status 1
Ошибка компиляции для платы)
ессно при одном и том же представленном тесте.
ЧУДЕСА...
Приложением два архивчика:
собственно исходный вариант без PROGMEM
и "модернизированный" с примитивным знакогенератором, прописанным массивом данных в ПЗУ
это "учебно-тренировочный материал" для понимания вышеописанного.
ардуино-IDE версии 1.8.8 со всеми на текушшу дату обновлениями.