дано:
Железяка с процессором LPC2366
16 внешних устройств с I2C-подобным протоколом. На каждое устройство - по своей шине.
Кучка светодиодов.

LPC-шка обменивается с внешними устройствами (протокол реализован софтово, дрыганьем GPIO), зажигает для пользователя нужный светодиод.

Проблема в следующем: на данный момент обмен осуществляется последовательно, и идёт достаточно долго. Хочется ускорить процесс раз этак в 5

Решение, скорее всего - операционка, 16 потоков обмена с устройствами и один - мигания лампочками.

Алгоритм обмена - дернули ногой, подождали 10 мкс (можно больше, т.к. у нас мастер), опять дернули ногой... Ожидание ответа от внешнего устройства - 1..5 мс. Соответственно, есть периоды, когда возможно отдать управление (меня устроит и вытесняющая многозадачность? она ведь проще?).


С операционными системами никогда не работал, поэтому требуется что-то очень простое в работе и освоении. Желательно наличие порта под Keil и LPC.
Также желательно чистое Си - на Си++ ничего серьезного я не делал.
Ресурсоемкость... Побыстрей да поменьше, конечно, хочется, но сейчас используется 10% камня.

Ну Вы, блин, даете. Так и напишите многопоточный бинарный модуль своими силами, зачем операционка? Но вообще скачайте книжку по scmRTOS - как раз по Вашей теме...

Это RL-RTX. Практически безальтернативно.
Время изучения - 8 часов включая всю теорию по RTOS
Время для запуска на своей плате - 8 часов, включая осознание важности правильного выбора глубины стеков и что с операционкой надо делиться ресурсами.
Во всяком случае такие показатели в разное время дали несколько наших программистов решивших использовать RTOS.

Итого гораздо быстрее чем написание собственного планировщика каким бы примитивным он ни был.

Фигасе решение! Первый раз слышу, чтобы операционка ускоряла процессы. Вообще-то любая операционка замедляет работу прикладных программ, так как сама выполняется часть времени.

Итак, по пунктам.

Драйвер сразу 16 интерфейсов... Ну, я думал на эту тему. Вроде б получается страшный монстр. Запись-то ещё ничего, а вот как ЭТО будет читать...

Книжку про scmRTOS листаю. Интересно, но пока не всё понятно.

RTX-RL. Почему безальтернативно? Ну кейл, ну и что?
Хотя... пришлите, пожалуйста, на мой-ник@gmail.com. Интересно.

Данные процессы вполне можно ускорить. Ибо большую часть времени мы стоим и ждём.

ага, а у поклоников "простых" решений любимейшее занятие использовать задержки, пожирающие львиную долю времени.

Ну здравствуйте - а зачем тогда придумали многопоточность? Дабы эффективно уменьшить простои процессора. Не сама операционка, конечно, ускоряет работу приложения а его(приложения) правильное проектирование. Ну и возможно это, конечно, не всегда.

Опытный разработчик знает - лучше отдать часть времени проца, чем отдать часть своего времени.

Золотые слова. А кто же мешает вам правильно спроектировать свое приложение? Оно не настолько сложное, чтобы ставить операционку. Правильное сочетание работы в прерываниях и простенького фонового диспетчера решит все проблемы.

Многопоточность нужна в универсальных коспьютерах - там заранее неизвестно, какие на нем будут запускаться задачи, поэтому приходится делать универсальное средство для разделения времени между ними. И то - Windows 3.1 имела невытесняющую многозадачность, то есть ОС не могла по своей инициативе переключиться на другую задачу, только если задача к ней обратилась. В контроллерах же все задачи заранее известны, сделай простенький диспетчер который будет вызывать их по кругу, а их спроектировать соответственно, чтобы они не занимали время если им нечего делать.

А при реальной многопоточности ОС для каждой задачи выделяет стек, при каждом переключении сохраняет всё ее состояние (даже неиспользуемые регистры), разделяет внешние устройства, и т.д... Представь, сколько на это уйдет времени.

..собственно мы просто друг-друга недопоняли. Я о том же только впрофиль.

У Вас один процесс с 16-ю наборами локальных параметров/стеков и переопределяемыми точками входа.

Где о таком почитать можно?