я не могу похвастаться большим производственным опытом. Но там, где я мог видеть сборку девайсов, всегда в приоритете было "сначала собрать плату, а уже потом прошить". Если купленные микросхемы флэш надо сначала где-то прошить, а потом передать на сборку плат - это выглядит лишним этапом, который усложняет производство.
С основным посылом согласен полностью. "Настоящий писатель будет писать и бесплатно" - это хамство, конечно. Очень радует, что все знают, что должен делать настоящий писатель. Быть смиренным и не думать о своем вознаграждении. Чота не вижу тут мнений типа "настоящий программист должен писать код бесплатно, а за деньги это делают примазавшиеся к Настоящему Программированию".
В то же время, с реальной жизнью сложно спорить. Если общество не платит массово за книги - значит, обществу это не надо. Имею частное мнение, что даже если победить пиратство - то особых продаж книг не возникнет. Раньше книга была единственным легко доступным развлечением, не было опции "скачать и посмотреть любой фильм" или "три часа листать ленту тиктока". А сейчас все это есть, и это для большинства - проще, чем читать. А значит, серьезных денег на этом нишевом рынке так и так не будет. Остальное - всего лишь следствие.
так что увы. такой у нас исторический период. Программирование, думаю, тоже поувянет через пару лет.
Автор, а вы хотели беспристрастно рассказать об опыте использования колонкой, или отомстить производителю за несоответствие вашим ожиданиям? Общая тональность статьи заставляет предположить второе.
Вы недооцениваете роль инженера по применению. Покупатель всегда задаст какие-то вопросы, ответы на которые продажник просто не может знать. И более того, продажник просто не поймет, корректно ли вопрос сформулирован.
Разработчик/интегратор сможет ответить, но держать целого разработчика на поддержку продаж - очень накладно. Кроме того, у разработчика чаще всего не развит скилл "вытащить из заказчика подробности о его применении".
Проблема в другом. Те, кто может быть инженером по применению, могут быть и полноценным разработчиком - за гораздо больший прайс к тому же. И мотивацией сидеть в роли инженера по применению остается только "общение с людьми". Что, впрочем, так себе мотивация. Вот и получается, что поди еще найди такого специалиста.
Я в свое время пришел к тому, что инженер по применению должен поработать года два и перейти в разработчики. тогда все более-менее довольны.
Главная проблема регулярок для меня - изучать их в отрыве от конкретной задачи ленишься, а при решении конкретной задачи они эмбеддеру нужны раз в год. Поэтому каждый раз открываешь их для себя с нуля :)
За мануал спасибо, было наглядно. Увижусь с ним, по моим расчетам, месяца через четыре :)
мне кажется, один только красивый качественный корпус вполне может весомо удорожать девайс. да и блок питания - не пустяк. но это ладно.
а вот зачем знать, какой там 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) вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Лайк как минимум за попытку систематизировать вот это вот все. Мои попытки написать про блютус всегда упираются в то, что попытка рассказать про "вот эту маленькую штуку" превращается в необходимость рассказать про весь стек целиком :)
Кажется, между "пост не дал ничего полезного" и "я зря потратил свое время" - есть некоторая разница. Возможно, не стоит личное мнение о материале уравнивать с объективной полезностью материала.
Горячий опыт новенького тимлида - это как минимум ценно тем, что записано по свежим впечатлениям. Опытные матерые тимлиды про такое не пишут. Они напишут кейсы и решения, но вот общее ощущение "я, дурак, думал, что буду успевать писать код" - вряд ли.
я не могу похвастаться большим производственным опытом. Но там, где я мог видеть сборку девайсов, всегда в приоритете было "сначала собрать плату, а уже потом прошить". Если купленные микросхемы флэш надо сначала где-то прошить, а потом передать на сборку плат - это выглядит лишним этапом, который усложняет производство.
1) Вы много устройств современных знаете, на которых флэшка шьется перед распайкой на плату? :)
2) Тестировать устройство на родном или неродном источнике - вопрос, ответ на который зависит от того, какая конкретно цель конкретных тестов.
Комплексная проблема, конечно.
С основным посылом согласен полностью. "Настоящий писатель будет писать и бесплатно" - это хамство, конечно. Очень радует, что все знают, что должен делать настоящий писатель. Быть смиренным и не думать о своем вознаграждении. Чота не вижу тут мнений типа "настоящий программист должен писать код бесплатно, а за деньги это делают примазавшиеся к Настоящему Программированию".
В то же время, с реальной жизнью сложно спорить. Если общество не платит массово за книги - значит, обществу это не надо. Имею частное мнение, что даже если победить пиратство - то особых продаж книг не возникнет. Раньше книга была единственным легко доступным развлечением, не было опции "скачать и посмотреть любой фильм" или "три часа листать ленту тиктока". А сейчас все это есть, и это для большинства - проще, чем читать. А значит, серьезных денег на этом нишевом рынке так и так не будет. Остальное - всего лишь следствие.
так что увы. такой у нас исторический период. Программирование, думаю, тоже поувянет через пару лет.
Автор, а вы хотели беспристрастно рассказать об опыте использования колонкой, или отомстить производителю за несоответствие вашим ожиданиям? Общая тональность статьи заставляет предположить второе.
Вы недооцениваете роль инженера по применению. Покупатель всегда задаст какие-то вопросы, ответы на которые продажник просто не может знать. И более того, продажник просто не поймет, корректно ли вопрос сформулирован.
Разработчик/интегратор сможет ответить, но держать целого разработчика на поддержку продаж - очень накладно. Кроме того, у разработчика чаще всего не развит скилл "вытащить из заказчика подробности о его применении".
Проблема в другом. Те, кто может быть инженером по применению, могут быть и полноценным разработчиком - за гораздо больший прайс к тому же. И мотивацией сидеть в роли инженера по применению остается только "общение с людьми". Что, впрочем, так себе мотивация. Вот и получается, что поди еще найди такого специалиста.
Я в свое время пришел к тому, что инженер по применению должен поработать года два и перейти в разработчики. тогда все более-менее довольны.
Спасибо, отклики мотивируют :)
Главная проблема регулярок для меня - изучать их в отрыве от конкретной задачи ленишься, а при решении конкретной задачи они эмбеддеру нужны раз в год. Поэтому каждый раз открываешь их для себя с нуля :)
За мануал спасибо, было наглядно. Увижусь с ним, по моим расчетам, месяца через четыре :)
мне кажется, один только красивый качественный корпус вполне может весомо удорожать девайс. да и блок питания - не пустяк. но это ладно.
а вот зачем знать, какой там 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) вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Лайк как минимум за попытку систематизировать вот это вот все. Мои попытки написать про блютус всегда упираются в то, что попытка рассказать про "вот эту маленькую штуку" превращается в необходимость рассказать про весь стек целиком :)
Спасибо)
Про аварийное удаление драйвера - действительно, интересно поизучать. Поставил в бэклог :)
о да, драйвера звуковых устройств - отдельный жанр, достойный лонгрида :)
Кажется, между "пост не дал ничего полезного" и "я зря потратил свое время" - есть некоторая разница. Возможно, не стоит личное мнение о материале уравнивать с объективной полезностью материала.
Горячий опыт новенького тимлида - это как минимум ценно тем, что записано по свежим впечатлениям. Опытные матерые тимлиды про такое не пишут. Они напишут кейсы и решения, но вот общее ощущение "я, дурак, думал, что буду успевать писать код" - вряд ли.