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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Hi All !

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

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

Проблема в том, что на 100% пока не видно, что еще за функцию нужно будет
прикрутить к уже известным.

Вот сижу и думаю: взять один процессор, в который наверняка все влезет с
запасом (TMS или MB90 нехудой какой-нибудь) или разделить задачу на отдельные
модули, как-то общающиеся между собой?
Плюс одного процессора: не нужно думать о физическом взаимодействии модулей,
всем все доступно через глобальные переменные.
Hо боязно, вдруг какая-то прожорливая задача (скажем, ЦОС) затормозит
выполнение всех остальных? А хочется реалтаймовости.

Если делать отдельными модульками, то беру под каждый модуль подходящий
процессор и реализую нужную мне функцию, не думая об остальных.
Плюс в том, что результат предсказуем, можно посчитать стоимость реализации
каждой функции, и может быть не нужно переползать на другие семейства
процессоров. Да и добавление новых возможностей не затрагивает другие модули.

Минусов тоже хватает: организация шины для обмена данными, например. Hу
конструктивно-производственно много программируемых микросхем всегда хуже, чем
одна, хоть и большая. Да и в цене выигрыша думаю не будет :)

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

Или плюнуть на все эти шины, взять что-то за 20$ и сделать Все-В-Одном?
Hаверное, это может быть что-то на 100 МИПСов 16-битное, и чтобы от БПФ все эти
мипсы не съеживались. ?
И RTOS там уже есть неплохой...?

А что взять? Из доступного в Москве и все-таки надежного, проверенного хотя бы
парой лет эксплуатации?
Ех, еще бы чтобы переползание было не очень болезненное (ну, скажем чтобы
программатор спаять, ПО скопировать, камень купить :).

И еще. Чтобы Си для этого монстрика найти можно было.

Hу и конечно неплохо, если модельный ряд состоит не из одной модели. То есть
взял пузатый, а в результате программа влезла и в предыдущий. Мелочь, а
приятно.


В-общем интересно мнение. Все выслушаю и обмозгую.
PS Сам склоняюсь к однопроцессорному варианту. Hо пока не знаю, что выбрать.
Цена не так важна, как доставабельность самого камня и сложность подготовки
инфраструктуры для работы с ним.


         WBRgrds
                   Ruslan


Re: Выбор элементной базы
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



Re: Выбор элементной базы
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 должны и в одиночку потянуть.

10-Channel, 1 MSPS, 12-Bit ADC
Two 12-Bit Rail-to-Rail Voltage Output DACs
Precision Voltage Reference (10 ppm)
45MIPS ARM7TDMI MCU Core
62K-Byte In-Circuit Re-Programmable Flash Program/Data Memory
8K-Byte SRAM
Serial Interface Ports (UART, SPI, and dual I2C)
3-Phase PWM
Comparator, Programmable Logic Array (PLA), Power Supply Monitor (PSM),
Power-On Reset (POR), Flexible Core Clocking Options, Flexible Power-Down
Modes
In-System Serial Programming
In-System JTAG Emulation

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

Посмотри www.analog.com/microconverter/arm7

/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



Re: Выбор элементной базы
Quoted text here. Click to load it

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

Аркадий

Re: Выбор элементной базы
12-Jul-04 20:14 Arcady Schekochikhin wrote to Ruslan Mohniuc:

Quoted text here. Click to load it
1ms
Quoted text here. Click to load it

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,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Site Timeline