Комментарии 22
При всех плюсах одноплатников, есть один, но безумно (для меня) важный МИНУС.
И он банален: короткий срок производства. Сегодня продаётся как семечки, а через условный год фиг где найти.
А модные стартаперы закладываю "что было под рукой". Заказали сто штук, выпустили изделие.
И через 2 года не могут купить и надо или скупать остатки (даже БУ - был такой случай), или зачастую полная переделка проекта (на что зачастую нет денег и времени. А иногда уже и связь с фрилансером-разработчиком потеряна (и такие случаи были).
А зачем переделывать "проект"? Меняется только плата. Интерфейсы у них одинаковые высунуты, если и отличаются в выбранном списке, то всегда есть пачка плат в другом списке с одинаковыми(нужными) интерфейсами.
Программное обеспечение не меняется(не представляю как глубоко привязанным надо сделать "проект" чтобы зависел от типа чипа на плате).
Меняется размер и место с выводом разъёмов, но это решается при проектировании корпуса на начальном этапе, если заложить "плата может смениться". Даже не закладывая проектирование "универсального" корпуса, то спроектировать корпус и распечатать на принтере - в современных реалиях это "копейки" по деньгам и времени. Опять же зачастую с этими одноплатниками рядом идёт готовое предложение по корпусам.
Т.е проблема - так себе. Из разряда "я сделал проект для 286 проца, а тут надо на i9 его запустить". Даже сейчас программы старые отлично работают под эмуляторами на куче не совместимых устройств.
Понимаю что есть редкие случаи привязывания низкоуровневое к железу, но это прям редкость с одной стороны или глупость в плане недальновидности с другой.
Ну вот например код который жестко привязан к железу малинки просто так на другом железе не запустить, там иногда прямое обращение к регистрам железа идет. Иногда используются библиотеки которые "знают" несколько плат, но не все. Т.е. разъем то более-менее совместим с малинкиным, а вот софт надо допиливать, возможно очень сильно а возможно - невозможно.
Чё так? Под линуксом и не перенести?
Зависимые к железу вещи выносятся в отдельные модули/файлы/функции. Меняешь только их и не греешь голову. Работа с io пинами? Так вообще это настраиваемое.
Не силен за малинки, за одноплатники, но побаловался в своё время атмегами и небыло проблемы(кроме объёма памяти иной раз) в переносе программы с одной меги на другую. На ассемблере если, то чуть дольше, на с++ только заголовочник подкидывай другой да частоты так же в заголовочнике прописывай. Часа не занимало.
Т.ч вам там или менять подход или менять разработчиков стоит. Что-то не нормальное творится.
Это если только лампочкой поморгать. На самом деле у разных поколений atmega обращения даже GPIO несколько меняются, но это видно в asm, а C все в заголовочнике проделано. А вот таймеры отличаются гораздо сильнее, там очень многого можно достичь используя их особенности, не говоря уже про контроллеры разных производителей. И вообще мелкие задержки реализуются не библиотечными функциями. Более сложные интерфейсы тоже у всех совсем по разному реализованы. так что при переходе на другого производителя перепиливать иногда надо более чем все.
Linux стандартизированный доступ дает к очень небольшому количеству железа, причем с ограничениями. Для чего то менее стандартного используют "грязные хаки" привязанные к конкретному железу. Достаточно просто покопаться в текстах библиотек, там на каждую плату свой подход
Linux стандартизированный доступ дает к очень небольшому количеству железа, причем с ограничениями. Для чего то менее стандартного используют "грязные хаки" привязанные к конкретному железу. Достаточно просто покопаться в текстах библиотек, там на каждую плату свой подход
Грязные хаки используют люди, которым лень разбираться со стандартными линуксовыми фреймворками и которым надо вчера (ок, не им самим, а их менеджерам, что не сильно отличается по результату). Отсюда возникают циклы задержки на for и отключение оптимизации компилятора, чтобы тот не мешал самовыражению (а потом сжимаем файловую систему, теряя производительность). Отсюда работа с регистрами GPIO напрямую вместо libgpiod, при этом надо отключить мешающие механизмы Линукса, а потом героически курочить прекрасно работающие нативные библиотеки. А, вот еще - есть любители дружить kgdb и jtag, и удивляющиеся, почему это у них ядро падает на каждом третьем запуске. ftrace-debugfs - это же для слабаков, только брякпойнты в ядре, только хардкор.
Вот на самом деле, когда ищу портировщиков на Линукс, строчка в резюме "STM32" заставляет десять раз подумать, ибо бить по рукам первое время умучаешься. Конечно, ребята не виноваты, они хороши в своей среде, они знают железо великолепно, они докапываются до таких мелочей в отладке, что снимаешь шляпу, мне бы в голову не пришло вывести эти регистры на печать - а они вывели и поймали плавающий баг...но как же тяжело с ними первые несколько месяцев
Так может и не надо уже использовать линукс и малинки для того чего они не предназначены. Копал я, например, проект управляли движками малинкой, сделали многоканальный скоростной ШИМ на малинке. Стандартными библиотеками там, помниться, не получиться просто ничего, для этого использовали DMA и программирование на уровне регистров - то, что, по хорошему, делается отдельными контроллерами, которые дебажат более подобающими методами.
Я вот не знаю зачем они так сделали, хотели, видать, попроще и подешевле. Явно никто и не думал куда то потом переносить. Но малинки то подорожали, люди хотят использовать апельсинки за копейки . Пытаются даже на апельсинку загрузить образ от малинки
Так вы оба правы в деталях. Особенно с джетсонами мучений много бывало (не от Nvidia Dev Kit, а промышленные от разных вендоров, там много может быть особенностей). К тому же, с другой стороны, готовый проект необязательно переводить на более современное железо, в проде главное, чтобы работало. Ну и нишевые какие-то вещи без причины лучше не использовать, а та же малинка до сих пор продается в старых версиях тоже.
Линукс может отличаться для каждой платы деревом устройств и соответственно драйверами. На "допил " нужны средства и время. Или вы "за бесплатно" это собираетесь осуществлять? Новый тип платы это еще и правка документации.
Есть одно "странное" применение RPi Zero (на самом деле любой RPi, но конкретно Zero - очень эффективно по цене) - в качестве универсального передатчика в комплекте с rpitx. И это то, что увы, ни один одноплатник пока еще делать не умеет
Ну так Вы и подтверждаете мои опасения )
Видимо, отсутствие практики сказывается на моём педагогическо-писательском умении доносить мысли.
Вы же сами пишите: придётся переделать с нуля ))
А у стартаперов всё жидко с финснсами: "ни ма у пана златого запасу"
Корпус - новый, плата - новая, софт - новый...
А за какие шиши?
Пара примеров от коллег и знакомых:
Торговый аппарат по продаже воды (водоматы). Сделали на какой-то Малинке. Год отлаживали, сделали некую партию, в течение пары лет продавали....Закончилось, заказали платы, а Малинок таких - тю-тю! И давай по магазинам скупать остатки, а потом еще и Б/У пришлось искать, чтобы закрыть потребность.
Когда же взывыли из-за невозможности приобретать, стали искать замену. А в итоге: полная переделка проекта! А денег нет, да и конкуренты не дремят - ушли заказчики к другим.
Аппарат для настройки спутниковый антенн (в жаргоне монтажников - "Фаиндер").
Сделали, продали, закончилось, а плат уже нет! Дум, развалился проект...
конкретно с малинками непонятно - они вроде взаимозаменяемые должны быть от старших к младшим если совсем не портачить
Odroid вот платы делал до последнего пока компоненты производили, Orange PI на LTS заявляет повышенные сроки..
Но больше мне непонятно зачем такое в водомат, там если не ардуинки (которой 100 лет в обед), так платы на esp32 достаточно
вы не понимаете: Это другое! Мы - модный стартап, и у нас - крутые модные решения!
С бАльшим графическим дисплеем аля HDMI на 24" и софт мы пишем исключительно на модных языках!
Я-б тоже всё это спокойно сделал на 8-битнике (и делал, и работают годами).
Из баек начала 2000-х:
Ходят легенды, что когда-то были люди, умеющие писать софт напрямую, в МК: без фреймворков, ОС, 9 слоёв абстракций...
А че там переделывать то в водоматах? И зачем там малина? Я бы изначально делал на ESP. Если там дисплей 1080p к нему не подключается, то одной-двух ESP32 будет за глаза. Софт уже весь разработан. Сборка с ноля, внедрение - неделя в темпе аврала (может, пара месяцев от силы, если работает один человек и это его первый проект).
По сути - двухстрочный дисплей, монето-приемник, реле на насос, счетчик потока, пара бинарных уровней на ёмкость, можно даже TDS воды мерить, если используется проточная вода напрямую через фильтр (там может ещё потребуется клапан, открывающийся-закрывающийся серво-приводом).
Инет подключать придется через Wifi, можно найти модуль с симкой. Контроль и управление можно осуществлять через телеграм, RPC-сервер на хостинге, либо даже SMS-сообщениями.
Всё это уместится на одной плате, по-быстрому накидал в KiCAD, скинул китайцам, через неделю получил тысячи экземпляров.
коллега, даже учитывая моё перманентное пятничное состояние, вдаваться в халивары оч не хочется ))
я тоже могу, на 8051, PIC, AVR, i8086, Z80 ))))))
но я ж не спорю ))
Не не, я имел в виду именно ESP, так как весь код написан и для реализации проекта не требуется писать ни строчки кода. Максимум - конфиг на YAML.
Это плохо продается. Мы сделали очередной водомат или крутой водомат с ИИ, второе с большей вероятностью купят, даже если там ИИ просто пиды настраивает.
Летние одноплатники: как для любителей DIY-проектов, так и для промышленности