Подскажите пожалуйста как лучше решить проблему средствами Dsp/Bios.
Создан Task, отвечающий за прием данных из сети. Прием UDP пакетов.
Есть подпрограмма декодера для преобразования полученных данных.
Создан Task вывода данных - отображения на экране.
Проц: TMS320DM6437
Попробовал прием, обработку, вывод сделать в одном потоке, но получается, что довольно часто теряются данные при приеме.
Вывод разделить прием пакетов в отдельном потоке, обработку и вывод в другом.
Какой механизм DSP/BIOS лучше использовать для передачи данных от одного потока к другому?
С DSP/BIOS серьезно не работал, посмотрел примеры, но под эту задачу, мне кажется, что ничего особенно не подходит.
Если не жалко поделитесь ссылкой, примером кода.
Полная версия этой страницы: DSP/BIOS
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
Смотрите в сторону объектов MBX - "почтовый ящик" и SEM - "семафор". MBX содержит в себе семафор и очередь данных.
Работают с этим так:
Одна задача вызывает MBX_post, а другая - MBX_pend() с параметром таймаута. Если таймаут SYS_FOREVER, то один поток будет бесконечно ждать, пока другой не вызовет MBX_post() (не положит в его маилбокс данные).
SEM - то же что и MBX, только передачи данных нет. Для Вашей задачи ИМХО лучше MBX использовать.
Если создаётся задел на будущее - то лучше обернуть приёмник UDP пакетов и декодирование в CELL объекты RF5 (reference framework). Тогда можно использовать SCOM объекты. Это работа затратная по времени, требует чёткой организации работы с памятью, но пользоваться потом вроде как удобнее.
Работают с этим так:
Одна задача вызывает MBX_post, а другая - MBX_pend() с параметром таймаута. Если таймаут SYS_FOREVER, то один поток будет бесконечно ждать, пока другой не вызовет MBX_post() (не положит в его маилбокс данные).
SEM - то же что и MBX, только передачи данных нет. Для Вашей задачи ИМХО лучше MBX использовать.
Если создаётся задел на будущее - то лучше обернуть приёмник UDP пакетов и декодирование в CELL объекты RF5 (reference framework). Тогда можно использовать SCOM объекты. Это работа затратная по времени, требует чёткой организации работы с памятью, но пользоваться потом вроде как удобнее.
Цитата(Vasiliy Rufitskiy @ Dec 6 2007, 17:05) 
Смотрите в сторону объектов MBX - "почтовый ящик" и SEM - "семафор". MBX содержит в себе семафор и очередь данных.
Работают с этим так:
Одна задача вызывает MBX_post, а другая - MBX_pend() с параметром таймаута. Если таймаут SYS_FOREVER, то один поток будет бесконечно ждать, пока другой не вызовет MBX_post() (не положит в его маилбокс данные).
SEM - то же что и MBX, только передачи данных нет. Для Вашей задачи ИМХО лучше MBX использовать.
Если создаётся задел на будущее - то лучше обернуть приёмник UDP пакетов и декодирование в CELL объекты RF5 (reference framework). Тогда можно использовать SCOM объекты. Это работа затратная по времени, требует чёткой организации работы с памятью, но пользоваться потом вроде как удобнее.
Работают с этим так:
Одна задача вызывает MBX_post, а другая - MBX_pend() с параметром таймаута. Если таймаут SYS_FOREVER, то один поток будет бесконечно ждать, пока другой не вызовет MBX_post() (не положит в его маилбокс данные).
SEM - то же что и MBX, только передачи данных нет. Для Вашей задачи ИМХО лучше MBX использовать.
Если создаётся задел на будущее - то лучше обернуть приёмник UDP пакетов и декодирование в CELL объекты RF5 (reference framework). Тогда можно использовать SCOM объекты. Это работа затратная по времени, требует чёткой организации работы с памятью, но пользоваться потом вроде как удобнее.
Спасибо. MBX попробовал. Работает.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.