Олли
Sun 3 июля 2016 г. 3:33 утра
OpenLibcm3 утверждает, что их библиотека поддерживает все крупные семьи продуктов MCU. Было бы неплохо объединить эту функциональность с широким признанием Arduino IDE. Если проблемы с юридическим лицензированием могут быть решены, то это комбинированное решение может быть использовано в приложениях для бизнеса в дополнение к существующим продуктам Maker.
Ура, Олли
Ура, Олли
Rogerclark
Sun 3 июля 2016 г., 4:11
Смотрите нижнюю часть этой ветки
ViewTopic.PHP?f = 9&t = 1146&начало = 10#p15440
Публикация по @slammer
ViewTopic.PHP?f = 9&t = 1146&начало = 10#p15440
Публикация по @slammer
Сжимать
Sun 3 июля 2016 г., 5:11 утра
Это еще не что иное, как тест.
Функции Arduino еще не внедрены, только скелет и «хорошая» строительная система для проектов OpenCM3 в Arduino Ide.
Я надеюсь найти время для выполнения некоторых функций, чтобы оценить платформу.
Функции Arduino еще не внедрены, только скелет и «хорошая» строительная система для проектов OpenCM3 в Arduino Ide.
Я надеюсь найти время для выполнения некоторых функций, чтобы оценить платформу.
Rogerclark
Sun 3 июля 2016 г., 11:40
@slammer & @Vassilis
Было ли это дизайнерским решением не помещать файлы линкера в папку варианта ?
Я заметил, что вы положили их в папку LiboPencm3/LIB.
Я хотел добавить вариант Maple Mini и добавить новый сценарий линкера с смещением загрузчика, но не был уверен, что папка LiboPencm3/LIB была лучшим местом для этого, чтобы положить это
Я предполагаю, что можно было бы иметь файлы линкеров с именем что -то вроде STM32F103CB_BOUTLOADER.LD, чтобы они могли быть использованы как общим STM32F103CB, так и Maple Mini
(Примечание. Я знаю, что если я свяжусь таким образом, мне нужно вручную доставить Maple Mini в режим загрузки DFU и добавить инструменты загрузки DFU и т. Д
Спасибо
Роджер
Было ли это дизайнерским решением не помещать файлы линкера в папку варианта ?
Я заметил, что вы положили их в папку LiboPencm3/LIB.
Я хотел добавить вариант Maple Mini и добавить новый сценарий линкера с смещением загрузчика, но не был уверен, что папка LiboPencm3/LIB была лучшим местом для этого, чтобы положить это
Я предполагаю, что можно было бы иметь файлы линкеров с именем что -то вроде STM32F103CB_BOUTLOADER.LD, чтобы они могли быть использованы как общим STM32F103CB, так и Maple Mini
(Примечание. Я знаю, что если я свяжусь таким образом, мне нужно вручную доставить Maple Mini в режим загрузки DFU и добавить инструменты загрузки DFU и т. Д
Спасибо
Роджер
Mrburnette
Sun 3 июля 2016 г. 14:27
Олли написал:<...>
Было бы неплохо объединить эту функциональность с широким признанием Arduino IDE. Если проблемы с юридическим лицензированием могут быть решены, то это Комбинированное решение может быть использовано в приложениях на уровне бизнеса В дополнение к существующим продуктам Maker.
Ура, Олли
Было бы неплохо объединить эту функциональность с широким признанием Arduino IDE. Если проблемы с юридическим лицензированием могут быть решены, то это Комбинированное решение может быть использовано в приложениях на уровне бизнеса В дополнение к существующим продуктам Maker.
Ура, Олли
Grumpyoldpizza
Sun 3 июля 2016 г., 15:23
Олли написал:OpenLibcm3 утверждает, что их библиотека поддерживает все крупные семьи продуктов MCU. Было бы неплохо объединить эту функциональность с широким признанием Arduino IDE. Если проблемы с юридическим лицензированием могут быть решены, то это комбинированное решение может быть использовано в приложениях для бизнеса в дополнение к существующим продуктам Maker.
Ура, Олли
Ура, Олли
Сжимать
Sun 3 июля 2016 г., 21:02
LiboPencm3 - очень тонкий слой на вершине доступа к регистрации, и я знаю, что это не завершено для новейших членов STM32 (по крайней мере, функции более высокого уровня).
С другой стороны мне не нравится HALMX, ужасное название функций, передавая даже простые аргументы со странными структурами со сложными именами, без абстракции, раздутые даже для простых процедур, . Только установка часов RCC занимает более 3 КБ!!!
Единственное жизнеспособное окончательное решение - использовать только CMSIS и получить доступ к регистрам непосредственно создавать свои собственные функции низкого уровня.
LiboPencm3 в порядке для зрелых членов STM32, и простой способ начать с F103, я вижу в этом возможность лучше узнать семью STM32, и я думаю, что после этого процесса будет проще использовать CMSIS.
Rogerclark написал:@slammer & @Vassilis
Было ли это дизайнерским решением не помещать файлы линкера в папку варианта ?
Я заметил, что вы положили их в папку LiboPencm3/LIB.
С другой стороны мне не нравится HALMX, ужасное название функций, передавая даже простые аргументы со странными структурами со сложными именами, без абстракции, раздутые даже для простых процедур, . Только установка часов RCC занимает более 3 КБ!!!
Единственное жизнеспособное окончательное решение - использовать только CMSIS и получить доступ к регистрам непосредственно создавать свои собственные функции низкого уровня.
LiboPencm3 в порядке для зрелых членов STM32, и простой способ начать с F103, я вижу в этом возможность лучше узнать семью STM32, и я думаю, что после этого процесса будет проще использовать CMSIS.
Rogerclark написал:@slammer & @Vassilis
Было ли это дизайнерским решением не помещать файлы линкера в папку варианта ?
Я заметил, что вы положили их в папку LiboPencm3/LIB.
Олли
Sun 3 июля 2016 г. 22:01
@Slammer,
Я полностью согласен с вашей оценкой. Существует сильная аналогия с нашим историческим случаем, когда мы начали модифицировать библиотеку Leaf Lab, чтобы она работала в рамках Arduino IDE. Теперь у нас есть шанс повысить ценность LiboPencm3, добавив недостающие функции и заставить ее работать с Arduino.
Я знаю, что могу следовать прогрессу вашего тестирования через GitHub, но мне интересно ваши планы в обработке вектора NVIC. Я процесс выполнения аналогичного процесса, используя LOCM3 с EMBITZ и еще не решил проблемы, связанные с управлением прерыванием.
Ура, Олли
Я полностью согласен с вашей оценкой. Существует сильная аналогия с нашим историческим случаем, когда мы начали модифицировать библиотеку Leaf Lab, чтобы она работала в рамках Arduino IDE. Теперь у нас есть шанс повысить ценность LiboPencm3, добавив недостающие функции и заставить ее работать с Arduino.
Я знаю, что могу следовать прогрессу вашего тестирования через GitHub, но мне интересно ваши планы в обработке вектора NVIC. Я процесс выполнения аналогичного процесса, используя LOCM3 с EMBITZ и еще не решил проблемы, связанные с управлением прерыванием.
Ура, Олли
Сжимать
Пн июля, 04, 2016, 10:37 утра
Другим вариантом для поистине унифицированной платформы было бы API низкого уровня MBED https: // github.com/mbedmicro/mbed (Посмотрите в каталог HAL/HAL)
MBED - это действительно унифицированный API почти во всех чипах рук и основан на вершине CMSIS/HAL каждого поставщика (см. Поддерживаемые платформы: https: // Разработчик.Mbed.орг/платформы )
В то время как верхний слой MBED (слой C ++) не важен для нас, нижний C API очень интересный, и можно построить сверху, ядро Arduino Core. C API скрывает все аппаратные вещи и обеспечивает единый (или почти единый) слой, например:
MBED - это действительно унифицированный API почти во всех чипах рук и основан на вершине CMSIS/HAL каждого поставщика (см. Поддерживаемые платформы: https: // Разработчик.Mbed.орг/платформы )
В то время как верхний слой MBED (слой C ++) не важен для нас, нижний C API очень интересный, и можно построить сверху, ядро Arduino Core. C API скрывает все аппаратные вещи и обеспечивает единый (или почти единый) слой, например:
uint32_t gpio_set(PinName pin);
void serial_init(serial_t *obj, PinName tx, PinName rx);
int serial_getc(serial_t *obj);
void spi_init(spi_t *obj, PinName mosi, PinName miso, PinName sclk, PinName ssel);
int spi_master_write(spi_t *obj, int value);
int spi_slave_receive(spi_t *obj);
...Rogerclark
Пн июля, 4 июля 2016 г., 11:08
@slammer
Re: Использование Mbed в качестве основного API
Это то, что RedBearlabs сделал для своей доски NRF51. https: // github.com/redbearlab/nrf51822-arduino
Я клонировал и использую этот репо для NRF51, но, похоже, он основан на довольно старом снимке MBED, и они (MBED), кажется, рефактировали много вещей за последний год.
Так что, хотя вы могли бы основывать на MBED, трудно понять, стабильно ли он, я.E, если они снова рефактор, невозможно просто сделать еще один снимок и заменить оригинальную копию, на которой основывалось ядро.
Я думаю, что другие люди е.глин. @martin имеет больше опыта MBBE и, возможно, может дать лучшее мнение о том, действительно ли это хорошо или нет.
Я использую его только в том случае, если мне нужно, так как мне не нравятся системы облачных, так как вы зависите от их систем, работающих на подключении к Интернету и т. Д
Re: Использование Mbed в качестве основного API
Это то, что RedBearlabs сделал для своей доски NRF51. https: // github.com/redbearlab/nrf51822-arduino
Я клонировал и использую этот репо для NRF51, но, похоже, он основан на довольно старом снимке MBED, и они (MBED), кажется, рефактировали много вещей за последний год.
Так что, хотя вы могли бы основывать на MBED, трудно понять, стабильно ли он, я.E, если они снова рефактор, невозможно просто сделать еще один снимок и заменить оригинальную копию, на которой основывалось ядро.
Я думаю, что другие люди е.глин. @martin имеет больше опыта MBBE и, возможно, может дать лучшее мнение о том, действительно ли это хорошо или нет.
Я использую его только в том случае, если мне нужно, так как мне не нравятся системы облачных, так как вы зависите от их систем, работающих на подключении к Интернету и т. Д
Сжимать
Пн июля, 4 июля 2016 г., 11:18 утра
Роджер, у меня нет опыта работы с MBBE, просто создавая некоторые небольшие программы.
SDK здесь, и нет причин использовать онлайн -компиляторы, мне было очень легко сделать проект кодовых блоков со всеми источниками MBBE для построения примеров с помощью GCC (требуется GCC V5 - если кто -то хочет, чтобы проект PM).
Я также не знаю, насколько стабилен, но это очень активный проект. Если бы кто -то был более опытным с mbed, его мнение было бы очень полезно.
К вашему сведению: со вчерашнего дня, Bluepill, официально поддерживается MBBE как target_bluepill_f103c8
https: // github.com/mbedmicro/mbed/tree/ ... Ill_f103c8
Rogerclark написал: Re: Использование Mbed в качестве основного API
Это то, что RedBearlabs сделал для своей доски NRF51. https: // github.com/redbearlab/nrf51822-arduino
SDK здесь, и нет причин использовать онлайн -компиляторы, мне было очень легко сделать проект кодовых блоков со всеми источниками MBBE для построения примеров с помощью GCC (требуется GCC V5 - если кто -то хочет, чтобы проект PM).
Я также не знаю, насколько стабилен, но это очень активный проект. Если бы кто -то был более опытным с mbed, его мнение было бы очень полезно.
К вашему сведению: со вчерашнего дня, Bluepill, официально поддерживается MBBE как target_bluepill_f103c8
https: // github.com/mbedmicro/mbed/tree/ ... Ill_f103c8Rogerclark написал: Re: Использование Mbed в качестве основного API
Это то, что RedBearlabs сделал для своей доски NRF51. https: // github.com/redbearlab/nrf51822-arduino
Martinayotte
Пн июля, 04, 2016, 13:22
Rogerclark написал:
Я думаю, что другие люди е.глин. @martin имеет больше опыта MBBE и, возможно, может дать лучшее мнение о том, действительно ли это хорошо или нет.
Сжимать
Пн, 04 июля 2016 г., 13:34
@martinayotte
Считаете ли вы, что использование API более низкого уровня MBED является жизнеспособным решением для более единого ядра Arduino Core? Как вы думаете об этом?
Считаете ли вы, что использование API более низкого уровня MBED является жизнеспособным решением для более единого ядра Arduino Core? Как вы думаете об этом?
Martinayotte
Пн июля, 04, 2016, 15:05
Наверное, но у меня нет всей точки зрения, и, конечно, это была бы утомительная работа.
Rogerclark
Пн июля, 04, 2016, 21:34
Martinayotte написал:Наверное, но у меня нет всей точки зрения, и, конечно, это была бы утомительная работа.
Сжимать
Втюж 5 июля 2016 г. 12:45
Я провожу некоторое время, изучая код RedBearlabs, и мой первый комментарий о переизбытке был совершенно неверным.
В то время как источники MBED C ++ находятся в основном каталоге, основные функции Arduino используют API более низкого уровня даже CMSIS в некоторых простых функциях (они не заботятся о совместимости). Несомненно, что разработчики RedBearlabs серьезно попытались оптимизировать MBED HAL для их цели.
Они также обновили источники MBED до последней версии.
В то время как источники MBED C ++ находятся в основном каталоге, основные функции Arduino используют API более низкого уровня даже CMSIS в некоторых простых функциях (они не заботятся о совместимости). Несомненно, что разработчики RedBearlabs серьезно попытались оптимизировать MBED HAL для их цели.
Они также обновили источники MBED до последней версии.
Rogerclark
Втюж 5 июля 2016 г. 12:53 утра
@Slammer
Спасибо за обзор RBL Core
Кто -то другой сказал мне, что они думали, что RBL в последнее время обновился, поэтому я, вероятно, снова буду раскошелиться на их репо, так как у меня есть модифицированная вилка, но это потребует модификации для работы, если RBL изменит их структуру.
Первоначально я знаю, что RBL, кажется, организовал папки MBED, когда они сделали свое репо, поэтому я посмотрю еще один взгляд и теперь посмотрю, ближе ли организация к организации Mbedmicro github Repo.
Спасибо за обзор RBL Core
Кто -то другой сказал мне, что они думали, что RBL в последнее время обновился, поэтому я, вероятно, снова буду раскошелиться на их репо, так как у меня есть модифицированная вилка, но это потребует модификации для работы, если RBL изменит их структуру.
Первоначально я знаю, что RBL, кажется, организовал папки MBED, когда они сделали свое репо, поэтому я посмотрю еще один взгляд и теперь посмотрю, ближе ли организация к организации Mbedmicro github Repo.
Martinayotte
Втюж 5 июля 2016 г. 2:20 утра
В моем случае, доска Arch_max будет моим приоритетом для ETH, вероятно, с MMED Lower Layer, но «Time-the-Missing-Endedient» ...
Олли
Втюю 05 июля 2016 г., 7:04
Может ли кто -нибудь объяснить, как RBL можно использовать для объединения платформы. Я не знаю никакой поддержки STM32F1. На практике единственная поддержка STM, которую я видел, - это STM32F2XX и использует очень старый код STM SPL.
С другой стороны, LOCM3 выглядит лучше, чем больше я его использую. Для обзора, посмотрите документацию, которая была получена из исходного кода в http: // libopencm3.GitHub.IO/DOCS/Последний/HTML/. Например, поддержка F7 довольно обширна в тот день, у нас будут дешевые доски F745/F746.
Ура, Олли
С другой стороны, LOCM3 выглядит лучше, чем больше я его использую. Для обзора, посмотрите документацию, которая была получена из исходного кода в http: // libopencm3.GitHub.IO/DOCS/Последний/HTML/. Например, поддержка F7 довольно обширна в тот день, у нас будут дешевые доски F745/F746.
Ура, Олли
Rogerclark
Втюж 5 июля 2016 г., 7:20 утра
Глядя еще раз на то, что сделал RBL, я вижу, что его не сразу можно использовать для ядра STM32, так как они, кажется, часто, кажется, напрямую получают доступ к аппаратным регистрам NRF51.
mbed, кажется, имеет внутренний API https: // Разработчик.Mbed.org/handbook/mbe ... -внутренние, который можно назвать из ядра STM32, но на их сайте есть заметка, что этот API может быть изменен
mbed, кажется, имеет внутренний API https: // Разработчик.Mbed.org/handbook/mbe ... -внутренние, который можно назвать из ядра STM32, но на их сайте есть заметка, что этот API может быть изменен
Стивестронг
Втюж 5 июля 2016 г. 8:36 утра
Ну, я думаю, даже если это изменится, я не могу представить, что это будет полностью измениться, чтобы адаптация/обновление для разных целей все равно будет приемлемо с точки зрения инвестированных усилий.
Сжимать
Втюж 5 июля 2016 г., 9:07
По мере того, как MBED растет, и включено больше целей, я думаю, что этот C API будет становиться все более и более стабильным, потому что верхний C ++ использует его.
В любом случае, размер кода проектов MBED немного увеличен. Мне удается уничтожить все классы C ++ и использовать только C API. Я сделал несколько тестов с GPIO и UARTS, примерно в 5-6 КБ двоичного кода. Кажется, что некоторые функции stdlib связаны без очевидной причины, но я пытаюсь сделать это. Большая часть кода является кодом инициализации RCC от HALMX. Неплохо.
В любом случае, размер кода проектов MBED немного увеличен. Мне удается уничтожить все классы C ++ и использовать только C API. Я сделал несколько тестов с GPIO и UARTS, примерно в 5-6 КБ двоичного кода. Кажется, что некоторые функции stdlib связаны без очевидной причины, но я пытаюсь сделать это. Большая часть кода является кодом инициализации RCC от HALMX. Неплохо.
Деван
Втюж 5 июля 2016 г., 17:51
Я в течение некоторого времени следил за разработкой MBED и немного недавно, поэтому у меня есть несколько мнений по этому вопросу:
Несмотря на то, что MBED управляет ARM, процесс разработки больше стремится к базару, чем к собору. Они принимают практически любые патчи, которые звучат разумно, и проходят автоматические регрессионные тесты. Это отлично подходит для расширения поддержки новых платформ, но также означает, что уровень качества довольно сильно варьируется между платформами. Например, доски Nucleo с поддержкой MBed STM32 вышли два года назад, но получили только официальную поддержку API Man Mething Monthound.
В случае ST конкретно, я думаю, что большая часть кода является тонкой оберткой вокруг кода HAL (и теперь Cubemx). В некотором смысле, что вы получаете, это код Cubemx, переупакованный для API MBED MBBE. Например, поток в этой проблеме GitHub проливает свет на процесс, когда они обновляют код ST:
https: // github.com/mbedmicro/mbed/ways/1096
Что касается LiboPencM3, его цели довольно твердо ориентированы на предоставление тонких обертках над доступом на уровне регистрации к периферийным устройствам. За исключением стека USB, API не структурированы для совместимости между сериями. Не существует единой функции API, которая может быть использована, чтобы сказать, настройте вывод GPIO в качестве выхода как на чипе F1, так и на чипе F0. По сути, это альтернатива CMSIS с открытым исходным кодом (до того, как лицензирование MBED вынуждено открыть CMSIS в рамках более разрешительных лицензий), которая прилагается к USB-стеку, прикрепленный к нему.
С точки зрения рабочей силы, сообщество LiboPencm3 определенно намного меньше, чем сообщество MBED. Количество запросов на открытое притяжение является довольно хорошим показателем того, что активисты (действительно, сопровождающие) не имеют пропускной способности для обзора кода и проверить большинство изменений сообщества. На данный момент для меня довольно распространено наткнуться на ошибку и обнаружить, что кто-то еще уже столкнулся с ней год назад и предложил решение, которое не было интегрировано, потому что никто другой не был доступен, который использует эту функцию и может проверить изменения.
В последние несколько дней проходили дискуссия о Unicore-MX, вилке, которая пытается решить некоторые из этих вопросов:
https: // gitter.im/libopencm3/обсудить?в ... 9E4A08EB4A
Если вы не чувствуете, как пробирайтесь через журналы чата, вот прямая ссылка The Unicore-MX GitHub Repo:
https: // github.com/machines/unicore-mx/unicore-mx
TLDR: у MBED есть HAL, но к лучшему или к худшему, это переупакованный код Cubemx.
LiboPencm3 на самом деле не HAL и несколько анемично, но есть вилка, которая хочет построить ее в HAL.
Несмотря на то, что MBED управляет ARM, процесс разработки больше стремится к базару, чем к собору. Они принимают практически любые патчи, которые звучат разумно, и проходят автоматические регрессионные тесты. Это отлично подходит для расширения поддержки новых платформ, но также означает, что уровень качества довольно сильно варьируется между платформами. Например, доски Nucleo с поддержкой MBed STM32 вышли два года назад, но получили только официальную поддержку API Man Mething Monthound.
В случае ST конкретно, я думаю, что большая часть кода является тонкой оберткой вокруг кода HAL (и теперь Cubemx). В некотором смысле, что вы получаете, это код Cubemx, переупакованный для API MBED MBBE. Например, поток в этой проблеме GitHub проливает свет на процесс, когда они обновляют код ST:
https: // github.com/mbedmicro/mbed/ways/1096
Что касается LiboPencM3, его цели довольно твердо ориентированы на предоставление тонких обертках над доступом на уровне регистрации к периферийным устройствам. За исключением стека USB, API не структурированы для совместимости между сериями. Не существует единой функции API, которая может быть использована, чтобы сказать, настройте вывод GPIO в качестве выхода как на чипе F1, так и на чипе F0. По сути, это альтернатива CMSIS с открытым исходным кодом (до того, как лицензирование MBED вынуждено открыть CMSIS в рамках более разрешительных лицензий), которая прилагается к USB-стеку, прикрепленный к нему.
С точки зрения рабочей силы, сообщество LiboPencm3 определенно намного меньше, чем сообщество MBED. Количество запросов на открытое притяжение является довольно хорошим показателем того, что активисты (действительно, сопровождающие) не имеют пропускной способности для обзора кода и проверить большинство изменений сообщества. На данный момент для меня довольно распространено наткнуться на ошибку и обнаружить, что кто-то еще уже столкнулся с ней год назад и предложил решение, которое не было интегрировано, потому что никто другой не был доступен, который использует эту функцию и может проверить изменения.
В последние несколько дней проходили дискуссия о Unicore-MX, вилке, которая пытается решить некоторые из этих вопросов:
https: // gitter.im/libopencm3/обсудить?в ... 9E4A08EB4A
Если вы не чувствуете, как пробирайтесь через журналы чата, вот прямая ссылка The Unicore-MX GitHub Repo:
https: // github.com/machines/unicore-mx/unicore-mx
TLDR: у MBED есть HAL, но к лучшему или к худшему, это переупакованный код Cubemx.
LiboPencm3 на самом деле не HAL и несколько анемично, но есть вилка, которая хочет построить ее в HAL.
Олли
Втюж 5 июля 2016 г., 19:17
Деван,
Если вы не чувствуете, как пробирайтесь через журналы чата, вот прямая ссылка The Unicore-MX GitHub Repo:
https: // github.com/machines/unicore-mx/unicore-mx Я начал делать свою вики с помощью LOCM3 с Embitz. У вас есть рекомендация, что я должен переключиться на Unicore-MX?
Были некоторые дискуссии о том, что поддержка LOCM3 снизилась после звездного начала несколько лет назад. Может ли Unicore-MX быть правильной альтернативой в качестве современного LOCM3.
С точки зрения инженерии я настоятельно предпочитаю стиль, используемый в LOCM3, по сравнению с чем -либо, поступающим из ARM или STM.
Ура, Олли
Если вы не чувствуете, как пробирайтесь через журналы чата, вот прямая ссылка The Unicore-MX GitHub Repo:
https: // github.com/machines/unicore-mx/unicore-mx Я начал делать свою вики с помощью LOCM3 с Embitz. У вас есть рекомендация, что я должен переключиться на Unicore-MX?
Были некоторые дискуссии о том, что поддержка LOCM3 снизилась после звездного начала несколько лет назад. Может ли Unicore-MX быть правильной альтернативой в качестве современного LOCM3.
С точки зрения инженерии я настоятельно предпочитаю стиль, используемый в LOCM3, по сравнению с чем -либо, поступающим из ARM или STM.
Ура, Олли
Деван
Втюж 5 июля 2016 г., 8:02 вечера
Я начал делать свою вики с помощью LOCM3 с Embitz. У вас есть рекомендация, что я должен переключиться на Unicore-MX?
Были некоторые дискуссии о том, что поддержка LOCM3 снизилась после звездного начала несколько лет назад. Может ли Unicore-MX быть правильной альтернативой в качестве современного LOCM3.
С точки зрения инженерии я настоятельно предпочитаю стиль, используемый в LOCM3, по сравнению с чем -либо, поступающим из ARM или STM. Я согласен с идеями, лежащей в основе вилки Unicore-MX, но я думаю, что это может быть слишком рано, чтобы начать использовать ее, так как их план по своей природе требует много широких, нарушающих изменений. Лично я жду более конкретной дорожной карты, прежде чем принять участие.
Были некоторые дискуссии о том, что поддержка LOCM3 снизилась после звездного начала несколько лет назад. Может ли Unicore-MX быть правильной альтернативой в качестве современного LOCM3.
С точки зрения инженерии я настоятельно предпочитаю стиль, используемый в LOCM3, по сравнению с чем -либо, поступающим из ARM или STM. Я согласен с идеями, лежащей в основе вилки Unicore-MX, но я думаю, что это может быть слишком рано, чтобы начать использовать ее, так как их план по своей природе требует много широких, нарушающих изменений. Лично я жду более конкретной дорожной карты, прежде чем принять участие.
Сжимать
Вторник 05 июля 2016 г., 8:51 вечера
Unicore-MX-это очень новый проект (всего 7 дней), на самом деле является либопенкм3 с некоторыми пятнами из собственной вилки с безумными машинами ( https: // github.com/machines/libopencm3/libopencm3 )
Конечно, направление проекта верно. Я буду наблюдать за прогрессом....
Конечно, направление проекта верно. Я буду наблюдать за прогрессом....
Вассилис
Чт, 07 июля 2016 г., 8:06 вечера
Есть небольшой прогресс в arduino_opencm3 проект.
Проект дорожная карта находится в Ридме.доктор медицинских наук файл.
Проект дорожная карта находится в Ридме.доктор медицинских наук файл.
Сжимать
Солнце 10 июля 2016 г., 10:41
Поскольку прогресс продолжается, добавляется предварительная поддержка F401RE (для нукле-401RE).
Код :: Blocks Building System для F103/F401 работает для тех, кто не использует Arduino IDE.
Код :: Blocks Building System для F103/F401 работает для тех, кто не использует Arduino IDE.
Олли
Солнце 10 июля 2016 г., 17:19
Сламмер написал:Поскольку прогресс продолжается, добавляется предварительная поддержка F401RE (для нукле-401RE).
Код :: Blocks Building System для F103/F401 работает для тех, кто не использует Arduino IDE.
Код :: Blocks Building System для F103/F401 работает для тех, кто не использует Arduino IDE.
Сжимать
Солнце 10 июля 2016 г. 22:34
Em :: Blocks/Embitz поддерживает только Windows....
У меня нет машины для Windows.... (Я жду версию Embitz Linux).
У меня нет машины для Windows.... (Я жду версию Embitz Linux).
Олли
Солнце 10 июля 2016 г. 11:36 вечера
Извините, я забыл об этом.
На форуме Embitz были повторены дискуссии о том, что несколько пользователей хотели бы использовать IDE в Linux, но разработчик (Gerard Zagema) не нашел бизнес -оправдания для дополнительных усилий. Этот бесплатный инструмент был разработан им и поддерживается им при финансировании от пожертвований добровольцев.
С помощью продуктов Rapsberry Pi и Espreffif существует все большее давление, чтобы перенести платформы разработки MCU в Linux.
Возможно, я посмотрю второй взгляд и переоцениваю последние блоки кода против последних Emblocks/Embitz и начну миграцию с W10 в Linux.
Ура, Олли
На форуме Embitz были повторены дискуссии о том, что несколько пользователей хотели бы использовать IDE в Linux, но разработчик (Gerard Zagema) не нашел бизнес -оправдания для дополнительных усилий. Этот бесплатный инструмент был разработан им и поддерживается им при финансировании от пожертвований добровольцев.
С помощью продуктов Rapsberry Pi и Espreffif существует все большее давление, чтобы перенести платформы разработки MCU в Linux.
Возможно, я посмотрю второй взгляд и переоцениваю последние блоки кода против последних Emblocks/Embitz и начну миграцию с W10 в Linux.
Ура, Олли
Сжимать
Солнце 10 июля 2016 г. 11:52 вечера
Как я понимаю, Embitz предоставляет мастер шаблонов для проектов ARM и лучшую поддержку отладчика ARM.
Во -первых, нет проблем с кодовыми блоками, так как вы можете определить все варианты проекта вручную (возможно, это немного сложно впервые).
Для отладчика, как я знаю, можно использовать C :: B в качестве фронта GDB без проблем (без выделенных зрителей Embitz).
Во -первых, нет проблем с кодовыми блоками, так как вы можете определить все варианты проекта вручную (возможно, это немного сложно впервые).
Для отладчика, как я знаю, можно использовать C :: B в качестве фронта GDB без проблем (без выделенных зрителей Embitz).
ZMEMW16
Пн 11 июля 2016 г., 21:32
Linux 64 Debian Jessie 8 сохранил ток, с виртуальной машиной VirtualBox XP, собирая значительную пыль
Я бы согласился на систему строительства кода :: Blocks построил, но не смог ничего найти.
Любой шанс на ссылку ?
Стивен
Я бы согласился на систему строительства кода :: Blocks построил, но не смог ничего найти.
Любой шанс на ссылку ?
Стивен
Сжимать
Пн 11 июля 2016 г., 21:50
Я использую C :: B в своей машине Debian. Я использую ночные сборки из https: // apt.Дженслоди.де/ , Но так как C :: B довольно стабильно, и все очень медленно меняется, официальный пакет 16.01 из репозитории Debian в порядке.
В репозитории https: // github.com/serasidis/arduino_opencm3, Внутри тестового каталога существует проект C :: B, который создает Arduino Core и некоторые небольшие программы (в качестве целей в многоцелевом проекте). Это мой испытательный стенд для разработки. Вы можете взять его в качестве основы для разработки STM32, содержит настройки для семей F1 и F4.
Все, что вам нужно сделать перед открытием проекта, - это определить компилятор ARM, по причинам совместимости, которые я использую инструмент, предоставленный Arduino, но вы можете использовать любой новый инструмент отсюда отсюда https: // launchpad.net/gcc-harm, внесенный . Вот снимок экрана для определения инструментов из моей системы:
В репозитории https: // github.com/serasidis/arduino_opencm3, Внутри тестового каталога существует проект C :: B, который создает Arduino Core и некоторые небольшие программы (в качестве целей в многоцелевом проекте). Это мой испытательный стенд для разработки. Вы можете взять его в качестве основы для разработки STM32, содержит настройки для семей F1 и F4.
Все, что вам нужно сделать перед открытием проекта, - это определить компилятор ARM, по причинам совместимости, которые я использую инструмент, предоставленный Arduino, но вы можете использовать любой новый инструмент отсюда отсюда https: // launchpad.net/gcc-harm, внесенный . Вот снимок экрана для определения инструментов из моей системы:
Браб
Ср. 13 июля 2016 г. 22:49
Привет, ребята,
Я являюсь частью команды, которая начала Unicore-MX Fork of Libopencm3 совсем недавно.
В этой теме уже обсуждались некоторые проблемы, которые мы разделяем о LiboPencM3.
Деван: Да, действительно, в переработке API по своему вкусу, мы сломаем некоторые вещи.
Насколько это плохо для текущего использования? Это зависит от того, предпочитаете ли вы добавленную функциональность
Unicore-MX над нечастыми обновлениями LiboPencm3.
В момент разбивания, через ~ 6 месяцев нам удалось получить 270 коммитов перед LiboPencm3 Master.
Большинство из тех, кто из либопенкм3, владеет PR Backlog. Некоторые из других источников, которые никогда не были разделены вверх по течению.
Другие, которых мы добавили, потому что нам нужна была функциональность для нашего основного проекта, Frosted, бесплатного Posix-совместимости
Встроенная ОС.
Другой вариант заключается в том, что мы могли бы некоторое время сохранить совместимость в обратном порядке, чтобы приспособиться к сообществу.
Наша цель - определить API сверху вниз и в первую очередь иметь стабильный API.
При этом мы хотим попытаться создать более единый API не только в одной семье, но и
через продавцов. Путь там сломает вещи, однако, если будут сделаны предложения о том, как
Чтобы сделать это, чтобы минимизировать боль пользователя, мы хотим принять их во внимание.
Slammer: дорожная карта следует ожидать за 3-4 недели. В этот момент мы пытаемся так сильно уколоть
Комментарии к нашим идеям как можно. Мы приветствуем любые идеи или проблемы, с которыми вы, сообщество, могут быть.
Помимо API, мы также считаем, что дополнительная функциональность сегодня предпочтительнее, чем требование совершенства,
который никогда не прибывает. Мы хотим быстро реагировать на проблемы и PR, и создать здоровое сообщество вокруг
этот. Мы не те, кто отвечает. Ты.
Если кто -то заинтересован в том, чтобы присоединиться к обсуждению и общему развлечению, наш трекер выпуска GitHub открыт
для публики, как и наш канал IRC на Freenode, #Unicore-MX.
Наш список рассылки также будет активен в ближайшее время.
Вся града Эрис!
Я являюсь частью команды, которая начала Unicore-MX Fork of Libopencm3 совсем недавно.
В этой теме уже обсуждались некоторые проблемы, которые мы разделяем о LiboPencM3.
Деван: Да, действительно, в переработке API по своему вкусу, мы сломаем некоторые вещи.
Насколько это плохо для текущего использования? Это зависит от того, предпочитаете ли вы добавленную функциональность
Unicore-MX над нечастыми обновлениями LiboPencm3.
В момент разбивания, через ~ 6 месяцев нам удалось получить 270 коммитов перед LiboPencm3 Master.
Большинство из тех, кто из либопенкм3, владеет PR Backlog. Некоторые из других источников, которые никогда не были разделены вверх по течению.
Другие, которых мы добавили, потому что нам нужна была функциональность для нашего основного проекта, Frosted, бесплатного Posix-совместимости
Встроенная ОС.
Другой вариант заключается в том, что мы могли бы некоторое время сохранить совместимость в обратном порядке, чтобы приспособиться к сообществу.
Наша цель - определить API сверху вниз и в первую очередь иметь стабильный API.
При этом мы хотим попытаться создать более единый API не только в одной семье, но и
через продавцов. Путь там сломает вещи, однако, если будут сделаны предложения о том, как
Чтобы сделать это, чтобы минимизировать боль пользователя, мы хотим принять их во внимание.
Slammer: дорожная карта следует ожидать за 3-4 недели. В этот момент мы пытаемся так сильно уколоть
Комментарии к нашим идеям как можно. Мы приветствуем любые идеи или проблемы, с которыми вы, сообщество, могут быть.
Помимо API, мы также считаем, что дополнительная функциональность сегодня предпочтительнее, чем требование совершенства,
который никогда не прибывает. Мы хотим быстро реагировать на проблемы и PR, и создать здоровое сообщество вокруг
этот. Мы не те, кто отвечает. Ты.
Если кто -то заинтересован в том, чтобы присоединиться к обсуждению и общему развлечению, наш трекер выпуска GitHub открыт
для публики, как и наш канал IRC на Freenode, #Unicore-MX.
Наш список рассылки также будет активен в ближайшее время.
Вся града Эрис!
Rogerclark
Ср. 13 июля 2016 г. 11:23
@brabo
Спасибо за обновление.
Спасибо за обновление.
Олли
Чт 14 июля 2016 г. 12:52 утра
@brabo,
Я знаю, что ваше основное внимание уделяется решению проблем, обнаруженных в LiboPencm3. Интересно, поскольку блокировки кода не нужны среди разработчиков STM32, если разработка Unicore-MX может включать примеры, как это
- Используйте Unicore-MX в кодовых блоках, работающих в Ubuntu или Debian
- Используйте Unicore-MX в кодовых блоках, работающих в W10 или OS-X
Для многих «ленивых» разработчиков было бы очень приятно иметь возможность загружать и устанавливать все с несколькими шагами и уверенность в том, что все хорошо работает вместе.
В течение последних нескольких дней я работал с последними Ubuntu LTS в VirtualBox, работая с последними блоками кода, используя последние инструменты и библиотеки Arm-None-Eabi. До сих пор я не смог завершить ни одного проекта STM32F103.
Ура, Олли
Я знаю, что ваше основное внимание уделяется решению проблем, обнаруженных в LiboPencm3. Интересно, поскольку блокировки кода не нужны среди разработчиков STM32, если разработка Unicore-MX может включать примеры, как это
- Используйте Unicore-MX в кодовых блоках, работающих в Ubuntu или Debian
- Используйте Unicore-MX в кодовых блоках, работающих в W10 или OS-X
Для многих «ленивых» разработчиков было бы очень приятно иметь возможность загружать и устанавливать все с несколькими шагами и уверенность в том, что все хорошо работает вместе.
В течение последних нескольких дней я работал с последними Ubuntu LTS в VirtualBox, работая с последними блоками кода, используя последние инструменты и библиотеки Arm-None-Eabi. До сих пор я не смог завершить ни одного проекта STM32F103.
Ура, Олли
Сжимать
Чт 14 июля 2016 г. 1:02
@brabo
Спасибо за обновление.
Я с большим интересом наблюдаю за прогрессом Unicore-MX.
К вашему сведению, разработка ядра идет хорошо, я и Вассилис мы усердно работаем, чтобы построить минимальное ядро.
До сих пор у нас есть Systimer (для Millis, Do Comply и т. Д.), Цифровой ввод -вывод, SPI и UARTS. SPI -код еще не очень оптимизирован, но он может запустить библиотеку Adafruit ILI9341 почти нетронутым. Код UART использует IRQ для приема/передачи с использованием акций (от официальных основных файлов Arduino) класс Ringbuffers (IMO не оптимизирован хорошо). Для нашей разработки мы пока используем BluePill и NucleOF401RE (я жду нуклеол476)
Вот вывод программы @Simonf отсюда: ViewTopic.PHP?f = 3&T = 1189#P15004
Спасибо за обновление.
Я с большим интересом наблюдаю за прогрессом Unicore-MX.
К вашему сведению, разработка ядра идет хорошо, я и Вассилис мы усердно работаем, чтобы построить минимальное ядро.
До сих пор у нас есть Systimer (для Millis, Do Comply и т. Д.), Цифровой ввод -вывод, SPI и UARTS. SPI -код еще не очень оптимизирован, но он может запустить библиотеку Adafruit ILI9341 почти нетронутым. Код UART использует IRQ для приема/передачи с использованием акций (от официальных основных файлов Arduino) класс Ringbuffers (IMO не оптимизирован хорошо). Для нашей разработки мы пока используем BluePill и NucleOF401RE (я жду нуклеол476)
Вот вывод программы @Simonf отсюда: ViewTopic.PHP?f = 3&T = 1189#P15004
AT Baudrate it Takes: -300 , 237uS. To send 1 char it should take uS :33333
AT Baudrate it Takes: -1200 , 237uS. To send 1 char it should take uS :8333
AT Baudrate it Takes: -2400 , 237uS. To send 1 char it should take uS :4166
AT Baudrate it Takes: -4800 , 237uS. To send 1 char it should take uS :2083
AT Baudrate it Takes: -9600 , 237uS. To send 1 char it should take uS :1041
AT Baudrate it Takes: -19200 , 237uS. To send 1 char it should take uS :520
AT Baudrate it Takes: -38400 , 237uS. To send 1 char it should take uS :260
AT Baudrate it Takes: -57600 , 240uS. To send 1 char it should take uS :173
AT Baudrate it Takes: -115200 , 243uS. To send 1 char it should take uS :86Браб
Чт 14 июля 2016 г., 11:23
@Rogerclark,
Не за что!
@Ollie,
Я думаю, это хорошее предложение, и я думаю, да, мы могли бы
Однако, однако, что наша нынешняя команда разработчиков не использует IDE, нам придется полагаться на сообщество, чтобы привести эти примеры
Но мы все делаем это хорошим и легко для начинающих, чтобы начать!
Мне нужно сделать некоторую окончательную работу по репозиторию LiboPencm3-Examples (например, переименование), и вскоре поместит онлайн-репозиторий Unicore-MX-Examplise Online. Мы можем обещать это: любой PR будет воспринят всерьез, и, если возможно, объединено.
@Slammer,
Также с удовольствием! Я проверю репозиторий arduino_opencm3, мне любопытно, как вы, ребята, делаете вещи
Не за что!
@Ollie,
Я думаю, это хорошее предложение, и я думаю, да, мы могли бы
Однако, однако, что наша нынешняя команда разработчиков не использует IDE, нам придется полагаться на сообщество, чтобы привести эти примеры
Но мы все делаем это хорошим и легко для начинающих, чтобы начать!
Мне нужно сделать некоторую окончательную работу по репозиторию LiboPencm3-Examples (например, переименование), и вскоре поместит онлайн-репозиторий Unicore-MX-Examplise Online. Мы можем обещать это: любой PR будет воспринят всерьез, и, если возможно, объединено.
@Slammer,
Также с удовольствием! Я проверю репозиторий arduino_opencm3, мне любопытно, как вы, ребята, делаете вещи
Олли
Пт 15 июля 2016 г. 12:19
@Slammer,
Спасибо за вашу работу LOCM3/ATM32DUIN. После нескольких часов разочарования я заключается в том, что Codeblocks не имеет реальной пользы в рамках естественной среды разработки Linux с текстовыми редакторами, файлами и GDB. С этой дополнительной экспозицией я помню, почему я выбрал Emblocks в первом месте над кодовыми блоками. Без сомнения, Codeblocks - отличная платформа для развития общего назначения, но ей не хватает собственной поддержки для встроенного управления разработкой.
Браб написал:
Однако, однако, что наша нынешняя команда разработчиков не использует IDE, нам придется полагаться на сообщество, чтобы привести эти примеры
Спасибо за вашу работу LOCM3/ATM32DUIN. После нескольких часов разочарования я заключается в том, что Codeblocks не имеет реальной пользы в рамках естественной среды разработки Linux с текстовыми редакторами, файлами и GDB. С этой дополнительной экспозицией я помню, почему я выбрал Emblocks в первом месте над кодовыми блоками. Без сомнения, Codeblocks - отличная платформа для развития общего назначения, но ей не хватает собственной поддержки для встроенного управления разработкой.
Браб написал:
Однако, однако, что наша нынешняя команда разработчиков не использует IDE, нам придется полагаться на сообщество, чтобы привести эти примеры
Браб
Пт 15 июля 2016 г., 18:45
@Ollie
Да, это план. Мы сделаем дорожную карту в течение 3-4 недель, а затем мы будем стремиться установить дату для первого стабильного выпуска API.
Как я уже говорил ранее, если есть интерес к тому, чтобы на некоторое время сохранять обратную совместимость, мы можем принять это во внимание и попытаться приступить к этому.
Надеюсь, что это отвечает на ваш вопрос на удовлетворение
Да, это план. Мы сделаем дорожную карту в течение 3-4 недель, а затем мы будем стремиться установить дату для первого стабильного выпуска API.
Как я уже говорил ранее, если есть интерес к тому, чтобы на некоторое время сохранять обратную совместимость, мы можем принять это во внимание и попытаться приступить к этому.
Надеюсь, что это отвечает на ваш вопрос на удовлетворение
Сжимать
Пн 18 июля 2016 г., 2:14
На самом деле LiboPencm3-это скорее обертка для операций с реестрами, чем реальная HAL-библиотека. Нет абстракции между семьями.
Во время разработки Arduino Core, так как я работаю над досками F1 и F4, существуют трудности почти на каждом шаге. LiboPencm3 строго «ориентирован на регистр», и пользователь должен хорошо знать оборудование на уровне регистра, а не на уровне операций, это почти как программирование с CMSIS.
Я надеюсь, что Unicore-MX основан на абстракции, потому что развитие кросс-семьи с LiboPencm3-кошмар....
(e.глин. Некоторые функции семейства F1 перемещены из одной подсистемы в другую в F4, например, ADC Prescaler, находится на RCC в F1 и на ADC в F4, именование функций в LiboPencm3 начинается с подситема, поскольку результат такая же функция. RCC_SET_ADCPRE (значение) в F1 и ADC_SET_CLK_PRESCALE (значение) В F4 они не имеют разницы только в префиксе, но также в описании... Полное бессовестность...)
Во время разработки Arduino Core, так как я работаю над досками F1 и F4, существуют трудности почти на каждом шаге. LiboPencm3 строго «ориентирован на регистр», и пользователь должен хорошо знать оборудование на уровне регистра, а не на уровне операций, это почти как программирование с CMSIS.
Я надеюсь, что Unicore-MX основан на абстракции, потому что развитие кросс-семьи с LiboPencm3-кошмар....
(e.глин. Некоторые функции семейства F1 перемещены из одной подсистемы в другую в F4, например, ADC Prescaler, находится на RCC в F1 и на ADC в F4, именование функций в LiboPencm3 начинается с подситема, поскольку результат такая же функция. RCC_SET_ADCPRE (значение) в F1 и ADC_SET_CLK_PRESCALE (значение) В F4 они не имеют разницы только в префиксе, но также в описании... Полное бессовестность...)
Олли
Пн 18 июля 2016 г., 7:49
Это сложный баланс. Существуют различия в возможностях между семьями, и мы не должны ничего забирать, потому что меньшие MCU не поддерживают их. Кроме того.
Печально, если и когда соглашения об именах не соответствуют отсутствию планирования более высокого уровня. На практике, возможно, MBED является единственным жизнеспособным решением для HAL и семейной последовательности.
Лично я доволен решением LOCM3, чтобы иметь последовательность только в семьях. Тот факт, что внутренние аппаратные средства не полностью скрыты, делает LOCM3 чистой и средней боевой машиной подходящей для многих критических приложений ресурсов.
У меня настолько аллергия на раздутие, что моя голова может взорваться, если потратить на это какое -либо длительное время с ней.
Ура, Олли
Печально, если и когда соглашения об именах не соответствуют отсутствию планирования более высокого уровня. На практике, возможно, MBED является единственным жизнеспособным решением для HAL и семейной последовательности.
Лично я доволен решением LOCM3, чтобы иметь последовательность только в семьях. Тот факт, что внутренние аппаратные средства не полностью скрыты, делает LOCM3 чистой и средней боевой машиной подходящей для многих критических приложений ресурсов.
У меня настолько аллергия на раздутие, что моя голова может взорваться, если потратить на это какое -либо длительное время с ней.
Ура, Олли
Сжимать
Пн 18 июля 2016 г., 9:45 утра
Проблема с MBED заключается в том, что основана на вершине HALMX, раздутого API поверх другого раздутого API......
Хотя существуют различия между семьями на уровне регистра, нам нужен тонкий слой, чтобы объединить как можно больше, эти различия. Типичный пример установки Прескалера АЦП показывает проблему. Я думаю, что OpenCM3 находится в правильном направлении, но еще много работы.
В ядре arduino_opencm3 мы стараемся сохранить ядро объединены и перемещать любые различия в файлах STM32/xxx_arh. Я думал, что эти случаи будет немного немного, но, похоже, это правило.... Я надеюсь, что Unicore-MX попытается решить некоторые из этих проблем.
Хотя существуют различия между семьями на уровне регистра, нам нужен тонкий слой, чтобы объединить как можно больше, эти различия. Типичный пример установки Прескалера АЦП показывает проблему. Я думаю, что OpenCM3 находится в правильном направлении, но еще много работы.
В ядре arduino_opencm3 мы стараемся сохранить ядро объединены и перемещать любые различия в файлах STM32/xxx_arh. Я думал, что эти случаи будет немного немного, но, похоже, это правило.... Я надеюсь, что Unicore-MX попытается решить некоторые из этих проблем.
Браб
Чт 11 августа 2016 г., 16:31
Всем привет!
Мы рады объявить здесь о нашем предложении API Unfiied API: https: // github.com/безумно-добавление ... /проблемы/18
Мы приветствуем дискуссию о нашем предложении, а также о любых идеях/мыслях/комментариях!
С нетерпением жду всех отзывов о нашем плане!
Браб.
Мы рады объявить здесь о нашем предложении API Unfiied API: https: // github.com/безумно-добавление ... /проблемы/18
Мы приветствуем дискуссию о нашем предложении, а также о любых идеях/мыслях/комментариях!
С нетерпением жду всех отзывов о нашем плане!
Браб.
Олли
Чт 11 августа 2016 г., 18:38
Браб написал:Всем привет!
Мы рады объявить здесь о нашем предложении API Unfiied API: https: // github.com/безумно-добавление ... /проблемы/18
Мы приветствуем дискуссию о нашем предложении, а также о любых идеях/мыслях/комментариях!
С нетерпением жду всех отзывов о нашем плане!
Браб.
Мы рады объявить здесь о нашем предложении API Unfiied API: https: // github.com/безумно-добавление ... /проблемы/18
Мы приветствуем дискуссию о нашем предложении, а также о любых идеях/мыслях/комментариях!
С нетерпением жду всех отзывов о нашем плане!
Браб.
Браб
Чт 11 августа 2016 г., 22:05
@Ollie,
Мы также чувствуем, что тяжелый перерыв - это путь в этот момент. На данный момент библиотека довольно фрагментирована и непоследовательна, поэтому практически любое изменение в конечном итоге нарушает код пользователя. Это также затрудняет участие участников, чтобы добавить что -то в библиотеку, и особенно трудно принять участие.
Наша дорожная карта, непосредственно цитируемая из нашего RFC:
- Объявить предложение и дорожную карту, запросить ответ сообщества на GitHub
- 3-4 недели: предложите унифицированный API, запросить ответ сообщества
- 7-8 недель: фаза End RFC, начало реализации в отдельной филиале и Freeze Master
- 8-12 недель: завершить Unified Lib и сделать его мастером
Мы попытались сделать как реалистичный график для этого хода, так и для обратной связи, а также быстро. Мы надеемся, что фактический этап реализации может быть короче, чем 4 недели, но мы можем столкнуться с непредвиденными проблемами (у них есть неприятный случай сделать это: P).
В этот момент мы уже расширяем аппаратную поддержку, но чтобы сделать ее максимально безболезненным, сначала нам нужен четкий определенный API и последовательность. Мы надеемся, что в конечном итоге мы сможем поддержать все семьи Cortex-M, которые имеют смысл быть в этой библиотеке, но это отдельный график от незаметных API.
Надеюсь, это ответит на ваш вопрос на удовлетворение
Браб.
Мы также чувствуем, что тяжелый перерыв - это путь в этот момент. На данный момент библиотека довольно фрагментирована и непоследовательна, поэтому практически любое изменение в конечном итоге нарушает код пользователя. Это также затрудняет участие участников, чтобы добавить что -то в библиотеку, и особенно трудно принять участие.
Наша дорожная карта, непосредственно цитируемая из нашего RFC:
- Объявить предложение и дорожную карту, запросить ответ сообщества на GitHub
- 3-4 недели: предложите унифицированный API, запросить ответ сообщества
- 7-8 недель: фаза End RFC, начало реализации в отдельной филиале и Freeze Master
- 8-12 недель: завершить Unified Lib и сделать его мастером
Мы попытались сделать как реалистичный график для этого хода, так и для обратной связи, а также быстро. Мы надеемся, что фактический этап реализации может быть короче, чем 4 недели, но мы можем столкнуться с непредвиденными проблемами (у них есть неприятный случай сделать это: P).
В этот момент мы уже расширяем аппаратную поддержку, но чтобы сделать ее максимально безболезненным, сначала нам нужен четкий определенный API и последовательность. Мы надеемся, что в конечном итоге мы сможем поддержать все семьи Cortex-M, которые имеют смысл быть в этой библиотеке, но это отдельный график от незаметных API.
Надеюсь, это ответит на ваш вопрос на удовлетворение
Браб.