Я далек от обучения школьников и от подхода шилд-на шилд-на шилд-через переходнушку. Из микроконтроллерного пожалуй Bluepill, из wireless - наверное ESP какую-то.
Но мне ближе подход подбора оборудования под конкретную прикладную задачу, а не наоборот.
Видимо я слишком старый. Не понять мне, для чего надо учить людей не сказать что плохому, но реально далекому от разработки на микроконтроллерах Arduino-like подходу, хотя Arduino как явление безусловно было прорывом. Без понимания того, что внутри, в embedded делать нечего. И чем раньше новоявленный микроконтроллерщик это поймет, тем ему же и легче будет.
У WCH весьма неплохая документация, куча примеров, порог вхождения минимальный для старта с того же HAL. Их MRS можно конечно назвать перенастроенным Eclipse, только вот реально удобнее иметь один инструмент вместо зоопарка от вендоров. И это я конечно не про Arduino IDE, а про Eclipse или VS.
А про отладку по printf() совсем не понял. Это вообще не отладка, а трассировка, и для этого есть родной SDI_printf() для WCH - работает из коробки. А отладка для микроконтроллера - это остановиться в прерывании, вручную дернуть ножками, глянуть осфиллографом, продолжить выполнение.
Что только люди не придумают, чтобы не покупать копеечный LinkE, который по одному проводу умеет одновременно прошивать, отлаживаться под openocd и еще и отладочную консоль трассировки иметь )))
Вы не поверите, но во всех изделиях, критичнее поделок с Али нормальные люди так и делают (пишут софт самостоятельно). А виснет I2C только у тех, у кого ардуино головного мозга и слепая вера в HAL от ST и т.п.
Нет, в Краснодаре не пробки. Там другое слово на Пэ. А если учесть стиль вождения и полнейшее отсутствие уважения к другим участникам движения - то Полный Пэ.
Н-да. Лежит у меня на карте ВТБ ххх рублей. Ну лежит и лежит, я этой картой не пользуюсь, в личный кабинет захожу раз в пятилетку. С принятием вышенаписанных мер, гениальный ИИ совершенно очевидно заблокирует мне попытку вывода при необходимости, ибо это будут "нетипичные для данного клиента запросы". Пошел снимать наличку.
Попробуйте. Начиная с определенного уровня навыка это не работает. Один за 400 сделает работу за 1 месяц, а два за 200 ни за месяц, ни вообще никогда не сделают, поскольку у них знаний на 200 и планку они взять не в состоянии. И учиться они чаще всего не могут или не хотят, поэтому они и за 200.
Вы пробовали? Мы - да. Компания с названием на ЭР. Банальные SMT резисторы. Брак до 1% в виде потери контакта (обрыва) через некоторое время. При очередной поставке "Ой, у нас ни говна ни ложки лента для упаковки закончилась, можно мы россыпью отгрузим?" SMT резисторы 0603 РОССЫПЬЮ, Карл! Возможно для штучных разовых партий и да, но точно не для серии. И, заметьте, про цену разговора нет вообще: $1 или $10 за катушку это копейки.
Формально есть. Фактически - добывай где-то по цене золота, разводи плату, пиши всё с нуля... Так-то и у китайцев контроллеров полно - без поддержки и обучения всё тлен, в массы не пойдет
это личный опыт, или так, мнение?
Мой вот личный: несколько сотен тысяч выпущенных изделий с китайскими процами от трех разных производителей (и не GigaDevice, а суровый китайский китай, про который до 24.02 никто и не слышал), и несколько разработок на отечественных процах, не пошедших пока в серию именно изза цены. Было бы желание, а возможности найдутся
Справедливости ради, аналоги класса Ардуино есть и у Миландра и у НИИЭТ, и они прям скажем получше Ардуино. Да, они делаются не на наших фабриках (если так можно назвать имеющиеся активы ГК Элемент). Но они есть. И для огромного пласта задач промавтоматизации их возможности более чем достаточны. Вопрос в цене. Существующее сейчас субсидирование конечного потребителя продукта - это бред, который придуман вражеским шпионом (и конечно же не любителями распилов), потому что субсидирование проца - грубо 500р на проц. Субсидирование конечного автомобиля или станка или медицинского прибора, в котором стоит это проц - ну вы поняли, да ...
Что-то не вяжется несколько месяцев бассейн + бег с физиологическими проблемами при подъеме с Гарабаши до Приюта 11. Точно перед этим чуть-чуть пивка было? Про остальные авантюры выше достаточно написали.
Также я не путаю размазывание работы с регистрами ровным слоем по всем исходникам, да еще и с магическими числами с нормальной абстракцией от железа.
"Нормальная абстракция" в моем понимании:
Один (ровно один, 1) заголовочный файл "hw_defines.h" с описанием целевой платы, какой GPIO на светодиод, какой на кнопку, какой канал I2C на какую периферию, какой канал DMA на прием данных по какому SPI и т.п.
И несколько файлов вида "hw_gpio.c", "hw_uart.c" и т.п. для работы с аппаратно зависимой периферией на регистрах.
И пишутся эти файлы под каждую целевую платформу, взяв в одну руку даташит на проц, во вторую-еррату, в третью - SDK от производителя, а в четвертую правила codestyle, принятые в Вашей компании, с Вашими блэкджеками и женщинами.
На выходе - абстрации вида
led_on(LED_STATUS), который дергает функцию из hw_gpio.c;
button_getstate(BUTTON_LEFT), который тоже дергает функцию из hw_gpio.c;
flash_write(*data, ...), который в свою очередь дергает функции из hw_spi.c
и т.п.
Все абстракции имеют четко оговоренные в том самом codestyle имена, правила вызовов и возврата и т.п. И тем самым покрытые один раз написанными юнит-тестами, не зависимыми от железа.
В результате мигрирование с платы на плату и даже с изделия на изделие в рамках одного типа процессора - это переписывание одного файла defines.h и дописывание файлов hw_xxx.c для периферии, которой раньше в проектах не было.
Мигрирование с проца на проц - переписывание тех самых файлов hw_xxx.c.
От работы с регистрами в embedded не уйти никуда, примененный в статье подход всего лишь переносит точку возникновения ошибки поглубже, ценой усложнения читабельности устраняя некоторую часть ошибок с помощью компилятора.
Меньше кода - меньше ошибок. Меньше специфичных для конкретной реализации конкретного языка (или упаси Б.г компилятора) - меньше проблем с совместимостью. Хотел бы я посмотреть на портирование ПО на проц, под который нет компилятора С++20 (а такие в Китае водятся, поверьте).
Короче - прицип бритвы Оккама, которому примененный в статье подход противоречит.
Если что, у меня опыт в embedded 25+ лет и изделия, к которым я руку приложил, работают по всей стране сотнями тысяч в режиме 24\7 (не бытовуха).
Я далек от обучения школьников и от подхода шилд-на шилд-на шилд-через переходнушку. Из микроконтроллерного пожалуй Bluepill, из wireless - наверное ESP какую-то.
Но мне ближе подход подбора оборудования под конкретную прикладную задачу, а не наоборот.
дубль
Видимо я слишком старый.
Не понять мне, для чего надо учить людей не сказать что плохому, но реально далекому от разработки на микроконтроллерах Arduino-like подходу, хотя Arduino как явление безусловно было прорывом. Без понимания того, что внутри, в embedded делать нечего. И чем раньше новоявленный микроконтроллерщик это поймет, тем ему же и легче будет.
У WCH весьма неплохая документация, куча примеров, порог вхождения минимальный для старта с того же HAL. Их MRS можно конечно назвать перенастроенным Eclipse, только вот реально удобнее иметь один инструмент вместо зоопарка от вендоров. И это я конечно не про Arduino IDE, а про Eclipse или VS.
А про отладку по printf() совсем не понял. Это вообще не отладка, а трассировка, и для этого есть родной SDI_printf() для WCH - работает из коробки. А отладка для микроконтроллера - это остановиться в прерывании, вручную дернуть ножками, глянуть осфиллографом, продолжить выполнение.
UPD: для v003 надо именно LinkE, не перепутайте с более дешевым но без поддержки v003 1-wire debug
Что только люди не придумают, чтобы не покупать копеечный LinkE, который по одному проводу умеет одновременно прошивать, отлаживаться под openocd и еще и отладочную консоль трассировки иметь )))
https://aliexpress.ru/item/1005005180653105.html
Все это прикручивается в пару кликов к Eclipse, кроссплатформенно и на вкус моих фломастеров явно удобнее чем VSCode
Вы не поверите, но во всех изделиях, критичнее поделок с Али нормальные люди так и делают (пишут софт самостоятельно). А виснет I2C только у тех, у кого ардуино головного мозга и слепая вера в HAL от ST и т.п.
Хехе. Сколько людей, столько и мнений))) Я пока не попал в Краснодар за рулем, тоже думал что самые-самые водители в Ростове.
Нет, в Краснодаре не пробки. Там другое слово на Пэ. А если учесть стиль вождения и полнейшее отсутствие уважения к другим участникам движения - то Полный Пэ.
Ага, и футы с фунтами, и вилки сетевые пусть не забудут.
Пошел покупать на Ави...то, а там ...
продавцы слегка ошалевшие )))
Н-да. Лежит у меня на карте ВТБ ххх рублей. Ну лежит и лежит, я этой картой не пользуюсь, в личный кабинет захожу раз в пятилетку. С принятием вышенаписанных мер, гениальный ИИ совершенно очевидно заблокирует мне попытку вывода при необходимости, ибо это будут "нетипичные для данного клиента запросы". Пошел снимать наличку.
Попробуйте. Начиная с определенного уровня навыка это не работает. Один за 400 сделает работу за 1 месяц, а два за 200 ни за месяц, ни вообще никогда не сделают, поскольку у них знаний на 200 и планку они взять не в состоянии. И учиться они чаще всего не могут или не хотят, поэтому они и за 200.
Вы пробовали? Мы - да. Компания с названием на ЭР. Банальные SMT резисторы. Брак до 1% в виде потери контакта (обрыва) через некоторое время. При очередной поставке "Ой, у нас
ни говна ни ложкилента для упаковки закончилась, можно мы россыпью отгрузим?" SMT резисторы 0603 РОССЫПЬЮ, Карл! Возможно для штучных разовых партий и да, но точно не для серии. И, заметьте, про цену разговора нет вообще: $1 или $10 за катушку это копейки.очень интересно, продолжайте пожалуйста
еще бы в default-city для джихад-курьеров такое сделали ... (мечтательно) ...
смешались в кучу ... биты, TCP, таймауты, Bluetooth, ...
горшочек, не вари, не дай Б..г Вы про HDLC во второй статье решите написать
это личный опыт, или так, мнение?
Мой вот личный: несколько сотен тысяч выпущенных изделий с китайскими процами от трех разных производителей (и не GigaDevice, а суровый китайский китай, про который до 24.02 никто и не слышал), и несколько разработок на отечественных процах, не пошедших пока в серию именно изза цены. Было бы желание, а возможности найдутся
Справедливости ради, аналоги класса Ардуино есть и у Миландра и у НИИЭТ, и они прям скажем получше Ардуино. Да, они делаются не на наших фабриках (если так можно назвать имеющиеся активы ГК Элемент). Но они есть. И для огромного пласта задач промавтоматизации их возможности более чем достаточны. Вопрос в цене. Существующее сейчас субсидирование конечного потребителя продукта - это бред, который придуман вражеским шпионом (и конечно же не любителями распилов), потому что субсидирование проца - грубо 500р на проц. Субсидирование конечного автомобиля или станка или медицинского прибора, в котором стоит это проц - ну вы поняли, да ...
Что-то не вяжется несколько месяцев бассейн + бег с физиологическими проблемами при подъеме с Гарабаши до Приюта 11. Точно перед этим чуть-чуть пивка было? Про остальные авантюры выше достаточно написали.
С говнокодерами уж точно не путаю.
Также я не путаю размазывание работы с регистрами ровным слоем по всем исходникам, да еще и с магическими числами с нормальной абстракцией от железа.
"Нормальная абстракция" в моем понимании:
Один (ровно один, 1) заголовочный файл "hw_defines.h" с описанием целевой платы, какой GPIO на светодиод, какой на кнопку, какой канал I2C на какую периферию, какой канал DMA на прием данных по какому SPI и т.п.
И несколько файлов вида "hw_gpio.c", "hw_uart.c" и т.п. для работы с аппаратно зависимой периферией на регистрах.
И пишутся эти файлы под каждую целевую платформу, взяв в одну руку даташит на проц, во вторую-еррату, в третью - SDK от производителя, а в четвертую правила codestyle, принятые в Вашей компании, с Вашими блэкджеками и женщинами.
На выходе - абстрации вида
led_on(LED_STATUS), который дергает функцию из hw_gpio.c;
button_getstate(BUTTON_LEFT), который тоже дергает функцию из hw_gpio.c;
flash_write(*data, ...), который в свою очередь дергает функции из hw_spi.c
и т.п.
Все абстракции имеют четко оговоренные в том самом codestyle имена, правила вызовов и возврата и т.п. И тем самым покрытые один раз написанными юнит-тестами, не зависимыми от железа.
В результате мигрирование с платы на плату и даже с изделия на изделие в рамках одного типа процессора - это переписывание одного файла defines.h и дописывание файлов hw_xxx.c для периферии, которой раньше в проектах не было.
Мигрирование с проца на проц - переписывание тех самых файлов hw_xxx.c.
От работы с регистрами в embedded не уйти никуда, примененный в статье подход всего лишь переносит точку возникновения ошибки поглубже, ценой усложнения читабельности устраняя некоторую часть ошибок с помощью компилятора.
Меньше кода - меньше ошибок. Меньше специфичных для конкретной реализации конкретного языка (или упаси Б.г компилятора) - меньше проблем с совместимостью. Хотел бы я посмотреть на портирование ПО на проц, под который нет компилятора С++20 (а такие в Китае водятся, поверьте).
Короче - прицип бритвы Оккама, которому примененный в статье подход противоречит.
Если что, у меня опыт в embedded 25+ лет и изделия, к которым я руку приложил, работают по всей стране сотнями тысяч в режиме 24\7 (не бытовуха).