Я бы сказал, что этот отрывок тоже не отражает контекста.
Кнут работал на уровне ассемблера.
Т.е думаю его слова сейчас напрямую относятся к разработчикам на Adruino или STM32 или чем-то подобном, т.е. малым встраиваемым системам.
Действительно когда кодируешь под микроконтроллер все время стараешься писать наиболее быстрые алгоритмы. Это как навязчивая мания, когнитивное искажение.
Потом оказывается что тормозит вовсе не то, что отняло столько внимания.
Но избавиться от него невозможно даже отлично зная советы Кнута, потому что есть что-то в психике.
Т.е. Кнут высказал не рекомендацию, а отметил медицинский факт.
Люди не перестанут ехать на другой конец города в другой магазин ради экономии пары центов.
Что значит куда? Они как в линуксе выводятся куда указывают stdin stdout stderr. Куда направите туда и выведется, можете зайти по телнету и запустить ваше приложение, вывод будет у вас в консоли.
Понятно.
Т.е. вы сразу какое бы простенькое приложение ни было всегда неявно требуете наличие TCP стека, файловой системы и операционной системы.
Потому что все должно сработать как в линуксе.
Оверхед доказан?
Лезу я в ваш репозитарий потому что вы сами предлагаете в него лезть. Для чего тогда все эти статьи?
Ок, я залез. Там пусто. Предлагается видимо идти в места расположения оригинальных пакетов. Но все что есть для этого — это какие-то невнятные аббревиатуры, даже минимальных подсказок нет. Спрашивается зачем такое выкладывать и пиарить? Где демки на этих проектах, доказавающие работоспособность?
Скажем из тройки lvgl nuklear, qt достоин внимания только lvgl.
Но он одинаково трудно портируется что под линукс что под windows. Там надо писать драйвер и под Chrom-ART там конечно драйвера нет!
Т.е. отсутствие преимущества доказано?
Ну и не забывайте что эти коменты читает весь интернет.
От того как вы отвечаете зависит в какой-то мере успешность вашего пиара.
Я же просто хочу отделить рациональные вещи от чисто субъективных предпочтений.
По сути диалог и заходит в область сравнения (которого вашей статье так не хватает) что есть в линуксе для embedded и что есть в RTOS растущих от железа.
Значительно проще все делает только значительное количество RAM.
Кстати я посмотрел ваш репозитарий проекта Embox.
Во-первых там черт ногу сломает, какая-то масса непонятных названий директорий сторонних опенсорсных проектов даже косвенно не намекающих зачем они нужны.
Во-вторых, действительно важные и мощные проекты типа SQLite, каких-то скриптовых движков, компрессоров и т.д. отлично портируются сразу на embedded платформу без линукса и симуляций.
То что действительно можно смело без привязки к аппаратуре симулировать — GUI. Для STM32 есть не менее 3-х прекрасных библиотек с которыми идут их демо платы, и они имеют адаптеры симуляции под Windows, но не под линукс. QT потрированный на STM32 по сравнению с ними мягко говоря бледнеет.
С другой стороны я не понял как можно компилировать библиотеку libmodbus под линукс и быть уверенным что она так же заработает на STM если у компиляторов разный retargeting
Как например выводить диагностические, отладочные, аварийные сообщения и куда?
Сколько они еще заберут стека, а сколько займут процессорного времени?
Вопросы риторические.
Контроль за кучей стоит делать сразу в приложении на целевой платформе.
Тогда не надо будет мучится в симуляторах под линуксом.
Мучится — это потому что такой процесс требует времени и создания симуляции реальных условий.
Опять же кучу лучше сделать единой для всего, и для драйверов периферии и для верхнего уровня, так буде более экономно.
Словом ну ничего не способствует портированию линуксовых библиотек на STM32.
Как косвенное доказательство — отсутствие таких библиотек в STM32Cube.
То есть если в libmodbus появится надпись что можно запускать на STM32 с помощью Embox. Вы будете использовать Embox, или саму библиотеку?
Точно, если такая надпись будет, то это будет верный сигнал о возможности легкого переноса библиотеки на любую RTOS.
А пока вы не показали как на линуксе вычислили минимальный размер heap для этой библиотеки.
Да я вижу что вы немало времени провели над анализом расхода памяти в симуляциях под линуксом. Это говорит о том что проблему прекрасно понимаете и сорсы вы все таки дорабатываете. Либо вынуждены брать чипы с большим объемом памяти.
Но на целевой платформе эти тестовые прогоны в любом случае точнее. Поскольку они учитывают и расход памяти низкоуровневым слоем работы с периферией. Уж периферию то никак в линуксе просимулировать не удастся.
Конечно если вы эти статьи пишете для самого себя с целью само убеждения, то понять можно.
Но вроде как посыл был в утверждении превосходства вашего метода.
Так вот фактов превосходства представлено не было на мой взгляд.
Запустили на хосте один раз, а на плате заработало.
Вот в это я и не верю.
Сколько раз я соединялся по modbus с промышленными контроллерами это всегда был челендж. 90% времени уходит на исследование проблем коммуникации.
Поскольку отсутствует исчерпывающая документация. О какой симуляции в линуксе может идти речь?
А если вы применили modbus для соединения одного своего дивайса с другим, то это исскуственный пример. Это история не про реальный modbus, а про то как сотворили оверхед. Т.е. по любому выполнили лишнюю работу.
Я даже не верю что линуксовые либы вообще можно использовать на STM32 без хитроумных рефакторингов, поскольку на STM самый дефицитный ресурс RAM, а в линуксе безоглядно используют heap. Да даже ограничения на стек заставляют стократно перепроверять все линуксовые сорсы чтобы не дай бог там не надумали делать массивы на стеке или списки со строками в автоматических переменных. Эт я еще не упомянул ретаргетинг С-ишных функций.
Тот же libmodbus вы должны были проверить на фрагментацию и исчерпание кучи, поскольку там вовсю используют malloc. Т.е. либо вы нам не рассказали о том как вы симмулируете фрагментацию на линуксе, либо вы не можете утвержадать что ваше приложение рабочее, поскольку не отлаживали его на целевой платформе.
Вот если в линуксовой либе специально указывают что она годная для embedded, то это другой разговор. Сам с удовольствием использую различные парсеры, интерпретаторы, протоколы из линукса. Но для этого не требуется сам линукс. Это лишний компонент.
Но почему разработка на Linux-е рассматривается как некое упрощение?
Фактически же делается двойная работа.
Сначала делается симуляция на линуксе и для этого делаются cgi скрипты ( которые тоже надо отлаживать), а потом все равно надо все отлаживать на целевой платформе.
Есть же STM32CubeMonitor, быстрый STLink, симуляторы прямо в IDE под STM и прочие средства делающие разработку и отладку на платформе STM быстрой и удобной.
Так ведь рядовая школа танцев учит сразу нескольким стилям.
Свинг там один из них. Мы например танцуем свинг, танго, фокстрот, румбу, ча-ча-ча и т.д. в течении одного занятия.
А на вечеринках все это нон-стоп сменяя одно друг друга.
Танцевать одно танго или один свинг это же скучно.
Лихо вы решаете что в каталог, а что в университете учить.
А я бы «The Art of Electronics» отнес к разряду каталогов, ибо там сплошь микросхемы от Analog Divices.
Чем новее издание тем больше в нем решений на микросхемах от AD. А где хотя-бы микросхемы от TI или Infineon?
ADC то описаны, но нюансы сопряжения их с микроконтроллерами не отражены никак.
То что у Хоровица написано есть в туче апнотов у всех производителей ADC.
А вот как сопрягать ADC одного производителя с uC другого — это уже более редкие знания.
Или как правильно трассировать?
Современный GPIO тоже не описывается просто уровнями напряжений, он гораздо сложнее.
И что интересно, начинающие сразу и упрутся во всю комплексность GPIO, потому что их описание в даташитах не упрощают, там десятки параметров и фичей. И они прочитав Хоровица все равно не поймут что там к чему.
Словом вопрос прост — откуда вы решили что именно такой состав знания нужен современному начинающему разработчику?
Какие-то есть аргументы?
Не стоит ли более четко разделить электронщиков по областям интересов, и сузить нишу Хоровица?
Я бы Хоровица поставил как необходимый источник для разработчиков микросхем, но не для современных разработчиков встраиваемой электроники к примеру.
12 часть называется «LOGIC INTERFACING»
Т.е. она в основном о сопряжении цифровых логических уровней. Большинство типов логики начинающие электронщики никогда в жизни не увидят.
В разделе про сопряжение с мощными нагрузками нету описания современных микросхем управления нагрузками в частности моторами и мелкими приводами.
Абсолютно нет информации о сопряжении полевых интерфейсов и локальных шин типа USB, Ethernet, CAN…
Нет ничего о сопряжении внешних аналоговых цепей с ADC микроконтроллеров, компараторами и GPIO.
Нет ничего про современные сенсоры IoT: акселерометры, гироскопы, IMU модули, емкостные, индуктивные и магнитные сенсоры приближения, вращения, движения…
Т.е. пропущено 90% информации необходимой начинающему современнному электронщику.
Не кажется ли вам что эта книга довольно таки устаревшая?
Если честно мы интровертные инженеры ( у нас тут целые команды разработчиков из разных фирм ходят) ни с кем на танцах не разговариваем. Пару слов перед началом и в конце и все.
Поэтому ничего не могу сказать про толерантность. Специфика руэды в том что-бы более минуты с одним партнером не танцевать.
Говорить и что-то узнавать некогда.
На вечеринках в барах тоже не до разговоров в грохоте. Начинается раунд и просто цепляешься к тому кто ближе всего и не занят. Дресс-кода нет никакого. Эта необычайная демократичность довольно привлекательна.
На классических танцах перед началом цикла занятий обычно предлагают выбрать меняться партнерами или нет. Чаще люди склонны отказываться от такой практики. Но если тренер настоит ничего не поделаешь, но такой тренер сразу теряет часть класса.
Но истерики на тренировках между парами — обычное дело. На любых парных танцах и в сальсе в том числе. Тренеры любят метод периодической (5-10 мин) смены партнеров именно потому чтобы не возникало истерик и ругани.
Однако в руэде есть некая форма равенства.
Все партнершы танцуют со всеми партнерами. Нет дискриминации по уровню подготовки, когда самые натренированные танцуют только с тренированными или самые красивые с самыми красивыми.
Вот когда на открытых вечеринках на парных танцах такая заваруха начинается это сильно расстраивает.
Некрасивые женщины обижаются, мужики завидуют и зляться и т.д.
Поэтому парные танцы более напряжные. Надеяться что в танго у вас будут всегда сексуальные, умелые и привлекательные партнершы — наивно.
Клубы практикуют еще линейные танцы. Эт когда в ряд становятся и синхронно двигаются.
Сальса для линейного варианта есть, а вот танго нет.
Что сложнее, танго или сальса сказать не могу.
За полтора года удалось надежно выучить лишь 5-6 фигур в танго. Не забываем что партнерша тоже должна их выучить и оба понимать движения одинаково и повторяемо.
В сальсе удалось запомнить где-то больше 20 комбинаций движений на пике формы (мы ж инженеры, у нас кроме этого еще кучу чего надо каждый день запоминать и помнить).
Но в сальсе больше сотни комбинаций движений, которые надо четко помнить по названиям и по спец. жестам.
Команды жестами это уже высший пилотаж, мы до них даже не дошли.
Сальсу и руэду в частности можно танцевать в очень тесных и шумных клубах, где не слышно даже партнера. Словом у сальсы экспресивность не пропадает в любой обстановке, а для танго все же нужно пространство.
В сальса руэда тоже возможен широкий спектр возрастов.
Я танго учил полтора года вместе с десятком других стилей пока ковид не наступил.
И танго пошло хуже всего. И женщинам кажется оно дается ещё тяжелее.
Зато в руэде программисты сразу танцуют с десятком партнерш, есть язык команд, четкий ритм, красивый рисунок, выход энергии больше чем в танго, очень редко надо тереться телами, меньше неловких моментов, больше динамики.
Какие патриотичные медработники в России!
А у нас в восточных европах наоборот. Всё стараются списать на ковид, ведь в этом случае тела не выдаются, точных причин никто не устанавливает, родственики не озабочены похоронами, но получают компенсацию на них.
Нам нужна диспетчеризация для домашних лифтов.
Т.е. выход в облака Azure, управление парком с групповыми операциями, риалтайм мониторинг, обновление ПО, логи, доступ с любых континентов, возможность отделения в группы и передача на владение третьим организациям.
Система управления там уже есть. Связь через USB VCOM с главной платой, через CAN со всей системой и через RS485 MODBUS с инвертером. Прикладные протоколы все кастомные.
Сколько будет стоить?
Ни в одном из трех примеров не было дано описания двойника и что в нем моделируется.
Кнут работал на уровне ассемблера.
Т.е думаю его слова сейчас напрямую относятся к разработчикам на Adruino или STM32 или чем-то подобном, т.е. малым встраиваемым системам.
Действительно когда кодируешь под микроконтроллер все время стараешься писать наиболее быстрые алгоритмы. Это как навязчивая мания, когнитивное искажение.
Потом оказывается что тормозит вовсе не то, что отняло столько внимания.
Но избавиться от него невозможно даже отлично зная советы Кнута, потому что есть что-то в психике.
Т.е. Кнут высказал не рекомендацию, а отметил медицинский факт.
Люди не перестанут ехать на другой конец города в другой магазин ради экономии пары центов.
Понятно.
Т.е. вы сразу какое бы простенькое приложение ни было всегда неявно требуете наличие TCP стека, файловой системы и операционной системы.
Потому что все должно сработать как в линуксе.
Оверхед доказан?
Лезу я в ваш репозитарий потому что вы сами предлагаете в него лезть. Для чего тогда все эти статьи?
Ок, я залез. Там пусто. Предлагается видимо идти в места расположения оригинальных пакетов. Но все что есть для этого — это какие-то невнятные аббревиатуры, даже минимальных подсказок нет. Спрашивается зачем такое выкладывать и пиарить? Где демки на этих проектах, доказавающие работоспособность?
Скажем из тройки lvgl nuklear, qt достоин внимания только lvgl.
Но он одинаково трудно портируется что под линукс что под windows. Там надо писать драйвер и под Chrom-ART там конечно драйвера нет!
Т.е. отсутствие преимущества доказано?
Ну и не забывайте что эти коменты читает весь интернет.
От того как вы отвечаете зависит в какой-то мере успешность вашего пиара.
Я же просто хочу отделить рациональные вещи от чисто субъективных предпочтений.
По сути диалог и заходит в область сравнения (которого вашей статье так не хватает) что есть в линуксе для embedded и что есть в RTOS растущих от железа.
Кстати я посмотрел ваш репозитарий проекта Embox.
Во-первых там черт ногу сломает, какая-то масса непонятных названий директорий сторонних опенсорсных проектов даже косвенно не намекающих зачем они нужны.
Во-вторых, действительно важные и мощные проекты типа SQLite, каких-то скриптовых движков, компрессоров и т.д. отлично портируются сразу на embedded платформу без линукса и симуляций.
То что действительно можно смело без привязки к аппаратуре симулировать — GUI. Для STM32 есть не менее 3-х прекрасных библиотек с которыми идут их демо платы, и они имеют адаптеры симуляции под Windows, но не под линукс. QT потрированный на STM32 по сравнению с ними мягко говоря бледнеет.
С другой стороны я не понял как можно компилировать библиотеку libmodbus под линукс и быть уверенным что она так же заработает на STM если у компиляторов разный retargeting
Как например выводить диагностические, отладочные, аварийные сообщения и куда?
Сколько они еще заберут стека, а сколько займут процессорного времени?
Вопросы риторические.
Тогда не надо будет мучится в симуляторах под линуксом.
Мучится — это потому что такой процесс требует времени и создания симуляции реальных условий.
Опять же кучу лучше сделать единой для всего, и для драйверов периферии и для верхнего уровня, так буде более экономно.
Словом ну ничего не способствует портированию линуксовых библиотек на STM32.
Как косвенное доказательство — отсутствие таких библиотек в STM32Cube.
Точно, если такая надпись будет, то это будет верный сигнал о возможности легкого переноса библиотеки на любую RTOS.
А пока вы не показали как на линуксе вычислили минимальный размер heap для этой библиотеки.
Да я вижу что вы немало времени провели над анализом расхода памяти в симуляциях под линуксом. Это говорит о том что проблему прекрасно понимаете и сорсы вы все таки дорабатываете. Либо вынуждены брать чипы с большим объемом памяти.
Но на целевой платформе эти тестовые прогоны в любом случае точнее. Поскольку они учитывают и расход памяти низкоуровневым слоем работы с периферией. Уж периферию то никак в линуксе просимулировать не удастся.
Конечно если вы эти статьи пишете для самого себя с целью само убеждения, то понять можно.
Но вроде как посыл был в утверждении превосходства вашего метода.
Так вот фактов превосходства представлено не было на мой взгляд.
Вот в это я и не верю.
Сколько раз я соединялся по modbus с промышленными контроллерами это всегда был челендж. 90% времени уходит на исследование проблем коммуникации.
Поскольку отсутствует исчерпывающая документация. О какой симуляции в линуксе может идти речь?
А если вы применили modbus для соединения одного своего дивайса с другим, то это исскуственный пример. Это история не про реальный modbus, а про то как сотворили оверхед. Т.е. по любому выполнили лишнюю работу.
Я даже не верю что линуксовые либы вообще можно использовать на STM32 без хитроумных рефакторингов, поскольку на STM самый дефицитный ресурс RAM, а в линуксе безоглядно используют heap. Да даже ограничения на стек заставляют стократно перепроверять все линуксовые сорсы чтобы не дай бог там не надумали делать массивы на стеке или списки со строками в автоматических переменных. Эт я еще не упомянул ретаргетинг С-ишных функций.
Тот же libmodbus вы должны были проверить на фрагментацию и исчерпание кучи, поскольку там вовсю используют malloc. Т.е. либо вы нам не рассказали о том как вы симмулируете фрагментацию на линуксе, либо вы не можете утвержадать что ваше приложение рабочее, поскольку не отлаживали его на целевой платформе.
Вот если в линуксовой либе специально указывают что она годная для embedded, то это другой разговор. Сам с удовольствием использую различные парсеры, интерпретаторы, протоколы из линукса. Но для этого не требуется сам линукс. Это лишний компонент.
Фактически же делается двойная работа.
Сначала делается симуляция на линуксе и для этого делаются cgi скрипты ( которые тоже надо отлаживать), а потом все равно надо все отлаживать на целевой платформе.
Есть же STM32CubeMonitor, быстрый STLink, симуляторы прямо в IDE под STM и прочие средства делающие разработку и отладку на платформе STM быстрой и удобной.
Не хватает сравнения, как этот процесс мог бы выглядеть на другой RTOS.
Посмотрим на книги которые вы упомянули:
Design of Analog CMOS Integrated Circuits
CMOS: Circuit Design, Layout, and Simulation
Это еще большее сужение области знаний.
Если нужен охват всей электроники я даж не знаю что посоветовать.
Ищите по кодовой фразе b-ok.global/s/Art%20of%20electronics
Кстати издание
Analog Circuit Design Volume 2: Immersion in the Black Art of Analog Design гораздо больше практических схем приводит чем в книге The Art of Electronics
Свинг там один из них. Мы например танцуем свинг, танго, фокстрот, румбу, ча-ча-ча и т.д. в течении одного занятия.
А на вечеринках все это нон-стоп сменяя одно друг друга.
Танцевать одно танго или один свинг это же скучно.
А я бы «The Art of Electronics» отнес к разряду каталогов, ибо там сплошь микросхемы от Analog Divices.
Чем новее издание тем больше в нем решений на микросхемах от AD. А где хотя-бы микросхемы от TI или Infineon?
ADC то описаны, но нюансы сопряжения их с микроконтроллерами не отражены никак.
То что у Хоровица написано есть в туче апнотов у всех производителей ADC.
А вот как сопрягать ADC одного производителя с uC другого — это уже более редкие знания.
Или как правильно трассировать?
Современный GPIO тоже не описывается просто уровнями напряжений, он гораздо сложнее.
И что интересно, начинающие сразу и упрутся во всю комплексность GPIO, потому что их описание в даташитах не упрощают, там десятки параметров и фичей. И они прочитав Хоровица все равно не поймут что там к чему.
Словом вопрос прост — откуда вы решили что именно такой состав знания нужен современному начинающему разработчику?
Какие-то есть аргументы?
Не стоит ли более четко разделить электронщиков по областям интересов, и сузить нишу Хоровица?
Я бы Хоровица поставил как необходимый источник для разработчиков микросхем, но не для современных разработчиков встраиваемой электроники к примеру.
Т.е. она в основном о сопряжении цифровых логических уровней. Большинство типов логики начинающие электронщики никогда в жизни не увидят.
В разделе про сопряжение с мощными нагрузками нету описания современных микросхем управления нагрузками в частности моторами и мелкими приводами.
Абсолютно нет информации о сопряжении полевых интерфейсов и локальных шин типа USB, Ethernet, CAN…
Нет ничего о сопряжении внешних аналоговых цепей с ADC микроконтроллеров, компараторами и GPIO.
Нет ничего про современные сенсоры IoT: акселерометры, гироскопы, IMU модули, емкостные, индуктивные и магнитные сенсоры приближения, вращения, движения…
Т.е. пропущено 90% информации необходимой начинающему современнному электронщику.
Не кажется ли вам что эта книга довольно таки устаревшая?
Я даж туда походил немного. Но это тема для очень молодых и сильных.
Поэтому ничего не могу сказать про толерантность. Специфика руэды в том что-бы более минуты с одним партнером не танцевать.
Говорить и что-то узнавать некогда.
На вечеринках в барах тоже не до разговоров в грохоте. Начинается раунд и просто цепляешься к тому кто ближе всего и не занят. Дресс-кода нет никакого. Эта необычайная демократичность довольно привлекательна.
На классических танцах перед началом цикла занятий обычно предлагают выбрать меняться партнерами или нет. Чаще люди склонны отказываться от такой практики. Но если тренер настоит ничего не поделаешь, но такой тренер сразу теряет часть класса.
Но истерики на тренировках между парами — обычное дело. На любых парных танцах и в сальсе в том числе. Тренеры любят метод периодической (5-10 мин) смены партнеров именно потому чтобы не возникало истерик и ругани.
Все партнершы танцуют со всеми партнерами. Нет дискриминации по уровню подготовки, когда самые натренированные танцуют только с тренированными или самые красивые с самыми красивыми.
Вот когда на открытых вечеринках на парных танцах такая заваруха начинается это сильно расстраивает.
Некрасивые женщины обижаются, мужики завидуют и зляться и т.д.
Поэтому парные танцы более напряжные. Надеяться что в танго у вас будут всегда сексуальные, умелые и привлекательные партнершы — наивно.
Клубы практикуют еще линейные танцы. Эт когда в ряд становятся и синхронно двигаются.
Сальса для линейного варианта есть, а вот танго нет.
Что сложнее, танго или сальса сказать не могу.
За полтора года удалось надежно выучить лишь 5-6 фигур в танго. Не забываем что партнерша тоже должна их выучить и оба понимать движения одинаково и повторяемо.
В сальсе удалось запомнить где-то больше 20 комбинаций движений на пике формы (мы ж инженеры, у нас кроме этого еще кучу чего надо каждый день запоминать и помнить).
Но в сальсе больше сотни комбинаций движений, которые надо четко помнить по названиям и по спец. жестам.
Команды жестами это уже высший пилотаж, мы до них даже не дошли.
Сальсу и руэду в частности можно танцевать в очень тесных и шумных клубах, где не слышно даже партнера. Словом у сальсы экспресивность не пропадает в любой обстановке, а для танго все же нужно пространство.
Я танго учил полтора года вместе с десятком других стилей пока ковид не наступил.
И танго пошло хуже всего. И женщинам кажется оно дается ещё тяжелее.
Зато в руэде программисты сразу танцуют с десятком партнерш, есть язык команд, четкий ритм, красивый рисунок, выход энергии больше чем в танго, очень редко надо тереться телами, меньше неловких моментов, больше динамики.
А у нас в восточных европах наоборот. Всё стараются списать на ковид, ведь в этом случае тела не выдаются, точных причин никто не устанавливает, родственики не озабочены похоронами, но получают компенсацию на них.
Т.е. выход в облака Azure, управление парком с групповыми операциями, риалтайм мониторинг, обновление ПО, логи, доступ с любых континентов, возможность отделения в группы и передача на владение третьим организациям.
Система управления там уже есть. Связь через USB VCOM с главной платой, через CAN со всей системой и через RS485 MODBUS с инвертером. Прикладные протоколы все кастомные.
Сколько будет стоить?