Вассилис
Сб 14 мая 2016 г., 17:36
Известно, что существует большой диапазон устройств STM32 (STM32L0, L1, L4, STM32F0, F1, F2,..,F7) в соответствии с их особенностями.
По этой причине ST классифицировал библиотеки STM32Cube с разными именами STM32Cubel0, STM32Cubel1,...,STM32Cubef7.
Я думал, что, возможно, это хорошая идея, чтобы разделить варианты HALMX в категориях, как и STM32Duino. Вместо использования общего Halmx Папка, которая включает в себя целые варианты, я бы предложил каждый диапазон STM32 (F0, F1 и т. Д.).
Например, вместо использования общего Halmx Папка мы могли бы использовать папку Halmx_f0 для всех STM32F0 MCUS, папка Halmx_f1 для всех STM32F1 MCU и т. Д.
Что ты скажешь об этом ?
По этой причине ST классифицировал библиотеки STM32Cube с разными именами STM32Cubel0, STM32Cubel1,...,STM32Cubef7.
Я думал, что, возможно, это хорошая идея, чтобы разделить варианты HALMX в категориях, как и STM32Duino. Вместо использования общего Halmx Папка, которая включает в себя целые варианты, я бы предложил каждый диапазон STM32 (F0, F1 и т. Д.).
Например, вместо использования общего Halmx Папка мы могли бы использовать папку Halmx_f0 для всех STM32F0 MCUS, папка Halmx_f1 для всех STM32F1 MCU и т. Д.
Что ты скажешь об этом ?
Сжимать
Сб 14 мая 2016 г. 18:23
Эта идея верна...
Кроме того, я думаю, что правильным способом является непосредственно использовать источник HAL внутри каждого каталога (F0, F1 и т. Д.). Каждый вариант в одной и той же семье должен использовать одни и те же файлы HAL. Cubemx - это нечто большее, является генератором кода инициализации поверх HALMX. Обычно каждый вариант должен иметь доску.C или вариант.C с конкретным кодом для соответствующего варианта. Думайте о HALMX как о API низкого уровня, такого как LiboPencm3 или Libmaple, и файлы Cubemx как минимальная инициализированная процедура.
Кроме того, я думаю, что правильным способом является непосредственно использовать источник HAL внутри каждого каталога (F0, F1 и т. Д.). Каждый вариант в одной и той же семье должен использовать одни и те же файлы HAL. Cubemx - это нечто большее, является генератором кода инициализации поверх HALMX. Обычно каждый вариант должен иметь доску.C или вариант.C с конкретным кодом для соответствующего варианта. Думайте о HALMX как о API низкого уровня, такого как LiboPencm3 или Libmaple, и файлы Cubemx как минимальная инициализированная процедура.
Grumpyoldpizza
Сб 14 мая 2016 г., 19:49
Вассилис написал:Известно, что существует большой диапазон устройств STM32 (STM32L0, L1, L4, STM32F0, F1, F2,..,F7) в соответствии с их особенностями.
По этой причине ST классифицировал библиотеки STM32Cube с разными именами STM32Cubel0, STM32Cubel1,...,STM32Cubef7.
Я думал, что, возможно, это хорошая идея, чтобы разделить варианты HALMX в категориях, как и STM32Duino. Вместо использования общего Halmx Папка, которая включает в себя целые варианты, я бы предложил каждый диапазон STM32 (F0, F1 и т. Д.).
Например, вместо использования общего Halmx Папка мы могли бы использовать папку Halmx_f0 для всех STM32F0 MCUS, папка Halmx_f1 для всех STM32F1 MCU и т. Д.
Что ты скажешь об этом ?
По этой причине ST классифицировал библиотеки STM32Cube с разными именами STM32Cubel0, STM32Cubel1,...,STM32Cubef7.
Я думал, что, возможно, это хорошая идея, чтобы разделить варианты HALMX в категориях, как и STM32Duino. Вместо использования общего Halmx Папка, которая включает в себя целые варианты, я бы предложил каждый диапазон STM32 (F0, F1 и т. Д.).
Например, вместо использования общего Halmx Папка мы могли бы использовать папку Halmx_f0 для всех STM32F0 MCUS, папка Halmx_f1 для всех STM32F1 MCU и т. Д.
Что ты скажешь об этом ?
Rogerclark
Сб 14 мая 2016 г. 9:00 вечера
Я думаю, что мотивация использования HAL была по нескольким причинам
* Для поддержки различных серийных процессоров e.G F2, F3 F7 и L Series и т. Д., Без необходимости писать весь код низкого уровня вручную (например, Leaflabs должны были многое сделать в Libmaple)
* Использовать официальный код STM в качестве основы, а это значит, что мы получаем официальные исправления ошибок при обновлении куба (хотя мы должны реэкспортировать для каждого ядра)
* Дайте пользователям возможность вызывать стандартные функции HAL, а не API Leaflabs на аппаратное обеспечение, так как это позволит людям использовать весь официальный пример кода и т. Д
* Используйте STM собственные USB -драйверы E.глин. Для CDC и т. Д., Поэтому нам не нужно использовать LIBWDI для установки драйвера Windows.
Одно предостережение с драйверами USB заключается в том, что я думаю, что мы должны переключиться на использование композитного устройства, предпочтительно, как раньше, а не позже, даже если оно содержит одно суб -устройства, так как мы должны иметь возможность добавлять HID и другие устройства (например, Ардуино Леонардо и т. Д
Но я не знаю, есть ли официальный композитный драйвер STM (VID PID), который мы можем использовать.
* Для поддержки различных серийных процессоров e.G F2, F3 F7 и L Series и т. Д., Без необходимости писать весь код низкого уровня вручную (например, Leaflabs должны были многое сделать в Libmaple)
* Использовать официальный код STM в качестве основы, а это значит, что мы получаем официальные исправления ошибок при обновлении куба (хотя мы должны реэкспортировать для каждого ядра)
* Дайте пользователям возможность вызывать стандартные функции HAL, а не API Leaflabs на аппаратное обеспечение, так как это позволит людям использовать весь официальный пример кода и т. Д
* Используйте STM собственные USB -драйверы E.глин. Для CDC и т. Д., Поэтому нам не нужно использовать LIBWDI для установки драйвера Windows.
Одно предостережение с драйверами USB заключается в том, что я думаю, что мы должны переключиться на использование композитного устройства, предпочтительно, как раньше, а не позже, даже если оно содержит одно суб -устройства, так как мы должны иметь возможность добавлять HID и другие устройства (например, Ардуино Леонардо и т. Д
Но я не знаю, есть ли официальный композитный драйвер STM (VID PID), который мы можем использовать.
Вассилис
Сб 14 мая 2016 г., 21:23
Роджер, вы предлагаете сохранить все варианты в одной папке, как сейчас ?
Rogerclark
Сб 14 мая 2016 г., 21:46
Вассилис
Я думаю, что репо, вероятно, станет очень большим, если у каждой платы есть полная копия файлов HAL, но я не знаю, практически ли это разделить его так, как было предложено.
Я не знаю, будет ли ядро HAL, которое экспортируется для L0 таким же, как и для F7
То, как @sheepdoll структурировал файлы, является самым безопасным, но, вероятно, имеет много дублирования.
Однако, пока мы не попытаемся построить совершенно разные ядра, E.глин. L0 из F7, я не думаю, что будет возможно решить, как лучший способ структурировать репо.
Кроме того, по связанной теме.
Я смотрел на создание пакета менеджера совета директоров для F1, и можно написать сценарий, который просто извлекает одно ядро из репо и пакетов.
Таким образом, одним из вариантов было бы иметь отдельные пакеты менеджеров доски для различных серий (хотя это было бы много отдельных пакетов), которые помогут с дублированием, поскольку конечные пользователи не будут загружать весь репо с каждым вариантом
Я думаю, что репо, вероятно, станет очень большим, если у каждой платы есть полная копия файлов HAL, но я не знаю, практически ли это разделить его так, как было предложено.
Я не знаю, будет ли ядро HAL, которое экспортируется для L0 таким же, как и для F7
То, как @sheepdoll структурировал файлы, является самым безопасным, но, вероятно, имеет много дублирования.
Однако, пока мы не попытаемся построить совершенно разные ядра, E.глин. L0 из F7, я не думаю, что будет возможно решить, как лучший способ структурировать репо.
Кроме того, по связанной теме.
Я смотрел на создание пакета менеджера совета директоров для F1, и можно написать сценарий, который просто извлекает одно ядро из репо и пакетов.
Таким образом, одним из вариантов было бы иметь отдельные пакеты менеджеров доски для различных серий (хотя это было бы много отдельных пакетов), которые помогут с дублированием, поскольку конечные пользователи не будут загружать весь репо с каждым вариантом
Ekawahyu
Вторник 24 мая 2016 г. 22:31
Кто -нибудь начал работать над этим разделением? Как выглядит новая структура? У меня есть по крайней мере платформы F0, F1, F4 и L0, что я могу проверить это с.
Я могу представить, что весь процесс порта на новую платформу/плату будет выглядеть так:
Я могу представить, что весь процесс порта на новую платформу/плату будет выглядеть так:
- Сгенерировать код с помощью STM32Cubemx
- Добавить setup () и loop () в основной.в
- Добавить чип.H, вариант.H, вариант.CPP
- Удалить драйверы и папки Middlewares, окончательный построен должен быть связан с библиотекой (Libf0.A, Libf1.а и т. Д.)
- Весь исходный код для CMSIS, STM32FXX или LXX проживает в новой папке драйверов ---> построить частично по мере необходимости
____ cores
| |_ mapleMX
|_ drivers
| |_ CMSIS
| |_ STMF0xx_HAL_Driver
| |_ STMF1xx_HAL_Driver
| |_ STMF2xx_HAL_Driver
| .
| .
| |_ STM32_USB_Device_Library
|_ libraries
|_ variants
| |_ MX
| |_ Inc
| |_ Src
| |_ SW4STM32
| |_ chip.h
| |_ variant.h
| |_ variant.cpp
|_ boards.txt
|_ platform.txt
Sheepdoll
Ср 25 мая 2016 г., 3:11
Многое из способов, которым он в настоящее время структурирован, - это воспользоваться тем, как Cube хранит файлы. Большая часть этого создается автоматически.
Одна идея, которая у меня была, было бы использовать git, где каждый вариант - это филиал. Таким образом, если вы хотите поработать над F1, то вы проверяете филиал F1. Работайте на F4, затем проверьте филиал F4. Каждая вариантная папка имеет .Файл МОК в нем. Распределение будет НЕТ иметь фактический код HAL. Это будет сгенерировано пользователем/конфигуратором для платы, которую они хотят использовать.
Также будет второй сценарий. Это может быть подключение к кубу. Мне нужно поговорить с контактом, который я установил в Maker Faire, чтобы посмотреть, возможно ли это вообще. В настоящее время я, вероятно, напишу это в PostScript, чтобы проверить концепцию. Этот сценарий гласит .Файл IOC изменяет Main для добавления setup () и loop () и создает вариант.CPP и вариант.H файл с использованием выбора, который пользователь сделал в инструменте Cube. Этот сценарий также должен был бы касаться досок.TXT и, возможно, платформа.текст.
Может случиться так, что только создатели платы используют эти сценарии для настройки общей платы. Становится немного грязным. Нет стандартного номера вывода Arduino to Number STM Thingsys. Библиотеки Nucleo и F0 SPL используют одинаковое отображение. Это отображение больше для пакета 'r ". Большинство кленов используют пакет 'c'. Отто собирается добавить еще больше путаницы.
Если Arduino IDE будет лучше поддерживать ARM, они действительно должны использовать реальную систему Makefile и динамические библиотеки, которые не загружаются, если не нужно. Я работаю над тем, чтобы получить 3 -й LCD -библиотеку, и она собирает всю проводку и бит -бить I2C на случай, если пользователь захочет ее назвать.
Одна идея, которая у меня была, было бы использовать git, где каждый вариант - это филиал. Таким образом, если вы хотите поработать над F1, то вы проверяете филиал F1. Работайте на F4, затем проверьте филиал F4. Каждая вариантная папка имеет .Файл МОК в нем. Распределение будет НЕТ иметь фактический код HAL. Это будет сгенерировано пользователем/конфигуратором для платы, которую они хотят использовать.
Также будет второй сценарий. Это может быть подключение к кубу. Мне нужно поговорить с контактом, который я установил в Maker Faire, чтобы посмотреть, возможно ли это вообще. В настоящее время я, вероятно, напишу это в PostScript, чтобы проверить концепцию. Этот сценарий гласит .Файл IOC изменяет Main для добавления setup () и loop () и создает вариант.CPP и вариант.H файл с использованием выбора, который пользователь сделал в инструменте Cube. Этот сценарий также должен был бы касаться досок.TXT и, возможно, платформа.текст.
Может случиться так, что только создатели платы используют эти сценарии для настройки общей платы. Становится немного грязным. Нет стандартного номера вывода Arduino to Number STM Thingsys. Библиотеки Nucleo и F0 SPL используют одинаковое отображение. Это отображение больше для пакета 'r ". Большинство кленов используют пакет 'c'. Отто собирается добавить еще больше путаницы.
Если Arduino IDE будет лучше поддерживать ARM, они действительно должны использовать реальную систему Makefile и динамические библиотеки, которые не загружаются, если не нужно. Я работаю над тем, чтобы получить 3 -й LCD -библиотеку, и она собирает всю проводку и бит -бить I2C на случай, если пользователь захочет ее назвать.
Стевех
Ср 25 мая 2016 г., 3:29
Arduino коренится в AVR, у которого не было альтернативных функций на выводах чипсов. Тогда отображение заданного штифта чипа с штифтом платы - это понятие Arduino, которая еще больше добавляет негибкости, если вы не используете собственные доски Arduino.
Возможно ли использовать концепции Arduino для имен выводов, с фиксированными функциями на каждом выводе, тогда как Cubemx позволяет отображать контакт на основе графического интерфейса примерно 8 выбираемых функций на PIN. Плюс ввод графического интерфейса всех параметров настройки для выбранной функции на PIN (например, скорость GPIO, подтягивания или период таймера или таймер захвата DMA Да/Нет, и так далее и так далее). Кажется несовместимым с концепцией Ардуино, когда у любого данного доски с именем X есть фиксированное отображение булавки.
Как вы знаете, как только вы используете Cubemx или Cubefn для генерации вариантов альтернативных функций для используемых контактов MCU, и параметров их устройства, кубики выплевывают весь код инициализации, ISRS, системные часы/PLL, шины и т. Д., и пустого главного (); Затем ваша работа фокусируется на приложении и документе HAL Library API, а не взломе ввода -вывода.
Мне может показаться, что код, внесенный пользователем, будет промежуточным программным обеспечением, как и HAL совместимые с FATFS, SDIO, LCD, Free_rtos и т. Д. Большинство всех функций ввода-вывода ввода-вывода, UARTS, SPI, SDIO, I2C и их драйверов, находятся в библиотеках HAL, не рассматриваются.
Возможно ли использовать концепции Arduino для имен выводов, с фиксированными функциями на каждом выводе, тогда как Cubemx позволяет отображать контакт на основе графического интерфейса примерно 8 выбираемых функций на PIN. Плюс ввод графического интерфейса всех параметров настройки для выбранной функции на PIN (например, скорость GPIO, подтягивания или период таймера или таймер захвата DMA Да/Нет, и так далее и так далее). Кажется несовместимым с концепцией Ардуино, когда у любого данного доски с именем X есть фиксированное отображение булавки.
Как вы знаете, как только вы используете Cubemx или Cubefn для генерации вариантов альтернативных функций для используемых контактов MCU, и параметров их устройства, кубики выплевывают весь код инициализации, ISRS, системные часы/PLL, шины и т. Д., и пустого главного (); Затем ваша работа фокусируется на приложении и документе HAL Library API, а не взломе ввода -вывода.
Мне может показаться, что код, внесенный пользователем, будет промежуточным программным обеспечением, как и HAL совместимые с FATFS, SDIO, LCD, Free_rtos и т. Д. Большинство всех функций ввода-вывода ввода-вывода, UARTS, SPI, SDIO, I2C и их драйверов, находятся в библиотеках HAL, не рассматриваются.
Rogerclark
Ср 25 мая 2016 г., 4:35
Re: Использование альтернативного конфигурации PIN -конфигурации
Я не уверен, нужно ли нам использовать эту функцию
Я понимаю, почему это удобно, но я думаю, что если вы хотите такой уровень конфигурации...
Вы, вероятно, должны либо использовать код куба напрямую (вообще не API -слой Arduino)
Или вы должны сделать свой собственный вариант платы, который имеет альтернативное отображение штифтов, которые вы хотите.
Re: Использование номеров Arduino Pin
Теперь я использую только номера портов/выводов стиля STM32 E.глин. PA11, но нет ничего, чтобы остановить нас, используя массив булавок и перечисления, как это делает Libmaple, так что такие платы, как Maple Mini.
Re: Структура кодовой базы
У меня не было времени, чтобы посмотреть на это, но, как я ранее говорил... Я не думаю, что мы создали достаточно вариантов, чтобы узнать, сколько кода является общим.
эн.глин. Я заметил, что кто -то написал о том, как у F03 был другой парамет в одной части кода, и я знаю, что у F4 есть разные настройки периферической скорости для F1
Так что может случиться так, что нам нужно много дублирования кода, и, возможно, предложение @Sheepdoll о различных ветвях Github, является одним из способов справиться с этим, не выглядящая массовой кодовой базой. (я.E, чтобы вы могли просто выбрать, какую филиал вы хотите загрузить Zip -файл)
Но мне интересно, сколько будет работать, чтобы тогда поддерживать весь общий код в курсе, так как я не уверен, можно ли использовать GIT Merge для этого (я подозреваю, что нет), и я использую подмодуль GIT для общего Код работает только для людей, которые клонируют репурус
Я не уверен, нужно ли нам использовать эту функцию
Я понимаю, почему это удобно, но я думаю, что если вы хотите такой уровень конфигурации...
Вы, вероятно, должны либо использовать код куба напрямую (вообще не API -слой Arduino)
Или вы должны сделать свой собственный вариант платы, который имеет альтернативное отображение штифтов, которые вы хотите.
Re: Использование номеров Arduino Pin
Теперь я использую только номера портов/выводов стиля STM32 E.глин. PA11, но нет ничего, чтобы остановить нас, используя массив булавок и перечисления, как это делает Libmaple, так что такие платы, как Maple Mini.
Re: Структура кодовой базы
У меня не было времени, чтобы посмотреть на это, но, как я ранее говорил... Я не думаю, что мы создали достаточно вариантов, чтобы узнать, сколько кода является общим.
эн.глин. Я заметил, что кто -то написал о том, как у F03 был другой парамет в одной части кода, и я знаю, что у F4 есть разные настройки периферической скорости для F1
Так что может случиться так, что нам нужно много дублирования кода, и, возможно, предложение @Sheepdoll о различных ветвях Github, является одним из способов справиться с этим, не выглядящая массовой кодовой базой. (я.E, чтобы вы могли просто выбрать, какую филиал вы хотите загрузить Zip -файл)
Но мне интересно, сколько будет работать, чтобы тогда поддерживать весь общий код в курсе, так как я не уверен, можно ли использовать GIT Merge для этого (я подозреваю, что нет), и я использую подмодуль GIT для общего Код работает только для людей, которые клонируют репурус
Стевех
Ср 25 мая 2016 г., 4:47
Rogerclark написал:Re: Использование альтернативного конфигурации PIN -конфигурации
Я не уверен, нужно ли нам использовать эту функцию
Я не уверен, нужно ли нам использовать эту функцию
Mrburnette
Ср 25 мая 2016 г. 13:09
Стевех написал:Rogerclark написал:Re: Использование альтернативного конфигурации PIN -конфигурации
Я не уверен, нужно ли нам использовать эту функцию
Я не уверен, нужно ли нам использовать эту функцию
Стевех
Ср 25 мая 2016 г., 21:21
Mrburnette написал:Стевех написал:Rogerclark написал:Re: Использование альтернативного конфигурации PIN -конфигурации
Я не уверен, нужно ли нам использовать эту функцию
Я не уверен, нужно ли нам использовать эту функцию
Mrburnette
Чт 26 мая 2016 г., 1:30 утра
Полу потребовалось 2 года, вероятно, на 100 часов недели, чтобы получить то, что есть Teensyduino, и это подмножество ввода/вывода на чипах, которые являются следующими подростками.
Я отдал подростку. Вероятно, все еще есть второй в коробке где -нибудь. Хорошая маленькая доска, но я возражал против того, чтобы исправить IDE, и этот проклятый всплывающий инструмент для загрузки такого глупого... Как Мюнстер 
Павел достаточно приличный чувак, я общался с ним несколько раз. Но Павел - это хардхед, без компромисса, делай это, как бы человек... Я могу относиться; Но мы сталкиваемся.
Точка всей этой дискуссии Павла? Честно говоря, я не знаю.
Но отказаться от автоматического сгенерированного кода из Cube/HAL-огромная ошибка. Непрактично изобретать и отлаживать все, что есть в HAL. Мое мнение не изменилось... ЕСЛИ Текущий GitHub будет иметь разные модели микроконтроллеров ST STM32FX, тогда эти советы должны быть способны быть запрограммированы Arduinoide по выбору платы. Развивающиеся функции и основная поддержка в порядке, IMO. Теперь я лично мог бы меньше заботиться о том, как материализируется ядро... людьми, автоматизированными инструментами или миллионами обезьян.
Я подозреваю, что 95% этого форума знают, что у ST есть профессиональные инструменты, и что можно использовать другие IDE, но избиение ардуиноида в качестве неполного ... Сравнение - это сравнение «яблоки и апельсины». Хитрость состоит в том, чтобы вернуть суть профессионального IDE (S), созданный код обратно в код основного кода с открытым исходным кодом для поддержки езды Arduino на вершине GCC.
Луча
Павел достаточно приличный чувак, я общался с ним несколько раз. Но Павел - это хардхед, без компромисса, делай это, как бы человек... Я могу относиться; Но мы сталкиваемся.
Точка всей этой дискуссии Павла? Честно говоря, я не знаю.
Но отказаться от автоматического сгенерированного кода из Cube/HAL-огромная ошибка. Непрактично изобретать и отлаживать все, что есть в HAL. Мое мнение не изменилось... ЕСЛИ Текущий GitHub будет иметь разные модели микроконтроллеров ST STM32FX, тогда эти советы должны быть способны быть запрограммированы Arduinoide по выбору платы. Развивающиеся функции и основная поддержка в порядке, IMO. Теперь я лично мог бы меньше заботиться о том, как материализируется ядро... людьми, автоматизированными инструментами или миллионами обезьян.
Я подозреваю, что 95% этого форума знают, что у ST есть профессиональные инструменты, и что можно использовать другие IDE, но избиение ардуиноида в качестве неполного ... Сравнение - это сравнение «яблоки и апельсины». Хитрость состоит в том, чтобы вернуть суть профессионального IDE (S), созданный код обратно в код основного кода с открытым исходным кодом для поддержки езды Arduino на вершине GCC.
Луча
Ekawahyu
Чт 26 мая 2016 г. 18:03
Я считаю, что мы все здесь вместе по разным причинам, написав основной код для Arduino STM32. Но, я думаю, должна быть хотя бы одна же причина, почему мы все здесь. Мы все являемся экспертом по кодам кода STM32 до самого низкого уровня, и это не главная причина, почему мы хотим работать над поддержкой Arduino IDE. У Ардуино нет лучшей IDE, но вы можете пойти и выбрать Eclipse по мере желания. По моему мнению, если вы достаточно способны касаться самого низкого уровня, то вы, вероятно, выберите другие инструменты, кроме Arduino IDE. Итак, что вы делаете? Какова ваша цель при этом?
Вот почему я здесь:
Вот почему я здесь:
- Я провел много времени в прошлом, играя с STM32F0, F1, F4, используя их стандартные периферийные библиотеки. У меня есть переносные коды, такие как простая оболочка и различная поддержка аппаратного драйвера с красиво написанными makefiles. ST-Link, Jlink, USB-Arm-OCD, вы называете это, я все поддерживает для Flashers. Внезапно, SPL был прекращен, и мне пришлось двигаться дальше с HAL? Это часы работы по замене SPL на HAL для нескольких ядер! Итак, я нашел STM32duino.com и я подумал, что если я смогу внести что -то для работы со всем.
- Я был очарован ростом сообщества Arduino, и я также замечаю некоторых ненавистников. Некоторые сказали, что Arduino не является «нормальным» языком программирования, не имеет многочисленных вкладок, не имеет поддержки для написания нескольких исходных кодов, но это Arduino! С предлагаемой простотой, еще больше людей присоединяются к клубу и пишут больше библиотеки для него. Я должен согласиться с Рэем в этом отношении. Держите это просто, потому что Arduino - это Arduino. Это не для экспертов, это для начинающих. То, как мы делаем это для цифрового ввода -вывода, правильно, назвав его PA, PB и т. Д., Вместо того, чтобы держать его в качестве Arduino с числами. Я думаю, что мы должны сделать то же самое для аналоговых булавок.
- STM32Cubemx - это просто инструмент для нас, чтобы быстрее генерировать код для более низких уровней. Я должен не согласиться, чтобы предоставить только *.МОК для других вместо полного сгенерированного кода из него. В течение последних двух недель я генерировал код с точно так же *.МОК, но сгенерированный код время от времени не был одинаковым. Что произойдет, если Сент решит перейти к чему -то еще в будущем и остановить их поддержку на STM32Cubemx? Тот же цикл повторится снова, точно так же, как больше не поддерживает SPL, и у всех нас осталось только *.МОК в наших репозиториях.
- Я проектирую электронные доски для младших детей для их Makerspace. Я использую STM32, потому что это доступно доступно большинство школ могут купить, и дешевле по сравнению с получением только AVR на UNO. У него встроенный DFU, программист не требуется. Если они решили пойти продвигаться, ST-Link дешевле, и я уже поместил Makefiles тут и там, чтобы построить, с Arduino Ide. Они могли программировать и отлаживать в Eclipse IDE за тот же исходный код и .Ино
Mrburnette
Чт 26 мая 2016 г., 19:05
Экавахю написал:<...>
Мы все являемся экспертом по кодам кода STM32 до самого низкого уровня, и это не главная причина, почему мы хотим работать над поддержкой Arduino IDE. У Ардуино нет лучшей IDE, но вы можете пойти и выбрать Eclipse по мере желания. По моему мнению, если вы достаточно способны касаться самого низкого уровня, то вы, вероятно, выберите другие инструменты, кроме Arduino IDE. Итак, что вы делаете? Какова ваша цель при этом?
<...>
Мы все являемся экспертом по кодам кода STM32 до самого низкого уровня, и это не главная причина, почему мы хотим работать над поддержкой Arduino IDE. У Ардуино нет лучшей IDE, но вы можете пойти и выбрать Eclipse по мере желания. По моему мнению, если вы достаточно способны касаться самого низкого уровня, то вы, вероятно, выберите другие инструменты, кроме Arduino IDE. Итак, что вы делаете? Какова ваша цель при этом?
<...>
