Цены для моего случая - порядка 300 в год просто безвариантно привлекательнее самоделки,
для 1000, полагаю тоже. Тем более, что никто самоделку потом поставить не запретит.

На счет Industrial (отсутствия???) чего-то не понял...


Ну а по книжкам! :-)
Примерно в 2000 году на русском языке были изданы (DiaSoft помнится) две книжки, что-то типа
"Ядро Linux в комментариях" и "IP стек в комментариях". Уровень софта вполне соответствует ныешнему
контроллерному. Может увлечет чтение?
У меня обе есть в бумажном варианте (только не под рукой) при необхобходимости могу дать
полные выходные данные.

-40 град С.Книжи эти я видел в каталогах, их уже не купить.
У меня сейчас есть много увлекательного чтива Все охватить не в состоянии.
Видимо, будет взят байт стаффинг, и написан простой протокол на его основе. Тогда вообще все универсально получится - хоть по COM порту гони, хоть по сокетам.

Я как-то сразу не оценил привлекательность байт стаффинга. Ну а то, что в худшем случае, когда в данных будут идти подряд одни ctl символы, трафик удвоится - меня не сильно волнует.

Излишество :-) в качестве физического интерфеса за Socket естественно может выступать
и COM порт со штатной для операционки поддержкой SLIP/PPP. Вы уж определяйтесь - либо "большая"
операционка со всеми ее достоинствами (ну и недостатками которые придется принимать и любить, как родные ) либо более самодельное с соответствующими достоинствами. Смешивать, пожалуй, это порочный путь.

Поиск маджика происходит в _остутствии_ синронизации, потом только проверка, то что описано у Вас это просто бездарная реализация, человеческий алгоритм приблизительно таков - реализуем peek_data(int len, char *buf) и read_data(int len, char *buf)

1. peek(sizeof маджик)) - не он - скипаем байт, goto 1
2. он -ждем заголовок пакета, он у нас стандартной длины, проводим проверки (можно проверить валидность поля длины, црц и т.д.) и если проверка не прошла скипаем sizeof(magic), goto 1
3. проверка прошла - ждем данные - проверяем црц - не совпала - скипаем sizeof(magic), goto 1
4: синхронизация установлена

И того теряем хвост 1 неполного пакета - устойчивость приема, в худшем случае (когда поток из одних маджиков например) определяется только качеством ф-ции црц

Буфер для сырого потока и так придется делать - где ж Вы выделенный фрейм хранить-то будете, разве что совсем примитивная задача. Временные затраты одни и те-же, а удобство пакетов очевидно - в их гибкости и уже произведенной работе по отделению мух от котлет, то бишь определению типа пакета и факта наличия/отсутствия данных - а вашем случае структурка оборачивается ненужными вставками. Стаффинг имеет смысл (т.е. обмен будет быстрее) только при фреймах одинаковой длины и/или для выделения синхры.

Советую на досуге еще подумать над вариантами, причинами и следствиями.

Пусть теоретики на своими прожектами думают - мне больше по душе прагматичная скорость практического подхода

На том и порешили - каждый сам себе Буратино.

Согласен! Просто я немного изменил начальные условия.

Для решения целевой задачи мне надо оцифровывать входной сигнал с
относительно высокой скоростью - 20кгц. 8 бит. Далее первичная
обработка: выделение границ битов (на амплитудной шкале), перевод в
битовый поток, привязка блока битов к GPS времени, и передача в
основную Линух систему для серьезной обработки.

Понятно, что если я на ARM920 200 Мгц ядре забубеню 20 кгц интеррапты под
Линухом, тот тут все быстродействие системы и кончится. Можно и ДМА
прикрутить, но все равно останется довольно заметный объем низовых
вычислений. Хочется освободить от этого основное ядро системы.

Я всю первичную обработку загоню в какой-нибудь LPC2138 (ресурсов по
процу и памяти как раз хватит), а вот подготовленный данные буду гнать
по RS-485 в Linux машику.

Как я уже описывал ранее, разработка будет идти "сверху", т.е.
до оцифровки реального сигнала дело дойдет не очень скоро. Все будет
отлаживаться на симуляторе, который и будет создавать все необходимые
мне "входные сигналы".

Просто хочется иметь один и тот же протокол, чтобы потом не пришлось
переписывать.

Понятно, что для TCP сокета байт стаффинг- странное решение. Но он мне
даст полную универсальность - могу симулятор запустить на той же
машине, где идет отладка, могу на другой (возможно, симулятор будет
очень крутым по необходимой вычислительной моще), когда дело дойдет до
контроллера - просто будут читать tty как файл.

Еще раз большое спасибо всем, кто потратил время на мое просвещение!!!

Сообщение отредактировал Evgeny_CD - Jan 17 2006, 15:56

Даже такой отторможенный арм как 920 должон легко взять планку в 20-50 кгц, см. adeos/xenomai latency test/examples.
Стандартный инженерный подход в определении границы софт-хард должен подразумевать владение/прикид цифр на имеющемся железе в парочке вариантовю Все равно, как показывает практика, решений одной и той же задачи бывает несколько - дело обычно в эстетизьме ... или в лени ...

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

Обработка входных данных алгоритмически проста, но вычислений немало.

В то же время, LPC2138 под управлением замечательной ОСи BigLoop все это сделает точно. И тогда под Linux с могу спокойно писать обработку верхнего уровня - которая как раз алгоритмически сложна, хотя объем вычислений там невелик. И я смогу написать все это, заботясь о простоте и красоте кода, и не очень думать производительности.

Папка есть, а где же книга? То есть, где она в /pub/?


Нашел: /pub/DOC/Books/OS/Unix_linux/Interprocess_Communication_in_Linux.chm. Спасибо makc и _artem_!

> оцифровывать входной сигнал с относительно высокой скоростью - 20кгц. 8 бит.

вы имеели в виду оцифровку видеосигнала? или я не понял почему эта скорость
высокая.

Нет, я говорю об аналоговых НЧ сигналах. Скорость _относительно_ высокая. Относительно, например, 1-битной оцифровки 100 гц, которой хватает для опроса датчиков охранной системы

А вы не пробовали поискать девкиты работающие под QNX? если конечно построение распределённой системы не есть ваша конечная цель, то в пределах одного проца решать задачи всегда лучше. Стандартный линукс не осилит прерывания 20КГц, а QNX - вполне.

...ь любой софт - не проблема. Найти правильное решение - вот проблема.

Я тщательно изучал вопрос полгода и пришел к выводу, что для моих задач (вероятно, и для многих других задач) вместо того, чтобы решать вопрос о том, какая полуOS/полумух потянет 20 Кгц прерывания, гораздо правильнее поставить ATmega48 за 1.2$, оцифровывать там, кучковать данные в пакеты, приписывать к каждому пакету метку реального времени, и загонять эти данные в *nix контроллер по стандартному интерфейсу (RS, Ethernet, CAN, ...). В правильной *nix системе затраты процессорного времени на блочный IO по стандартным каналам невелики, а что касается "решать задачи всегда лучше" - понятно, что на том же линухе приятнее программить, чем под uCOS.

Что касается аппаратуры - AT91RM9200 просто гениальный проц со своей кучей коммуникационных контроллеров и DMA. К нему можно подцепить десяток этих ATmega48 вообще без проблем и лишней аппапаратуры (хотя, сказать по честному, AT91SAM7S32 за 4$ со своим SSC и DMA подходит куда лучше) А вот заниматься поиском ответа на вопрос: "Какая высокоуровневая OS потянет 200 Кгц прерывание?" и "4ГГц процессора хватит для этого?" я просто принципиально не буду.