Comments 34
Какая интересная кроха с проводным сетевым интерфейсом, у меня умный дом на распберях построен(по одной на каждое помещение), она конечно хорошо поддерживается софтом.
LuckFox он называется. (lack - недостаток, luck - удача) :-)
Очень-очень мало проектов на этих платах.
Интересно бы погонять именно npu на производительность и энергоэффективность.
Непонятна ниша. Вряд-ли можно получить быстрый рантайм с этим линуксом, питонами, шарпами итп. А если он не нужен, то есть миллион вариантов. Фигачить это в датчики умного дома.... ну такое себе, лично у меня нет уверенности что оно будет стабильно работать годами, а профит совершенно невелик по сравнению с каким-нибудь esphome его как по мне и нету вовсе. Какое-то применение наверняка можно найти, вопрос какое...
Ну, вы недооцениваете лень.
Писать на питоне под полноценным линуксом и на arduino c, не говорят уже о стм32 две очень большие разницы.
Да даже под esp32 попрбуйте вёбсервер поднять, там предел - 20 коннектов чтоли ( в том который из библиотеки какой-то стандартной )
Ещё же есть всякие видеокамеры. А если докинут Npu - можно будет крутить всякие opencv.
Хочу попробовать подключить к принтеру.
Второе, что я установил, — это среду .NET для запуска приложений на C#.
В этом месте у меня пердюмонокль произошёл....Зачем С#? Почему??? Для чего??? Вы же ж как бы в Linux, как Microsoft очутился тут? Причем далее по тексту никаких "экзотических" задач и не было...Чем вам классический gcc-то не угодил?? Ну и С++...зачем С# туда городить?
Я попросил чат GPT написать простенький тест скорости операций для float и double
Уверяю Вас, GPT с лёгкостью напишет код для GCC, не нужно было чуждую в Linux C# засовывать, это противоестественно.
С с++ очень сложно для ARMv7. Как я понял там надо ставить виртуальную машину с линукс с компилятором, настраивать подключение к ней из среды. Потом отладку непонятно как вести, как-то через adb подключаться...
Я хотел попробовать, но там прям очень много всего нужно для этого сделать, не стоит того для DIY проектов.
Что может быть сложного с С++ в Linux ? Можно прямо на этой плате все скомпилировать, если не хочется настраивать кросс-компиляцию на основной машине.
Стоит, конечно.
"Мало оперативной памяти" на этой машинке вам именно из-за того, что вы пытаетесь работать с ней несвойственными операционному окружению методами. Виртуалки какие-то... Среда... adb, прости Г~ди...
Про .NET хотел смолчать, но всё-таки: попробуйте то же самое моргание сделать на Си прямо по месту, на самой машинке, путем редактирования текстового файла blink.c тестовым редактором и последующей компиляции его путём запуска gcc -O2 -o blink blink.c . Интересует разница в производительности моргания светодиодиком :)
ЗАЧЕМ??!? А главное нафига?! Как раз в Linux-e С++ самое "родное", что только там может быть: sudo apt install gcc - ВСЕ! больше ничего не нужно! ну если хотите чтото серьезное с Makefile-ом...ну поставьте туды make аналогичной командой...никакие виртуальные машины, никакие Adb; зачем так сложно то??? Это вы прямо сову на глобус натянули когда C# закорячили туда... причем сове это не по душе...
Вопрос в скорости разработки и лёгкости поддерживания. Если умеешь в дотнет, то на кой ся учить? Профита будет ровно никакого для мелких поделий.
А потому, что одноплатников со всеми этими вашими проприетарными способами установки linux, как в сабже дохрена, и что там наворочено... Лучше поддерживать один код, когда этих штук у тебя админится дохрена, а потом у тебя несколько дохнет, а тебе "аналогичные" впаривают, которые не аналогичные... Да даже если не дохрена, это на работах ваших и пет проектах копайтесь сколько угодно, а когда делаешь для себя, то хочется меньше копать, меньше отлаживать, просто запустить и всё, а потом, при случае, либо перенести на другое такое же железо, либо масштабировать...
Вы наверное нажали не тому комментатору "ответить"....именно об этом я и пишу, полностью с вашей точкой согласен, нужно использовать стандартные инструменты для типовых и стандартных задач....не нужно городить "экзотическое" для Linux среды С# когда он там как ламбарджини в колхозе или как мотоблок "Нева" на WallStreet. (кому какое сравнение ближе) - короче не к месту никак.
Во-первых, .NET в никсах уже лет как 10 запускается. Во-вторых, давно уже запускают в докерах, а не на голых никсах. А в этом плане - какая разница, на чём код.
Эдак-то можно и на питоне под него писать.
Вай нот, важен только результат. Ну ладно, не только. Важна ещё долговременная поддержка и не только собой. И тут высокоуровневые языки выигрывают, как более читаемые и популярные.
Им бы ещё, помимо читаемости, ещё программы выполнять научиться как следует, а то потом пишутся такие вот статьи: памяти мало, процессор медленный...
Что не так в моей статье? Я рассмотрел плату в том ключе, в котором она интересна для меня.
Я же в первом сообщении в ветке комментариев написал что не так. Если непонятно, расшифрую: вы прикрутили не совсем тот инструмент под задачи которые описаны в статье, это делается проще и для железки и для сопровождения через стандартный путь, даааа... безусловно можно как угодно решить задачу, и даже виртуальную машину скорячить и даже докер засунуть, но есть прямой и правильный путь - стандартное использование стандартного инструментария, а не как вы микроскопом гвозди заколачиваете.
Для меня в подобных девайсах главное - поддержка доступности в течении многих лет и наличие документации и сообщества. Наличие библиотек стало менее значимым, так как AI часто способны написать нужный функционал. Другой важный фактор это энергоэффективность, и тут у нишевых систем не всё так хорошо как хотелось. Цена имеет значение только для домашних исследований. В общем, поставить два условных pico оказывается проще и эффективней чем один такой недолинукс.
На этой плате есть очень интересный проект, аудиофильский стример в формате Beaglebone Black (принимал участие в его создании)
https://forum.puredsd.ru/t/bbfox-project/1532
Фактически это универсальное устройство вывода ОЧЕНЬ выокого уровня - воспроизводит цифровую музыку из сети (интернета или локальной сети) и передаёт её на аудиооборудование — например, на ЦАП. Поддерживаемые протоколы
HQPlayer (NAA)
Roon (RAAT)
Squeezelite (LMS)
AirPlay
MPD (UPnP)
APrender (UPnP)
APSqueeze bridge
APlayer
APScream (ASIO)
Spotify Connect
Qobuz Connect
Из фишек реализации, очень низкое потребление (12V 100mA в режиме воспроизведения)
А есть ли у них SDK для работы с NPU? Конвертация моделей, инференс, оптимизация и т.д.
Вроде здесь https://habr.com/ru/articles/852376/ достаточно подробно описано.
LuckFox pico — одноплатник в форм факторе Arduino