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

По моему разумению, если у меня configTICK_RATE_HZ равен 1000 (то есть планировщик крутится с периодом 1 миллисекунда), то vTaskDelay() и vTaskDelayUntil() у меня могут работать не быстрее одной миллисекунды.
А мне надо задержки в микросекундах (для работы с iButton, да и не только).
Поиск по словам FreeRTOS, delay, us привели только к http://www.google.ru/codesearch/p?hl=ru#YO...os%20delay%20us (в районе 700-ой строки), но использовать NOP в ОСРВ как-то не кошерно. В голове крутится мысль, что надо просто запустить свободный таймер и по нему отсчитывать задержки. Смущает только то, что гугль на подобное решение в связке с FreeRTOS не направляет - толи никто не озадачивается таким вопросом, толи он для всех слишком очевиден.
P.S. речь идет о LPC2388.

Можно подкрутить configTICK_RATE_HZ. Мне удобнее было сделать 6000 для проекта. Можно сделать еще больше. Но предел всё же есть )

В том-то и дело, что предел есть, мне удалось только в 10 раз уменьшить configTICK_RATE_HZ, дальше уже начинаются ошибки блокировки (BlockTime).

У вас 4 UART. Выделите один для iButton, и неободимости в задержках для iButoon уже нету
У меня UART0 используется для программирования, отладки и 1wire.
Расскажите для чего еще задержки нужны?

А поподробней можно? Вроде, где-то что-то перед глазами мелькало про совмещение УАРТа с iButton, буду рад, если ткнете носом, но текущей проблемы это не решит - железо уже реализовано, да и кроме iButton-а есть еще подключенные на разные ноги датчики температуры, на все уартов не хватит.

Я обошелся одним уартом на датчики и iButton сразу. Очень удобно.
Вот апноут от Maxim с описанием. Никаких граблей.
Самым сложным было измерение температуры на датчиках с оборваным питанием - они как-бы питаются от шины (VCC к GND не подключен), но сбрасываются при измерении...

За наводку спасибо, буду читать. Но сути проблемы это не меняет - у меня есть устройство, в котором надо зажигать светодиод на 1-10 микросекунд, сейчас я это выдерживаю просто циклами, но вопрос-то и был - как правильнее это организовать во FreeRTOS?

ИМХО нужно использовать таймер... Потому что сама FreeRTOS тут уже ничем не поможет.

Задержки таких порядков делаются либо аппаратно с использованием соответствущих интерфейсов (UART, таймер с compare модулем и т.п.), либо программно пустым циклом. Причем на современных контроллерах рассчитать точную программную задержку достаточно сложно, поскольку будет она зависеть от работы конвейера, настроки акселератора памяти (МАМ для LPC). Тут будет лучше завести один таймер, чтобы он тикал аппаратно, и поллить регистр его счетчика.
Учитывайте, что если вы хотите сделать задерку порядка единиц микросекунд через сервис ОС, то ОС на это время будет передавать управление другой задаче. Но только накладные расходы по переключению контекста у вас будут соизмеримы или больше времени задержки, которую вы хотите обеспечить. Для uCOS переключение контекста на LPC с тактовой ядра 60МГц и включенным полностью МАМ имеет порядок 10 мкс. У вас же на ожидание задержки ОС будет как минимум 2 переключения контекста - туда и обратно, да еще учтите накладные расходы по обслуживанию таймера ОС, где будут обрабатываться таймауты всех задач, работающих в данный момент.
Поэтому - при проектировании устройства распределяйте аппаратные функции периферии так, чтобы на нужных выводах у вас можно было аппаратно производить генерацию импульсов малой длительности.
Если у вас это уже выведено на GPIO - делайте это программно. Но тут есть одно "но". Если вам нужно сделать задержку программно "не менее чем", то тут все достаточно не сложно, просто делаете пустой цикл. Если же вам нужно делать точную временную задержки - то ее нужно делать в критической секции ОС. Для 1-Wire полностью программная реализация на программных задержках будет неэффективна. Будете в одной задаче постоянно торчать, а другие блокировать. Реализуйте 1-Wire c помощью UART как вам уже выше сказали, либо на capture - compare модулях таймера.

Еще, кстати, есть преобразователи интерфейсов из I2C в 1Wire.

Лишняя трата денег, имхо.

я для 1wire с freertos реализовывал не сложный конечный автомат на прерывании таймера, который все необходимые задержки и выдерживал. В конце работы результат складывал в очередь которую уже обрабатывал "штатный" поток самой ос.

З.Ы. спасибо HARMHARM за UART для 1Wire.