Главная проблема регулярок для меня - изучать их в отрыве от конкретной задачи ленишься, а при решении конкретной задачи они эмбеддеру нужны раз в год. Поэтому каждый раз открываешь их для себя с нуля :)
За мануал спасибо, было наглядно. Увижусь с ним, по моим расчетам, месяца через четыре :)
мне кажется, один только красивый качественный корпус вполне может весомо удорожать девайс. да и блок питания - не пустяк. но это ладно.
а вот зачем знать, какой там wifi-модуль? что даст знание спецификации вайфай или блютуса? вряд ли это секретная информация, но просто непонятно - а зачем?
Люблю интернет за потрясающую доброту комментариев. "Автор, ну куда ты полез, да еще статью об этом написал, все совсем не так". Что характерно, как должно быть "так" - никто не рассказывает, пока статью не напишешь :)
1) Респект за статью. Дельно и по существу. Может, и изобретение велосипеда (не знаю, никогда не смотрел на процессы разработки софта для automotive), но очень предметное и полезное. ИМХО, один из главных плюсов статьи - подробное описание встреченных граблей. Это та информация, которой не делятся производители. И в то же время - это ценный источник компетенций.
2) Есть у меня подозрение, что при всем опыте того же боша - не так уж там все гладко. В конце концов, не на ровном месте у них столько версий систем управления. так что заходы типа "делают совсем не так" и "прогоняют миллионы тестов", имхо, не относятся к делу.
3) Про электронную педаль.
"физическая педаль газа в виде реостата (переменного резистора) - это такой ползунок, который может двигаться между двумя позициями, в коде мы знаем насколько он сдвинут - на 0% или на 100%. Ничем не отличается от электронной педали газа."
Душню, но: электронная педаль газа - тоже с двумя резисторами. Только обычно не "противоположно направленными", а подобранными так, чтоб на выходе одного всегда напряжение было в два раза выше, чем на выходе второго.
4) Не знаю, доводилось слышать или нет про проект опенсорсного блока управления двигателем - https://rusefi.com/
Рискну предположить, что польза от понимания происходящего "под капотом ide" не столько в чувстве удовлетворения, сколько в том, что гораздо понятнее становится, что делать, если что-то пошло не так при сборке. Что автоматически сильно сокращает время на починку сломавшейся сборки.
Всякие там автосборки и ci/cd - это уж как пойдет, а вот понимание, что и как происходит - оно здесь и сейчас.
Опять же, настроил однажды тулчейн под stm32 - потом значительно проще будет разбираться с тулчейном от какого-нибудь nordic, у которого даже не знаю, есть ли своя ide :)
1) Что касается сути замечаний - повторюсь, они приняты и я за них благодарен, они действительно по делу. Статья будет как минимум дополнена замечаниями, что здесь рассмотрен легаси и что так не надо писать новые драйверы.
2) Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с SDK от того же allwinner? Или эту задачу она не решает?
3) Список использованных материалов не был приведен, т.к. их особо, кроме исходников, и не использовалось. Сейчас, после дополнений, вероятно, стоит его написать.
4) я охотно принимаю замечания и не пытаюсь перейти на личности. просто аллергия на тональность "о госссподи, да все же знают, что...". Потому что "все знают", но мало кто этим знанием делится в понятной форме. А когда начинаешь копать условно с нуля - всей этой информации остро не хватает. И, так уж складывается, найти все это легко только тогда, когда уже знаешь, что именно искать. Возможно, вы не до конца осознаете, но воспринимается написанное вами именно как тот самый тон. Может, конечно, это я излишне снежинка. Но обычно мои ощущения меня не обманывают. Поэтому я пытаюсь попросить высказываться немного нейтральнее.
Хорошо. А почему вы считаете, что это статья "как надо писать драйверы", а не "как устроены драйверы для распространенных чипов"? Пользуясь вашей тональностью - вы бы хотя бы прочитали заголовок, который приведен аж в самом начале строки :)
GPIO UAPI был уже c 4.6-r1, в stable пошло ядро 4.19, так насколько легаси нам нужно ?
Вот я беру и делаю что-то на Allwinner. Вижу в доступном мне SDK именно такой драйвер. Да, легаси. И что, теперь надо переписать драйвер, или реализовывать все же свою задачу?)
1) безусловно, использование gpio из userspace - это в принципе не очень хорошая практика, независимо от способа доступа. GPIO должен быть завернут во что-то. gpio-keys, gpio-leds, что-то более другое.
2) да, вероятно, брать старые железки со старыми ядрами - не самый оптимальный вариант, и современный код изучать правильнее. Спасибо за ссылки, это полезная информация. Тем не менее, есть множество массово производимых и разрабатываемых устройств, где используются ядра 4.x и 5.x, где используется вендорский sdk именно с таким кодом, или около того.
Поэтому, вероятно, для авторов новых драйверов эта статья - пример того, как не надо делать. А вот для тех, кто применяет существующее - вполне может быть полезно.
3) Не совсем понял, что значит "сразу нет", применительно к процитированным участкам кода.
4) вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Лайк как минимум за попытку систематизировать вот это вот все. Мои попытки написать про блютус всегда упираются в то, что попытка рассказать про "вот эту маленькую штуку" превращается в необходимость рассказать про весь стек целиком :)
Кажется, между "пост не дал ничего полезного" и "я зря потратил свое время" - есть некоторая разница. Возможно, не стоит личное мнение о материале уравнивать с объективной полезностью материала.
Горячий опыт новенького тимлида - это как минимум ценно тем, что записано по свежим впечатлениям. Опытные матерые тимлиды про такое не пишут. Они напишут кейсы и решения, но вот общее ощущение "я, дурак, думал, что буду успевать писать код" - вряд ли.
Хм, нет, это что-то не так.
Сколько кордовы (и плагинов) видел — вполне нормально это разбивалось на несколько js, и полотна кода не требовались… И HTML вполне себе отдельный HTML, не смешанный с js.
Про ошибку в WebView — сложно сказать, моя работа с кордовой сводится к относительно простым тестовым проектам и плагинам, сложных вещей в UI я не делал, может, не натыкался просто.
Ну, по поводу «самый-самый» — тут мне сложно оценить, я не так много фреймворков трогал руками)
Понял, спасибо.
я как-то свыкся с идеей, что "вчера собиралось — сегодня нет" — это основа основ программирования, поэтому даже не ощущаю этого как минуса :)
Спасибо, развернуто. А можно еще раскрыть про "априори проигрывают в юзабили нативным решениям"? В идеале — с примером. А то не совсем понятно, что имеется в виду.
А расскажете, какие трудности возникли с поддержкой этих проектов? Ну то есть, я нисколько не сомневаюсь в их объективности, но всем было бы полезно знать конкретику.
А расскажете подробнее? Хотелось бы подробностей о минусах, детальнее. Думаю, полезно будет не только мне, но и тем, кто наткнется на эту статью через годы :)
Главная проблема регулярок для меня - изучать их в отрыве от конкретной задачи ленишься, а при решении конкретной задачи они эмбеддеру нужны раз в год. Поэтому каждый раз открываешь их для себя с нуля :)
За мануал спасибо, было наглядно. Увижусь с ним, по моим расчетам, месяца через четыре :)
мне кажется, один только красивый качественный корпус вполне может весомо удорожать девайс. да и блок питания - не пустяк. но это ладно.
а вот зачем знать, какой там wifi-модуль? что даст знание спецификации вайфай или блютуса? вряд ли это секретная информация, но просто непонятно - а зачем?
Люблю интернет за потрясающую доброту комментариев. "Автор, ну куда ты полез, да еще статью об этом написал, все совсем не так". Что характерно, как должно быть "так" - никто не рассказывает, пока статью не напишешь :)
1) Респект за статью. Дельно и по существу. Может, и изобретение велосипеда (не знаю, никогда не смотрел на процессы разработки софта для automotive), но очень предметное и полезное. ИМХО, один из главных плюсов статьи - подробное описание встреченных граблей. Это та информация, которой не делятся производители. И в то же время - это ценный источник компетенций.
2) Есть у меня подозрение, что при всем опыте того же боша - не так уж там все гладко. В конце концов, не на ровном месте у них столько версий систем управления. так что заходы типа "делают совсем не так" и "прогоняют миллионы тестов", имхо, не относятся к делу.
3) Про электронную педаль.
"физическая педаль газа в виде реостата (переменного резистора) - это такой ползунок, который может двигаться между двумя позициями, в коде мы знаем насколько он сдвинут - на 0% или на 100%. Ничем не отличается от электронной педали газа."
Душню, но: электронная педаль газа - тоже с двумя резисторами. Только обычно не "противоположно направленными", а подобранными так, чтоб на выходе одного всегда напряжение было в два раза выше, чем на выходе второго.
4) Не знаю, доводилось слышать или нет про проект опенсорсного блока управления двигателем - https://rusefi.com/
Возможно, пригодится. Или нет.
век живи - век учись) я тогда добился сборки с мейкфайлом, и даже не посмотрел альтернативы. а оно вон оно как)
Рискну предположить, что польза от понимания происходящего "под капотом ide" не столько в чувстве удовлетворения, сколько в том, что гораздо понятнее становится, что делать, если что-то пошло не так при сборке. Что автоматически сильно сокращает время на починку сломавшейся сборки.
Всякие там автосборки и ci/cd - это уж как пойдет, а вот понимание, что и как происходит - оно здесь и сейчас.
Опять же, настроил однажды тулчейн под stm32 - потом значительно проще будет разбираться с тулчейном от какого-нибудь nordic, у которого даже не знаю, есть ли своя ide :)
Это интересный вопрос. Сходу точно не отвечу, надо смотреть и изучать. Запланирую :) либо дополню сюда, либо в следующей статье.
Это правда. А не нравится именно формулировка, или тут какая-то фактическая ошибка?
Опять же по пунктам, от сути к восприятию:
1) Что касается сути замечаний - повторюсь, они приняты и я за них благодарен, они действительно по делу. Статья будет как минимум дополнена замечаниями, что здесь рассмотрен легаси и что так не надо писать новые драйверы.
2) Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с SDK от того же allwinner? Или эту задачу она не решает?
3) Список использованных материалов не был приведен, т.к. их особо, кроме исходников, и не использовалось. Сейчас, после дополнений, вероятно, стоит его написать.
4) я охотно принимаю замечания и не пытаюсь перейти на личности. просто аллергия на тональность "о госссподи, да все же знают, что...". Потому что "все знают", но мало кто этим знанием делится в понятной форме. А когда начинаешь копать условно с нуля - всей этой информации остро не хватает. И, так уж складывается, найти все это легко только тогда, когда уже знаешь, что именно искать. Возможно, вы не до конца осознаете, но воспринимается написанное вами именно как тот самый тон. Может, конечно, это я излишне снежинка. Но обычно мои ощущения меня не обманывают. Поэтому я пытаюсь попросить высказываться немного нейтральнее.
Хорошо. А почему вы считаете, что это статья "как надо писать драйверы", а не "как устроены драйверы для распространенных чипов"? Пользуясь вашей тональностью - вы бы хотя бы прочитали заголовок, который приведен аж в самом начале строки :)
Вот я беру и делаю что-то на Allwinner. Вижу в доступном мне SDK именно такой драйвер. Да, легаси. И что, теперь надо переписать драйвер, или реализовывать все же свою задачу?)
Давайте по порядку.
1) безусловно, использование gpio из userspace - это в принципе не очень хорошая практика, независимо от способа доступа. GPIO должен быть завернут во что-то. gpio-keys, gpio-leds, что-то более другое.
2) да, вероятно, брать старые железки со старыми ядрами - не самый оптимальный вариант, и современный код изучать правильнее. Спасибо за ссылки, это полезная информация. Тем не менее, есть множество массово производимых и разрабатываемых устройств, где используются ядра 4.x и 5.x, где используется вендорский sdk именно с таким кодом, или около того.
Поэтому, вероятно, для авторов новых драйверов эта статья - пример того, как не надо делать. А вот для тех, кто применяет существующее - вполне может быть полезно.
3) Не совсем понял, что значит "сразу нет", применительно к процитированным участкам кода.
4) вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Лайк как минимум за попытку систематизировать вот это вот все. Мои попытки написать про блютус всегда упираются в то, что попытка рассказать про "вот эту маленькую штуку" превращается в необходимость рассказать про весь стек целиком :)
Спасибо)
Про аварийное удаление драйвера - действительно, интересно поизучать. Поставил в бэклог :)
о да, драйвера звуковых устройств - отдельный жанр, достойный лонгрида :)
Кажется, между "пост не дал ничего полезного" и "я зря потратил свое время" - есть некоторая разница. Возможно, не стоит личное мнение о материале уравнивать с объективной полезностью материала.
Горячий опыт новенького тимлида - это как минимум ценно тем, что записано по свежим впечатлениям. Опытные матерые тимлиды про такое не пишут. Они напишут кейсы и решения, но вот общее ощущение "я, дурак, думал, что буду успевать писать код" - вряд ли.
Сколько кордовы (и плагинов) видел — вполне нормально это разбивалось на несколько js, и полотна кода не требовались… И HTML вполне себе отдельный HTML, не смешанный с js.
Про ошибку в WebView — сложно сказать, моя работа с кордовой сводится к относительно простым тестовым проектам и плагинам, сложных вещей в UI я не делал, может, не натыкался просто.
Ну, по поводу «самый-самый» — тут мне сложно оценить, я не так много фреймворков трогал руками)
Понял, спасибо.
я как-то свыкся с идеей, что "вчера собиралось — сегодня нет" — это основа основ программирования, поэтому даже не ощущаю этого как минуса :)
Спасибо, развернуто. А можно еще раскрыть про "априори проигрывают в юзабили нативным решениям"? В идеале — с примером. А то не совсем понятно, что имеется в виду.
А расскажете, какие трудности возникли с поддержкой этих проектов? Ну то есть, я нисколько не сомневаюсь в их объективности, но всем было бы полезно знать конкретику.
А расскажете подробнее? Хотелось бы подробностей о минусах, детальнее. Думаю, полезно будет не только мне, но и тем, кто наткнется на эту статью через годы :)