Comments 22
А зачем переделывать "проект"? Меняется только плата. Интерфейсы у них одинаковые высунуты, если и отличаются в выбранном списке, то всегда есть пачка плат в другом списке с одинаковыми(нужными) интерфейсами.
Программное обеспечение не меняется(не представляю как глубоко привязанным надо сделать "проект" чтобы зависел от типа чипа на плате).
Меняется размер и место с выводом разъёмов, но это решается при проектировании корпуса на начальном этапе, если заложить "плата может смениться". Даже не закладывая проектирование "универсального" корпуса, то спроектировать корпус и распечатать на принтере - в современных реалиях это "копейки" по деньгам и времени. Опять же зачастую с этими одноплатниками рядом идёт готовое предложение по корпусам.
Т.е проблема - так себе. Из разряда "я сделал проект для 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 достаточно
А че там переделывать то в водоматах? И зачем там малина? Я бы изначально делал на ESP. Если там дисплей 1080p к нему не подключается, то одной-двух ESP32 будет за глаза. Софт уже весь разработан. Сборка с ноля, внедрение - неделя в темпе аврала (может, пара месяцев от силы, если работает один человек и это его первый проект).
По сути - двухстрочный дисплей, монето-приемник, реле на насос, счетчик потока, пара бинарных уровней на ёмкость, можно даже TDS воды мерить, если используется проточная вода напрямую через фильтр (там может ещё потребуется клапан, открывающийся-закрывающийся серво-приводом).
Инет подключать придется через Wifi, можно найти модуль с симкой. Контроль и управление можно осуществлять через телеграм, RPC-сервер на хостинге, либо даже SMS-сообщениями.
Всё это уместится на одной плате, по-быстрому накидал в KiCAD, скинул китайцам, через неделю получил тысячи экземпляров.
Летние одноплатники: как для любителей DIY-проектов, так и для промышленности