Board.KolibriOS.org

ДедОк, IP-камера это ж целый компьютерчик, как по стоимости, так и по прожорливости, да и по габаритам, впрочем, тоже... А ведь еще надо учесть, что таких глаз требуется 2шт
yogev_ezra, а когда ждать размеры можно?

Gluk wrote:yogev_ezra, а когда ждать размеры можно?

Так на сайте же всё есть - http://www.compactpc.com.tw/ebox-3300MX.htm
115 x 115 x 35 mm

на сайте был, а этой страничке не приметил. Спасибо большое, и прошу прощения за невнимательность

Уважаемый Gluk, не понимаю, чем вас пугает масса в 180 грамм, цена в 185$, потребление в 6 ватт, и размеры 4х спичечных коробков, если это много возьмите камеру за 80$. массой грамм в 150 и энергопотребленем в 3 ватта... не думаю, что это так много.. теперь о моих параметрах... господа, если использовать, например, GPIO, то мы получим дискретный сигнал с уровнями ТТЛ/КМОП, которого очень мало для разгона затворов транзисторов МОСФЕТ, да и схема явно с реверсом, значит - мостовая схема и 2 уровня сигналов, кроме того, явно нужна программная регулировка скорости, а это ШИМ, и значит, Колибри для его формирования непригодна в принципе, ибо она не РТОС, кроме тогоне даст шина достаточного тока для обеспечения достаточной крутизны фронтов, а это значит, что и транзисторы попалим. и ещё кучу всего... нужна, как минимум, микросхема-драйвер в промежутке, а ещё лучше контроллер управления группой двигателей, без этого система нежизнеспособна... а для посылки команд в контроллер вполне можно обойтись и 232, например... MODBUS RTU я выбрал, как наиболее распространённый, и универсальный... можно и вообще свой протокол присобачить, если охота... кстати, у меня на одном предприятии работает система, которая по протоколу MODBUS RTU опрашивает 19 контроллеров 3 раза в секунду, собирает данные, фильтрует, показывает на видеофрагментах, формирует архив, (около 100 Мб в сутки) метит его, сохраняет на винт, отображает, если надо, готовит срезы событий и функциональные последовательности... вобщем, ведет себя как СКАДА... уже 4 года, и без единого сбоя... так что думаю поможем если что с модбасом.... просто в моей версии, есть все готовые компоненты, которые уже разработаны... сеть, мпег, последовательные порты, модбас... только в кучу всё собрать.. с нуля, на разработку и отладку, уйдёт очень много времени, а его хронически нехватает, и никто с этим реально возится не будет, поболтаем, и разойдёмся...

и ещё... что-то сильный запах прожектёрства, мы же тут, извините, ежей рожаем... нужно знать все предполагаемые характериситики, нужно техзадание, нужны спецификации того, что уже есть... иначе, это просто такой себе кружок, на поболтать...

Gluk. вам стоит обратить на это внимание, иначе люди устанут от интеллектуального боя с тенью. и потеряют интерес...

Ну вот, хоть с размерами корпуса определились, это уже большой плюс.
А вот еще, не нужно забывать определиться с цветом. С цветом корпуса!
Тот что по ссылке, какой то женский, что ли... есть каталог цветов корпуса? Из чего выбирать то?
"Хаки" есть?

Gluk wrote:к тому же выбор какой-никакой сделан

ГДЕ ТЫ ЭТО НАПИСАЛ? Перечень, составляющие выбора каковы? Хочешь, чтобы люди забили на...? Забьют. Трепаться будут, а сути будет НОЛЬ! 1000%!

Gluk wrote:то, что USB в Колибри нет, не означает, что на него надо забить. Скорее, совсем наоборот!

где, ткни, пожалуйста, было про "забить"? Для тебя эквивалентны слова "забить" и "оптимальное решение"?

ДедОк wrote:если использовать, например, GPIO, то мы получим дискретный сигнал с уровнями ТТЛ/КМОП, которого очень мало для разгона затворов транзисторов МОСФЕТ

уважаемый ДедОк!!! ЭТО ЛЖЕИНФОРМАЦИЯ!
Давайте не будем говорить о том, что не знаем точно или сомневаемся! Если а это факт,то приводить доводы ссылки, фото, PDF и т.п. Я очень болезненно воспринимаю мягко говоря ИНВЕРСНУЮ информацию, особенно в тоне утверждения.
ФАКТЫ, пример:

ДедОк wrote:кроме того, явно нужна программная регулировка скорости, а это ШИМ, и значит, Колибри для его формирования непригодна в принципе, ибо она не РТОС

ядро менуета в свое далекое кучеравое время известным фином было позиционировано как RTOS, об этом были публикации... Если исходить из того, что основной базовый концепт Колибли-ядра тот же, то имеется преемственность, собственно... может это никто не знает или не интересуется, это другой вопрос. Может "текущее" ядро претерпело серьезные изменения... и я не в курсе? Тады скажи мне где, что, когда.

ДедОк wrote:кроме тогоне даст шина достаточного тока для обеспечения достаточной крутизны фронтов, а это значит, что и транзисторы попалим.

опять фантазии на вольную тему...? Да? Не надо сгущать краски, там где этого не видно или приведи ФАКТЫ.

ДедОк wrote:и ещё... что-то сильный запах прожектёрства, мы же тут, извините, ежей рожаем... нужно знать все предполагаемые характериситики, нужно техзадание, нужны спецификации того, что уже есть...

слово техзадание и иже с ним видимо тоже табу профессора. ШО там за профессор... прожектЁр с автономным прожектором видимо

Gluk wrote:иначе, это просто такой себе кружок, на поболтать...

Gluk. вам стоит обратить на это внимание, иначе люди устанут от интеллектуального боя с тенью. и потеряют интерес...

УЖЕ!

yogev_ezra!
Большая просьба!
Дать максимально развернутые ответ по GPIO, где она, что она, может доки по ней появились?
Странно, по 3300 про GPIO явно не указано, остается понимать, что HW совместимость с низу (v.2300) имеет место, то есть на фото сайта оранжевый разьём это GPIO. Исхожу из этого:

Короче, для построения робота или некоторого ряда роботов нужно использовать оптимальную базовую платформу:

eBox-3300MX-GC85: GPIO Version with 2 x RS-232, and 1 x RS-485 port

1. уже только на RS-485 можно заюзать сеть низкоскоростных контроллеров контроля и управления датчиками и моторами и гидро-пневмо-приводами, построенных на технологии, например AVR. "Скорость реакции" периферии будет естественно, мягко говоря невысокой... но для ползающего, ехающего сойдет. Зато быстра реализация.

2. для шагающих, летающих роботенков, где нужны с одной стороны и гироскопы и акселерометры, а с другой нечто вороде пропорциональное ШИМ управление соленоидами, винтами, шаговиками и т.п. - юзается GPIO

3. возможна оптимальная смесь п.1 и п.2 "по месту", по задаче, "по силам"...

4. если есть (описалово, инфа!?) GPIO + DMA то заюзать видеозахват можно весьма эффективно. Разрешение, fps, размер кадра... будут получены в ходе разработки и адаптации

5. наличие WiFi позволит управлять им. Если нет такого 3300-го чтобы на борту, то юзается Ethernet соединение
5.1 можно заюзать IP Web камерки и вполне может быть не одну(!) эффективно используя единственное Ethernet соединение при помощи пассивного хаба на резисторах

количество и качество работы устройств определяется опытным путем, при наличии знаний и соотв. опыта, конечно.

6. отладка удаленного плана типа сброс "дампа картинки" для анализа на машине разработчика, возможна либо по Etherenet либо RS-232, коих 2 штуки имеем тут.

7. передавайте привет гигантическому профессору! С него пиво!

VaStaNi wrote:yogev_ezra!
Большая просьба!
Дать максимально развернутые ответ по GPIO, где она, что она, может доки по ней появились?
Странно, по 3300 про GPIO явно не указано, остается понимать, что HW совместимость с низу (v.2300) имеет место, то есть на фото сайта оранжевый разьём это GPIO. Исхожу из этого:

Да, 3300MX-GC85 спереди выглядит именно так, и оранжевый разъём - это именно GPIO.

и это все чем можешь помочь? А как там на счет чипсета MX(PDF), все также плохо? Или кто то что то раскопал, появилось в инете...
Дело весьма усугубляется именно этим (отсутствием техдоки) и НЕ только по GPIO программированию, но и USB - аналогично. Вернее с ним ЕЩЁ ХУЖЕ! Это нужно четко понимать. Особенно тем, кто думает, мечтает, о том, что недалеки времена, когда Колибри, USB и eBox заживут дружной жизнью. Разве, что где то они у кого то тихо тихо есть... или куплены, но давать низззззяяяя!
Колибри проект массовый, а значит тупик с данной платформой. Выбирать нужно, тогда другую платформу, на Intel или VIA что то там было...
Иначе: костыли, костыли, костыли, горбатость воплощения и итоговое уродство.
Я не усугубляю и не юродствую, это моё честное и многовекторное, взвешенное мнение на текущий момент, ситуацию. Я так это вижу.

yogev_ezra, ты хоть скажи что с данным типом eBox-3300MX-GC85 у тебя? Возможно, нет, уже есть на руках, выслал тому то и он, допустим может потестить GPIO пробные тесты... если что созреет. Gluk уже НЕ ЕЁ получит? В пути?

Нашёл убогую техдоку на чипсет DX, проливающую, хоть немного, но свет на регистры и возможности GPIO. Возможно в чипах МX преемственность, совместимость имеется... тогда все по плану, что выше - вполне реальность.
Судя по "обилию" постов в ветке эта инфа тоже никому не нужна, думаю так. На всякий случай даю ссылки, может найдется кому нужно, а может кто то нароет больше и тоже последут примеру и выложит здесь ссылку. Про USB почти ноль! Пипец!
Vortex86DXds
Vortex86man

ДедОк wrote:господа, если использовать, например, GPIO, то мы получим дискретный сигнал с уровнями ТТЛ/КМОП, которого очень мало для разгона затворов транзисторов МОСФЕТ, да и схема явно с реверсом, значит - мостовая схема и 2 уровня сигналов, кроме того, явно нужна программная регулировка скорости, а это ШИМ, и значит, Колибри для его формирования непригодна в принципе, ибо она не РТОС, кроме тогоне даст шина достаточного тока для обеспечения достаточной крутизны фронтов, а это значит, что и транзисторы попалим. и ещё кучу всего... нужна, как минимум, микросхема-драйвер в промежутке, а ещё лучше контроллер управления группой двигателей, без этого система нежизнеспособна...:

Если ориентироваться на элементную базу 80-х годов - то может быть Вы в чем-то и правы.
Современные КМОП-сборки идеально подходят для управления высокоиндуктивными нагрузками, в том числе и по мостовой схеме. Практически все защитные элементы в них уже имеются: ТТЛ уровни затворов, ДШ-защита от экстратоков замыкания/размыкания, очень высокая крутизна характреристики и малое время переключения, миллиомное сопротивление открытого канала, отрицательный тепловой коэффициент усиления (для защиты от локального пробоя канала), и т.п. Нет разве что только оптронной развязки, но она роботу и не нужна.

Теперь насчет ШИМ и RTOS.
Практически достижимый максимум скорости Gluk-робота - 20..30 см/с
На такой черепашьей скорости для превращения Колибри в RTOS достаточно добавить в ядро простенький [кольцевой] буфер, данные из которого будут поочерёдно выплёвываться в GPIO при каждом прерывании по времени (100 раз в секунду). Это будет круче чем ШИМ, при неопределенности по координате плюс-минус 2мм.

С быстрой камерой (и на свинцовых аккумуляторах) можно разогнаться до 2-3 м/с (см. мои первые посты). Но и здесь ШИМ совершенно не нужен - в программе-максимум трассу надо будет проходить "юзом", как на авторалли, при максимальной мощности разгона/торможения

VaStaNi wrote:в смысле на Колибри у них ставка или просто что то там собираются?

у них есть желание продемонстрировать возможности Колибри на чем-нибудь очень зрелищном. Правда, пока еще не решили - будет этот робот колёсным или летающим.

VaStaNi wrote:а делать [USB-cam] кто будет? Есть кому? Я знаю лишь одного киевлянина, который реально может или "уже", но за идейные принципы, он врядли портирует свой код сюда, например.

Не знаю. Вебкамерами мне сейчас совсем некогда заниматься.
У меня есть нестандарные, но реально работающие в Колибри камеры:
1) быстрая стереопара (SXGA моно или SVGA в цвете; 2х10бит, 40Мпс). Кабель нестандартный, 4 синхронных LVDS-канала и еще I2C для настройки режимов камер. Оцифровка на ПЛИС Spartan-3 на шину PCIe x1 (весь комплект будет стоить около $700), хотя в принципе обычная PCI тоже потянет (около $250 всё вместе). Если есть желание, схему можно переделать на стандартный кабель CameraLink, но дешевле она от этого явно не станет.
2) сверхбыстрая SXGA монохромная камера (10бит/пикс, 700Мпс). Тут всё нестандартное, широкополосное и очень дорогое.

VaStaNi wrote:Колибри проект массовый, а значит тупик с данной платформой. Выбирать нужно, тогда другую платформу, на Intel или VIA что то там было...
Иначе: костыли, костыли, костыли, горбатость воплощения и итоговое уродство.

Верно, надо искать базовую платформу - если система будет полноценно реализована хотя бы на ней, тогда легче будет и конкурентов раскрутить насчет документации.
Именно поэтому я и остановился на AMD RS780. Хотя там даже и в открытых описаниях черт ногу сломит.

VaStaNi wrote:Главное корпус -убогий кусок пластика и фирма.

VaStaNi wrote:Ну вот, хоть с размерами корпуса определились, это уже большой плюс.
А вот еще, не нужно забывать определиться с цветом. С цветом корпуса!
Тот что по ссылке, какой то женский, что ли... есть каталог цветов корпуса? Из чего выбирать то?
"Хаки" есть?

Просьба не оскорблять мои компьютеры - у них у всех корпус выполнен целиком из металла
И вообще, не понял, причём здесь сами компьютеры? Они что, виноваты, что Gluk их выбрал?
Размеры и энергопотребление были частью ТЗ - eBox-3300MX-GC85 отвечает этому ТЗ.

VaStaNi wrote:

art_zh wrote:Если скорость и разрешение видео некритичны, то я бы остановился на USB-камере,- гораздо дешевле, да и протокол там ненамного сложнее чем USB-HID.

а делать кто будет? Есть кому? Я знаю лишь одного киевлянина, который реально может или "уже", но за идейные принципы, он врядли портирует свой код сюда, например. Зато АС, однозначно. Последние лет 5 USBями парился, итог - реальный результат... но ровно столько же я не писал ему... А вообще USB по сложности превышает Ethernet раза в 3. Тут кандидатов поднять его думаю нет. Сам пытался несколько раз браться, но текущие проблемы и акценты жизни "сминают планы всмятку", сами прерывы вышибают "из седла" так, что долго вруливаешь на чем остановился таки в прошлый раз..., в добавок считаю, что ядро Колибри надо менять под это дело..., а это "тухлое дело", которая ни к чему не приводит, как посмотрю. Для этого единомышленники нужны.

Ты представляешь чёрта страшнее, чем он есть на самом деле. Asper + hidnplayr за несколько месяцев написали драйвера для сети + звука под eBox-3300MX, с нуля! Без техдока! Работают без багов! Значит, и для USB можно (тем более, его будут писать 5 человек, а не 2).

ДедОк wrote:Уважаемый Gluk, не понимаю, чем вас пугает масса в 180 грамм, цена в 185$, потребление в 6 ватт, и размеры 4х спичечных коробков, если это много возьмите камеру за 80$. массой грамм в 150 и энергопотребленем в 3 ватта... не думаю, что это так много..

Так не бывает Обычно, если размер и энергопотребление меньше, то цена дороже, а не дешевле! Хочу линки!

VaStaNi wrote:и это все чем можешь помочь? А как там на счет чипсета MX(PDF), все также плохо? Или кто то что то раскопал, появилось в инете...

Открыто в интернет производитель ничего не выложит, так как боятся конкурентов. Тут есть 3 варианта:
1) Я подпишу NDA и получу эти документы. Но это будет бесполезно, так как я программист очень плохой и сам это не осилю, а если Я выложу эти документы в интернете, то нарушу закон и меня конкретно выебут оштрафуют.
2) Кто-то из вас (нормальных программистов) подпишет NDA и получит эти документы. Вам лично они помогут, выложить в интернет не советую, но тут уж вы сами себе хозяева.
3) Ждать, пока кто-то другой, не связанный с Колибри, выложит в интернет документы, которые получил он. В этом случае и Колибри в выигрыше, и закон никто из нас не нарушил, потому что скачали то, что дали скачать. По этому варианту уже кто-то выложил что-то, что было сделано для RDC IAD100 R3306, который является братом-близнецом Vortex86DX, который в eBox-3300 (не путать с eBox-3300MX, в котором Vortex86MX). Скачать здесь: viewtopic.php?f=25&t=1631&start=45 (пролистайте до середины страницы, там файл из 5 частей).

VaStaNi wrote:Дело весьма усугубляется именно этим (отсутствием техдоки) и НЕ только по GPIO программированию, но и USB - аналогично. Вернее с ним ЕЩЁ ХУЖЕ! Это нужно четко понимать. Особенно тем, кто думает, мечтает, о том, что недалеки времена, когда Колибри, USB и eBox заживут дружной жизнью. Разве, что где то они у кого то тихо тихо есть... или куплены, но давать низззззяяяя!

По словам производителя, которые 100% верны (проверены на практике), Vortex86MX = Vortex86DX + (on-chip VGA) + (HD Audio) + (MMX) - (ISA).
Исходя из этого:
1) HD Audio = уже написано Asper-ом, работает 100%, если есть какой-то баг - он исправит, только найдите баг сначала
2) MMX = просто набор команд, Asper уже изучил, какие команды конкретно поддерживаются, но для этого проекта их можно даже не использовать, если что.
3) on-chip VGA = в Колибри всё равно только VESA, так что без разницы, какой там чип. А в роботе даже VESA не нужно (он же без монитора).
4) Нет ISA - ну так не используйте его. Ту часть дока, где в RDC IAD100 R3306 описывается ISA, выкиньте в мусорку

VaStaNi wrote:Колибри проект массовый, а значит тупик с данной платформой. Выбирать нужно, тогда другую платформу, на Intel или VIA что то там было... Иначе: костыли, костыли, костыли, горбатость воплощения и итоговое уродство.

Как раз наоборот - только с Vortex86 / eBox у Колибри есть будущее. И это не пустые слова! Дешевизна и тормознутость Vortex86 + бесплатность и быстрота Колибри + пустое место в БИОСе для Колибри + процессор x86 + маленький + без вентиляторов + низкое энергопотребление + очень быстрый БИОС + ... + ... + ... + я их раздаю на халяву

VaStaNi wrote:yogev_ezra, ты хоть скажи что с данным типом eBox-3300MX-GC85 у тебя? Возможно, нет, уже есть на руках, выслал тому то и он, допустим может потестить GPIO пробные тесты... если что созреет. Gluk уже НЕ ЕЁ получит? В пути?

На руках именно такой версии у меня нет - никто их не покупает. Заказал специально 2 штуки - для Gluk-a и для кого-нибудь ему в наставники. Через недели две они будут у меня. К 1 мая, думаю, Gluk её получит.

USB везде OHCI/UHCI + EHCI. Всё контроллеры стандартные, документации и исходников хватает. Так что здесь больше от желания зависит.

art_zh wrote:для превращения Колибри в RTOS достаточно добавить в ядро простенький [кольцевой] буфер, данные из которого будут поочерёдно выплёвываться в GPIO при каждом прерывании по времени (100 раз в секунду). Это будет круче чем ШИМ, при неопределенности по координате плюс-минус 2мм.

ну вот ты пришел к "идейному зародышу" механизма КПСВВ, как я от этого "отталкивался" в 2007-м. А вот не так давно я тебе(и другим) немного описал и даже нарисовал болок-схемку здесь. Левая часть рисунка это и есть типа твое понятие "кольцевой буфер"+ "при каждом прерывании по времени". Вижу зарегился ты тут на форуме в 2009-м к сожалению. К сожалению, птому что в 2007-м мне не было с кем здесь это обсуждать видимо...
2011й сегодня и "мы пришли к тому", что таки есть x86 и есть GPIO и DIO и TTL и LPT являются все параллельными портами прямого доступа к пинам. И таки реально LPT управлять ключами, соленоидом, роботом. Другое дело, что их почти "выжили". Робототехникам требуется не какая-нибудь офисная мать, а x86 embedded-мать "под задачу" с DIO, SERVO, например. Тот же eBox ведь разработали многовариантно, вернее чипсет-линейку Vortex86.
ШИМ.
ШИМ бывает аппаратный (к стати в Vortex86 он есть), а бывает программный. То, что ты привел является базовым программным механизмом получения ШИМа. Естественно он (программный ШИМ) опирается на максимально жесткий такт (IRQ0), прямой доступ к портам из ядра и... модуляция импульсов по оси времени, которая называется скважностью импульсов. Статические DIO данных - это тоже ШИМ, только с очень большим периодом изменения сотояния пинов(бит). В обычных архитектурах ОС ядер (Колибри не исключение) приложение вынуждено постоянно через API OS "прорываться к телу" портов и модифицировать биты портов (ключей), создавать высокоприоритетные "нити"... это масса накладных расходов на производительность, прежде всего. И это очень заметно, тормозит, замораживается... Это следствие "перебора" по тактам, особенно если процесс много их жрет. В задачах регулирования посредством портов, особенно непрерывных, бывает несколько портов, несколько пинов, несколько зависимостей(!) между воздествием и регулированием... Разумному кодеру понятно куда эта дорожка ведет.
Итак, есть несколько портов, несколько приложений с ними связанных. Возникает и суперпроблема строгой тактовой синхронизации (тактовая "пин-привязка") даже при событийном механизме в ОС...
В КПСВВ я вынес это "за пределы приложения". Приложение делает "заявку" на обслуживание такого то порта, с таким то "заданием по дискретному сигналу", на такую то его длительность(бесконечно - частный случай), начиная с.....
Т.е. по сути ставит "в очередь", допустим, задачу генерировать меандр для битов 2,4 (какие нибудь пин-выводы GPIO), с периодом 23 такта IRQ0, длительностью 5 секунд (NNN периодов IRQ0. Пусть это внешне - крутим колеса вперед, например), все!!! Приложение БОЛЬШЕ ЭТИМ НЕ ЗАНИМАЕТСЯ, переключения контекта НА "ЭТО" НЕТ, синхронизация обеспечена, межбитовые задержки минимальны (джиттер!), процессорное время (а оно ведь общее на все задачи и ядерные и аппликухи!) расходуется минимально, минимально возможное, т.к. это часть обработчика прерывания. Но и это не все! В одной обработке прерывания мы в состоянии обработать все порты, требующие RT обслуживания в соответствии "с заявками телезрителей" от аппликух... но и это не все! Ладно..., базовые основы я изложил внятно кажется.

art_zh wrote:

VaStaNi wrote:в смысле на Колибри у них ставка или просто что то там собираются?

у них есть желание продемонстрировать возможности Колибри на чем-нибудь очень зрелищном. Правда, пока еще не решили - будет этот робот колёсным или летающим.

а они программеры? Тут обитают вообще? Непонятно, как делать на оси, которую... не юзал что ли. Или с твоей помошью? Зрелищное, понятно, в каких "масштабах эффекта" и деньгах... гм, да и что важно на чьи, если не секрет? Может спонсор есть и серьезны ставки? Просто хобби и адреналин вскипает? Типа соревнования, бои роботов, шоу роботов для богатеньких там... Ну в приват можно если, что сугубое. Дело в том, что я и сам прикидывал варианты такие как то. Нужны условия. Ну понимаешь валяются знания, опыт, наработки, жалко просто так гнить им... А типа на форумах доказывать, писать статьи каждому встречному, что ты не дурак и не чекнутый и не трепишься, так это давно пройдено. Времени жалко, вот уже начинаю жалеть по поводу этой ветки

art_zh wrote:Верно, надо искать базовую платформу - если система будет полноценно реализована хотя бы на ней, тогда легче будет и конкурентов раскрутить насчет документации.

непонял тут про "конкурентов раскрутить" это кто если не секрет? Они у тебя есть личным образом? У команды? У Колибри? Очем это?

yogev_ezra wrote:Ты представляешь чёрта страшнее, чем он есть на самом деле. Asper + hidnplayr за несколько месяцев написали драйвера для сети + звука под eBox-3300MX, с нуля! Без техдока! Работают без багов! Значит, и для USB можно (тем более, его будут писать 5 человек, а не 2).

я могу понять твою эйфорию, но ты искжаешь действительность или ее принципиально не хочешь видеть. Листинги=техдоки, потом сам приводишь файл, который у них у него был, есть! Как же ты говоришь слово "без"! Другое дело откуда, как, что было источником информации. Линукс драйвер портировали, я так думаю, ну здорово, молодцы! Но зачем же искажать! От этого слаще что ли будет? Кому?
И потом, ничего это не значит - по поводу USB. В том доке твоем ни слова про USB ни про GPIO, а зависимость количества участвующих человек и итогового качества или продвижения - вопрос спорный. Просто восхищаться текущим и ждать вплощения следующего блока, это хорошо, но есть вопросы и кто то их должен решать. Не понятно чего ты как самый заинтересованный, не хочешь выполнить это ниже (NDA) и тихо-тихо дать на прочтение доверенным разработчикам?

yogev_ezra wrote:1) Я подпишу NDA и получу эти документы. Но это будет бесполезно, так как я программист очень плохой и сам это не осилю, а если Я выложу эти документы в интернете, то нарушу закон и меня конкретно выебут оштрафуют.

все преступники и сволочи и сразу выложат что ли если ты по почте зашифрованным мылом пришлешь? Там отпечатки пальцев нужны??? Ты же заинтересован вроде... че то мутишь, темнишь все...

yogev_ezra wrote:

VaStaNi wrote:Колибри проект массовый, а значит тупик с данной платформой. Выбирать нужно, тогда другую платформу, на Intel или VIA что то там было... Иначе: костыли, костыли, костыли, горбатость воплощения и итоговое уродство.

Как раз наоборот - только с Vortex86 / eBox у Колибри есть будущее. И это не пустые слова! Дешевизна и тормознутость Vortex86 + бесплатность и быстрота Колибри + пустое место в БИОСе для Колибри + процессор x86 + маленький + без вентиляторов + низкое энергопотребление + очень быстрый БИОС + ... + ... + ... + я их раздаю на халяву

да не не путай ты драйвер-офисные вещи и успешных роботов, успешние RT вещи в которых знают толк некоторые, с ними, как минимум сталкивающиеся. Управление, регулирование... и просто TCP пакетик принять с погрешностью "+" "-" (1-2) секунды... разные айсберги!
Вот слова горбатость и т.д. это туда! Под "успешными" нужно понимать не просто проползти, проехать как нибудь, а например пролететь, прошагать... "эффектно", так сказать внешне это проявляется, не тяп-ляп это делается.
Правильно многие тут сказали (а им не внимают некоторые) ТЗ, условия, параметры... Габариты корпуса... равно, как и его цвет, не определяющие параметры проекта и выяснять их 125-й пункт ТЗ.... Вопросы так и "висят" ведь...
И ваще, я так понял, раз ты и Gluk одно лицо(или ты главный у него... слушай ты не тот профессор? А? ), так тогда его тут мы больше не увидим? Ты рулить ТЗ будешь? Ну так изложи.

art_zh wrote:Верно, надо искать базовую платформу

вот целый день рыл "выгодные варианты" и в основном типа "под тебя" вообщем типа... основные критерии бегло:
камера(ы), пропускная способность по ним, наличие DIO на платах, Intel или что то в широком тех-док-доступе... одно питание, несколько Ethernetov... короче вариантов 20-30 перебрал, включая про видеозахват. Цены почти не затрагивал. Нужно фильтровать будет еще. Интересует ли вообще тебя, твоих парней? Выложить, описать "+", "-" ? Здесь полезно(нужно) или приват?