IMO: Пора заморозить кодовую базу F103

Mrburnette
Чт 30 июня 2016 12:37
У меня был хит В другом потоке относительно серьезных изменений в серийном (не USB) коде. Подробности не важны.

Я думаю, что через 3 года пришло время закрыть главу о улучшениях F1XX Corecode. Много работ было выполнено в начале «исправления» и миграции кода Leaflabs в Arduino 1.5 -кратные стандарты, и это было наиболее успешным. Мы не в 1.6.9 и STM32Duino хорошо работает. Без сомнения, по мере продвижения ардуиноида, некоторые изменения могут потребоваться для базы F1XX, но IMO это время прекратить мышление об улучшениях на основном уровне.

Вышеуказанное сказано, улучшения, которые имеют огромную ценность (например, реализации DMA) могут быть вынесены до голосования. Или лучше, я думаю, что эти изменения должны перейти в другую филиал GitHub. В настоящее время у нас есть «мастер» и «разработка», и я предлагаю, чтобы вскоре мастер и развитие станут такими же, и что новая ветвь под названием «Breakfix» будет создан только для того, чтобы «исправить» вещи, которые обнаружены критическая проблема. Текущий отдел разработки тогда станет тем, что вы, ребята, хотите, чтобы это было ... Поместите новый серийный код, добавьте параметры и т. Д. Но эта ветвь никогда не попадет в «Мастер».

Я считаю, что мы обязаны нашей составляющей базой, чтобы стабилизировать и поддерживать стабильность в «Мастере». Пользователи должны знать, что код, который они пишут сегодня и публикуют, будет работать без проблем.

Как и мы сегодня, нет формального механизма продвижения от разработки до мастера. Несколько участников пробуют это, кажется, работает, и код продвигается. Если Breakfix будет реализован, я предлагаю формальную схему продвижения и, возможно, принять парадигму ESP8266... или другой, если один известен. В корпоративной среде есть акционеры департамента и руководители бизнеса. Когда проблемы с кодом будут выдвинуты формально, они исследуются, исправление кода (иногда процедурное) задокументировано, и все области применения узнают об этой документации. Между тем, команда Break-Fix делает кодирование и вкладывает исправление для тестирования. Режим тестов с использованием известных данных используется для обеспечения того, чтобы предложенное исправление ничего не нарушало! После того, как команда Break-Fix будет удовлетворена самим собой, они перемещают код в предварительную выгоду, где владелец приложения бизнес-единицы (может быть внутренним объектом ИТ), подтверждает исправление, а также свидетельствует о других проблемах. Каждый уведомлен о том, что предварительная производительность будет способствовать производству в определенное время и дату.

Я не предлагаю команды формирования и определяю роли, но я говорю, что некоторая хорошая процедура процесса может быть получена путем формализации процесса фиксированного тестирования. Это решение Роджера, в моем уме.


Луча

Martinayotte
Чт 30 июня 2016 г. 12:46
Mrburnette написал:Но эта ветвь будет никогда найти свой путь в "Мастер".

Mrburnette
Чт 30 июня 2016 г. 13:00
Martinayotte написал:Mrburnette написал:Но эта ветвь будет никогда найти свой путь в "Мастер".

Рик Кимбалл
Чт 30 июня 2016 г. 13:04
Я думаю, что это может быть достигнуто, просто создав релиз

https: // Помогите.GitHub.com/статьи/создание изданий/
https: // github.com/rogerclarkmelbourne/ ... 2/выпуски

Не нужно заморозить, просто запечатлеть момент времени и назовите его. ARDUINO API/IDE идет вперед с или без нас. Сказать, что мы никогда не будем меняться, - это игнорирование реальности Arduino IDE.

Так что я говорю «да», чтобы создать релиз!

Mrburnette
Чт 30 июня 2016 г., 13:35
Хорошо... релиз ... ;)

Рик Кимбалл
Чт 30 июня 2016 г., 13:38
Поскольку вы опубликовали тему GitHub и Branches и все, я думаю, мы должны перейти к схеме ветвления, основанной на проблеме на GitHub. Это пойдет на что -то в этом роде:

o Некоторый пользователь имеет интерес к какой -то функции или исправлению, он создает новую проблему. Это дает другим людям возможность комментировать или предложить решение
o Оригинальный пользователь разжигает Master Repo и создает новую филиал под названием Vusse_xxx. Где XXX является проблемой #. Затем они идут вперед и вносят необходимые изменения и отправляют запрос на привлечение.
o Если консенсус людей думает, что это хорошо, оно может быть включено в мастер.

Этот подход дает людям возможность увидеть, что изменилось, предложить улучшения или проблемы, и в целом они могут попробовать это. Это позволяет вам опробовать конкретные функции, проверив эту ветвь. Причина изменений прикреплена к конкретной проблеме, а документация и комментарии также доступны для прочтения.

Это сработало довольно хорошо для проекта Energia. Например, я хотел добавить функцию паритета в серийный порт. Я создал проблему, а затем филиал:

https: // github.Com/Energia/Energia/Проблемы/766
https: // github.com/energia/energia/commits/angue_766

Несмотря на то, что они не включили мои изменения, другие люди могут найти мои конкретные изменения для реализации этой функции.

Martinayotte
Чт 30 июня 2016 г., 13:54
Да ! ... И, как и в большинстве проектов, github Repo просто помечен этим номером релиза ...
Мы также можем сделать то же самое, что и ребята из ядра, с ровной/нечетной нумерацией для альтернативных стабильных выпусков и выпусков разработки.

Mrburnette
Чт 30 июня 2016 г. 15:46
Честно говоря, GitHub в порядке, так как ESP8266 хорошо использовал этот подход.

Но, как и выпуска Arduino IDE, STM32Duino действительно нуждается в подходе к выпуску кода, чтобы выпустить код. Итак, если у меня есть читатель, где-то пытается дублировать один из моих многочисленных проектов V-USB, я знаю, что должен сказать им, чтобы использовать Arduino Ide 1.0.5 ... Как идут дела с STM32, я держу копии ZIP, достигая даты на моем сервере Linux. В то время как я могу вернуться назад, конечный пользователь с меньшей вероятностью поймет, как откатить GitHub на один момент времени... Хотя я помню, что один из нас объяснял на форуме... Но релизы - лучший подход.


Луча

Martinayotte
Чт 30 июня 2016 г., 16:10
Я согласен с тобой, Рэй.
Все идет вместе, теги Github, zip -файлы, документы и даже IDE связаны с ними.
Конечно, это не значит делать это ежедневно, но только на официальных выпусках ... ;)

Rogerclark
Чт 30 июня 2016 г. 22:59
Я в порядке с созданием релизов, но я подозреваю, что 99% людей просто захватят то, что в мастер -репо.

Re: Основные филиалы, связанные с выпуском

Да. Я использовал эту систему для коммерческих проектов, и она хорошо работает.

Но, как правило, я нахожу, что участники не разжигают репо, и делают пиар и т. Д

Гораздо более вероятно, что кто -то публикует фрагмент кода или замены на форуме.

Поэтому я должен обновить репо и проверить изменение.

Вряд ли кто -то, кажется, даже смотрит на филиал разработки и дает мне отзывы.

Обычно я проверяю материал, только когда объединяю ветвь разработки обратно в Master, и новый пользователь загружает его и находит проблему.

Возможно, публикации в ветку объявлений недостаточно, чтобы люди знали, что есть изменения. Но спам всех с помощью Forum Wide PM кажется инвазивным, как известно, многие участники форума бездействуют или перешли на другие mcus e.глин. ESP8266

Mrburnette
Чт 30 июня 2016 г. 11:44
<...>
  • Гораздо более вероятно, что кто -то публикует фрагмент кода или замены на форуме. Поэтому я должен обновить репо и проверить изменение.
  • Вряд ли кто -то, кажется, даже смотрит на филиал разработки и дает мне отзывы.
  • Обычно я проверяю материал, только когда объединяю ветвь разработки обратно в Master, и новый пользователь загружает его и находит проблему.
Это своего рода моя точка зрения. Если что-то не сломано, Dev-Branch-следующий релиз. Если что -то сломано; Затем у вас есть возможность исправить главную ветвь или исправить филиал разработки & продвигать. Ваше решение, вероятно, будет зависеть от вашей оценки «Как сломался?"

Поскольку у каждого есть доступ к разработке, если это решение конечного пользователя, на котором можно запустить. Но когда я скачаю или говорю кому -нибудь, чтобы скачать Master, я думаю, что это должно контролировать версию.

ИМО, рекламные акции от развития до производства - это примерно 2 раза в год.

Хотя мы все ценим ваше мастерство тестирования; Тестирование в идеальном мире было бы невнимательным, сценаристом. По мере того, как вы и я живем в реальности, я предлагаю, чтобы человек, подающий улучшение, также отправила план испытаний & Тестовый эскиз. За 30 дней до запланированного выпуска звонок для добровольцев может избавить вас от тестирования за пределы того, что вы хотите сделать. Если план испытаний определяет связанные с этим областями, вызывающие озабоченность (USART, SPI, I2C, USB и т. Д.) тогда добровольцы могут использовать свои собственные наброски для дальнейшего тестирования.

Я за усовершенствования, но с изменениями поступает ответственность за тщательное впитание и проверку и исчерпывающее тестирование. С таким большим количеством усилий направлено на F4, возможно, внедрение новых идей там 1 -го и Backport в F1 после этого... Но это просто еда для размышлений.

Луча

Rogerclark
Пт, 01 июля 2016 г. 12:05
Луча

Тестирование всегда является проблемой, его трудоемкой и часто требует конкретной платы или конкретной периферической, и часто она включает в себя конкретную ОС.
На самом деле для меня слишком много перестановки, чтобы проверить некоторые вещи вообще. Так что я совершенно полагаюсь на то, что другие люди тестируют и даю мне знать, работают ли вещи или нет.

Re: 2 -летний цикл выпуска

мммм. 2 года в вычислениях очень долгое время. Если я посмотрю на проект на GitHub, и он не сделал новую версию в прошлом году, я обычно избегаю его, так как я предполагаю, что он недостаточно активен.

Глядя на то, что делает @iggr для ESP8266, у него, кажется, есть 2 новых релиза в месяц (в среднем)
https: // github.com/esp8266/arduino/releases

Кроме того, эта главная ветвь обновляется очень часто https: // github.com/esp8266/arduino/commits/master
(Несколько раз в неделю)

Он также, кажется, не использует филиалы. (Не то чтобы я согласен с этим методом, я просто отмечаю, что он делает в очень успешном проекте, и я действительно уважаю @iggr, поскольку он прикладывает гораздо больше усилий в ESP8266, чем я в STM32, и уровень его навыков программирования намного выше мой)

Martinayotte
Пт, 01 июля 2016 г., 2:29
Привет, Роджер,

Рэй упомянул «Цикл выпуска 2 раза», а не «цикл выпуска 2 года», но даже 6 месяцев довольно длинные, может быть, «каждый квартал» будет приятнее.
Он также, кажется, не использует филиалы @Igrr не создает филиалы, но он постоянно использует теги, просто чтобы «сделать снимок/картинка» во время выпуска.
Филиалы могут быть созданы из этих тегов, если есть необходимость в основных исправлениях ошибок по этим конкретным тегам, в противном случае филиалы никогда не будут созданы.
На веб -сайте GitHub теги выглядят как филиалы, люди могут проверить эти конкретные теги для тестирования/отладки, но он не потребляет хранилище (в любом случае пространство GitHub не ограничено).

Rogerclark
Пт, 01 июля 2016 г., 2:46
Мартин

Спасибо за разъяснение. около x 2

Я думаю, это зависит от того, является ли что -то исправлением ошибки или улучшением. То, что некоторые люди считают важным исправлением, рассматривается другими как улучшение
эн.глин. Аппаратный серийный напиток, гораздо медленнее, чем AVR, и означает, что какой -то проект не работает, как это делал на AVR, в каком случае его можно рассматривать как исправление ошибки, так как мы не поддерживаем то, что уже делает AVR, но в равной степени это улучшение Libmaple.

Как правило, я стараюсь убедиться, что Libmaple настолько совместим с кодом AVR, насколько это возможно, так как я думаю, что это была одна из причин, по которой люди не взяли на Maple Mini в больших количествах (в дополнение к высокой стоимости)

эн.глин. Вы должны были изменить все ссылки на серийный на Serialusb и должны были установить специфические режимы STM для анализа и т. Д

Но каждый случай должен рассматриваться индивидуально, и, возможно, в некоторых обстоятельствах принести пользу для изменений, может принести пользу для большинства.

Martinayotte
Пт, 01 июля 2016 г., 3:07
Привет, Роджер,

Я согласен с тобой ! (И я думаю, что у нас общий голос об этом, и даже @igrr ;) )

Это действительно редко, что ветвь создается из тега, даже @iggr еще никогда не делал этого.
В ядре Linux это встречается чаще, в основном для удовлетворения старых ядер, которые все еще часто используются, делая обратную порцию некоторых функций, сделанных на Mainline.
(Но у нас есть далеко, когда у нас есть те сценарии, где старые версии STM32Duino находятся в производстве и абсолютно нуждаются в тех портах)

Другими словами, у вас нет гораздо больше, что вы действительно делаете ... :)

Просто добавьте в свой список несколько небольших задач:

- Решите график релиза, который встречает вас в свободном времени.
- быть убежден в стабиллете главного филиала с помощью сообщества.
- Сбросьте большой флаг Damier (и здесь, вы конечный судья !) и применить тег GitHub, и создайте несколько пакетов JSON, такие как ESP8266, используя шаги сборки, я думаю, что @Ddrown получил работу. (Хотя эти пакеты не должны быть сделаны самостоятельно, так как тег позволит некоторым другим участникам помочь здесь)
- Конечно, есть, возможно, есть другие задачи, такие как создание нового релиза.журнал, но это также может быть сделано кем -то другим.

Необходимость небольших шагов (за исключением, может быть, упаковки), весь процесс принесет процесс выпуска STM32Duino почти такой же, как ESP8266, с почти большим усилием с вашей стороны.

Другими словами, «теги» - это волшебство ... : D

Rogerclark
Пт, 01 июля 2016 г., 3:51
Спасибо, Мартин

Я знаю @ddrown как какой -то код Perl, который производит пакеты JSON, мне нужно будет проверить, запускает ли мой Cygwin их, как не нужно переключаться на ящик Linux или виртуальную машину.
(Ну, возможно, хранение виртуальной машины только для пакетов JSON для выпусков было бы лучшим вариантом.)

Я рад сделать филиалы для исправлений ошибок, хотя у нас будет много ветвей, и, возможно, почему @iggr использует теги.


Один большой вопрос, однако. Какой первоначальный номер выпуска. Я не уверен, что это можно назвать 1.0, как я подозревает

Так что это должно быть

0.0 < release_number < 1.0

Martinayotte
Пт, 01 июля 2016 г., 4:19 утра
Ну, возможно, сохранить виртуальную машину только для пакетов JSON для выпусков было бы лучшим вариантом.) Конечно, это поможет !
Даже я использую виртуальные машины Linux под Linux, чтобы избежать загрязнения окружающей среды, в моем случае, работая Xenial 16.04 до 14 лет.04, чтобы скомпилировать ядра для Aarch64-Linux-gnu-pinea64 или для нескольких ядер H3 Orangepi вкуса без загрязнения моего основного рабочего стола. (Я даже держал более старый Ubuntu 12.04 В виртуальной машине, потому что FFMEG производил гораздо меньший миль на галлон от MythTV, что текущие выпускают)

Не беспокойтесь о филиалах, так как я сказал, что @iggr никогда не делал филиалов для исправлений ошибок, эти исправления ошибок всегда идут в голову (если не крупный), @igrr никогда не делает никаких обратных портов, никогда не для функций или ошибок, голова-это кровоточащий край Если вам нужно/желаю этого.

Для нумерации версий, моя мысль: как Ubuntu, ежеквартально, 16.06 для сегодняшнего тега ! : D

Rogerclark
Пт, 01 июля 2016 г., 4:40
Re: нумерация версий

Хорошая идея.

На самом деле я думаю, что я дискуссии что -то подобное с @Ddrown для пакетов JSON, и это нормально, пока нет никаких ведущих нулей E.глин. Я не думаю, что IDE, как 2016 год.06.05 как номер версии. Я думаю, что это настаивает на 2016 году.6.5

В любом случае. Хорошая идея использовать какую -то базовую систему даты

Martinayotte
Пт, 01 июля 2016 г., 4:56 утра
... И опять же, мы все не хотим, чтобы управление релизом стало для вас бременем для вас !

(Я еще не вышел на пенсию, как Рэй ;-), Но я был частью Softimage Microsoft в течение 4 лет, прежде чем они продали нас в 199X, я отвечал за внедрение и поддержание всего процесса выпуска)

Rogerclark
Пт, 01 июля 2016 г., 5:08 утра
Мартин

Должен признать, приятно, что @ddrown делает пакеты JSON, так как мне меньше нужно сделать ;-)

Martinayotte
Пт, 01 июля 2016 г., 5:18 утра
Если эти сценарии пакетов в порядке, да, просто автоматизация сборки выполнит работу !

Ваша основная работа не должна быть связана с кодированием, это должно быть только для объявления временной метки флага Damier !
(Конечно, вы можете сделать какое -то качество качества, но это зависит от вас с вашей доступностью)

Пойдем на первую попытку в ближайшее время, 16.07 ! : P

Mrburnette
Пт, 01 июля 2016 г., 12:20
Martinayotte написал: <...>
Ваша основная работа не должна быть связана с кодированием, это должно быть только для того, чтобы объявить временную метку флага Дамиера !
(Конечно, вы можете сделать какое -то качество качества, но это зависит от вас с вашей доступностью)
<...>

Rogerclark
Пт, 01 июля 2016 г., 21:29
Mrburnette написал: ....
В какой -то момент в будущем Китай может закончиться из -за их, казалось бы, неограниченного поставок устройств STM32F103, и доски $ 4 могут стать историей.


Луча

Ekawahyu
Пн июля, 04, 2016 12:53
Martinayotte написал:Пойдем на первую попытку в ближайшее время, 16.07 ! : P

Rogerclark
Пн июля, 04, 2016 1:18
Экавахю написал: Ребята, вы когда -нибудь думали о том, чтобы иметь официальный собственный совет STM32Duino? Например, например, WhitePill? ;) Просто мысль о том, чтобы оживить вещи, так как мы собираемся иметь 16.07 Скоро.

Я могу спроектировать и проверить доску. Мы также могли бы попытаться собрать кампанию, чтобы получить ее массовую продукцию здесь, в США за 5 долларов США. Все, что вам, ребята, нужно сделать, это дать мне входные данные и предложения по номеру детали и упаковке STM32, размеру платы, количество кнопок, количество штифтов заголовка, порт USB и т. Д. Я определенно могу сэкономить время, чтобы догнать 16.07 Выпуск! Что ты говоришь?

Martinayotte
Пн, 04 июля 2016 г., 2:04
Если там, конечно, мне нужно иметь дизайн совета директоров сообщества, как сказал @Roger, он не будет на основе F1XX, так как в Китае их много, и мы не можем конкурировать с их ценами.
Но для более новых F4X и F7X это было бы здорово иметь какую -то совету по сообществу, но это должно быть наполнено, по крайней мере, тем, что можно найти на текущих досках, таких как Arch_max: SDCARD Holder и ETH, все за менее чем 19 долларов США.95

Rogerclark
Пн июля, 04, 2016, 2:13 утра
И @grumpoldpizza имеет небольшую доску L4, которая, я думаю, хорошая ниша, я.E, как плата за печать STM32F4

Тем не менее, я подозреваю, что цена доски F4 будет в регионе 10 долларов, и большинству людей не понадобится скорость и т. Д., Поэтому все равно будет просто синей таблеткой за 2 доллара

Когда вы дойдете до ценовой точки за 10 долларов, вы начинаете конкурировать с RPI Zero и Orange Pi и C.ЧАС.я.P и т. Д

Таким образом, размер рынка намного меньше, так как вы получаете лишь часть общего рынка

ИМХО не так много конкуренции за синюю таблетку за 2 доллара. Вы можете получить Arduino Pro Mini за 1 доллар.25, включая доставку, но соотношение цены и качества, синие таблетки выигрывают, так как у нее есть USB, а также намного быстрее, а также гораздо больше ОЗУ, Флэш и т. Д.

Единственная причина, по которой я сейчас иногда использую Pro Mini, - это когда мне нужна какая -то функция, которую мы не перенесли в STM32, E.глин. I2C раб.

Ekawahyu
Пн июля, 4 июля 2016 г., 3:04
Ну, я просто подумал, что иметь по крайней мере один официальный открытый аппаратный аппаратный аппарат STM32Duino будет круто. Конечная цель - не продажа, а предоставление создателям, которые любят строить вещи с нуля с помощью эталонного дизайна, который работает и полностью поддерживается ядром. Я уверен, что некоторые из людей на форуме попытаются построить его сами, если мы сможем доказать, что Дом будет стоить им менее 5 долларов.

@RogerClark: А как насчет использования логотипа Infinity STM32Duino? Он где -то защищен? Доска @Grumpoldpizza - это открытое аппаратное обеспечение? Может быть, мы сможем взять его дизайн с его разрешения и сделать его официальным? Я думаю, было бы здорово иметь хотя бы один официальный совет, полностью поддержанный сообществом.
Martinayotte написал:Но для более новых F4X и F7X это было бы здорово иметь какую -то совету по сообществу, но это должно быть наполнено, по крайней мере, тем, что можно найти на текущих досках, таких как Arch_max: SDCARD Holder и ETH, все за менее чем 19 долларов США.95

Рик Кимбалл
Пн июля, 04, 2016, 3:08
Я знаю, что вся причина, по которой меня привлекла к тому, что на STM32 был из-за наличия досок для рук Cortex-M3 стоимостью менее 5 долларов США и готова уйти без меня. Если бы я собирался потратить более 5 долларов, я бы купил ядра или доски для обнаружения STM, и это все равно стоило бы меньше, чем я мог бы построить.

Rogerclark
Пн июля, 4 июля 2016 г., 3:59 утра
Экавахю написал: @RogerClark: А как насчет использования логотипа Infinity STM32Duino? Он где -то защищен?

Олли
Пн июля, 4 июля 2016 г., 5:49 утра
@ekawahyu,

Если вы можете иметь STM32F745VET6 и ESP32 на одной плате со всеми булавками - исключая OSC и загрузку - выставлены на 0.1 -дюймовая сетка на доске стоимостью менее 15 долларов, мне было бы очень интересно.

Для заголовков могут быть следующие альтернативы
- Нет заголовков, которые тогда подразумевали бы «обязательный» щит
- Нормальные заголовки для SWD (или JTAG), один или два UARTS

Две пользовательские кнопки и два светодиода. Один или два USB. Нет Ethernet из-за встроенной беспроводной связи. В обязательном щите я хотел бы увидеть большое количество 3 -контактных кластеров для прямой проводки датчиков и сервоприводов.

За доску за 10 долларов я был бы рад за L4 + ESP32.

За доску за 5 долларов я доволен существующими альтернативами и новыми досками ESP32.

Ура, Олли

Маленькие звуковые сигналы/зуммеры, которые на самом деле являются крошечными динамиками - Игрок RTTTL перенесен на STM32DUINO