Comments 37
А когда понадобится вычислить и отобразить значения, на переменной можно нажать LoadА есть ли возможность сделать mute для всех переменных, кроме одной? Зачастую все же хочется следить за состоянием одной-двух переменных на каждом шаге.
Отладчиком пользуюсь часто. И особенно мне нравится возможность просмотра регистров периферии прямо во время отладки.
Есть ли поддержка SVD в CLion? они позволяют просматривать регистры периферии конкретного микроконтроллера прямо во время отладки. SVD — это XML файл с описанием регистров периферии(в JSON было бы удобнее, моё мнение). Было бы здорово иметь возможность дополнять эти файлы более подробным описанием регистров прямо в IDE и скидывать свои дополнения или справления в общий котёл.
скажите, а когда будет, и будет ли, возможность поменять генератор для cmake?
С разработчиками встроенных систем мы общаемся. Во-первых, в рамках исследования мы делали большой опрос.
Во-вторых, у нас в команде несколько разработчиков, в прошлом занимавшихся встроенными системами. У всех, конечно, свой опыт, но какую-то интересную выборку дает. Я вот сама проработала в embedded networking, делала всякие IP routers/gateways, IPTV и прочие интеерсные железки. У Elmot опыт скорее любительский, зато диапозон попробованных MCU большой.
опыт скорее любительский, зато диапазон попробованных MCU большой
Поймите, любительский большой диапазон попробованных сильно отличается от большого диапазона используемых профессиональным разработчиком. И потребности соответственно отличаются. Например, NordicEnergy в своей работе использует различный спектр микроконтроллеров и его Ваш продукт пока не сильно заинтересовал.
А то сейчас вроде и разрабатывать можно и отлаживаться, но при этом половина функций не работает. Основная трабла, компиляторы не проходят проверку при создании Cmake проекта или при его обновлении, обещали вроде в 2019.2 поправить, ждем…
Не понимаю ваших проблем с кубом — он просто генерирует код для настройки периферии и клокинга, почему им нельзя пользоваться?
А что(и, главное, кто) Вам обещали в 2019.2, если не секрет?
Что то у меня Gcc подключать не хочет, падает при создании Cmake проекта…
Я беру его отсюда https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
В настройках ставлю MinGw и подсовываю компиляторы со ссылки и получаю ошибку, что компилятор не может справиться с простым тестом при создании. Cmake проекта.
Если подсовывать IAR компилятор, то почти проходит, за исключением компиляции с каким то ключом, который он не знает.
В итоге проект компилитсясвсе таки, но пути к заголовочникам не видит. Вот, например:
[YouTrack, Commented] Issue CPP-12576: include_directories ignored by 'inspection' if compiler check fail
И вот,
[YouTrack, Commented] Issue CPP-12788: Toolchain file break highlighting
И все это под этим:
[YouTrack, Voted] Issue CPP-871: Support for cross-compilation/debug and embedded development
Мне обещали исправление ошибки при создании Cmake проекта и связанных с ней типа проблемы с нахождением путей к include заголовочникам, сейчас приходится прописывать полный путь в исходниках…
А путь к std заголовочникам вообще не знаю как прописать.
Куб генерит код, но этим кодом нельзя пользоваться в реальной жизни, так как у этого кода даже просто много ворнингов от компилятора, не говоря уже про проверку статическим анализатором кода, в генереном коде баги, например в USB (но это то что сам видел и прочувствовал), так то даже в CMSIS есть баги с выравниванием структур… А в кубе и подавно.
Ну и кода там генериться мама не горюй, чтобы светодиодом поморгать… В общем для дома и учеба самое то, а для промышленных применений такой генерый код не пройдет ни одной сертификации..
SET(CMAKE_C_COMPILER_WORKS 1)
SET(CMAKE_CXX_COMPILER_WORKS 1)
IAR, конечно, в планах, но не сейчас
Т.е. баги не в самом кубе, а в стандартных библиотеках. Тут я соглашусь, особенно про их ужасный USB.
Тем не менее, даже с необходимостью править косяки в библиотечном коде в целях сертификации, куб очень полезен в начале проекта на сложных чипах(F4, F7, L4, H7, WB), иначе там чтения доки на несколько недель.
А путь к std заголовочникам вообще не знаю как прописать.
По идее само долно найтись, если тулчейн в path.
Насчет Куба, я согласен, что полезен он для быстрого начала, для проверки там идей и так далее, но по хорошему даже метод обращения к регистрам нужно менять в CMSIS. И да доки придется читать. Но без этого никуда, как говориться, лучше день потерять, потом за пять минут долететь :)
Для примера, что в голову пришло…
class RegisterReadOnly
{
};
class RegisterWriteOnly
{
};
class RegisterReadWrite : public RegisterReadOnly, public RegisterWriteOnly
{
};
template <std::size_t size, typename RegisterType, std::uint32_t address,
typename std::enable_if_t<std::is_base_of<writeOnly, RegisterType>::value>>
class Register
{
public:
using registerType = typename RegisterTraits<size>::internalType;
constexpr Register(): reg{*reinterpret_cast<std::uint32_t*>(address)}
{
} ;
Register& operator=(const registerType& right)
{
reg = right ;
return *this ;
}
Register& operator |=(const registerType& right)
{
reg |= right ;
return *this ;
}
private:
volatile registerType & reg;
};
int main()
{
Register<32U, RegsiterReadWrite, GPIOA_MODER_BASE_ADDR> GpioaModer;
GpioaModer |= (1 <<3) ;
Register<32U, RegsiterReadOnly, ADC1_SR_BASE_ADDR> Adc1SR;
Adc1SR |= 1 ; // ошибка компиляции, так как регистр ReadOnly
}
И там же тысячи регистров со своими особенностями (битовые поля, различные назначения битов, зарезервированные значения и прочее разрушающее чтение), это будут гиганские объемы кода. Лучше уж статический анализатор запилить, который берет SVD файл и проверяет все эти заморочки, причем неспецифичным к чипу и вендору способом.
Кроме того, библиотеки на С, а не на плюсах.
И это вряд ли изменится в обозримом будущем.
) Ну да, но за плюсами будущее, библиотеки потихоньку переписываются, а по моей специфике мы пишем все библиотеки сами, так как код сертифицируется на SIL3 и Си там не приветствуется, по сколько совсем не совсем он строго типизированный.
Кстати регистров много, но отличаются они только адресами, типом доступа и размерностью…
Кто то же CMSIS заголовояники для каждого процессора написал ( с ошибками кстати), тут просто дело времени, но ошибок меньше, например можно проверить, что структура выровнена по размеру регистррв и не имеет дырок и все это во время компиляции.
Забыл сказать, у меня Windows, возможно под Linux таких проблем нет...
Многие микроконтроллеры идут с SDK или библиотеками различных стеков (BLE, 6LoWPAN и т.д.) следовательно надо реализовывать поддержку этих дополнений.
Да, это абсолютно верно. Какую поддержку для этих SDK и библиотек было бы желательно иметь, кроме того, что уже идет из коробки? В CLion уже есть довольно мощный редактор кода, отладчик, memory view. Запланирована поддержка Peripheral Registers View
потратить силы на другой инструментарий
Если есть пожелания по конкретным утилитам, то заведите тикет, мы посмотрим, что можно сделать
Но пару дней назад переехал на ноутбуке с macos high sierra на ubuntu 19.04.
И начались сильные тормоза из-за CLion. При редактировании проекта использование cpu подскакивает на максимум. При включенном power saving режиме такого нет.
Под макосью таких проблем не наблюдалось. Проекты ровно те же самые редактировались.
Грустно :(
CLion 2019.1: ClangFormat, подсветка кода через Clangd, memory view, начальная поддержка микроконтроллеров