Вам виднее, кто кроме вас вашу задачу знает? Если необходим именно десяток удалённых процессоров и система не может быть спроектирована в рамках одного, то конечно же вы правы. Но если вы хотите синхронизировать все эти процессы при помощи linux ipc на десятках килогерц, то возможно вы не сможете так решить свою задачу. Реалтайм (или близкие) синхронизации в qnx на мой взгляд выполнить удобнее. Спорить конечно не имеет смысла, в этом вы тоже правы.

QNX хорошя штука, но дорогая и не очень гибкая. Кроме того, я недолюбливаю решения, от которых у меня нет исходников. Естественно, я не собираюсь (пока?) править исходники ядра Linux и eCos (хотя ничего страшного тем нет), но сам факт их наличия греет мне душу.

Линукс насколько я вижу мигрирует к десктопу быстрее, чем к embedded устройствам. И пользуюсь я им только по той причине, что прерываний 5..10Кгц в нынешней постановке моих задач хватает. Да, среда удобная, мне тоже нравится что она открытая. Но влезать в реализацию ядра не имею никакого желания, поэтому что полузакрытость QNX, что открытость линукса - это в определённой степени одно и то же. То есть и в QNX и в линуксе вам как разработчику до определённого уровня задач и не нужно думать о ядерной реализации, а работать только с процессами (ipc о которых вы и спрашивали). А если для вас синхронизация с более высокой частотой критична, придётся связываться с реалтаймовыми патчами ядра линукса, что не факт будет лучше чем пользоваться готовым и сертифицированным (!) продуктом. имхо.

Чистый Linux тосклив для embedded - это правда. Есть масса веток, ориентированных на embedded приложения - они куда интереснее.

Я все-таки постраюсь, чтобы IPC у меня использовался для медленных "сущностей" - десятки мс.

Есть такая чудная штука - RTAI (rtai.org). IMHO, она крайне перспективна, и вот ее и хочется освоить. Вопрос сертификации меня не волнует. Я уже много раз высказывал мнение, что сертификация к качеству продукта отношения не имеет (и не только в России) - это еще один способо развода на деньги. Что, многочисленные взломанные банковские системы не имели сертифкатов?

Самое лучшее что могу вам посоветовать - побыстрее попробовать все вышеуказанные продукты ручками. Например мне не понравились ни rtlinux ни rtai по сравнению с qnx. Возможно что дело вкуса. Сертификацию я упомянул потому что хотел показать что разработчикам под qnx она потребовалась потому, что их области применения этого требуют. Есть формальная разводка на деньги, а есть список необходимых требований - по моему это надо разделять. В любом случае желаю вам успехов.

Спасибо за Ваши ценные замечания!

Я прощу прощения если не в тему, но
Evgeny_CD а не приходила ли Вам мысль отказаться от операционки?
Чем дальше я читал эту ветку тем бесполезнее мне казалось ее применение.

По Вашим словам 1bit на 100 Гц (опрос охранки) - это низкая скорость, но и опрос этот как правило выполняет один Intel 80C51 (128 байт RAM, ~0.5MIPS @12Mhz).

Вы же планируете использовать ARM, LPC2138 - 60Mhz (59 32х битных MIPS)
20 Khz 8 bit, для 60-ти мегагерцового ARM'а - семечки. Ну смешно ведь ставить линукс лишь только для того чтобы использовать более дорой ARM контроллер и к тому же сделать его "тормознутым".

IP стек реализовать - плевое дело, гораздо проще чем разобраться с его реализацией в Linux
у меня с этим mega48 справлялся, походу обслуживая 16-ти разрядный стерео DAC @48kHz, тот самый проц который стоит меньше доллара по словам mse и который здесь почему-то используют только в качестве "сопроцессора для защиты софта".

Если планируется использование пром PC, то можно взять просто DOS (он сейчас тоже вроде как Free), и извращаться как душе будет угодно. Под DOS ведь тоже есть нормальный IP стек, например Microsoft Client 3, Trumpet-TCP и прочие.

PS: и по ходу MAC канального уровня, на котором строится траспорт (IP-стек) и сеансовый уровень (Sockets), обеспечивает доставку пакетов в том виде и в том порядке в котором пакеты были сформированы на транспортном уровне. Максимальный объем IP пакета определяется максимальным объемом MAC пакета и реализацией драйвера, и в большинстве случаев ограничивается 2-4kb.

Нет. Ось нужна.

1. Проблема не в опросе, а в дальнейшей обработке. Например, Berkeley DB (http://dev.sleepycat.com/) я не возьмусь портировать под BigLoop, а база данных мне очень нужна.

2. DOS - "фтопку". Хоть free, хоть за деньги.

3. Мне надо, чтобы проект прожил 10 лет без кардинаьной смены идеологии, и мог много раз перескочить на разные аппаратные платформы.

Так что ОСь будет служить вовсе не для утяжеления основного контроллера.

Весомый аргумент в пользу ОС.



Ну а этот не совсем весомый

Опыт показывает, что независимо от сложности софта и ОС под которую он был написан, без особых усилий его можно перенести на другую аппаратную платформу, даже в том случае если софт этот был написнан не на C, а на asm'е или чем-нибудь еще. При условии, что перенос будет осуществляться той же командой разработчиков. А у Вас помоему ситуация еще проще, сами планируете писать софт, под самостоятельно разрабатываемый девайс. Imho при таком подходе лучше удешевлять на всю катушку аппаратную часть, вместо гонки за кроссплатформенностью. Хотя это только imho.

ЗЫ: а есть сомнения, что при индивидуальном подходе устройство продержится 10 лет? Или через 5 лет будет уже другая полоса звуковых частот? ;>

Сообщение отредактировал defunct - Jan 31 2006, 03:03

Проблема вспомнить через 10 лет, что же ты тут такого написал . Разработка будет не индивидуальная, а силами небольшой команды. У нас уже есть примеры устройств на 87C51GB, которые прожили более 10 лет. И так хочется софт на них переписать, и так обломно ковыряться в асмовых исходиках (а софт там state of the art с точки зрения целевой задачи, его лет 5 по кусочкам писали и баги фиксили).

По поводу устройства на 87C51 - есть поговорка "Пока работает - не чини"
А вот возникла бы надобность перекинуть софт под другую платформу, думаю вначале было бы "обломно", а потом оказалось бы совсем не сложно

Так и постпуаем, каждый раз с матом добывая эти самые 51GB - ибо они уже антиквариат.