Comments 114
Какие-нибудь GPIO или интерфейсы типа I2C будут?
посмотрите этот топик
ODROID-X2 — без hdmi?
Хорошая штука, но у raspberry pi цена вкуснее.
но по той цене очередь, доставка, время заказа… да и слабее она заметнее, чем герой этой статьи.
Лично я выбрал малинку из-за добротного комьюнити. Цена у распберри пи не намного меньше, учитывая доставку.
Из минусов — размер:
ФОТО
Всем хороши, но интересно, по каким тайным причинам в таких мощных девайсах отсутствует SATA? Был бы очень кстати — для десктопа то.
Поскольку в таком сценарии использования это будет скорее тонкий клиент, то может USB Flash drive удобней использовать?
Девайс универсальный, сценариев использования можно придумать много, значит и выбор портов мог бы быть побогаче. Хотя бы в топовой версии вместо 6-го USB воткнули бы SATA, был бы идеал.
Поскольку в таком сценарии использования это будет скорее тонкий клиент
Похоже проблема такая же как и у меня. Я вот понятия не имею, что значат вот эти циферки:
1.7 GHz quad-core Exynos 4412 Prime ARM Cortex-A9
2 GB of RAM.
Ясно, что это менее производительные процессоры нежели х86, но насколько?
Если просто «менее», то тут уже хватает на домашний nas/торрент с головой и тогда, да, остается только сата.
В общем, если кому не влом, пожалуйста, разъясните. Конкретный пример: тащить торрент со скоростью 5мб/с и показывать 720p по hdmi одновременно эта штука сможет?
UFO just landed and posted this here
А что такое x86? 386 — это x86? Pentium II — это x86? А core i7 вы относите к x86 или x86_64?
А видео вообще не показательно: для него есть аппаратное ускорение, позволяющее его играть на весьма слабых процессорах. А так да, скорее всего сможет.
А видео вообще не показательно: для него есть аппаратное ускорение, позволяющее его играть на весьма слабых процессорах. А так да, скорее всего сможет.
Пусть будет интел атом «близкий по циферкам».
x86 — общее обозначение архитектуры i386 и выше.
core i7 принято относить к i686 или к i786 но это все условности.
core i7 принято относить к i686 или к i786 но это все условности.
На 8086/8088, 80186 и 80286 современные операционки (под современными можно подразумевать в данном случае системы на базе ядра Linux) не работают.
Из ядра Linux уже вот вот начнут выпиливать i386 поддержку.
ну может тогда чтобы быть честным то поддерживать и первый Intel i8042?
Каждое ядро примерно соответствует Intel Atom в однопотоке. А их тут 4.
Выходит вполне себе медиа-центр. Тогда отсутствие сата огорчает, конечно.
По мне так наличие ethernet или wi-fi вполне себе компенсирует отсутствие этого разъёма, ибо медиа-центр должен быть маленьким, а данные, уж если хранить локально, то лучше хранить на отдельном NAS, с кучей дисков, в месте где он не будет никому мешаться.
Я думаю лучше совмещать медиацентры с насом. Еще гонять трафик туда-сюда, да еще и отдельное устройство держать.
Опять же имхо, но когда есть несколько медиа-центров, к примеру на кухне, и в зале, то лучше иметь отдельный NAS.
А самое хорошее решение когда есть возможность выбора, было бы здорово иметь платки расширения для такой конструкции, тот же ethernet не всегда нужен, ибо можно использовать wi-fi, возможность поставить sata, ну и т.д.
А самое хорошее решение когда есть возможность выбора, было бы здорово иметь платки расширения для такой конструкции, тот же ethernet не всегда нужен, ибо можно использовать wi-fi, возможность поставить sata, ну и т.д.
В общем читал лет 5 назад, мерили на PPC/ARM, если поделить на частоту, раза почти в полтора медленнее на целых числах и сильно более драматично отставание было на плавающей арифметике. Но тогдашнюю версию ARM я не помню, мож с той поры FPU и что-то типа MMX/3dNow приделали, я не в курсах. Думаю, скорость на одно «яйцо» должна быть на уровне Атома на той же частоте (у него вообще чуть ли не 486 архитектура без предсказания ветвлений и соотв.выброса 50-80% результатов в помойку).
у него вообще чуть ли не 486 архитектура без предсказания ветвлений и соотв.выброса 50-80% результатов в помойку
facepalm.jpg
Почитайте лучше:
www.ixbt.com/cpu/intel-atom-architecture-1.shtml
www.ixbt.com/cpu/intel-atom-vs-celeron.shtml
Считайте, что он на уровне современных Intel Atom одноядерных, ARM-15 решения — пошустрее будут, по тестам двухъядерные процессоры ARM-A15 имеют примерно в полтора раза большую производительность, чем QuadCore ARM-A9.
Вроде ничего не напутал, ошибаюсь — поправьте. ;)
Вроде ничего не напутал, ошибаюсь — поправьте. ;)
Можно подключить 2.5" SATA диск через внешний USB-бокс )
На таком xbmc лагать не должен. Цена опять же адекватная, осталось дождаться нормального порта xbmc на android :) Непонятно правда какой там ethernet, гигабит или 100.
Да, использую raspberry в том числе в качестве медиацентра. Минус — жуткие тормоза в меню из-за нехватки RAM.
Да, использую raspberry в том числе в качестве медиацентра. Минус — жуткие тормоза в меню из-за нехватки RAM.
У линуха (в т. ч. и у андроида) вроде все плохо с Exynos: ни исходников, ни документации. Разработчики кастомных прошивок плачут кровавыми слезами. Как у них удастся все это завести без плясок с бубном и с полной поддержкой?
Подскажите, а есть для плат типа Raspberry и ODROID какие нибудь стандартные дополнительные многофункциональные интерфейсы ввода-вывода, чтобы можно было подключать всякие датчики, актуаторы и т.п. Хочется чтобы была возможность подключать все это также легко, как на платах Arduino.
elinux.org/RPi_Expansion_Boards дохрена
Судя по спецификациям
Не мало важным отличием модулей ODROID-X\ODROID-X2 от ODROID-U\ODROID-U2 является:
ODROID-X\ODROID-X2 — Parallel LCD / IO interface 50pin IO Port
В версиях U\U2 такого нет, но зато можно приобрести USB to IO expansion board for GPIO/PWM/SPI/UART/I2C/ADC interfaces за 15$
www.youtube.com/watch?feature=player_embedded&v=oAiov-bgz9w
Запуск XBMC 12.0 под андроидом
www.youtube.com/watch?feature=player_embedded&v=O3v0ydCG2yU
По хорошему если приобретать ODROID-U2 за 89$ то необходимо будет так же докупить:
5V/2A Adaptor — 9$
WiFi Module Kit — 9$
eMMC Module (8GB) — 25$ (Pre-installed Android 4.x for ODROID-U2. Ready to run from out of box)
IO Board — 15$
итого 147$
Можно сэкономить на Wifi и блоке питания, но вот будет ли работать конструкция без NAND за 25$?
Не мало важным отличием модулей ODROID-X\ODROID-X2 от ODROID-U\ODROID-U2 является:
ODROID-X\ODROID-X2 — Parallel LCD / IO interface 50pin IO Port
В версиях U\U2 такого нет, но зато можно приобрести USB to IO expansion board for GPIO/PWM/SPI/UART/I2C/ADC interfaces за 15$
www.youtube.com/watch?feature=player_embedded&v=oAiov-bgz9w
Запуск XBMC 12.0 под андроидом
www.youtube.com/watch?feature=player_embedded&v=O3v0ydCG2yU
По хорошему если приобретать ODROID-U2 за 89$ то необходимо будет так же докупить:
5V/2A Adaptor — 9$
WiFi Module Kit — 9$
eMMC Module (8GB) — 25$ (Pre-installed Android 4.x for ODROID-U2. Ready to run from out of box)
IO Board — 15$
итого 147$
Можно сэкономить на Wifi и блоке питания, но вот будет ли работать конструкция без NAND за 25$?
А с ODROID-U за $69, в какую минимальную сумму получится уложиться?
А кто для чего использует подобные девайсы?
Я бы попробовал использовать как медиа-центр.
Можно в машину засунуть в качестве CarPC. Можно очень умный дом замутить. Но главное использование — наверно медиа-центр и десктоп клиент.
Я бы подобное хотел под домашний мини-сервер использовать — торренты/общие ресурсы по WiFi + раздача контента на телевизор, только да, хочется еще сюда SATA.
Для этого эзернет и\или вайфай + сервер в кладовке.
это пока лучшее решение из тех что я видел.
это пока лучшее решение из тех что я видел.
Если сервер — это старый системник, то совсем не хочется, по энергии это решение не экономично.
У меня был готовый NAS сервер с двумя USB портами, который кушал от БП 5В/2А — очень радовало. Но он только мог торренты тянуть и в качестве файл-сервера с горем пополам.
У меня был готовый NAS сервер с двумя USB портами, который кушал от БП 5В/2А — очень радовало. Но он только мог торренты тянуть и в качестве файл-сервера с горем пополам.
Был у меня поднят nas на популярном маршрутизаторе от asus, пришлось отказаться. Инет у мя быстрый, хотелка большая. Короче не пошло дело, стал тормозить и зависать. И собрал я на экономичной платформе x86 вполне солидный сервачок. Потребляет в пике ват 150. При этом все прелести в нем уживаются без проблем. А сейчас вообще обленился с планшета смотрю фильмы скачанные на рабочем компе =) так зачем мне sata?
У меня сервер в кладовке в среднем потребляет 60Вт. у него Core2 E4500 2.2GHz, 8GB RAM, 1.5TB HDD + 160GB Backup HDD.
на нем ISA Server 2006 выполняет роль файрвола и маршрутизатора, VMWare Server 2.0 крутит несколько Linux серверов (LAMP в основном). На нем же FTP и несколько моих приложений (например CGI галерея)
на нем ISA Server 2006 выполняет роль файрвола и маршрутизатора, VMWare Server 2.0 крутит несколько Linux серверов (LAMP в основном). На нем же FTP и несколько моих приложений (например CGI галерея)
mini ITX система?
Нет, как ни странно :)
А чем же вы его запитываете на 60ВТ?
обычным БП. Правда, когда я собирал его в далеком конце 2007го, я не думал, что он будет столь экономичен, и купил FSP BlueStrom 400Wt :). Он воткнут в UPS APC 525VA с функцией замера потребляемой мощности. От UPS работает 30-40 минут примерно, зависит от нагрузки.
Странно что такой десктопный конфиг так мало ест, конечно если замер мощности не врет.
Похоже, что не врет, замерял внешним ваттметром тоже.
На самом деле данные о прожорливости ПК сильно преувеличены. Мой ПК с E8400, 8GB RAM, 1500GB HDD и 128GB SSD, GeForce 9600GT+ AMP!, двумя мониторами: NEC 2490WUXI2, Acer B209W (24" и 20") ест в состоянии покоя 160Вт примерно. При игре в UnrealIII примерно 235-250Вт.
На самом деле данные о прожорливости ПК сильно преувеличены. Мой ПК с E8400, 8GB RAM, 1500GB HDD и 128GB SSD, GeForce 9600GT+ AMP!, двумя мониторами: NEC 2490WUXI2, Acer B209W (24" и 20") ест в состоянии покоя 160Вт примерно. При игре в UnrealIII примерно 235-250Вт.
Не странно. Есть пиковое потребление и есть потребление включенного, но не нагруженного компьютера. Эти цифры отличаются на порядки. Блок питания должен обеспечивать максимальное потреблени и желательно с запасом.
Ну если смотреть с планшета, то в принципе может и интернета хватит.) А если на телевизоре в хорошем качестве да с добротным звуком — не пролезет в интернет-канал. :-)
Я, например, на ODROID-X развернул Ubuntu с парочкой USB-камер и Motion, чтобы записывать перемещения моих питомцев пока я не дома.
Сзади на телевизор приклеить двухсторонним скотчем, беспроводная мышь + клавиатура, и вот он, самый умный Smart TV.
Простая игровая консоль.
У меня на RPi крутится bind9 для своего домена и раздача статики, которой я пользуюсь удаленно
все круто только про радиатор только не кто не пишет
А бывают такие-же мелкие и мощные, но с несколькими ethernetами?
Часто можно компенсировать отсутствие нескольких портов Ethernet при помощи свитча.
Нельзя. Несколько портов нужно для маршрутизации. Маршрутизировать через свитч нельзя. Нужно иметь собственные интерфейсы. Единственный вариант — через USB. Но все это медленно и печально, так же печально как и GPIO через USB — лампочкой то можно поморгать, но например обрабатывать в реальном времени датчики ускорения уже нет — задержки USB слишком велики для этого.
Надо брать умный свич с vlan'ами. Тогда можно иметь ОЧЕНЬ много портов. Вот только выгода от этого начинает теряться.
О том и речь, что вся эта халабуда кажется супермногообещающей и сверхдешевой, пока не начнешь применять его там, где нужна существенная часть его возможностей — сразу обрастает кучей негибких кабелей, блоками питания и платами расширения, становится больше чем nanoITX комп, а по мощности примерно сравним. Только еще винт не подключишь и софт под ARM немного сложнее чем под x86 бывает найти.
его прелесть была бы полной, имей он прямой выход на GPIO с низкой задержкой. При такой мощности это был бы ураганный девайс — роботов на нем строить было бы одно удовольствие. или встроить в управление любым ТС можно было бы. А так — через USB общаться с GPIO это все равно что Arduino присобачить через USB к RPi или обычному компу и назвать комп девелоперской платой.
его прелесть была бы полной, имей он прямой выход на GPIO с низкой задержкой. При такой мощности это был бы ураганный девайс — роботов на нем строить было бы одно удовольствие. или встроить в управление любым ТС можно было бы. А так — через USB общаться с GPIO это все равно что Arduino присобачить через USB к RPi или обычному компу и назвать комп девелоперской платой.
Вы опять неправильно подходите к вопросу.
Даже наличие GPIO не даст вам «низкой задержки», линукс это не система реального времени.
GPIO через USB более чем правильное решение при грамотном проектировании системы. Если решать в лоб, как вы собираетесь, то конечно, вам не хватит никаких интерфейсов — ни USB, ни GPIO — вы не обеспечите нужный отклик.
Задачи такого рода решают буферизацией данных с того же акселерометра для последующей их обработки. Потому что вам в любом случае будет нужен буфер для расчетов и фильтрации. Точно также происходит работа со звуком во всех современных системах, работа на уровне буферов.
Накапливается буфер с данными, отсылается по USB через какую-нибудь Interrupt EP, обеспечивающую постоянный период опроса.
Может быть, чем постоянно говорить что на этих модулях можно только лампочками мигать, таки попробуете собрать систему? Робота или что-нибудь еще, реально работающее? А то вы пока все только говорите что они не подходят, не пробуя с ними работать.
Даже наличие GPIO не даст вам «низкой задержки», линукс это не система реального времени.
GPIO через USB более чем правильное решение при грамотном проектировании системы. Если решать в лоб, как вы собираетесь, то конечно, вам не хватит никаких интерфейсов — ни USB, ни GPIO — вы не обеспечите нужный отклик.
Задачи такого рода решают буферизацией данных с того же акселерометра для последующей их обработки. Потому что вам в любом случае будет нужен буфер для расчетов и фильтрации. Точно также происходит работа со звуком во всех современных системах, работа на уровне буферов.
Накапливается буфер с данными, отсылается по USB через какую-нибудь Interrupt EP, обеспечивающую постоянный период опроса.
Может быть, чем постоянно говорить что на этих модулях можно только лампочками мигать, таки попробуете собрать систему? Робота или что-нибудь еще, реально работающее? А то вы пока все только говорите что они не подходят, не пробуя с ними работать.
Одное дело задержки из-за того, что ОС не реального времени, другое дело задержки USB шины. Они по определению больше, чем задержки процесса, выполняемого с высоким приоритетом при прямом доступе к шине SPI, I2C как это в Raspberry Pi. при этом никто не мешает к Raspberry подключить и через USB хоть ту же Arduino. Так что не надо про подход. На Raspberry уже есть работоспособный квадрокоптер. Сомневаюсь, что при управлении через USB на этой плате удастся такое провернуть.
Вы бы поменьше сомневались и побольше сами проектировали. Тогда бы и не придумывали «определения» которых не существует.
Доступ к SPI, I2C и GPIO идет через драйверы этих шин, как и доступ к USB. Понятия «прямого доступа» тут нет, на борту процессора есть несколько аппаратных контроллеров интерфейсов, в линуксе есть драйверы, дергающие регистры этих контроллеров. Драйвер дергает регистры (независимо от интерфейса, и SPI и USB и I2C, все что есть), дальше контроллер формирует искомые сигналы на пинах. Сам. Аппаратно.
Процесс с любым приоритетом выполняет системный вызов, переходя в кернел-спейс, что уже само по себе порождает задержку. Дальше идут задержки в драйверах (да-да, для SPI тоже, не только для USB).
Вы ни на одной шине построите обработку такого типа, как в ОСРВ — у вас не прогнозируемые задержки при обращении к любой, абсолютно любой периферии.
При этом Full-Speed USB передаст накопленный буфер, пока SPI будет еще только начинать шевелить своим клоком.
Еще раз: нужна обработка потоковых данных — буферезируем, отправляем буферы, за время пока копится следующий, обрабатываем пришедший — это для обработки всех данных, которые планируется фильтровать, считать всякие БПФ, корреляции и тому подобное. Все что тут нужно — чтобы обработка выполнилась быстрее, чем наберется следующий буфер. И временные затраты на обработку будут намного меньше, чем задержки в драйвере, особенно при использовании высокоскоростных шин (скорости FS USB превышают скорости SPI на порядки, не говоря уж об I2C)
Нужна очень быстраяи и прогнозируемая реакция на внешнее воздействие — ставится внешний контроллер, работающий под управлением ОСРВ (либо без ОС), который хендлит это и шлет отчет хостовой системе.
Системы такого рода — вычислители, их задача — обработка больших объемов информации — энкодинг видео, аудио, стриминг этих видео/аудио, обработка сигналов, вычисления верхнего уровня наподобие определения своего местоположения и построения карты, в случае робота.
Raspberry к ним же относится, это системы одного класса.
И вот этот модуль тоже к ним относится. И коптер можно строить на любой из них.
Чем рассуждать о вещах, с которыми вы не просто не работали, а даже не хотите работать, лучше начните проектировать, возьмите тот же Raspberry, подергайте из юзерспейса GPIO, посмотрите на отклик. Потому что пока на любую технологию вы отвечаете одинаково.
Битбанг FTDIшкой (которая для этого разработана) — вы говорите «это извращение, только лампочками мигать».
Программирование прикладных программ для эмбеддед платформы на питоне — опять я слышу от вас «это только лампочками мигать»
Построение устройства на платформе с линуксом — и опять вы со своими лампочками.
Доступ к SPI, I2C и GPIO идет через драйверы этих шин, как и доступ к USB. Понятия «прямого доступа» тут нет, на борту процессора есть несколько аппаратных контроллеров интерфейсов, в линуксе есть драйверы, дергающие регистры этих контроллеров. Драйвер дергает регистры (независимо от интерфейса, и SPI и USB и I2C, все что есть), дальше контроллер формирует искомые сигналы на пинах. Сам. Аппаратно.
Процесс с любым приоритетом выполняет системный вызов, переходя в кернел-спейс, что уже само по себе порождает задержку. Дальше идут задержки в драйверах (да-да, для SPI тоже, не только для USB).
Вы ни на одной шине построите обработку такого типа, как в ОСРВ — у вас не прогнозируемые задержки при обращении к любой, абсолютно любой периферии.
При этом Full-Speed USB передаст накопленный буфер, пока SPI будет еще только начинать шевелить своим клоком.
Еще раз: нужна обработка потоковых данных — буферезируем, отправляем буферы, за время пока копится следующий, обрабатываем пришедший — это для обработки всех данных, которые планируется фильтровать, считать всякие БПФ, корреляции и тому подобное. Все что тут нужно — чтобы обработка выполнилась быстрее, чем наберется следующий буфер. И временные затраты на обработку будут намного меньше, чем задержки в драйвере, особенно при использовании высокоскоростных шин (скорости FS USB превышают скорости SPI на порядки, не говоря уж об I2C)
Нужна очень быстраяи и прогнозируемая реакция на внешнее воздействие — ставится внешний контроллер, работающий под управлением ОСРВ (либо без ОС), который хендлит это и шлет отчет хостовой системе.
Системы такого рода — вычислители, их задача — обработка больших объемов информации — энкодинг видео, аудио, стриминг этих видео/аудио, обработка сигналов, вычисления верхнего уровня наподобие определения своего местоположения и построения карты, в случае робота.
Raspberry к ним же относится, это системы одного класса.
И вот этот модуль тоже к ним относится. И коптер можно строить на любой из них.
Чем рассуждать о вещах, с которыми вы не просто не работали, а даже не хотите работать, лучше начните проектировать, возьмите тот же Raspberry, подергайте из юзерспейса GPIO, посмотрите на отклик. Потому что пока на любую технологию вы отвечаете одинаково.
Битбанг FTDIшкой (которая для этого разработана) — вы говорите «это извращение, только лампочками мигать».
Программирование прикладных программ для эмбеддед платформы на питоне — опять я слышу от вас «это только лампочками мигать»
Построение устройства на платформе с линуксом — и опять вы со своими лампочками.
Уже. И прежде чем поучать, посчитайте задержки в несколько тактов при переходе в режим ядра и сравните с задержками в несколько миллисекунд шины USB, которая по определению быстрее не может. с MIDI никогда не работали? на слух заметно серьезное отставание, когда я играю на MIDI клавиатуре, а по USB midi команды обрабатываются в реальном времени на ПК — очень неприятная задержка получается и от нее никак не избавиться потоковой реализацией.
С коптером то же самое — пока поток туда сюда сбегает, коптер завалится уже или уйдет в некорректируемый расколбас. Слишком низкая скорость реакции.
При частоте проца 700 мГц даже Ос типа линукса при грамотном написании софта способна давать задержки прямого управления периферией куда меньше весьма латентной шины USB.
С коптером то же самое — пока поток туда сюда сбегает, коптер завалится уже или уйдет в некорректируемый расколбас. Слишком низкая скорость реакции.
При частоте проца 700 мГц даже Ос типа линукса при грамотном написании софта способна давать задержки прямого управления периферией куда меньше весьма латентной шины USB.
Да потому что не проектируют так системы, вы как всегда берете молоток, лупите им по полену и удивляетесь что оно что-то не пилится, отвергая пилу со словами, что ей нельзя забивать гвозди.
Не ставят хорошие инженеры ОС, не являющейся ОСРВ на обработку задач реального времени. Ставят контроллер, предназначенный для этого, связывая его с управляющей системой по доступной шине — по той же USB, допустим.
Пытаться мегагерцами нагнать процесс — редкостный идиотизм, потому что нельзя спрогнозировать задержку и приходится надеяться что оно «авось успеет».
Ваше «серьезное отставание» — особенности реализации, минимальная задержка USB составляет 1 мс по стандарту, это минимальный интервал для интеррапт-передачи.
Я не верю, что вы на слух способны определить задержку даже в 10-15 мс.
«Переход в режим ядра» это не несколько тактов, до момента, как ваши данные появятся на шине любого из интерфейсов, выполнится большое количество кода, включающее проверки переданных в системный вызов данных и код драйвера, который этой шиной управляет.
При любой обработке данных задержка будет обусловлена еще и алгоритмом, вы не вычислите БПФ по одному отсчету, не вычислите фильтр, не посчитаете корреляции.
Поэтому при работе с потоком данных все равно придется прибегать к буферизации.
И передать буфер по USB можно намного быстрее, чем по I2C.
Поэтому не надо опять заводить свою шарманку с лампочками — то что вы пытаетесь применить один и тот же подход в лоб, при проектировании любых систем — ваша беда, а не недостатки инструментов.
Не ставят хорошие инженеры ОС, не являющейся ОСРВ на обработку задач реального времени. Ставят контроллер, предназначенный для этого, связывая его с управляющей системой по доступной шине — по той же USB, допустим.
Пытаться мегагерцами нагнать процесс — редкостный идиотизм, потому что нельзя спрогнозировать задержку и приходится надеяться что оно «авось успеет».
Ваше «серьезное отставание» — особенности реализации, минимальная задержка USB составляет 1 мс по стандарту, это минимальный интервал для интеррапт-передачи.
Я не верю, что вы на слух способны определить задержку даже в 10-15 мс.
«Переход в режим ядра» это не несколько тактов, до момента, как ваши данные появятся на шине любого из интерфейсов, выполнится большое количество кода, включающее проверки переданных в системный вызов данных и код драйвера, который этой шиной управляет.
При любой обработке данных задержка будет обусловлена еще и алгоритмом, вы не вычислите БПФ по одному отсчету, не вычислите фильтр, не посчитаете корреляции.
Поэтому при работе с потоком данных все равно придется прибегать к буферизации.
И передать буфер по USB можно намного быстрее, чем по I2C.
Поэтому не надо опять заводить свою шарманку с лампочками — то что вы пытаетесь применить один и тот же подход в лоб, при проектировании любых систем — ваша беда, а не недостатки инструментов.
Мало ли чего не делают хорошие инженеры.
Если хочется делать все как надо — нужно работать инженером. Я, к счастью, могу себе позволить делать то и так что и как мне нравится. И это получается. Без лишних затрат, просто. А устраивать зоопарк я никогда не любил. Принцип KISS никто не отменял.
Чем меньше элементов, тем проще и надежнее работает.
Вот с какого хрена оно не успеет? что в Raspberry делать оси? это не винда, она ничем не занята, жестких дисков нет, никаких фоновых задач нет, если не запустить. Все можно настроить так, как надо.
Вы можете верить, а можете нет — это ваше дело. А задержка вовсе на 15 мс образуется. Я сказал «весьма неприятная», а это означает, что когда я нажимаю следующую клавишу предыдущая только начала играть. когда я снял аккорд — он начал звучать. Если мы играем арпеджио — это не имеет значения, а если я играю футбольный марш или рэгтайм Артист Эстрады, это весьма и весьма досаждает. К тому же можно снять наушники и послушать что играет само электропиано через свои колонки, запаздывание на слух очевидно даже не музыканту.
А по вашему данные с датчиков данные магически появятся на USB? Они все равно должны пройти по I2C через гораздо более медленный МК, быть там обработан и запихнуты в пакет, потом пройти ни разу не быстрый UART, который тоже имеет буфер с двух сторон, затем добраться до ОС, дождаться прерывания и только тогда будут обработаны.
Даже без UART с USB реализацией на МК это будет не быстрее.
Еще раз — никому не интересно как быстро можно передать буфер. Важна латентность и скорость реакции на единичные данные. Пропустить пару пакетов из-за того, что это не ОСРВ допустимо, а вот тупить постоянно — нет.
У нас разный подход, я это знаю. Сделаете коптер на этой плате с ее убогим GPIO на PIC — вы правы, а пока не вижу смысла в дальнейшем споре. Вместо того, чтобы поучать в общем, сделайте пример. Код и схему. Так, чтобы это понятно было даже мне.
Если хочется делать все как надо — нужно работать инженером. Я, к счастью, могу себе позволить делать то и так что и как мне нравится. И это получается. Без лишних затрат, просто. А устраивать зоопарк я никогда не любил. Принцип KISS никто не отменял.
Чем меньше элементов, тем проще и надежнее работает.
Вот с какого хрена оно не успеет? что в Raspberry делать оси? это не винда, она ничем не занята, жестких дисков нет, никаких фоновых задач нет, если не запустить. Все можно настроить так, как надо.
Вы можете верить, а можете нет — это ваше дело. А задержка вовсе на 15 мс образуется. Я сказал «весьма неприятная», а это означает, что когда я нажимаю следующую клавишу предыдущая только начала играть. когда я снял аккорд — он начал звучать. Если мы играем арпеджио — это не имеет значения, а если я играю футбольный марш или рэгтайм Артист Эстрады, это весьма и весьма досаждает. К тому же можно снять наушники и послушать что играет само электропиано через свои колонки, запаздывание на слух очевидно даже не музыканту.
А по вашему данные с датчиков данные магически появятся на USB? Они все равно должны пройти по I2C через гораздо более медленный МК, быть там обработан и запихнуты в пакет, потом пройти ни разу не быстрый UART, который тоже имеет буфер с двух сторон, затем добраться до ОС, дождаться прерывания и только тогда будут обработаны.
Даже без UART с USB реализацией на МК это будет не быстрее.
Еще раз — никому не интересно как быстро можно передать буфер. Важна латентность и скорость реакции на единичные данные. Пропустить пару пакетов из-за того, что это не ОСРВ допустимо, а вот тупить постоянно — нет.
У нас разный подход, я это знаю. Сделаете коптер на этой плате с ее убогим GPIO на PIC — вы правы, а пока не вижу смысла в дальнейшем споре. Вместо того, чтобы поучать в общем, сделайте пример. Код и схему. Так, чтобы это понятно было даже мне.
Что делать Raspberry на коптере тогда, если «она ничем не занята и фоновых задач нету»? Накой черт ее туда пихать, если вы ее не нагружаете?
В реальной системе она будет энкодить видео и обрабатывать алгоритм более высокого уровня, реализующий автономный полет. Если вы ее используете исключительно в виде контроллера двигателей — это, опять же, исключительно ваша беда.
Позволить-то вы можете делать как вам нравиться, но тогда и не выдавайте это за какую-то истину, утверждая что именно так и надо. Так и говорите вместо «надо» или «правильно» — «мне так хочется».
При правильной реализации данные, требующие обработку реального времени так и будут обрабатываться на контроллере двигателей, в пределах следящей системы. А управляющие воздействия на эту систему будет формировать Raspberry или любой другой вычислитель, выполняющий высокоуровневые вычисления.
То что вам не интересно — это я вижу, точно также как вам не интересно слушать доводы о преимуществах и недостатках языков программирования, применительно к задачам, а зря. Помогло бы приблизиться к качественным реализациям, отойдя от «поделок на коленке».
Нету понятия «единичные данные», если вы собрались считать БПФ на 1024 точки, то единицей для вас будет буфер из 1024 точек входного сигнала и латентность напрямую зависит от того, как быстро вы его передадите.
С чего вдруг я должен вам делать пример, код и схему? Я такой же пользователь хабра, пишу статьи по мере желания, а не по вашему требованию.
Вы считаете возможным выдавать свое «делать то и так что и как мне нравится» за какую-то истину, я считаю возможным указать вам на то, что это не инженерный подход а ваши личные хотелки, с чем вы кстати и согласились.
И тоже не вижу смысла в дальнейшем споре, если вы сами сказали что делаете как вам нравится и не претендуете на грамотность решения с инженерной точки зрения.
В реальной системе она будет энкодить видео и обрабатывать алгоритм более высокого уровня, реализующий автономный полет. Если вы ее используете исключительно в виде контроллера двигателей — это, опять же, исключительно ваша беда.
Позволить-то вы можете делать как вам нравиться, но тогда и не выдавайте это за какую-то истину, утверждая что именно так и надо. Так и говорите вместо «надо» или «правильно» — «мне так хочется».
При правильной реализации данные, требующие обработку реального времени так и будут обрабатываться на контроллере двигателей, в пределах следящей системы. А управляющие воздействия на эту систему будет формировать Raspberry или любой другой вычислитель, выполняющий высокоуровневые вычисления.
То что вам не интересно — это я вижу, точно также как вам не интересно слушать доводы о преимуществах и недостатках языков программирования, применительно к задачам, а зря. Помогло бы приблизиться к качественным реализациям, отойдя от «поделок на коленке».
Нету понятия «единичные данные», если вы собрались считать БПФ на 1024 точки, то единицей для вас будет буфер из 1024 точек входного сигнала и латентность напрямую зависит от того, как быстро вы его передадите.
С чего вдруг я должен вам делать пример, код и схему? Я такой же пользователь хабра, пишу статьи по мере желания, а не по вашему требованию.
Вы считаете возможным выдавать свое «делать то и так что и как мне нравится» за какую-то истину, я считаю возможным указать вам на то, что это не инженерный подход а ваши личные хотелки, с чем вы кстати и согласились.
И тоже не вижу смысла в дальнейшем споре, если вы сами сказали что делаете как вам нравится и не претендуете на грамотность решения с инженерной точки зрения.
не передергивайте. Я говорю про посторонние задачи. Это не ПК, на котором Winamp играет, киношку показывает MPC, компилится проект и между делом опрашиваются датчики и управляются моторы.
Делать он будет все то же что и полетный контроллер, но лучше — математику можно применить более приличную, а не убогий целочисленный огрызок, который работает на контроллере, а значит полет может быть более стабильным. Памяти достаточно, чтобы работать с нормальной математикой, не изгаляясь, а вся математика весьма и весьма быстрая по сравнению с реакцией моторов — механика инертна. Именно поэтому нужно реагировать быстро, никакие потоки не годятся.
Я свой подход за истину не выдаю. Я объяснил, почему считаю, что Raspberry дает то, чего не дает эта плата. Я имею свободу делать как сочту нужным, а не как мне продиктуют убогие возможности платы по работе с периферией.
В этом и ценность. Есть гибкость есть выбор. Мне он нужен. Вам нет? прекрасно, не пользуйтесь.
Кроме локальных задач, есть еще глобальные, кроме буфера на 1024 точки есть много чего, что я хочу иметь возможность делать на том же проце, где считается полетная математика и откуда управляются моторы, чтобы принимать решения на месте, а не организовывать канитель между МК и ARM процом.
Насчет примеров — я не требую ничего. Вы хотите меня переубедить зачем-то, считаете, что ваш подход единственно правильный. Вы ошибаетесь, но доказать кроме как на практике вы не можете, потому что заключения умозрительные, вы не пробовали это сделать. Ведь так?
Не надо лезть с советом туда где не просят. Если б я вас спросил, что выбрать тогда и советовали бы. А раз влезли с советом, нужно аргументировать не авторитетом и «так правильно, так делают», а говорить конкретно — вот алгоритм, вот реализация, это проверно и работает, а если их нет, то обсуждать нечего. Все варианты одинаково хороши.
Делать он будет все то же что и полетный контроллер, но лучше — математику можно применить более приличную, а не убогий целочисленный огрызок, который работает на контроллере, а значит полет может быть более стабильным. Памяти достаточно, чтобы работать с нормальной математикой, не изгаляясь, а вся математика весьма и весьма быстрая по сравнению с реакцией моторов — механика инертна. Именно поэтому нужно реагировать быстро, никакие потоки не годятся.
Я свой подход за истину не выдаю. Я объяснил, почему считаю, что Raspberry дает то, чего не дает эта плата. Я имею свободу делать как сочту нужным, а не как мне продиктуют убогие возможности платы по работе с периферией.
В этом и ценность. Есть гибкость есть выбор. Мне он нужен. Вам нет? прекрасно, не пользуйтесь.
Кроме локальных задач, есть еще глобальные, кроме буфера на 1024 точки есть много чего, что я хочу иметь возможность делать на том же проце, где считается полетная математика и откуда управляются моторы, чтобы принимать решения на месте, а не организовывать канитель между МК и ARM процом.
Насчет примеров — я не требую ничего. Вы хотите меня переубедить зачем-то, считаете, что ваш подход единственно правильный. Вы ошибаетесь, но доказать кроме как на практике вы не можете, потому что заключения умозрительные, вы не пробовали это сделать. Ведь так?
Не надо лезть с советом туда где не просят. Если б я вас спросил, что выбрать тогда и советовали бы. А раз влезли с советом, нужно аргументировать не авторитетом и «так правильно, так делают», а говорить конкретно — вот алгоритм, вот реализация, это проверно и работает, а если их нет, то обсуждать нечего. Все варианты одинаково хороши.
Судя по структурной схеме у Exynos4412 сеть Ethernet через USB преобразователь LAN9730 проброшена.
У карамболы два эзернета, на ней можно сделать роутер.
UFO just landed and posted this here
Вот именно, как девелоперская платформа — это ерунда. Еще один медиацентр.
Не забывайте, это для разработчиков приложений для Андроид в первую очередь
А чем он для разработчиков Android отличается от любого телефона или планшета?
Ооо, сколько оказывается у нас тут разработчиков под Android несогласных. :)
Так чем отличается то? Я отвечу — ничем. USB есть у большинства даже планшетов, Ethernet тоже. А мощность процов вообще отношения не имеет. Так что за неимением озвученных преимуществ на эмоции обращать внимания не вижу смысла.
Так чем отличается то? Я отвечу — ничем. USB есть у большинства даже планшетов, Ethernet тоже. А мощность процов вообще отношения не имеет. Так что за неимением озвученных преимуществ на эмоции обращать внимания не вижу смысла.
О. Десктоп на Андроид. Теоретически этому ничего не мешает. Но практически: Я купил вот такой вот плеер.
Первая проблема — с аппаратной клавиатуры не получается включить русский язык. Вроде, как есть ПО для этого, но у меня так и не получилось его запустить.
Воторая проблема это ужасные RDP клиенты. В Андроид нет правой кнопки мыши. Для эмуляции используется долгое нажатие левой. Но тогда не получается перетаскивать окна.
Первая проблема — с аппаратной клавиатуры не получается включить русский язык. Вроде, как есть ПО для этого, но у меня так и не получилось его запустить.
Воторая проблема это ужасные RDP клиенты. В Андроид нет правой кнопки мыши. Для эмуляции используется долгое нажатие левой. Но тогда не получается перетаскивать окна.
TeamViewer тоже ПКМ у подсоединённой мыши игнорирует? У меня утащили USB-мама кабель от планшета, прямо сейчас не могу проверить. :(
О клавиатуре, используйте Russian Keyboard, раскладка переключается по ALT+Пробел, сама клавиатура при подключенной хардварной не показывается на экране, в области уведомлений отображается текущая раскладка.
Коллеги, а кто что думает по поводу этой новости про данные о количестве вакансий для Андроид-разработчиков? Происходит ли то же самое в России?
Если подключить шесть 2,5 винчестеров WD (допустим, такие goo.gl/ohwRs) через переходники SATA to USB (goo.gl/HoxBR), нормально будет в плане питания платы и винчестеров?
В железе сильно не разбираюсь пока.
В железе сильно не разбираюсь пока.
В причем тут плата?
в общем виде, вам надо учесть пиковые (пусковые) токи всех винчестеров.
питаться они будут от блока питания напрямую, так что к плате это не относится.
в общем виде, вам надо учесть пиковые (пусковые) токи всех винчестеров.
питаться они будут от блока питания напрямую, так что к плате это не относится.
От такого блока питания goo.gl/7J2Mj?
Как я понимаю, получается, что смогу подключить только 2 винчестера, так как у блока питания 2А, а каждый винчестер потребляет (пиковый ток) 0.985А (2 стр., 2 столбец таблицы — goo.gl/0WrsY).
Буду рад поправкам, если я не прав.
Как я понимаю, получается, что смогу подключить только 2 винчестера, так как у блока питания 2А, а каждый винчестер потребляет (пиковый ток) 0.985А (2 стр., 2 столбец таблицы — goo.gl/0WrsY).
Буду рад поправкам, если я не прав.
OUYA же почти в эту цену будет
А кто нибудь подскажет в чем прелесть использования подобного девайса как дешевого десктопа? Я так полагаю, взаимодействие с ним планируется через обычную мышь и клавиатуру. Вроде как не очень удобно, учитывая пальцеориентированность Андроид. Или я не прав?
Sign up to leave a comment.
Новые альтернативы Raspberry Pi на базе Exynos: Десктоп на Android за $69 + microSD