Как раз таки если цель прошивки опрашивать кнопку и мигать диодом то да частота ядра может и важна. А если у вас команда разработчиков и каждая группа работает над своей частью функционала, то да, многие могут и не знать какая-там частота у ядра. Многие даже не знают сколько их там тех ядер.
Ну например если системный фреймворк в компании делает отдельная команда и разработчики логики уже получают микроконтроллер на котором круттится таже FreeRTOS. Возьмите к примеру SDK который c ESP32 идет. Там в общем никакой разницы нет ядро на 180 или 200MHz работает. Примерно так же во многих компаниях делается. Небольшая команда запускает собственный фреймворк на новом MCU, а дальше команда работающая над целевым устройством это использует. Ну и потом, есть системы где частота ядра вообще динамически меняется в процессе работы. Завязываться на нее смысла вообще нет.
Это очень зависит от типа микроконтроллера и решаемых задач. Бывает, что от частоты работы ядра в общем-то ничего и не зависит особо если в предел производительности не упереться.
Я на Ethernet сам перешёл. Кабель в монитор, а монитор к макбуку по usb-c. Все равно у каждого рабочего места Ethernet есть, а wifi нет нет да и проседает иногда.
Это ещё делается потому что инит дисплея отлаживается с помощью кастомной софтины с GUI, а в итоге она генерит просто массив значений, которые надо отправить в регистры. Вот она так и попадает во всякие драйверы.
GOOS=android GOARCH=arm64 go build -o bin/simple-proxy
Вот это для меня основная киллер фича в Go. Простой командой, не качая ничего больше кроме самого Go, можно собрать бинарник который запустится на любом, даж самом сильно урезанном линуксе. Не знаю есть ли другой такой язык, позволяющий так просто собирать под практически любые таргет системы.
Скажем так, что перенос многих фций в планшет, в BMW не заставляет думать, что это что-то плохое и не надо было этого делать. Я не совсем понимаю, что я там должен делать в планшете в процессе езды. Климат настроен, аудио с руля переключается, для навигации голос есть. Ну и потом они оставили крутилку управления т.е. этим планшетом можно управлять не касаясь его.
Ну не знаю. У меня две машины, Honda Clarity где более менее стандартный набор кнопок и BMW, где вот два экрана, как в картинке в посте. Климат и подогревы в BMW в меню, да, не так удобно как в хонде, но я и не ладу туда часто. Температура есть всегда на экране снизу, а остальные ф-ции редко нужны. За несколько лет езды на обоих машинах не могу сказать, что страдаю из-за отсутствия каких-то кнопок. Наоборот, в BMW ехать приятней.
Вообще я заметил, что если в машине куча фций переносится в планшет, то требования к дизайну интерфейса должны быть сильно жостче. В этом в основном кроется проблема. Физические кнопки убрали, но нормального интерфейса не завезли.
Сравнивал точность предсказания остатка заряда в Model Y и BMW iX. Тесла на отрезке миль 25км ошиблась на 3% в большую сторону т.е. показывало больше остаток чем реально осталось когда приехали. BMW на расстоянии 150км ошиблась на 1% в меньшую сторону т.е. реально осталось больше чем она предсказывала.
Ожидается, что кандидат раскажет, как происходит возврат из ф-ции и если адрес возврата в стеке то почему он мог испортиться. Из опыта, больше половины тех кого я собеседовал на embedded SW инженера не понимают, как происходит вход и возврат из функций.
NASC - это механически разьем как у Тесла но внутри электрический протокол CCS. Для автопроизводителей это значит что надо только поменять форму разьема, електрически и програмно у них и так уже CCS. А вот Тесле нужно будет на суперчарджерах поменять электронику зарядных постов. Она должна иметь PLC модем для связи в формате CCS. Американские суперчарджеры не имеют этих модемов. Так же как их не имели европейские до релиза Model 3. В Европе все суперчарджеры были заменены, тоже самое ждет и штаты в случае принятия NASC.
Но не надо забывать, что переход только по механической части разъема. Интерфейс внутри будет использоваться стандартный CCS а не проприетарный от Теслы. Тут даже в Тесле понимают что их родной нужно менять.
похоже наигралась индустрия с интерактивным дизайном. Даже Андроид переходит на декларативный подход с их Compose.
Как раз таки если цель прошивки опрашивать кнопку и мигать диодом то да частота ядра может и важна.
А если у вас команда разработчиков и каждая группа работает над своей частью функционала, то да, многие могут и не знать какая-там частота у ядра. Многие даже не знают сколько их там тех ядер.
Ну например если системный фреймворк в компании делает отдельная команда и разработчики логики уже получают микроконтроллер на котором круттится таже FreeRTOS. Возьмите к примеру SDK который c ESP32 идет. Там в общем никакой разницы нет ядро на 180 или 200MHz работает. Примерно так же во многих компаниях делается. Небольшая команда запускает собственный фреймворк на новом MCU, а дальше команда работающая над целевым устройством это использует.
Ну и потом, есть системы где частота ядра вообще динамически меняется в процессе работы. Завязываться на нее смысла вообще нет.
Это очень зависит от типа микроконтроллера и решаемых задач. Бывает, что от частоты работы ядра в общем-то ничего и не зависит особо если в предел производительности не упереться.
А почему у производителя приемника не узнать, что там выдается на CAN?
Так по CAN или UART оно передается?
Я на Ethernet сам перешёл. Кабель в монитор, а монитор к макбуку по usb-c. Все равно у каждого рабочего места Ethernet есть, а wifi нет нет да и проседает иногда.
Это ещё делается потому что инит дисплея отлаживается с помощью кастомной софтины с GUI, а в итоге она генерит просто массив значений, которые надо отправить в регистры. Вот она так и попадает во всякие драйверы.
А можно еще приоткрыть глаза о том, что такое этот фаззинг и зачем он нужен?
Ну хотя бы по UDS из genealogy блока всю нужную инфу получить можно. Правда email разработчика или дата сборки вряд-ли туда попадает.
Вот это для меня основная киллер фича в Go. Простой командой, не качая ничего больше кроме самого Go, можно собрать бинарник который запустится на любом, даж самом сильно урезанном линуксе. Не знаю есть ли другой такой язык, позволяющий так просто собирать под практически любые таргет системы.
Скажем так, что перенос многих фций в планшет, в BMW не заставляет думать, что это что-то плохое и не надо было этого делать. Я не совсем понимаю, что я там должен делать в планшете в процессе езды. Климат настроен, аудио с руля переключается, для навигации голос есть. Ну и потом они оставили крутилку управления т.е. этим планшетом можно управлять не касаясь его.
Ну не знаю. У меня две машины, Honda Clarity где более менее стандартный набор кнопок и BMW, где вот два экрана, как в картинке в посте. Климат и подогревы в BMW в меню, да, не так удобно как в хонде, но я и не ладу туда часто. Температура есть всегда на экране снизу, а остальные ф-ции редко нужны. За несколько лет езды на обоих машинах не могу сказать, что страдаю из-за отсутствия каких-то кнопок. Наоборот, в BMW ехать приятней.
Вообще я заметил, что если в машине куча фций переносится в планшет, то требования к дизайну интерфейса должны быть сильно жостче. В этом в основном кроется проблема. Физические кнопки убрали, но нормального интерфейса не завезли.
Ну и да, сенсорные кнопки на руле в WV это зло.
Сравнивал точность предсказания остатка заряда в Model Y и BMW iX. Тесла на отрезке миль 25км ошиблась на 3% в большую сторону т.е. показывало больше остаток чем реально осталось когда приехали. BMW на расстоянии 150км ошиблась на 1% в меньшую сторону т.е. реально осталось больше чем она предсказывала.
Ожидается, что кандидат раскажет, как происходит возврат из ф-ции и если адрес возврата в стеке то почему он мог испортиться. Из опыта, больше половины тех кого я собеседовал на embedded SW инженера не понимают, как происходит вход и возврат из функций.
Да, ожидается, что кандидат скажет про стек и перечислет варианты из-за чего он мог бы испортиться.
NASC - это механически разьем как у Тесла но внутри электрический протокол CCS. Для автопроизводителей это значит что надо только поменять форму разьема, електрически и програмно у них и так уже CCS. А вот Тесле нужно будет на суперчарджерах поменять электронику зарядных постов. Она должна иметь PLC модем для связи в формате CCS. Американские суперчарджеры не имеют этих модемов. Так же как их не имели европейские до релиза Model 3. В Европе все суперчарджеры были заменены, тоже самое ждет и штаты в случае принятия NASC.
Ну и хорошо, что отсутствует. Пусть где-то за океаном регулируют.
NACS это только механика, внутри будет CCS. И Тесле придется переделать свои суперчарджеры чтобы он поддерживался.
Но не надо забывать, что переход только по механической части разъема. Интерфейс внутри будет использоваться стандартный CCS а не проприетарный от Теслы. Тут даже в Тесле понимают что их родной нужно менять.