Новое в разработке встраиваемых систем. Работа на цифровом KVM - PullRequest
1 голос
/ 19 января 2009

Я новичок во встраиваемой разработке, но некоторое время интересовался этой областью. Я думаю, что это достаточно близко к программированию; и я видел достаточно людей, которые демонстрируют знания в этой области, поэтому я спрошу здесь.

Я решил, что классным проектом, который охватит множество различных областей программирования и аппаратного обеспечения, будет разработка KVM на основе цифровых ЛВС. Моя конечная игра состоит в том, чтобы иметь несколько «блоков», которые содержат много (я думал 4-8) VGA и PS / 2 парных гнездовых портов и один порт Ethernet. Вы должны подключить устройство к локальной сети и к компьютерам, а затем получить к нему доступ с помощью программного обеспечения, работающего на других клиентах на базе Windows в сети. Каждый блок будет иметь свой собственный IP, но отвечать на какой-то пакет широковещательной рассылки, чтобы у каждого клиента был полный список всех компьютеров, подключенных к каждому блоку. Как вы можете догадаться, я не слишком разбираюсь в сетевом программировании (еще одна причина, по которой я выбрал этот проект).

Моя первоначальная идея состояла в том, чтобы каждый блок содержал три микропроцессора. Один (который имеет много аналоговых портов ввода / вывода) будет взаимодействовать с VGA и PS / 2 I / O. Это преобразовало бы VGA в какой-то цифровой пакет, который был бы отправлен (IC2 / USB / что угодно) на второй процессор. Он также получил бы цифровую упаковку от второго процессора, содержащую ввод от мыши / клавиатуры, отправленный от клиента. Затем он преобразовал бы это в аналоговый выход и отправил бы их через порты PS / 2.

Второй процессор получает выходные данные VGA от каждого активного компьютера, объединяет их в одно изображение и сжимает с использованием сжатия JPEG. Теперь сжатое изображение будет отправлено на третий процессор.

Третий процессор будет отслеживать все активные клиенты и взаимодействовать с картой Ethernet. Он отправит сжатый вывод на монитор нужным клиентам, а также получит ввод с клавиатуры / мыши, который будет отправлен на второй процессор.

Это первый встроенный проект, о котором я когда-либо задумывался. У меня есть следующие вопросы. Примечание: меня больше интересует, как вы пришли к ответу, чем сам ответ. Это опыт обучения больше всего на свете. Хотя я работаю в ремонтно-технической мастерской, у которой текущий аналоговый KVM выходит из строя и у меня недостаточно портов для того количества машин, которое у нас постоянно на стенде; так что, если я смогу сделать это достаточно дешево, это может быть полезно.

Вопрос 1:

Мой нынешний план совершенно идиотский? Думаю я о проблеме?

Вопрос 2:

Насколько быстрым должен быть каждый процессор? Первым будет преобразование возможного

165 888 000 байт (1440 * 900 * 32 * 4) (максимальное разрешение, которое я хочу поддерживать, максимальное время, умноженное на 4 компьютера)

Это примерно 158 МБ. На какой скорости должен работать процессор, чтобы обрабатывать такое количество данных 30 раз в секунду?

Затем то же самое относится ко второму процессору, который должен сжимать 158 МБ пикселей в JEPG. Процессор локальной сети должен был бы работать намного меньше из-за сжатия.

Вопрос 3:

Куда мне обратиться, чтобы получить оборудование, необходимое для его сборки? Что касается микропроцессоров, у них должен быть доступен компилятор Си. Я думаю, что мог бы сойти с ума, написав сжатый JPEG в ASM.


В основном я застрял. Трудно, если не невозможно, найти достаточно ресурсов в сети, чтобы начать в этой области; так что мне интересно, может ли кто-нибудь здесь указать мне правильное направление.

Кроме того, я довольно ограничен в своих знаниях в области электроники.

EDIT

Я не понимаю, почему этот вопрос был отклонен. На мой взгляд, этот вопрос может дать ответы, которые могут помочь программистам войти во встроенную разработку. У меня есть идея, и я знаю, как процессоры и память работают достаточно хорошо для кодирования. Однако в моих знаниях существует разрыв между знанием этого и способностью внедрять свои собственные устройства. Это было бы полезно для тех, кто находится в моем положении.

Ответы [ 5 ]

1 голос
/ 20 января 2009

Q1. Помимо того, что он очень амбициозен, звучит так, будто он может сработать.

Q2. Я хотел бы взглянуть на ПЛИС, они являются хорошим кандидатом для возможности захвата видео. Хороший ресурс - FPGA4Fun . С правильной FPGA вы сможете запускать захват и сжатие на одной FPGA. Нечто подобное Комплект 32-битного сетевого процессора AVR может работать для взаимодействия с сетью.

Q3. Octopart - хорошее место для поиска поставщиков.

Электронные ссылки в электронном виде в произвольном порядке

Электроника Wisc-Online

Электронные закладки Tom Loredo

Уроки по электрическим схемам

Это лишь немногие, с которыми я сталкивался в своих восхитительных электронных ссылках. Я не прошел через это, но они должны быть в состоянии указать вам правильное направление. Удачи.

1 голос
/ 19 января 2009

Это интересная идея. У него действительно есть некоторые приложения по сравнению с программным обеспечением для удаленных рабочих столов - я могу перезагрузить сервер и сделать биос, или даже установить ОС удаленно.

Учитывая стоимость необходимого вам оборудования (CPU / VGA / OS / tcp) и небольшие объемы (вы не собираетесь продавать миллионы), я бы начал с небольшого компьютера с Linux, как * 1003. * beagleboard и использовать протокол TightVNC и / или RDP. (Возвращение VGA с удаленного ПК будет интересным)

Учитывая астрономические цены на корпоративные KVM-переключатели, вы можете зарабатывать на этом!

1 голос
/ 19 января 2009

Для клиентского протокола вы можете посмотреть на взаимодействие с использованием протокола VNC. Это даст вам преимущество, предоставляя вам встроенный протокол и, возможно, клиент.

Tight VNC имеет доступный исходный код.

1 голос
/ 19 января 2009

Мое мнение: вы далеко от исходной точки с «концом» проблемы, над которой вы собираетесь работать. VNC уже слишком хорош для того, что вы описываете. Позвольте мне описать проблемы так, как я их вижу:

Требования к обработке для встраиваемого приложения непомерны - как уже упоминали другие люди, видео поражает. Вам почти наверняка понадобится сжать его, что потребует большей мощности процессора, вам потребуется достаточно оперативной памяти для хранения всей этой информации, и на секунду представьте, сколько данных он выдает - 20 МБ кадра или около того. Это много данных. Плюс, если вы реализуете это, ваш «компьютер» будет иметь два IP-адреса - один для управления видео / клавиатурой и мышью, а другой - для доступа к файлам и т. Д. Это просто кажется мне глупым.

Это не решает проблему, о которой вы думаете, но я думаю, что вам лучше реализовать тонкий клиент, который подключается только к серверу VNC и обрабатывает команды клавиатуры / мыши, а затем кодирует их в VNC-совместимые команды Ethernet, и отображает видеоданные на подключенном мониторе. Вы даже можете поместить на него большую кнопку, которая переключается между списком IP-адресов компьютеров (в стиле KVM). Вероятно, это можно сделать с помощью вычислительной мощности ARM в несколько сотен мегагерц плюс, возможно, отдельного чипа для обработки видео. TI и AVR делают процессоры ARM, так что это хорошее место для начала. Пример встроенной платы ARM, на которой работает Linux, приведен здесь:

http://opencircuits.com/Linuxstamp

У него нет видео, но есть Ethernet, последовательный порт, USB и т. Д. Это хорошая отправная точка для разработки встроенного ARM Linux, и я думаю, что это направление, которое вы должны выбрать. Попробуйте также uCLinux, и удачи!

1 голос
/ 19 января 2009

165 888 000 байт (1440 * 900 * 32 * 4) (максимальное разрешение, которое я хочу поддерживать, максимальное время, умноженное на 4 компьютера)

  • Если 32 - битовая глубина, значит, ваш расчет выключен. 32 бита = 4 байта, поэтому полоса пропускания входящих данных (1440 x 900 x 4 x 4) = чуть менее 20 МБ на кадр.

  • Вероятно, для 8-разрядного процессора потребуется не менее (1440 x 900 x 4 x 4 x 30) инструкций в секунду, т. Е. 622 МГц только для чтения ввода. 32-битный процессор может быть в 4 раза медленнее = 156 МГц. Но это минимальная скорость, помните

  • Выясните, сколько циклов требуется для выполнения любой необходимой обработки. Допустим, вы пишете программу, которая может обрабатывать каждый выходной пиксель за 10 циклов, у вас получается (1440 x 900) пикселей, поэтому вам потребуется 32-битный процессор со скоростью (1440 x 900) x (10 циклов) x (30 кадров в секунду) ) = 389 МГц

...