Раньше так про С говорили те, кто писал на ассеблере. А до них про так про ассемблер говорили те, кто набивал перфокарты. А до них про перфокарты так говорили те, кто считал на счетах. Угадайте что говорили о тех кто считал на счетах те, кто ...
Просто есть подозрение, что задачи тут не при чем. А речь о компетенциях. Почему бы просто не признать, что вот при таком уровне компетенций и ресурсах мы выбираем вот такой ПЛК, других выбрать не могли, но нет времени на освоение ST и всех либ с API, поэтому еще и C используем. Не вижу ничего в этом плохого, нормальная экономика в условиях ограничений. Но маскировать одну причину некоей абстрактной свободой или некими задачами, это знаете ли так себе. Описали бы тогда вашу задачу. А то ни то, ни сё. Неинформативно. Как выглядят кривые интерфейсы разных IDE полагаю и так все знают.
Так и не понял в чем преимущество программирования ПЛК на C. На C программируют сложные глубоко встроенные системы. А ПЛК это про программирование только верхнего слоя и про масштабирование. Если приходится вручную писать расчет SHA256 на ПЛК, значит неправильно выбран ПЛК. SHA считается уже давно аппартатно на STM32, ESP32 и прочей мелочи. Если на ПЛК в демо-примере обрабатывается пара светодиодов, то тема ПЛК вообще не раскрыта. ПЛК - это когда вы одним движением руки переходите от десятка сигналов к тысяче. И нужно лишь показать как это движение сделать и как увидеть лимит и не разрушить риалтайм. Нужна демонстрация в IDE масштабного рефакторига - одновременных операций над тычячами переменных таких как: переименования, мапирование на физические сигналы, редактирование типов и т.д. Как тут поможет C непонятно. Другое дело графические нотации типа Stateflow. У них хоть и нет нативной масштабируемости, но зато уникальная гибкость в рефакторинге архитектуры. Гибридная графическая нотация типа Stateflow гораздо легче воспринимается чем чисто текстовая.
На этот счет какое-то время назад был изобретен протокол ExpressivePixels с открытым кодом. В анимации на embedded самое сложное - создать саму анимацию.
К сожалению такие статьи не приносят много информации. ChatGPT больше по этой теме скажет. Было бы интересно увидеть сами алгоритмы слияния типа EKF или Madgick. Например посмотреть на график такого типа:
Чтобы понять возможность слияния данных IMU и GPS и ресурсоемкость алгоритмов.
Да уж, медики нам подскажут. Это те самые медики кторые дали нижнюю границу 5.6, человеку измерили 5.1 аппаратами с погрешностью в 20% и сказали что он может спать спокойно. А ведь при погрешности 20% это может быть уже и 6.1 - почти конец. Поэтому важнее симптомы, а не показания и комментарии медиков. Симптомы надо собирать комплексно. Это и давление, и ЭКГ, и качество сна, и пульс под нагрузками и прочее.
There are several situations in which sensor readings alone should not be used for making treatment decisions. These include rapidly changing glucose levels indicated by trends arrows pointing straight up or down, sensor readings in the hypoglycemic range, or when symptoms do not match sensor readings. In these instances, confirmatory blood glucose checking should be performed.
Т.е. именно показания о пониженной глюкозе и показания о резком изменении глюкозы являются самыми сомнительными. И симптомы важнее показаний, а не наоборот. Одна из причин в том, что измеряется глюкоза не напрямик в крови, а в коже. Может стоит посидеть пока ни диете и копить деньги на будущие часы с инфракрасными спектрометрами от Samsung. Будут и точнее и юзабельнее.
Я бы уточнил - контроллер в семействе. Но не семейство и тем более не архитектура. И вряд ли кто-то научит выбирать правильные архитектуры. Слишком уже развит vendor lock-in
Понимаю. Походу Segger сам дал этой технологии широкое толкование. Но вот тут я описал какая связь между SWO и RTT. А у вас через RTT через JTAG, по честном это и есть тот медленный semihosting. JTAG - это медленно и неэфективно. Быстро - это когда в чипе есть ARM CoreSight DAP.
Нет никакого RTT в ESP32, поскольку нет SWO. JTAG по сравнению с SWO и по сравнению с настоящей трасировкой весьма неэффективный канал отладки. Поэтому думаю разработчик на ESP будет процентов на 100% тратить больше времени на отладку, чем разработчик на любом ARM Cortex M
У esp32 мало ног и очень слабый отладочный встроенный движок. Из него не сдалать комбайна типа такого. А вот Raspberry Pi Pico 2 W на такое претендует. Но мультипроцессорность сильно неудобна если количество разработчиков ограничено одним.
Надо все же признать что чип ADAU1701 довольно старый, и АЦП его все те же 24 бита. Нынче на 24 бита можно найди кодеки со встроенными эквалайзерами которым не нужно компилировать прошивку, чтобы просто перестроить эквалайзер. А поставив к современному кодеку чип с ARM Cortex-M85 можно работать с 64-битным промежуточным звуком. Кстати, подключение аудиосигналов проводниками без экранов - это осознанное решение?
На производстве еще были матричные игольчатые установки проверки печатных плат.
Шаг у них был что вроде 2.54 и PCAD 4.5 с его привязкой к сетке очень помогал в разработке плат с переходными строго по сетке. Платы перед покрытием прогоняли на таких стендах. Стенды сопровождались громоздким вычислительным блоком выводившим инфу на принтер. И тоже была забава перепрошить ПЗУ этого блока, чтобы он выводил что тебе хочется. Прошивки тогда не защищались, схемы были полными. Твори - не хочу.
С PCAD 4.5 было несколько проблем. Надо было вылечить сам PCAD, потом надо было вылечить автотрассировщик Spectra. Авторассировка в те времена кстати проходила на ура. Все дорожки можно было спокойно делать одной ширины. У нас делали 0.6 мм. Частоты были низкими, о плэйнах никто еще не слыхал. Так что ортогональная трассировка прекрасно подходила. Переходных ставили по два. Да, в отделе появлялись лишние люди и всю работу приходилось брать самому. Ну так и зарплату надо было платить одному. Тогда вопрос стоял не сколько получать, а получать ли вообще. И PCAD 4.5 здорово тогда помог самым умным выйти из нищеты. Самый высший пилотаж был сделать утилиту для вывода из PCAD не перфоленту, которую понимали немецкие сверлильные станки. С фотоплоттерами было меньше проблем.
Умиляет вот такое. Да, подключается без глюков, а вот работает из этих глюков не вылезая. Вся семейка CYW43 - это сплошной глюкодром. Их будут давить и глушить все роутеры и экстендеры в округе.
Смотрите еще раз внимательней. Подключение кварца совпадает. Подключение питания совпадает насколько видно. SPI Flash, можно уверенно сказать, подключена к SPI0 чипа. Дисплей тоже подключен к SPI. Совпадение? ... Не думаю. ®
Согласен. Кварц не подходит и не туда подключен. По подключению кварца и по частоте очень похоже на чип MSPM0G310x Там кстати и CAN-FD самый продвинутый и к дисплею ноги SPI подходят и пины на CAN с правильной стороны. И памяти мало, так что надо внешнюю цеплять для хранения виджетов дисплея.
Вариантов тут не так много как кажется. Не более 7 производителей и не более 13 вариантов семейств. Если не считать совсем нишевые чипы.
Тут ролик вылез, где более четко про будущее сказали - https://www.youtube.com/watch?v=JmpBqphgNhc Если в кратце, то будущее за GB200 NVL72 SuperPOD. Им будет владеть единолично NVIDIA, и с помощью него получит мировое господство. Программисты действительно станут совершенно не нужны. Потому что им не на чём будет программировать. PC станут бессмысленны. SuperPOD будет быстрее их в 1000 раз, и прогать на PC будут только маргиналы. Все будут либо заняты обучением на удаленке инстансов SuperPOD-а , потому что SuperPOD громаден и прожорлив. Либо сопровождать его продукты жизнедеятельности на исполнительных контроллерах той же NVIDIA. Вот такое светлое будущее.
Раньше так про С говорили те, кто писал на ассеблере. А до них про так про ассемблер говорили те, кто набивал перфокарты. А до них про перфокарты так говорили те, кто считал на счетах. Угадайте что говорили о тех кто считал на счетах те, кто ...
Просто есть подозрение, что задачи тут не при чем. А речь о компетенциях.
Почему бы просто не признать, что вот при таком уровне компетенций и ресурсах мы выбираем вот такой ПЛК, других выбрать не могли, но нет времени на освоение ST и всех либ с API, поэтому еще и C используем.
Не вижу ничего в этом плохого, нормальная экономика в условиях ограничений.
Но маскировать одну причину некоей абстрактной свободой или некими задачами, это знаете ли так себе. Описали бы тогда вашу задачу. А то ни то, ни сё. Неинформативно.
Как выглядят кривые интерфейсы разных IDE полагаю и так все знают.
Так и не понял в чем преимущество программирования ПЛК на C.
На C программируют сложные глубоко встроенные системы. А ПЛК это про программирование только верхнего слоя и про масштабирование.
Если приходится вручную писать расчет SHA256 на ПЛК, значит неправильно выбран ПЛК. SHA считается уже давно аппартатно на STM32, ESP32 и прочей мелочи.
Если на ПЛК в демо-примере обрабатывается пара светодиодов, то тема ПЛК вообще не раскрыта.
ПЛК - это когда вы одним движением руки переходите от десятка сигналов к тысяче. И нужно лишь показать как это движение сделать и как увидеть лимит и не разрушить риалтайм. Нужна демонстрация в IDE масштабного рефакторига - одновременных операций над тычячами переменных таких как: переименования, мапирование на физические сигналы, редактирование типов и т.д.
Как тут поможет C непонятно.
Другое дело графические нотации типа Stateflow. У них хоть и нет нативной масштабируемости, но зато уникальная гибкость в рефакторинге архитектуры. Гибридная графическая нотация типа Stateflow гораздо легче воспринимается чем чисто текстовая.
На этот счет какое-то время назад был изобретен протокол ExpressivePixels с открытым кодом.
В анимации на embedded самое сложное - создать саму анимацию.
К сожалению такие статьи не приносят много информации.
ChatGPT больше по этой теме скажет.
Было бы интересно увидеть сами алгоритмы слияния типа EKF или Madgick.
Например посмотреть на график такого типа:
Чтобы понять возможность слияния данных IMU и GPS и ресурсоемкость алгоритмов.
Да уж, медики нам подскажут.
Это те самые медики кторые дали нижнюю границу 5.6, человеку измерили 5.1 аппаратами с погрешностью в 20% и сказали что он может спать спокойно.
А ведь при погрешности 20% это может быть уже и 6.1 - почти конец.
Поэтому важнее симптомы, а не показания и комментарии медиков.
Симптомы надо собирать комплексно. Это и давление, и ЭКГ, и качество сна, и пульс под нагрузками и прочее.
Однако вот цитата из статьи:
Т.е. именно показания о пониженной глюкозе и показания о резком изменении глюкозы являются самыми сомнительными. И симптомы важнее показаний, а не наоборот. Одна из причин в том, что измеряется глюкоза не напрямик в крови, а в коже.
Может стоит посидеть пока ни диете и копить деньги на будущие часы с инфракрасными спектрометрами от Samsung. Будут и точнее и юзабельнее.
Я бы уточнил - контроллер в семействе. Но не семейство и тем более не архитектура.
И вряд ли кто-то научит выбирать правильные архитектуры. Слишком уже развит vendor lock-in
Понимаю. Походу Segger сам дал этой технологии широкое толкование.
Но вот тут я описал какая связь между SWO и RTT.
А у вас через RTT через JTAG, по честном это и есть тот медленный semihosting.
JTAG - это медленно и неэфективно. Быстро - это когда в чипе есть ARM CoreSight DAP.
Нет никакого RTT в ESP32, поскольку нет SWO.
JTAG по сравнению с SWO и по сравнению с настоящей трасировкой весьма неэффективный канал отладки.
Поэтому думаю разработчик на ESP будет процентов на 100% тратить больше времени на отладку, чем разработчик на любом ARM Cortex M
У esp32 мало ног и очень слабый отладочный встроенный движок. Из него не сдалать комбайна типа такого.
А вот Raspberry Pi Pico 2 W на такое претендует.
Но мультипроцессорность сильно неудобна если количество разработчиков ограничено одним.
Надо все же признать что чип ADAU1701 довольно старый, и АЦП его все те же 24 бита. Нынче на 24 бита можно найди кодеки со встроенными эквалайзерами которым не нужно компилировать прошивку, чтобы просто перестроить эквалайзер.
А поставив к современному кодеку чип с ARM Cortex-M85 можно работать с 64-битным промежуточным звуком.
Кстати, подключение аудиосигналов проводниками без экранов - это осознанное решение?
На производстве еще были матричные игольчатые установки проверки печатных плат.
Шаг у них был что вроде 2.54 и PCAD 4.5 с его привязкой к сетке очень помогал в разработке плат с переходными строго по сетке. Платы перед покрытием прогоняли на таких стендах.
Стенды сопровождались громоздким вычислительным блоком выводившим инфу на принтер. И тоже была забава перепрошить ПЗУ этого блока, чтобы он выводил что тебе хочется. Прошивки тогда не защищались, схемы были полными. Твори - не хочу.
С PCAD 4.5 было несколько проблем. Надо было вылечить сам PCAD, потом надо было вылечить автотрассировщик Spectra. Авторассировка в те времена кстати проходила на ура. Все дорожки можно было спокойно делать одной ширины. У нас делали 0.6 мм. Частоты были низкими, о плэйнах никто еще не слыхал. Так что ортогональная трассировка прекрасно подходила. Переходных ставили по два. Да, в отделе появлялись лишние люди и всю работу приходилось брать самому. Ну так и зарплату надо было платить одному. Тогда вопрос стоял не сколько получать, а получать ли вообще.
И PCAD 4.5 здорово тогда помог самым умным выйти из нищеты.
Самый высший пилотаж был сделать утилиту для вывода из PCAD не перфоленту, которую понимали немецкие сверлильные станки. С фотоплоттерами было меньше проблем.
Умиляет вот такое.
Да, подключается без глюков, а вот работает из этих глюков не вылезая.
Вся семейка CYW43 - это сплошной глюкодром. Их будут давить и глушить все роутеры и экстендеры в округе.
Смотрите еще раз внимательней.
Подключение кварца совпадает. Подключение питания совпадает насколько видно. SPI Flash, можно уверенно сказать, подключена к SPI0 чипа. Дисплей тоже подключен к SPI.
Совпадение? ... Не думаю. ®
Согласен. Кварц не подходит и не туда подключен.
По подключению кварца и по частоте очень похоже на чип MSPM0G310x
Там кстати и CAN-FD самый продвинутый и к дисплею ноги SPI подходят и пины на CAN с правильной стороны. И памяти мало, так что надо внешнюю цеплять для хранения виджетов дисплея.
Вариантов тут не так много как кажется. Не более 7 производителей и не более 13 вариантов семейств. Если не считать совсем нишевые чипы.
Это скорее всего ESP32-H2.
Там есть CAN (TWAI) и мультиплексирование любой периферии на любые пины. Корпус совпадает.
Тут ролик вылез, где более четко про будущее сказали - https://www.youtube.com/watch?v=JmpBqphgNhc
Если в кратце, то будущее за GB200 NVL72 SuperPOD. Им будет владеть единолично NVIDIA, и с помощью него получит мировое господство.
Программисты действительно станут совершенно не нужны. Потому что им не на чём будет программировать. PC станут бессмысленны. SuperPOD будет быстрее их в 1000 раз, и прогать на PC будут только маргиналы. Все будут либо заняты обучением на удаленке инстансов SuperPOD-а , потому что SuperPOD громаден и прожорлив. Либо сопровождать его продукты жизнедеятельности на исполнительных контроллерах той же NVIDIA.
Вот такое светлое будущее.
По любому шум надо было исследовать, иначе прилетит бумерангом.