Ну или опять Keil. Понимаю, что под виндой, но виртуальной виндой. Собственно её (винду) и держу ради нескольких программ. Бывает, что устройства в сборе нет... да и отладить надо только контроллер, точнее прошивку для него. Ну и: Тут надо посмотреть динамику выполнения, точнее изменения параметра программой Тут смотрим загрузку ядра функциями программы в динамике Тут используем функционал виртуальных кнопок, которые в динамике могут изменять параметры в программе. А синтаксис функций как в Си Тут смотрим состояние регистров и параметров и по желанию изменяем их Для ряда микроконтроллеров имеется и эмуляция внутренней периферии. Часто выставляя флаги в этих устройствах подбирают нужную конфигурацию, а код можно менять прямо из отладки. Правда для вступления изменений в силу надо перекомпилировать:
Посмотрите там Keil uV4, а в ходу уже uV5 и он ныне моден. В поисковике было. А начинал я с uV3. Они все под ARM, а вот uV2 был для 51-го ядра (ныне АВР). На оф. сайте есть http://www.keil.com а вот таблэтки в других местах
Вот любителей STM32 порадует не очень. Почему? А потому, что данный производитель действительно как сосиски штампует контроллеры и при этом документация такова, что там много неточностей. И потом поправки в документации. А симуляторы по 1000 раз для этого никто не будет переделывть и Keil не исключение. И так: 1. Создаём проект и выбираем устройство: 2 Нам предлагается установить шаблонный стартовый файл на ассемблере именно для выбранного устройства (рассмотрим его самого позже). И соглашаемся. Хотя можете или потом добавить, либо сделать. 3 Сделаем новый файл, сохраним его с расширением Си, напишем функцию main, а потом добавим его в проект И что? Компилируем эту пустышку: И имеем сообщение про SystemInit как раз в стартовом файле. Да верно нужна функция начальной настройки. ....
... Но идём в директорию куда встал Keil и находим такой файл, где есть эта функция 4. Копируем его к себе в проект: 5 И опять не то, он выведет нас на заголовочный файл (который лучше сохранить к себе в проект и в нём делать изменения - не надо мусорить!) Надо только выбрать тип устройства. Тут всё откомпилировалось! ... Кстати рекомендую посмотреть приметы, коих там куча! Да именно примеры!
Мне VS ближе как-то https://adelectronics.ru/2018/06/16/visual-studio-2017-написание-и-отладка-проекта-для-soc/ это бич всех производителей. Ради интереса полистал MSP430 - такое ощущение, что одни выжимки. У атмела с новыми МК таже история.
да работа с редактором удобна и интерактивная подсказка и сразу доступ к структуре. Знаю. А вот без JLink как? Именно не как среда разработки, а как симулятор? С JTag и т.п. всё понятно: По поводу выбора компилятора: выбрав GCC укажите соответственно путь к нему Тут спора нет Верно, но только правила для периферии почти все повторяются (регистры и т.п.) от одного МК к другому МК. Зачастую меняются только одни адреса регистров, но вот биты в них чаще одни и те же. Складывается впечатление, что зачастую сами периферийные устройства одни и те же. А зачем к примеру менять GPIO ну или ADC если их параметры идентичны? Соответственно и биты фланов и т.п. идентичны.
Почему-то так и думал услышать подобное Слово почти или многие похоже отсутствуют в Великом и Могучем. А про восьмибитки вообще ничего сказать не могу вообще. Почти не знаком на таком уровне. Подразумеваю только ARM/Cortex AT91SAM7S64(256) и AT91SAM3U4E к примеру. И не говорю что все совпадают... разное расположение по адресам, но многие внутренние периферийные устройства вообще идентичны. А вот про STM такого не скажу, хоть и не пользую... но мой коллега по работе пересел на них и совсем не доволен именно в поддержке этих устройств. А симуляцию он и вовсе не применяет. Но он талантливый и опытный и не только в этой теме. А тут я говорил про симуляцию... на Keil. Кстати в Proteus много АВРок, и даже дуня есть. Можно и схему там сваять да и указать файл прошивки. Жаль с ARM/Cortex там совсем бедно, что и побуждает на подобную симуляцию с помощью Keil для наглядности. А вообще сам везде использую метод условной компиляции, где добавляю "лишний" код при компиляции для отладки. При нужде вывод параметров в консоль и т.п. Трудоёмко, но помогает... особенно если нет средств пошаговой отладки или иной любой.
Вот выдавливаю из ADuC7024 всё, что возможно. Тут прерывание FIQ Код (C++): /* **************** * работа от T1 * **************** */ void FIQ_Handler (void) __irq { PWMA = *pw_addr; if(flag1 & _adc_start) { //*dat_addr = (((ADCDAT >> 16) & 0x0FFF) + *dat_addr) >> 1; *dat_addr = ((ADCDAT >> 16) & 0x0FFF); dat_addr++; if(!(dat_addr < max_dat_addr)) dat_addr = dat_addr_null; } pw_addr++; if(!(pw_addr < max_pw_addr)) { pw_addr = &pw[0];//pw_addr_nul; if(flag1 & _adc_start) flag1 &= (~(_adc_start | _adc_on)); else if(flag1 & _adc_on) flag1 |= _adc_start; } T1CLRI = 0x01; } Видно, что это прерывание срабатывает в симуляторе 2.04e-5 секунд, а в регистр T1LD(регистр таймера) загружается 0х0354. Это для формирования синусоиды из 15 точек(по времени). Интервал между точками 25.714 градусов. А заданная частота для подсчёта 3500 Гц. В понедельник испытаю в реале. Время на IRQ сократил (там по 3-м таймерам) с одним вектором на всех(надо анализировать по флагам). Заменил где можно if на case. Кстати очень большая разница по времени выполнения. Теперь IRQ требует меньше времени выполнения чем main. Кстати основные вычисления в IRQ.
