Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
- Ruslan Mohniuc
July 6, 2004, 11:45 am
Reply
Save
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
Вот над задачкой думаю.
Дано: есть кучка входных сигналов (аналоговых и дискретных). Поток поступления
данных- около 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
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
Совсем недавно 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]
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 ?
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
Совсем недавно 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: Выбор элементной базы
Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ) правильно
спроектированной ОС (не очень понятно, относится ли к таким винда, но даже линух,
не говоря о БСД - относится). Главное - чтобы не было длинных блокировок
прерывания в коде. Совершенно уже другой вопрос - а какого собственно уровня
должна быть эта реакция? Если цель твоя - прикрепить перывание к процессу (!)
и получить процесс реагирующий за менее 1мс - вот тут опаньки, но это ведь
не всегда нужно. Часто можно все в ядре обрабатывать. А собственно х86 вполне
себе имеет время реакции 1мс даже и без прерывания (в смысле прерывания от
объекта -
быстрое прерывание от таймера таки нужно).
Аркадий
Re: Выбор элементной базы
12-Jul-04 20:14 Arcady Schekochikhin wrote to Ruslan Mohniuc:
1ms
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,
1ms
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 */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Выбор элементной базы
Hi Arcady !
Совсем недавно 13 Jul 04 00:14, Arcady Schekochikhin писал к Ruslan Mohniuc:
>> Или у тебя есть положительный опыт решения задач с временем реакции
>> порядка 1ms на базе x86 под управлением какой-то RTOS?
AS> Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ)
AS> правильно спроектированной ОС (не очень понятно, относится ли к таким
AS> винда, но даже линух, не говоря о БСД - относится). Главное - чтобы не
AS> было длинных блокировок прерывания в коде. Совершенно уже другой
AS> вопрос - а какого собственно уровня должна быть эта реакция? Если цель
AS> твоя - прикрепить перывание к процессу (!) и получить процесс
AS> реагирующий за менее 1мс - вот тут опаньки, но это ведь не всегда
AS> нужно.
Угу, боюсь у меня те самые опаньки. В-общем, склоняюсь к своей плате-вставке,
которая жесткий реалтайм на себя возьмет, а на долю x86 останется все небыстрое
и вспомогательное (общение с внешним миром, вычитка из буферов FIFO
платы-вставки и сохранение подготовленных результатов, дополнительная
матобработка итд.)
Конечно, хотелось бы разрулить задачу так, чтобы обойтись рудневым-шиляевым по
оцифровке, а все остальное софтово, но это мечты, причем, подозреваю,
несбыточные.
WBRgrds
Ruslan
Совсем недавно 13 Jul 04 00:14, Arcady Schekochikhin писал к Ruslan Mohniuc:
>> Или у тебя есть положительный опыт решения задач с временем реакции
>> порядка 1ms на базе x86 под управлением какой-то RTOS?
AS> Время реакции 1мс совершенно легко достигается в любой (ЛЮБОЙ)
AS> правильно спроектированной ОС (не очень понятно, относится ли к таким
AS> винда, но даже линух, не говоря о БСД - относится). Главное - чтобы не
AS> было длинных блокировок прерывания в коде. Совершенно уже другой
AS> вопрос - а какого собственно уровня должна быть эта реакция? Если цель
AS> твоя - прикрепить перывание к процессу (!) и получить процесс
AS> реагирующий за менее 1мс - вот тут опаньки, но это ведь не всегда
AS> нужно.
Угу, боюсь у меня те самые опаньки. В-общем, склоняюсь к своей плате-вставке,
которая жесткий реалтайм на себя возьмет, а на долю x86 останется все небыстрое
и вспомогательное (общение с внешним миром, вычитка из буферов FIFO
платы-вставки и сохранение подготовленных результатов, дополнительная
матобработка итд.)
Конечно, хотелось бы разрулить задачу так, чтобы обойтись рудневым-шиляевым по
оцифровке, а все остальное софтово, но это мечты, причем, подозреваю,
несбыточные.
WBRgrds
Ruslan
Site Timeline
- » MontaVista PreviewKit
- — Next thread in » Microcontrollers (Russian)
-
- » mouser.com >>IC's Distributor
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » TLYp vs lgy
- — The site's Newest Thread. Posted in » Electronics (Polish)
-
- » Regulator ładowania aku 12V-12V / ogranicznik pr ądu
- — The site's Last Updated Thread. Posted in » Electronics (Polish)
-
XML Sitemap