[Shein 0]

Доброо времени суток.

Вопрос отчасти банальный, но все же...

 

Запускается проект на ARM7 AT91SAM7X___. Задача - специализированное устройство для передачи данных, прием данных по нескольким стыкам UART, USB, CAN, обработка и передача далее по линии связи.

 

Рассматривается вопрос применения RTX kernel от Keil'а. Кто имеет опыт работы с этой илидругими RTOS? какие впечатления? Подводные камни? Время на освоение?

 

Возможно есть системы более подходящие для подобной задачи?

Предполагаю, что сколько людей столько и мнений и все же...

 

Ранее подобные проекты делались полносью самостоятельно. Сейчас сроки поджимают, да и интересно даст ли применение RTOS упрощение реализации?

[Nixon 4]

Используйте RTX. Никаких проблем кроме необходимости понимания основ RTOS и грамотного проектирования нет. Хорошо документирована, имеет плагин отладки для Keil и примеры применения.

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

[Axel 1]

Рекомендую - на основе собственного опыта - TNKernel. Бесплатная, прозрачная, с открытыми исходниками. Имеющиеся примеры помогают быстро освоить. Подводные камни - только традиционные, типа инверсии приоритетов. Я доволен...

 

[prgjz 0]

Я тоже TNKernel предпочитаю из за свободных исходников, и нет неободимости с однм только Keil (как в случае RTX) дружить. Если память в кристале дорога то scmRTOS очень компактна.

[VslavX 0]

Рекомендую - на основе собственного опыта - TNKernel. Бесплатная, прозрачная, с открытыми исходниками. Имеющиеся примеры помогают быстро освоить. Подводные камни - только традиционные, типа инверсии приоритетов. Я доволен...

Дык, в TNKernel для мутексов реализован протокол наследования приорититов, который почти полностью проблему инверсии решает - один из плюсов этой системы.

 

[alman 0]

Запускается проект на ARM7 AT91SAM7X___. Задача - специализированное устройство для передачи данных, прием данных по нескольким стыкам UART, USB, CAN, обработка и передача далее по линии связи.

 

Рассматривается вопрос применения RTX kernel от Keil'а.

 

Кто имеет опыт работы с этой илидругими RTOS? какие впечатления? Подводные камни? Время на освоение?

Возможно есть системы более подходящие для подобной задачи?

 

Просто посмотрите в сторону микроядра L4 - http://l4hq.org/arch/arm/

 

На его основе можно построить всё что угодно, например, операционную систему - http://www.l4os.ru

 

 

 

[Shein 0]

Используйте RTX. Никаких проблем кроме необходимости понимания основ RTOS и грамотного проектирования нет. Хорошо документирована, имеет плагин отладки для Keil и примеры применения.

Время на освоение при наличии головы на плечах почти 0.

Собственно мне тоже показалось, при первом знакомстве, что сложного там ничего нет. Хотя это же и смутило, как-то не верится что все так просто и функционально. Вот и подумалось, вдруг там не все так красио как в документации.

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

Собственно я не так выразился. Имелось ввиду именно ускорение разработки.

[sergeeff 1]

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

[Shein 0]

Рекомендую - на основе собственного опыта - TNKernel. Бесплатная, прозрачная, с открытыми исходниками. Имеющиеся примеры помогают быстро освоить. Подводные камни - только традиционные, типа инверсии приоритетов. Я доволен...

Почитал, выглядит не плохо.

Такой, возможно глупый, вопрос: возможна ли отладка в TNKernel при использовании Keil+ULINK(JTAG)? RTX, насколько я понял, поддерживается отладчиком Keil достаточно хорошо, наглядно отображая состояние системы.

 

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

Пусть так. Надо же когда-то начинать :) Да и задача, по моему разумению, очень уж красиво ложится на многопоточную реализацию. Самому "изобретать велосипед" тоже вряд ли быстро получится.

[Сулейман 0]

Прошу прощения что влезаю, но тема кажется подходящая.

У меня такой вопрос, можно ли под какую-нибудь RTOS написать приложение изначально в проекте не присутствующее, но которое можно будет подгрузить, не переписывая при этом файлы системы. То есть аналог .exe в Windows.

[VslavX 0]

Прошу прощения что влезаю, но тема кажется подходящая.

У меня такой вопрос, можно ли под какую-нибудь RTOS написать приложение изначально в проекте не присутствующее, но которое можно будет подгрузить, не переписывая при этом файлы системы. То есть аналог .exe в Windows.

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

 

[AlexandrY 3]

Конечно - решаете вопрос динамического связывания (линковки) и ...

 

К чему воздух молотить? ;)

 

Короче нет маленьких и понятных RTOS с такой фичей.

Нужна виртуализация памяти, а это уже только в толстых осях.

[sasamy 9]

Короче нет маленьких и понятных RTOS с такой фичей.

Нужна виртуализация памяти, а это уже только в толстых осях.

 

http://prex.sourceforge.net/

 

Prex has the following features:

 

* Task & Thread Control: preemptive priority scheduling with 256 priority levels

* Memory Management: memory protection, virtual address mapping, shared memory, MMU or MMU-less configuration

* IPC: object name space, synchronous message passing between threads

* Exception: fault trapping, framework for POSIX signal emulation

* Synchronization: semaphores, condition variables, and mutexes with priority inheritance

* Timers: sleep timers, one-shot or periodic timers

* Interrupt: nested interrupt service routines, and prioritized interrupt service threads

* Device I/O: minimum synchronous I/O interface, DPC (Deferred Procedure Call)

* Security: task capability, pathname-based access control, I/O access permission.

* Real-time: low interrupt latency, high resolution timers and scheduling priority control

* Power Management: power policy, idle thread, DVS (Dynamic Voltage Scaling)

* Debugging Facility: event logging, kernel dump, GDB remote debug

* File Systems: multi-threaded, VFS framework, buffer cache, ramfs, fatfs, arfs, etc.

* POSIX Emulation: pid, fork, exec, file I/O, signal, pipe, tty, pthread, etc.

* Libc: C library fully optimized to generate a small executable file

* CmdBox: a small binary that includes tiny versions of many UNIX utilities.

* Networking: (plan) TCP/IP stack, BSD socket interface

 

Prex minimum hardware requirements are as follows:

 

* Processor: 32-bit Processor (x86, ARM, PowerPC)

* Memory: 256KB of RAM (Kernel < 25k bytes)

* Timer: programmable interval timer

 

Не такая уж и большая :)

[AlexandrY 3]

Не такая уж и большая :)

 

Да, для лохотрона много не надо. :cranky:

[SII 0]

К чему воздух молотить? ;)

 

Короче нет маленьких и понятных RTOS с такой фичей.

Нужна виртуализация памяти, а это уже только в толстых осях.

 

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