Выбор элементной базы

Hello, Ruslan! You wrote to All on Tue, 06 Jul 2004 15:45:17 +0400:

RM> Вот над задачкой думаю. RM> Дано: есть кучка входных сигналов (аналоговых и дискретных). Поток RM> поступления данных- около 50 килобайт в секунду. [...]

Очевидно, в будущем ты столкнёшся с конфликтом вычисления/измерения. На "маленьком" процессоре не хватит производительности для вычислений, а у "большого" окажутся высокие накладные расходы на смену контекстов, т.е. обслуживание измерений станет слишком дорогим, а свой штатный в/в он будет стремиться осуществлять через ПДП. Мне кажется, что именно в таком ключе и нужно подходить к этой задаче. Кто-то "маленький" и шустрый обслуживает "кучку входных сигналов" и размещает результаты в общей (двухвходовой) памяти. Кто-то другой, хорошо умеющий молотить числа этим пользуется. В дальнейшем эту часть железа можно будет безболезнено перевести на другую, более подходящую архитектуру, распараллелить и т.д. Двухвходовость памяти обеспечить какой-нибудь ПЛМ-кой прозрачно для обоих сторон, её можно будет перепрошить, если у вычислителя вдруг поменяется интерфейс (вместо "ALE, -RD, -WR" появятся "-SYNC, R/W, ...").

RM> Hасчет внутренней межмодульной шины. Я на CAN смотрю. Есть RM> приоритетность, микроконтроллер имеет дело с уже принятым пакетом. RM> Hе нравится размер пакета (8байт), маловато, много накладных. RM> Вот думал над параллельной шиной (ну хоть бы 8-битной), но не RM> придумал, как обеспечить к ней множественный асинхронный доступ. RM> Скажем, к общему для всех модулей массиву RAM, но так, чтобы без RM> коллизий и с приоритетами. Hо арбитра не придумал :(

См. SCSI. Но цена готовых контроллеров/шинников (а возможно, и потребление терминаторов) тебе не понравятся, да и не нужна тебе _такая_ пропускная способность. Но идеи позаимствовать можно :-).

RM> Ех, еще бы чтобы переползание было не очень болезненное (ну, скажем RM> чтобы программатор спаять, ПО скопировать, камень купить :).

AVR в качестве контроллера в/в + МАХ3000/7000 - все обслуживаются одним и тем-же байт-бластером :-). Ну, а числодробилка... тут не знаю. Но если у него своей памяти на борту не будет, а будет внешняя флешка, то можно первую парочку обучить её программировать :-).

Alexander,Derazhne@adic,kiev,ua (replace commas with dots) Alexander Derazhne

Hi Alexander !

Совсем недавно 06 Jul 04 18:43, Alexander Derazhne писал к Ruslan Mohniuc:

RM>> Вот над задачкой думаю. RM>> Дано: есть кучка входных сигналов (аналоговых и дискретных). RM>> Поток поступления данных- около 50 килобайт в секунду. AD> [...]

AD> Очевидно, в будущем ты столкнёшся с конфликтом AD> вычисления/измерения. Hа "маленьком" процессоре не хватит AD> производительности для вычислений, а у "большого" окажутся высокие AD> накладные расходы на смену контекстов, т.е. обслуживание измерений AD> станет слишком дорогим, а свой штатный в/в он будет стремиться AD> осуществлять через ПДП. Мне кажется, что именно в таком ключе и нужно AD> подходить к этой задаче. Кто-то "маленький" и шустрый AD> обслуживает "кучку входных сигналов" и размещает результаты в общей AD> (двухвходовой) памяти. Кто-то другой, хорошо умеющий молотить числа AD> этим пользуется.

Угу, и такая идея есть. Hа входе для обслуживания АЦП ставлю ПЛМ, далее через двухпортовую память читаю из нее данные.

RM>> накладных. Вот думал над параллельной шиной (ну хоть бы RM>> 8-битной), но не придумал, как обеспечить к ней множественный RM>> асинхронный доступ. Скажем, к общему для всех модулей массиву RM>> RAM, но так, чтобы без коллизий и с приоритетами. Hо арбитра не RM>> придумал :(

AD> См. SCSI. Hо цена готовых контроллеров/шинников (а возможно, и AD> потребление терминаторов) тебе не понравятся, да и не нужна тебе AD> _такая_ пропускная способность. Hо идеи позаимствовать можно :-). Спасибо, гляну. Hо вряд ли буду применять. Подозреваю, что непросто там это.

RM>> Ех, еще бы чтобы переползание было не очень болезненное (ну, RM>> скажем чтобы программатор спаять, ПО скопировать, камень купить RM>> :). AD> AVR в качестве контроллера в/в + МАХ3000/7000 - все обслуживаются AD> одним и тем-же байт-бластером :-). У меня сейчас в случае нужды становится 1К30 плюс PIC. От твоего варианта отличается тем, что сам ПИК для ПЛМ-ки и прикидывается бластером :)

AD> Hу, а числодробилка... тут не знаю. Вот о выборе числодробилки я и думаю сейчас.

И вообще решил сделать подход с другой стороны. А именно, посчитать что же мне нужно-то считать. Сейчас медитирую над ДПФ-БПФ, пытаюсь разобраться что это такое и не смогу ли я в моем случае засунуть это в ПЛМ-ку (ну чайник я в ЦОСе, что тут сказать). Тогда вообще лафа: про ресурс остальных задач вроде бы устаканивается, что нужно будет шустрого- то в Альтеру суну. Hу, может это уже не любимая 1К30 будет, или она, но не одна :)

WBRgrds Ruslan

Wed Jul 07 2004 16:11, Ruslan Mohniuc wrote to Alexander Derazhne:

RM> Hi Alexander !

RM> Совсем недавно 06 Jul 04 18:43, Alexander Derazhne писал к Ruslan RM> Mohniuc:

RM>>> Вот над задачкой думаю. RM>>> Дано: есть кучка входных сигналов (аналоговых и дискретных). RM>>> Поток поступления данных- около 50 килобайт в секунду.

Я думаю новые процессоры от AD должны и в одиночку потянуть.

Цены обещают от $4.5 младшие модели идут в CSP корпусах

Посмотри

/Sam [samoutin(ат)hotbox.ru]

On 06/Jul/04 at 15:45 you write:

RM> Вот над задачкой думаю. RM> Дано: есть кучка входных сигналов (аналоговых и дискретных). RM> Поток поступления данных- около 50 килобайт в секунду. RM> И есть кучка функций-пользователей, которые используют эти RM> входные данные.

а чем не устраивает PC104 и полноценная RTOS ?

Hi Dmitry !

Совсем недавно 08 Jul 04 22:33, Dmitry Ponyatov писал к Ruslan Mohniuc:

RM>> Вот над задачкой думаю. RM>> Дано: есть кучка входных сигналов (аналоговых и дискретных). RM>> Поток поступления данных- около 50 килобайт в секунду. RM>> И есть кучка функций-пользователей, которые используют эти RM>> входные данные.

DP> а чем не устраивает PC104 и полноценная RTOS ? В смысле плата АЦП, а все остальное RTOS на x86? Я об этом думал. Посоветовался со специалистами. Мне сказали, что довально непредсказуемо решение задачи настолько реального времени (у меня там еще есть времена реакции порядка 1 ms) с помощью QNX. То есть такое да, делается, но по дороге встречается масса грабель, о чем и читали в соответствующих форумах. Я поверил на слово. :) Или у тебя есть положительный опыт решения задач с временем реакции порядка 1ms на базе x86 под управлением какой-то RTOS?

WBRgrds Ruslan

Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ) правильно спроектированной ОС (не очень понятно, относится ли к таким винда, но даже линух, не говоря о БСД - относится). Главное - чтобы не было длинных блокировок прерывания в коде. Совершенно уже другой вопрос - а какого собственно уровня должна быть эта реакция? Если цель твоя - прикрепить перывание к процессу (!) и получить процесс реагирующий за менее 1мс - вот тут опаньки, но это ведь не всегда нужно. Часто можно все в ядре обрабатывать. А собственно х86 вполне себе имеет время реакции 1мс даже и без прерывания (в смысле прерывания от объекта - быстрое прерывание от таймера таки нужно).

Аркадий

Hi Arcady !

Совсем недавно 13 Jul 04 00:14, Arcady Schekochikhin писал к Ruslan Mohniuc:

AS> Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ) AS> правильно спроектированной ОС (не очень понятно, относится ли к таким AS> винда, но даже линух, не говоря о БСД - относится). Главное - чтобы не AS> было длинных блокировок прерывания в коде. Совершенно уже другой AS> вопрос - а какого собственно уровня должна быть эта реакция? Если цель AS> твоя - прикрепить перывание к процессу (!) и получить процесс AS> реагирующий за менее 1мс - вот тут опаньки, но это ведь не всегда AS> нужно.

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

WBRgrds Ruslan

AS> Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ) правильно AS> спроектированной ОС (не очень понятно, относится ли к таким винда, но Мнэээ... W2K SP3 RS232, 115200 Пакеты в рамке SLIP. Работа через WinAPI. Байт SLIP_END (0xC0) объявлен как event-character. Поток приёма спит по ожиданию event, спрашивает у винды сколько там у неё в буфере байтов, выгребает все, разбирая byte-stuffing, формирует внутреннюю структуру пакета. Видит, что это пришло подтверждение на предыдущий переданный, формирует следующий пакет и отправляет его, опять засыпает. Запущено НЕ под администратором, приоритеты задачи/потоков не задирались.

По осциллографу время от конца последнего (SLIP_END) байта, посланного в PC до начала старт-бита следующего пакета из PC в устройство - около 200микросекунд, дрожание в пределах 20мкс. Одиночные вылеты в большие времена может и есть, глазом не видно. До переписывания с тупого "пусть ReadFile вернёт что там есть" на ожидание событий и время было гораздо больше, и вылеты на довольно много (10мс? 20мс? не помню) -- не редкость.

Правда, в качестве x86 AthlonXP 1700+ и W2K практически не нагружена (ну что-то там тащит flashget и аська висит, вот и всё). Но и никаких мер по повышению скорости реакции типа задирания приоритетов процессу/потоку не принималось.

wbr,