Пригодна ли Raspberry Pi к использованию в условиях повышенных помех?
Хотим использовать Малинку в своих проектах, но специфика производимой нами электроники в том, что она производит жуткие помехи(если конкретно, то у нас выходной каскад на мощных полевых транзисторах работает на нелинейную нагрузку).
Даже со специально предназначенными для промышленной электроники микроконтроллерами Microchip(PIC'ами) бывают проблемы, поэтому потребительская электроника вызывает вопросы.
Есть у кого-то опыт использования Малинки в таких условиях?
Образ для работы с hardware вообще не годится — к образу не подключишь I2C сенсоры или SPI девайс, или другие устройства.
Просто софт без общения с аппаратной частью вообще не имеет для меня смысла — он есть на любом большом ПК или КПК или планшете. Прелесть МК именно в том, чтобы работать с аппаратной частью, а для этого нужна удобная среда разработки. Если каждая компиляция и запуск — это целая история, то желание экспериментировать с этим железом отпадает довольно быстро.
Проблема в том, что лично мне использовать linux крайне неудобно — мне не близок UNIX way никаким образом, из его преимуществ для меня ТОЛЬКО бесплатность. По всем параметрам удобства разработки он уступает Windows средам разработки. По крайней мере так лично для меня.
А работа напрямую через отладчик с железом и возможностью управлять исполнением кода — это большой плюс для того же STM32.
Общее быстродействие процессора в 454 МГц под линуксом не кардинально отличается от STM32F4 с его частотой 168-180МГц и 210-225 MIPS и наличием ОСРВ при необходимости и без накладных расходов на линукс.
Вот вы говорите про готовый инструментарий. А я его не вижу — как мне написать приложение, которое будет автоматически запускаться при старте железки, общаться по SPI или I2C c МК и обмениваться в бинарном режиме по Bluetooth Serial или WiFi с ПК?
Обработка данных + лог на SD карту, возможно чтение данных с GPS и связь по 3G. И не в виде убогих скриптов под shell- это не программирование. Shell cкрипты — это жалкий огрызок того, что можно писать в native софте. Лично мне извращаться с консольными потоками и кучей параметров для кучи программ, пытаясь от них получить простой результат, который пишется на С или Delphi за 5-10 минут неудобно. Мне нужна нормальная среда разработки пусть на С/С++ с библиотеками доступа к железу напрямую или через API вызовы, с доступом к WiFi, UART, GPIO и прочему. Питон — слабое утешение. На нем конечно можно что-то сделать, но совсем не так удобно и после любого универсального языка он немного условен и ограничен.
Разумеется, это мое личное мнение, но мы обсуждали именно мои потребности. Многим может и хватить пары простых жестко заданных скриптов с 2-3 ветвлениями. У меня программы обычно посложнее.
Хорошо, если у вас все так просто настраивается. На деле же обычно все получается гораздо хуже — на Raspberry Pi я даже готовый скрипт долго дотачивал и потерял полдня, чтобы просто поднять WiFi — мой USB WiFi модуль никак не хотел заводиться. А уж говорить о том, насколько часто в линуксе возникают вещи — «не работает и все тут» даже не приходится — достаточно просмотреть обсуждения здесь на хабре, как обходить минные поля. У меня ни один из примеров не заработал просто из коробки — весь код приходится адаптировать, права менять, что-то настраивать и все равно все работает не так как хочется. :) Но это так, лирика. Я и говорю — готов весь этот зверинец терпеть, если от него существенная польза.
очень не рекомедную использовать A13 для любых задач «повышенной ответственности». по одной большой причине — вы не имеете DDR3 design guide для A13 и обвели известную разводку. а эта самая разводка, она имеет баги. буквально вчера ко мне обратился товарищ с вопросами, почему его плата на А13 зависает после 12-30 часов работы и активной нагрузке на память (обработка видео и т.д.), угадайте в чем причина, подсказка: залипает с memory corruption.
День шестой, Суббота:
Наконец-то я могу плотно заняться делом.
Подключил сервы. Задумался о том, как ими управлять. Написал скрипт в lua с shell вызовами. Другого то метод мигания портами, кроме вызова драйверов не предлагается. Косо посмотрел на скрипт... lua,shell,linux... Тяжеловато, но проц, думаю, мощный, справится... Ага, счас... Хорошо, я человек опытный, первым делом осцилограф подцепил.
Завел систему... импульсы есть. Только странные какие-то 50% скважность, хотя я просил от силы 3%... Знакомый симптом... Задержка, превышающая по длительности все sleep и delay программы в несколько раз, как раз так и выглядит...
Переписал скрипт на чистый shell. Стало немного быстрее, но все равно... Замерил время. Ужаснулся.
крутой скрипт lua+shell 20 миллисекунд. Черт побери, двадцать миллисекунд - это 12 600 000 тактов.
Что он делает все это время? Посмотреть бы в глаза монстру за гордым именем квант времени ОС...
А ведь это просто включил выключил...
Что до чистого shell-а.
shell 1,76 миллисекунд... 264 000 тактов. Это на операцию, которая может быть выполнена в шесть!
Базовая функциональность linux-овых драйверов?...
Для сравнения проверил Ардуинку... Функция digitalWrite, которую все хают за тормознутость...
6,40 микросекунд. Микросекунд! В 275 раз быстрее, при том, что процессор в 20 раз медленнее...
Вот роутер с пачку сигарет, на linux, потому-что так проще, взять устаревший мультимедийный чип от android-смартфона (с графическим ускорителем, GPS и прочей ненужной лабудой) воткнуть на него linux побыстренькому, закрыть естественно все что только можно, и продукт на рынке!
Да, только каждый раз при включении, подождите минутку, пока linux загрузится, а еще не забывайте заряжать почаще, linux любит кушать…
Про torrent или ftp (32Гб макс, на скорости 1 Мб/с), или медиастриммер который даже иногда не лагает на фильмах с низким битрейтом, я не буду рассказывать…
Да, sshd там нет, но есть telnetd из busybox, но чтоб он заработал надо перепрошить веб-морду…
-
Какой профит от linux? он еле шевелится, жрет батарею и тупит.
Я бы предпочел чтобы прибор включался за 5 сек и жил сутки от аккума! Мобильный девайс как ни как!
-
linux используют там, где нужно побыстрому прикрутить кучу железа, wifi, usb, файловые системы… т.к. в нем много дров практически под все. Или же использовать стек сетевых протоколов, с гибкой маршрутизацией…
Сам по себе linux ничего не сможет в железке делать, разве что top через COM-port выводить ))
Для работы с железом ему нужны дрова, а программирование дров задача сложнее написания кода под МК, шаг влево, шаг вправо — кернел паник и core dump. Написание таких дров, реализация некоей логики в них, превышает сложность написания той же логики для MK на Си в IAR, причем намного! Получается что мы сделали ту же или больше работы, но в добавок у нас где то сбоку еще и linux висит. Возникает вопрос, зачем он нужен? для того чтоб ssh было у 0.1% пользователей которые знают что это означает?
Даже если вы используете стандартные шины, и в linux под ваш чип, в ядре уже есть модули (что далеко не факт) поддержки вашей конкретной перефирии вашего чипа, вам все равно придется описывать обмен данными через шину своими драйверами, если вы конечно делаете что то отличное от сферического девайса с одним COM-портом для отладки наружу
Have you considered using a commercial cheap router such as the tp-link tl-wr703.
You can find them for around 20$ on ebay (with the AC adaptor and shipping included).
Multiple hardware upgrades have already been described.
Yes, I've considered using a System-on-Chip with a full fledged Linux. The problem is that I consider the quality of the software stack of such systems to be relatively low, and particularly hard to upgrade and improve because of the sheer size of that software (Linux alone has millions of lines of code, and add to that a full userspace) and the poor documentation of these SoCs (many vendors just provide botched drivers for an old version of Linux and call that support).
Экранирование и фильтрация — это не выключатель, а ползунок. Не существует 100% решения(по крайней мере в наших условиях), но одни микросхемы, допустим, работают при 99%, а другие — при 90%.
Damme: Если у вас относительно "дубовые" PIC-и вешаются, что можно сказать о ширпотребовской админской игрушке, построенной на чипе от роутера-мыльницы.
Бюджетные контроллеры с DDR памятью вообще-то не отличаются надежностью. Читал разные отзывы при реальном использовании таких устройств в режиме работы 7*24, есть проблемы. Плюс сюда накладываются проблемы с драйверами и самими никсами, все таки это ОС.
habrahabr.ru/post/182000/#comment_6325302:
очень не рекомедную использовать A13 для любых задач «повышенной ответственности». по одной большой причине — вы не имеете DDR3 design guide для A13 и обвели известную разводку. а эта самая разводка, она имеет баги. буквально вчера ко мне обратился товарищ с вопросами, почему его плата на А13 зависает после 12-30 часов работы и активной нагрузке на память (обработка видео и т.д.), угадайте в чем причина, подсказка: залипает с memory corruption.
