Вопрос ламера по Linux IPC, Inter Process Comminications Опции

[Evgeny_CD]

Есть два процесса под Linux. Им надо обмениваться пакетами данных.

Пакет представляет из себя:

* заголовок - поле фиксированной длины
* данные - поле переменой длины (<= MAX_LEN), заполненное бинарными
случайными данными.

Как лучше всего сделать такой обмен?

Я удумал следующее.

1. Канал. Пишем, читаем. Но поскольку он имеет байтный интерфейс, при
последовательном чтении непонятно, где начинается заголовок. Значит,
придется вводить какие-то механизмы для его нахождения (Escape
последовательности и пр.). Это не сложно, но совершенно лишнее действие
в контексте решаемой задачи (нужно ее решить максимально быстро по
программированию, расход памяти и процессорного времени не важен (в
разумных пределах)).

2. Разделяемая память. Наделать там кучу семафоров, и обмениться
указателями на структуры.

3. Гибрид

Делаем разделяемую память, а там - кольцевой массив структур. Каждая
структура - это сообщение, данные пакета аппроксимированы массивом
максимальной длины (пустые места в памяти не волнуют).

2 потока для каждого направления обмена.

Передающий процесс пишет в поток send_msg char значение номера
элемента в массиве, куда он положил пакет.

Принимающий процесс пишет в поток msg_ask char значение номера элемента в
массиве, который он прочитал (освободил).

IMHO, так еще будет быстрее всего (нет лишнего копирования) и
экономнее (по памяти) всего (нет памяти для лишних копий).

Вероятно, я изобретаю велосипед. А что скажут Гуру по данному поводу?

[zltigo]

Есть два процесса под Linux. Им надо обмениваться пакетами данных.

Самое простое и безобидное через сокеты. Заодно и потом можно и на разные машины разнести
без всяких усилий.

[Evgeny_CD]

Самое простое и безобидное через сокеты. Заодно и потом можно и на разные машины разнести без всяких усилий.

С сокетами отчасти понятно. Но непонятно, как из потока выделять загловки пакетов? Или просто читать (и писать) блоками фиксированой длины, понимая, что в TCP сокете ничего потеряться не должно.

[zltigo]

С сокетами отчасти понятно. Но непонятно, как из потока выделять загловки пакетов? Или просто читать (и писать) блоками фиксированой длины, понимая, что в TCP сокете ничего потеряться не должно.

Значит с сокетами не понятно :-(.
Это _пакетный_ интерфейс.

[Evgeny_CD]

Значит с сокетами не понятно :-(.
Это _пакетный_ интерфейс.

Спасибо! Ну что же, будем вчитываться дальше.

[psL]

Если один процесс родительский, а второй его потомок - лучше использовать pipe.
Если два независимых - то каналы FIFO. Кстати - каналы FIFO обеспечивают атомарные запись/чтение. Т.е. пакеты(кадры) не перемешиваются, в отличие например от передачи через TCP. Видимо это то что нужно.
Для разделяемой памяти существует ограничение на количество блоков разделяемой памяти для процесса (что-то около 20, но это зависит от системы и ее настроек).
Еще можно обмениваться через файлы, отображаемые в память.

Лучшая книга - Уильям Стивенс
Unix. Взаимодействие процессов Уильям Стивенс. Unix. Взаимодействие процессов

[zltigo]

Если один процесс родительский, а второй его потомок - лучше использовать pipe.
Если два независимых - то FIFO. Кстати - FIFO обеспечивает атомарные запись/чтение. Т.е. пакеты(кадры) не перемешиваются, в отличие например от передачи через TCP. Видимо это то что нужно.
.....
Еще можно обмениваться через файлы, отображаемые в память.

1. Pipe и FIFO суть одно и то-же и работают одинаково. И оба
исключительно НЕ пакетные - не сохраняют границ сообщений (вспоминаем о чем речь шла).
FIFO принадлежность System-V базирующихся систем и в линейке BSD не
используются по причине нахренненужности.
2. Ну не надо сюда TCP приплетать и пугать "перемешиванием" путая его с повтором.
3. FIFO как раз и есть файл "отображаемый на память", как и сокет при адресации AF_UNIX.

[psL]

> 1. Pipe и FIFO суть одно и то-же и работают одинаково.
Не одно и то же, хотя бы с точки зрения того, что я говорил выше.

> И оба исключительно НЕ пакетные - не сохраняют границ сообщений (вспоминаем о чем речь шла).
pipe возможно, насчет FIFO не уверен. Поскольку с FIFO могут работать и несколько процессов.

> FIFO принадлежность System-V базирующихся систем и в линейке BSD не используются по причине нахренненужности.
Разговор вроде был о Linux, а не о фрях.

> 2. Ну не надо сюда TCP приплетать и пугать "перемешиванием" путая его с повтором.
Возможно я неправильно выразился, я имел ввиду, что TCP - не гарантирует сохранения границ пакетов. Неудачный пример.

> 3. FIFO как раз и есть файл "отображаемый на память", как и сокет при адресации AF_UNIX.
С точки зрения реализации - наверное да, но все-таки это разные механизмы IPC.

[zltigo]

> 1. Pipe и FIFO суть одно и то-же и работают одинаково.
Не одно и то же, хотя бы с точки зрения того, что я говорил выше.

Выше вы говорили, что:

Кстати - каналы FIFO обеспечивают атомарные запись/чтение. Т.е. пакеты(кадры) не перемешиваются

Продолжаю утверждать, что с этой точки зрения отличий Pipe и FIFO НЕТ НИКАКИХ.

> И оба исключительно НЕ пакетные - не сохраняют границ сообщений (вспоминаем о чем речь шла).
pipe возможно, насчет FIFO не уверен. Поскольку с FIFO могут работать и несколько процессов.

?????

Разговор вроде был о Linux, а не о фрях.

Речь идет о многочисленных последователей вышеупомянутых. BSD Socket предоставляет
продуманный унифицированый интерфейс. По этой причине присутствует повсеместно, в отличие
от FIFO.

я имел ввиду, что TCP - не гарантирует сохранения границ пакетов.

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.

С точки зрения реализации - наверное да, но все-таки это разные механизмы IPC.

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

[psL]

?????

Имелось ввиду что:
Для канала дочерний процесс может получть дескриптор только от процесса родителя. Каналы не могут использоваться в качестве IPC между независимыми процессами.
Очередь FIFO - отдельный тип файла в файловой системе, со всеми вытекающими. Не используются в BSD.
Вообще, много чего разного, при похожести в первом приближении.

Запись числа байтов, меньше емкости FIFO или канала гарантированно атомарна. Это означает, что в случае, когда несколько процессов одновременно записывают в канал, порции данных от этих процессов не перемешиваются. Если размер пакета больше емкости канала или FIFO - атомарность не гарантируется.

Не верите - спросите у Робачевского и Ко.

я имел ввиду, что TCP - не гарантирует сохранения границ пакетов.

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.

В смысле прикладных пакетов, которые пользователь посылает. Подразумевалась вроде работа на прикоадном уровне? Прикладной уровень не всегда может забрать свой пакет полностью. Небольшим пакетам (по-моему до 8 КБ) это кстати не грозит - я же сказал пример неудачный.

С точки зрения реализации - наверное да, но все-таки это разные механизмы IPC.

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

В nix вообще идеологически все построено на файлах. С этой точки зрения и каналы FIFO, и локальные сокеты, и совместно используемые "файлы, отображаемые в память" (ну не помню я как этот тип IPC правильно называется) суть одно и то же. Но есть тонкости, которые определяющие - Поэтому один механизм IPC называется так, а другой эдак.

Кстати реализация BSD сокетов в каких либо облегченных версиях Linux тоже не совсем обязательно присутствует.

Если я в чем-то и ошибаюсь - всему виной моя недостаточная осведомленность.

Всех благ!

Сообщение отредактировал psL - Jan 15 2006, 09:45

[Harbour]

Насчет выделения пакетов из какого угодно потока (в том числе ненадежного) - че за трабла :

#define MAGIC 0xFEEDBEEF

struct Header {
int magic;
int len; // длина данных после заголовка
int cmd; // тип пакета
// ... всяческие полезные поля
int crc; // црц данных
} __attribute__ ((packed));

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

А в ipc вообше-то messag'ы есть такие - ими говорят очень удобно обмениваться ... Я так и не понял - процессы на одной машине ? В смысле нафига IPC заворачивать ?

Сообщение отредактировал Harbour - Jan 14 2006, 19:07

[zltigo]

Я так и не понял - процессы на одной машине ? В смысле нафига IPC заворачивать ?

1. За тем, что процессы изолированы во многих OC.
2. IPC для этого в OC и создаются, причем с учетом минимизации побочных эффектов.
3. Ну а в предложенной (к делу не относящейся реализации) рассчитывать на то, что DEADBEEF не встретится, и синхронизироваться ценой потери нескольких фреймов, конечно можно....., но радиолюбительство. Простейший надежный вариант формирования фрейма в байтовом потоке, например, в SLIP протоколе.

[alexr22b]

я имел ввиду, что TCP - не гарантирует сохранения границ пакетов.

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.
[quote]

Я уже кучу денег заработал исправляя программы которые пользуются TCP/IP как пакетным протоколом. (Особенно wireless)
Вот выдержка из RFC которая прямо об этом и предупреждает.

------------------------------------------

As for your second issue, please remember the admonition in RFC 1123:


" 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34


" Implementors MUST NOT assume any correspondence between READ
boundaries on the control connection and the Telnet EOL
sequences (CR LF).


" DISCUSSION:
" Thus, a server-FTP (or User-FTP) must continue reading
characters from the control connection until a complete
Telnet EOL sequence is encountered, before processing
the command (or response, respectively). Conversely, a
single READ from the control connection may include
more than one FTP command."

[zltigo]

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.

Вот выдержка из RFC которая прямо об этом и предупреждает.
4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34

Сначала к проблеме передачи пакета прицепили ни к селу ни к городу TCP/IP уровень, потом
на него навернули Telnet протокол и его паковку байтов в пакеты.... Для кучи приплели радиоканал....

Перестаньте пожалуйста морочить голову.

[_artem_]

Vikladivayu knizku na /upload/doc/Unix_Linux_books :

Interprocess Communications in Linux®: The Nooks & Crannies
By John Shapley Gray

Publisher : Prentice Hall PTR
Pub Date : January 13, 2003
ISBN : 0-13-046042-7


Copyright
Introduction
Acknowledgments
Chapter 1. Programs and Processes
Section 1.1. Introduction
Section 1.2. Library Functions
Section 1.3. System Calls
Section 1.4. Linking Object Code
Section 1.5. Managing Failures
Section 1.6. Executable File Format
Section 1.7. System Memory
Section 1.8. Process Memory
Section 1.9. The u Area
Section 1.10. Process Memory Addresses
Section 1.11. Creating a Process
Section 1.12. Summary
Section 1.13. Key Terms and Concepts

Chapter 2. Processing Environment
Section 2.1. Introduction
Section 2.2. Process ID
Section 2.3. Parent Process ID
Section 2.4. Process Group ID
Section 2.5. Permissions
Section 2.6. Real and Effective User and Group IDs
Section 2.7. File System Information
Section 2.8. File Information
Section 2.9. Process Resource Limits
Section 2.10. Signaling Processes
Section 2.11. Command-Line Values
Section 2.12. Environment Variables
Section 2.13. The /proc Filesystem
Section 2.14. Summary
Section 2.15. Key Terms and Concepts

Chapter 3. Using Processes
Section 3.1. Introduction
Section 3.2. The fork System Call Revisited
Section 3.3. exec's Minions
Section 3.4. Using fork and exec Together
Section 3.5. Ending a Process
Section 3.6. Waiting on Processes
Section 3.7. Summary
Section 3.8. Key Terms and Concepts

Chapter 4. Primitive Communications
Section 4.1. Introduction
Section 4.2. Lock Files
Section 4.3. Locking Files
Section 4.4. More About Signals
Section 4.5. Signal and Signal Management Calls
Section 4.6. Summary
Section 4.7. Key Terms and Concepts

Chapter 5. Pipes
Section 5.1. Introduction
Section 5.2. Unnamed Pipes
Section 5.3. Named Pipes
Section 5.4. Summary
Section 5.5. Key Terms and Concepts

Chapter 6. Message Queues
Section 6.1. Introduction
Section 6.2. IPC System Calls: A Synopsis
Section 6.3. Creating a Message Queue
Section 6.4. Message Queue Control
Section 6.5. Message Queue Operations
Section 6.6. A Client–Server Message Queue Example
Section 6.7. Message Queue Class
Section 6.8. Summary
Section 6.9. Key Terms and Concepts

Chapter 7. Semaphores
Section 7.1. Introduction
Section 7.2. Creating and Accessing Semaphore Sets
Section 7.3. Semaphore Control
Section 7.4. Semaphore Operations
Section 7.5. Semaphore Class
Section 7.6. Summary
Section 7.7. Key Terms and Concepts

Chapter 8. Shared Memory
Section 8.1. Introduction
Section 8.2. Creating a Shared Memory Segment
Section 8.3. Shared Memory Control
Section 8.4. Shared Memory Operations
Section 8.5. Using a File as Shared Memory
Section 8.6. Shared Memory Class
Section 8.7. Summary
Section 8.8. Key Terms and Concepts

Chapter 9. Remote Procedure Calls
Section 9.1. Introduction
Section 9.2. Executing Remote Commands at a System Level
Section 9.3. Executing Remote Commands in a Program
Section 9.4. Transforming a Local Function Call into a Remote Procedure
Section 9.5. Debugging RPC Applications
Section 9.6. Using RPCGEN to Generate Templates and a MAKEFILE
Section 9.7. Encoding and Decoding Arbitrary Data Types
Section 9.8. Using Broadcasting to Search for an RPC Service
Section 9.9. Summary
Section 9.10. Key Terms and Concepts

Chapter 10. Sockets
Section 10.1. Introduction
Section 10.2. Communication Basics
Section 10.3. IPC Using Socketpair
Section 10.4. Sockets: The Connection-Oriented Paradigm
Section 10.5. Sockets: The Connectionless Paradigm
Section 10.6. Multiplexing I/O with select
Section 10.7. Peeking at Data
Section 10.8. Out of Band Messages
Section 10.9. Summary
Section 10.10. Key Terms and Concepts

Chapter 11. Threads
Section 11.1. Introduction
Section 11.2. Creating a Thread
Section 11.3. Exiting a Thread
Section 11.4. Basic Thread Management
Section 11.5. Thread Attributes
Section 11.6. Scheduling Threads
Section 11.7. Using Signals in Threads
Section 11.8. Thread Synchronization
Section 11.9. Thread-Specific Data
Section 11.10. Debugging Multithreaded Programs
Section 11.11. Summary
Section 11.12. Nomenclature and Key Concepts

Appendix A. Using Linux Manual Pages
Section A.1. Manual Page Sections
Section A.2. Manual Page Format
Section A.3. Standard Linux System Calls

Appendix B. UNIX Error Messages
Appendix C. RPC Syntax Diagrams
Section C.1. Introduction
Section C.2. RPC Definitions
Section C.3. RPC Keywords
Section C.4. Some RPC Examples

Appendix D. Profiling Programs
Section D.1. Introduction
Section D.2. Sample Program for Profiling
Section D.3. Generating Profile Data
Section D.4. Viewing and Interpreting Profile Data

Appendix E. Bibliography

[Evgeny_CD]

Vikladivayu knizku na /upload/doc/Unix_Linux_books :

Interprocess Communications in Linux®: The Nooks & Crannies
By John Shapley Gray

Спасибо!

[Evgeny_CD]

Спасибо всем просветившим меня!

Из всего многообразия IPC мне приглянулись сокеты, т.к. они более
универсальны, и позволяют разнести задачи по разным машинам (сейчас
это не надо, но на следующем этапе точно потребуется). Так что
имеет смысл брать именно их.

Но они не гарантирует сохранения границ моих блоков данных.

Прикрутить формирователь фреймов из SLIP - это круто, но не хочется.
Хочется по простому...

Моя следующая идея.

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

Далее процесс повторяется.

Как эта идея?

[nazim]

Я для этой цели использовал простой "самодельный" протокол:
-----
02 байта тип пакета
02 байта длина данных
хх Данные
-----
Пакеты садятся в буффер, первый пакет "выдёргивается", всё остальное сдвигается к началу + проверки.
На первый взгляд, довольно нудно парсить, но как показала практика способ удобный.
Позволяет легко разделять "слипшиеся" пакеты (TCP NODELAY не везде работает).
Проверяется всего один сокет (всего один вызов select())

А можно ещё проще, опять по одному сокету:
На каждую посылку принимать подтверждение (длина и тип естественно в заголовке), тупо! но действенно.

Сообщение отредактировал nazim - Jan 15 2006, 19:24

[Evgeny_CD]

...Я для этой цели использовал простой "самодельный" протокол:
-----
02 байта тип пакета
02 байта длина данных
хх Данные
-----
Пакеты садятся в буффер, первый пакет "выдёргивается", всё остальное сдвигается к началу + проверки.
На первый взгляд, довольно нудно парсить, но как показала практика способ удобный.
Позволяет легко разделять "слипшиеся" пакеты (TCP NODELAY не везде работает).
Проверяется всего один сокет (всего один вызов select())...

Думал я об этом. Вроде препятствий нет - TCP должен по идее гарантировать:
* доставку байтов
* сохранениех их порядка
* отсутствие дупов

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

Приняли как описано - засунули в структуру (данные апроксимируем массивом максимальной длины). "Провернули" буфер указателей.

Обработчики пакетов с другой стороны "проворачивают буфер" и разбираются с содержимым структуры.

Один трабл - синхронность запуска и остановки процессов. В варианте разных машин это може быть не так примитивно.

Вероятно, надо сделать гибрид. Ввести все таки контрольный сокет, по нему буквально однобатный обмен: типа приняли 0x55 - вычитали сокет до конца, выкинули эти данные, обресетили state machine и начали все сначала. В ответ по контрольному сокету можно 0xАА кинуть - типа обресетился, готов.

За идею!

[zltigo]

Обалдеть.

[Evgeny_CD]

Обалдеть.

А можно узнать, от чего? Если я какое ламерство написал - поянилите, плиз! Все-таки, сокеты сохраняют границы пакетов или нет? Я в литературе пока информации о сохранении границ не нашел.

[psL]

Вообще-то для обеспечения прозрачности передаваемых данных существует такое дело как байтстаффинг: договариваются о некотором управляющем символе, присутствие которого означает, что следующий за ним символ - команда. Если следующий символ - также управляющий символ, значит эти два символа интерпретируются как один символ данных равный управляющему символу. Немного сумбурно написал, но смысл такой:
0x10 0x12 - управляющий символ 0x10, команда 0x12(смысл которой например начало или конец пакета)
0x10 0x10 - данные 0x10
В качестве управляющего символа естественно лучше всего брать наименее вероятный в потоке данных.
Собственно нечто подобное в SLIP и реализовано.

Ну так вот при перемещении фрагмента кадра в кольцевой буфер этот байтстаффинг и делается.
При этом кольцевой буфер является именно [b]кольцевым буфером символов[b], а не кольцевым буфером кадров/пакетов.

Для обработки пакетов при копировании из буфера сокетов в буфер символов создается управляющая структура типа

Код

typdef struct frame
{
...всякие полезности...

    size_t head_len;        // длина поля заголовка(при необходимости)
    char*  phead;            // указатель на заголовок
    
    size_t data_len;        // длина поля данных(при необходимости)
    char*  pdata;            // указатель на данные
    
...другие всякие полезности...

} frame;

которая ставится в очередь и после обрабатывается в фоновом потоке.

Удачи!

[zltigo]

Обалдеть.

А можно узнать, от чего? Если я какое ламерство написал - поянилите, плиз! Все-таки, сокеты сохраняют границы пакетов или нет? Я в литературе пока информации о сохранении границ не нашел.

1. Да я много написал. Потом оставил одно слово.

В общем Вам пора практикой заняться. И чем быстрее, тем лучше.
А чужие книги, статьи, идеи - относитесь к ним более критично. Написание книг это бизнес.
И другой, нежели проектирование, бизнес.

2. По конкретному вопросу о сохранении (если естественно не SOCK_STREAM )- сохраняют,
для этого и делалось. Отвечать за отсутствие ГРУБЕЙШИХ ошибок в многочисленных реализациях я естественно не могу, но СОХРАНЯЮТ.
3. Использование TCP уровня взамодействия в пределах одной машины перебор. TCP имеет смысл при работе именно черт знает через что (этому определению безхозный интернет полностью
соответствует ). Плата за "гарантированую доставку" _полная_ потеря реального времени и потеря произвольного (но порядка десятков килобайт) количества пакетов до получения хоть какого-то
намека на развал соединения. В принципе вышеописанное не является "родовым пятном", просто
реализации в 'больших системах' (линукс, вынь) давно плюют на обработку ошибок транспортного уровня и ограничиваются (в лучшем случае) только фиксацией факта для статистики. Производители
железок тоже пошли по этому (пусть с проблемами протоколы высокого уровня разбираются) пути.
Правда такая ситуация породила и рынок альтернативных стеков и самодельных надстроек
над UDP или RAW. Лично я пользуюсь для встроенных систем самообжитым IP стеком с обработкой
аппаратных ошибок, что при работе в _локальной_ сети с _правильным_ железом хабов/свичей
позволяет без потерь доставлять UDP датаграммы. При необходимости более жесткого
реального времени, большей простоты (со строны контроллера) и меньшей непредсказуемости конкретной реализации IP стека и драйверов на "больших" машинах - пользуюсь самодельным протоколом на фрейме IEEE 802.3 по мотивам IEEE 802.2. Со стороны "больших" реализуется как надстройка над RAW Socket.

[Evgeny_CD]

...В общем Вам пора практикой заняться. И чем быстрее, тем лучше.
А чужие книги, статьи, идеи - относитесь к ним более критично. Написание книг это бизнес.
И другой, нежели проектирование, бизнес...

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

Но я несколько опечалился. Неужели разные "BSD-Like" стеки так сильно отличаются друг от друга? Все-таки сохранять или не сохранять границы юзеровских пакетов - это фундаментальное отличие. Я думал в этой области все давно вылизано, и царит полнейшая гармония. Весь кайф испортился.

[zltigo]

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

Я НЕ ВСТРЕЧАЛ и ДУМАЮ НЕ ВСТРЕЧУ такого безобразия - это ФУНДАМЕНТ. Все мои замечания по этому поводу относятся только к тому что где-то кто-то что-то видел/слышал и по этой причине решил
добавить в механизм еще свою спичечку привязав ее веревочкой...
Для _высокоуровневых_ протоколов в массовых серьезных операционках - можете считать, что царит гармония. За поведение многочисленых "микроконтроллерных" стеков сделанных кем-то для использования в каких-то определеных условиях при использовании изделия в других РАЗНООБРАЗНЫХ условиях отвечать просто НЕВОЗМОЖНО.
Ну и еще замечание - если собираетесь базироваться на на *NIX ообразной открытой операционке для чего либо не являющегося настольной машиной с иксами - обратите свой взор в сторону FreeBSD.
Ее по крайней мере делает поименованый управляемый коллектив.

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

Это не Ваши знания :-( они разрознены и противоречивы местами. Дальше что? Монетку кидать?
На здравый смысл уповать? На книжку ссылаться? Только практика критерий истины.
И еще Ваш подход (это я базируясь на надбюдениях за другими темами) к делу поражает немалым размахом. Такая организация дела несомненно работает и по своему эффективна, но в БОЛЬШИХ
коллективах (ну начиная с полусотни разработчиков и прочего персонала на проект) с изрядным финансированием, для содержания оных. Это Ваш случай? Если нет, то все Ваши усилия на поддержание "установленного порядка" сожрут все ресурсы разработчиков.

[Evgeny_CD]

Ну и еще замечание - если собираетесь базироваться на на *NIX ообразной открытой операционке для чего либо не являющегося настольной машиной с иксами - обратите свой взор в сторону FreeBSD.
Ее по крайней мере делает поименованый управляемый коллектив.

Эта мысли меня уже посещала. Но стремно:
* спецов по BSD очень мало
* книжек тоже, хотя несколько книжек я уже утащил
* книжек по NetBSD вообще нет (я не нашел). По иее это самый что ни на есть embedded BSD
* хочется иметь ту же самую платфому на писюке и embedded девайсе. Хотя бы пока я учусь.

Потом, очень даже возможно, будут перепрыгивать на BSD.

Это не Ваши знания :-( они разрознены и противоречивы местами. Дальше что? Монетку кидать?
На здравый смысл уповать? На книжку ссылаться? Только практика критерий истины.
И еще Ваш подход (это я базируясь на надбюдениях за другими темами) к делу поражает немалым размахом. Такая организация дела несомненно работает и по своему эффективна, но в БОЛЬШИХ
коллективах (ну начиная с полусотни разработчиков и прочего персонала на проект) с изрядным финансированием, для содержания оных. Это Ваш случай? Если нет, то все Ваши усилия на поддержание "установленного порядка" сожрут все ресурсы разработчиков.

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

2. Замах большой, это так. И колектива 50 девелоперов (вместе с бюджетом) тоже нет. Но с годами я дозрел до практики downgrade. Т.е. когда задача осмысливается целиком, начиная с верхнего уровня. Потом я рисую схему сущностей проекта (листов 30 А4), и делаю безжалостную кастрацию всей красоты, оставив ГЛАВНОЕ, и "крючки" для навешивания всего остального.

Потом выдаю lite версию девелоперам, и постепенно это становится философией команды. И когда новички приходят - их есть чем учить.

В ходе длительных размышлений за последние полгода мне удалось нашупать контуры новой среды разработки. Там не так важен сокетный протокол, и даже embedded ось не так важна (а вот синтетически порт под Linux важен принципиально!), и важна именно идеология декомпозиции задачи и обеспечения связи между компонентами.

3. Дьявол таится в деталях. Я не сомневаюсь в этом! И проблем будет масса! Лично для меня важно понимать, что именно надо делать (иметь некое объектно-ориентированное мышление применительно к целевой задаче, когда важны методы , а вот конкретный "экземпляр класса" выстраивается по ситуации), а с самим деланием потихоньку разберемся. Мир не без добрых людей.

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

[zltigo]

Эта мысли меня уже посещала. Но стремно:
* спецов по BSD очень мало
* книжек тоже, хотя несколько книжек я уже утащил
* книжек по NetBSD вообще нет (я не нашел). По иее это самый что ни на есть embedded BSD
* хочется иметь ту же самую платфому на писюке и embedded девайсе. Хотя бы пока я учусь.

1. Ну по большому счету их под Линукс мало, если не считать спецов уровня "инсталляторов
Windows". Массовые программисты разницы ПРОСТО НЕ ПОЧУВСТВУЮТ. Ну разбираться в
железках/драйверочках (впрочем помнится с железом проблем к Вас не предвидится) в BSD
заметно приятнее.
2. Ну книжки... С простыми вопросами и без них разберетесь, а готового рецепта выхода из сложной
ситуации Вы в них не найдете - НЕ ДЛЯ ЭТОГО ИХ ПИШУТ. А исходники BSD много читабельнее,
нежели то болото в которое превратились многочиленные Линуксы.
3. А может просто возьмете "кувалду побольше" (помнится я уже намекал на SOM-144, например)
и получите без проблем с портированием (и сопровождением оного) почти одинаковые системы. Причем, если Вы полагаете, что если на десктопе и на какой-нибудь железке с ARM9 будет одна операционка по причине того, что там и там она спекулирует раскрученным словечком Линукс, то это совсем не так
:-(
Сколько там контроллеров с 'линуксом' в год предполагается выбрасывать на рынок?

[Evgeny_CD]

1. Ну по большому счету их под Линукс мало, если не считать спецов уровня "инсталляторов
Windows". Массовые программисты разницы ПРОСТО НЕ ПОЧУВСТВУЮТ. Ну разбираться в
железках/драйверочках (впрочем помнится с железом проблем к Вас не предвидится) в BSD
заметно приятнее.
2. Ну книжки... С простыми вопросами и без них разберетесь, а готового рецепта выхода из сложной
ситуации Вы в них не найдете - НЕ ДЛЯ ЭТОГО ИХ ПИШУТ. А исходники BSD много читабельнее,
нежели то болото в которое превратились многочиленные Линуксы.
3. А может просто возьмете "кувалду побольше" (помнится я уже намекал на SOM-144, например)
и получите без проблем с портированием (и сопровождением оного) почти одинаковые системы. Причем, если Вы полагаете, что если на десктопе и на какой-нибудь железке с ARM9 будет одна операционка по причине того, что там и там она спекулирует раскрученным словечком Линукс, то это совсем не так
:-(
Сколько там контроллеров с 'линуксом' в год предполагается выбрасывать на рынок?

Конечно, оси на дектопе и контроллере будет разные. Но, если у них одинаковые версии ядра, то базовые интерфейсы, по идее, должны совпадать. Я собственно, на это и надеюсь.

SOM-144 - привлекательная вещь, я про них очень хорошо помню, и цены не очень безумные. Но я пока на нашел их Industrial, и, боюсь, цены там как раз будут неразумные.

Для прототипов, где мне будут нужны x86, буду использовать это
http://www.icop.com.tw/products_category.asp?CategoryID=2

По моим оценками Intel PXA270 600 Мгц мне должно хватить на ближайщие проекты на несколько лет вперед. Но хочется иметь позможность "спуска вниз", посему попробую все-таки целевой осью сделать eCos. Собственно, будет использован аналог SOM-144 от
http://www.toradex.com/e/Products_Colibri_..._Pentium_M.html

Контроллеров будет от 100 до 1к в год - как дело пойдет.

Ядро по исходникам изучать пока не готов

[Harbour]

Я так и не понял - процессы на одной машине ? В смысле нафига IPC заворачивать ?

1. За тем, что процессы изолированы во многих OC.
2. IPC для этого в OC и создаются, причем с учетом минимизации побочных эффектов.
3. Ну а в предложенной (к делу не относящейся реализации) рассчитывать на то, что DEADBEEF не встретится, и синхронизироваться ценой потери нескольких фреймов, конечно можно....., но радиолюбительство. Простейший надежный вариант формирования фрейма в байтовом потоке, например, в SLIP протоколе.

1-2 Тут есть много вариантов.
3. Синхронизация происходит ценой потери _одного_ неполного, на момент подключения к каналу, фрейма.

Сообщение отредактировал Harbour - Jan 16 2006, 09:39

[zltigo]

3. Синхронизация происходит ценой потери _одного_ неполного, на момент подключения к каналу, фрейма.

Это если Вы всегда, постоянно ищите помянутое 4x байтовое магическое значение и тем самым
начисто исключаете его наличие в потоке для других целей. Но мне помнится там у Вас еще и размер
поминался? Из чего я сделал вывод, что внутри фрейма указанного размера магическое значение
НЕ ищется.. А иначе зачем размер еше гонять?

Считаем:
1. Потеряли байтик - потеряли первый фрейм
2. Не нашли в ожидаемом месте магическое значение - начинаем искать - теряем второй фрейм
3. Встретилось нештатное магическое значение - продолжаем терять...

Естественно, ценой хранения предыдущего фрейма можно выкрутиться с п.2, но цена выкрутиться
будет еще и всплеск затрат времени в ранее гладком алгоритме (а байтики то об этом не знают
и продолжают идти..., что в некоторых случаях (речь не про сокеты) может потребовать еще и буфера для сырого потока). В случае c байт/бит стаффингом всегда имеем простой алгоритм с абсолютно предсказуемыми максимальными затратами времени на выделение фрейма и отсутствие необходимости
в дополнительных буферах для запоминания чего-либо на случай проблем. Может оказаться немаловажным и тот факт, что имеем ВСЕГДА одинаково БЕЗ ИСКЛЮЧЕНИЙ работающий алгоритм, а
в случае с волшебными словами еще придется писать и тестировать ветки поведения
при ошибках. Это конечно не "бином Ньютона", но ошибиться можно :-( а оно это надо?

[zltigo]

SOM-144 - привлекательная вещь, я про них очень хорошо помню, и цены не очень безумные. Но я пока на нашел их Industrial, и, боюсь, цены там как раз будут неразумные.

Для прототипов, где мне будут нужны x86, буду использовать это
http://www.icop.com.tw/products_category.asp?CategoryID=2

Контроллеров будет от 100 до 1к в год - как дело пойдет.

Ядро по исходникам изучать пока не готов

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

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

Ядро по исходникам изучать пока не готов

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

[Evgeny_CD]

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

-40 град С.

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

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

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

[zltigo]

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

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

[Harbour]

3. Синхронизация происходит ценой потери _одного_ неполного, на момент подключения к каналу, фрейма.

Это если Вы всегда, постоянно ищите помянутое 4x байтовое магическое значение и тем самым
начисто исключаете его наличие в потоке для других целей. Но мне помнится там у Вас еще и размер
поминался? Из чего я сделал вывод, что внутри фрейма указанного размера магическое значение
НЕ ищется.. А иначе зачем размер еше гонять?

Считаем:
1. Потеряли байтик - потеряли первый фрейм
2. Не нашли в ожидаемом месте магическое значение - начинаем искать - теряем второй фрейм
3. Встретилось нештатное магическое значение - продолжаем терять...

Естественно, ценой хранения предыдущего фрейма можно выкрутиться с п.2, но цена выкрутиться
будет еще и всплеск затрат времени в ранее гладком алгоритме (а байтики то об этом не знают
и продолжают идти..., что в некоторых случаях (речь не про сокеты) может потребовать еще и буфера для сырого потока). В случае c байт/бит стаффингом всегда имеем простой алгоритм с абсолютно предсказуемыми максимальными затратами времени на выделение фрейма и отсутствие необходимости
в дополнительных буферах для запоминания чего-либо на случай проблем. Может оказаться немаловажным и тот факт, что имеем ВСЕГДА одинаково БЕЗ ИСКЛЮЧЕНИЙ работающий алгоритм, а
в случае с волшебными словами еще придется писать и тестировать ветки поведения
при ошибках. Это конечно не "бином Ньютона", но ошибиться можно :-( а оно это надо?

Поиск маджика происходит в _остутствии_ синронизации, потом только проверка, то что описано у Вас это просто бездарная реализация, человеческий алгоритм приблизительно таков - реализуем 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 неполного пакета - устойчивость приема, в худшем случае (когда поток из одних маджиков например) определяется только качеством ф-ции црц

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

[zltigo]

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

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

[Harbour]

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

[zltigo]

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

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

[Evgeny_CD]

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

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

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

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

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

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

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

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

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

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

[Harbour]

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

[Evgeny_CD]

...Даже такой отторможенный арм как 920 должон легко взять планку в 20-50 кгц, см. adeos/xenomai latency test/examples...

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

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

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

[Konst_777]

Vikladivayu knizku na /upload/doc/Unix_Linux_books :

Interprocess Communications in Linux®: The Nooks & Crannies
By John Shapley Gray

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


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

[zaratustra]

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

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

[Evgeny_CD]

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

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

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

[zaratustra]

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

[Evgeny_CD]

А вы не пробовали поискать девкиты работающие под 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ГГц процессора хватит для этого?" я просто принципиально не буду.

[zaratustra]

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

[Evgeny_CD]

...Реалтайм (или близкие) синхронизации в qnx на мой взгляд выполнить удобнее. Спорить конечно не имеет смысла, в этом вы тоже правы...

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

[zaratustra]

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

[Evgeny_CD]

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

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

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

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

[zaratustra]

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

[Evgeny_CD]

....В любом случае желаю вам успехов...

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

[defunct]

Я прощу прощения если не в тему, но
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.

[Evgeny_CD]

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

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

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

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

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

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

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

[defunct]

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

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

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

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

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

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

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

[Evgeny_CD]

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

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

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

[defunct]

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

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

[Evgeny_CD]

...По поводу устройства на 87C51 - есть поговорка "Пока работает - не чини" ...

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