Добрый день, коллеги!

Скачал последнюю версию порта для LPC2xxx. К сожалению, на LPC2478 код не запускается, пришлось маленько пофиксить инициализацию периферии, немного ассемблера в одном из файлов ОСи. Вроде дело пошло. Задачи запускаются. Я не уверен в надежности и стабильности, пока тестирую.

Пока первый вопрос.

Как я понял, планировщик может вызываться из прерывания системного таймера и по софтовому прерыванию. Это задается опцией scmRTOS_CONTEXT_SWITCH_SCHEME. Мне кажется, что для LPC2478 софтовое прерывание не нужно. Достаточно таймерного. Я правильно понимаю? Т.е. можно использовать scmRTOS_CONTEXT_SWITCH_SCHEME = 0?

Гм... скажем так, я, прочитав документацию, так и не понял, чем отличаются два метода вызова планировщика, и какой когда использовать?

Спасибо!

Неправильно поняли . Планировщик вызывается там, где возникла необходимость передать управление другой задаче. Это может быть и в основном коде потока, и в прерывании периферии и в прерывании системного таймера. А вот методов вызова перепланировки предусмотрено два: scmRTOS_CONTEXT_SWITCH_SCHEME = 0 - простой вызов функции, которая будет складывать на стек все регистры, даже если она вызвана на выходе из прерывания и часть регистров уже сохранены обработчиком, и scmRTOS_CONTEXT_SWITCH_SCHEME = 1 - для переключения контекста вызывается отдельное прерывание, обработчик которого написан на асме и это гарантирует, что ни один регистр не будет сохранен дважды. Второй вариант, как видно, менее требователен к стеку. Другое его преимущество - если приоритет этого прерывания сделать самым низким, то при возникновении нескольких прерываний переключение контекста будет выполнено один раз после выхода из последнего обработчика, а не на выходе из каждого. Поэтому такой метод и рекомендуется использовать. "Нулевой" метод используется лишь там, где нет возможности использовать "первый" - например, в ADuC702x, где нет контроллера прерываний и невозможно сгенерить прерывание программно.

Спасибо за остоятельный ответ!
К сожалению, я до сих пор использовал 3-ю версию, и то на AVR. Не все нюансы знаю) Буду разбираться.

У меня уже мечта добавить к этой оси виртуальные таймеры ( это мне точно нужно ).

Спасибо большое за ее создание! Выбирал для арм долго между FreeRTOS, TNKernel и родной, с 2006 года знакомой, scmRTOS. Выбор пал в пользу последней из за того, что она вкорне написана на Си++, который мне более удобен)

А что они такого вам дадут?

Мне они нужны для управления автоматикой. Скажем, каждый день в 9 утра открывать дверь, по понедельникам в 17-00 проветривать помещение)

Думаю, что вклиненные в ядро и сервисы ОС, они будут работать наиболее производительно. Да и потренируюсь маленько. С осями я на ВЫ.

То есть они должны быть привязаны к календарю, времени в часах-минутах?

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

Жаль, конечно, что в этой ОСи нельзя динамически создавать/удалять задачи, но я либо обойдусь текущим функционалом, либо попробую что-нить припилить)

А аппаратный таймер - это что физически?


Смотря как часто опрашивать. Я не думаю что ваша задача управления автоматикой выглядит так:
в 9:00 выставить в порт заданный уровень, время реакции - 3 мкс.

В LPC2478 есть RTC.


Да, пока поллингом и делаю. На другой платформе. Опрашиваю раз в 0.5 сек.

А может быть действительно - лишнее это (виртуальные таймеры). Буду думать.

Но вот динамическое создание/удаление процессов было бы полезно: сработал таймер, запустили процесс, выдали в сеть команду, удалили процесс. Поскольку этот процесс может занимать иногда ощутимое конечное время (сеть одна, устройств много, много кто хочет с ними пообщаться, приходится ждать), то чтобы не задерживать работу системы, он бы мог работать отдельно.

Хотя здесь может помочь буферизация в очереди.

В общем будем думать. Просто лапки чешутся что-нить "поковырять".

Впрочем, это уже для другой темы разговор.

И что можно разрешить прерывание в заданное время (часы-минуты-дата)?



Видимо динамическое создание/удаление процессов вызовет падение скоростных характеристик Оси.
Но если таких процессов немного (которые создавать-удалять хотите), то что мешает их сделать обычными процессами с низким приоритетом, ожидающими своего события и начинающими работать, например от сигнала пришедшего от RTC_Handler?

Да, на одну дату можно. Но мне нужно больльше. Например 32 таймера. Кажется, что поллингом проще будет.

Да, можно и так!

Спасибо, хорошее обсуждение получилось, мои мысли упорядочились)

Почему бы не создать сортированный список времен срабатывания таймеров, как сделано в FreeRTOS? Срабатывает будильник, отсылает сообщение, берет из списка следующее время, программирует его в будильник RTC и т.д.

Интересная мысль! Гляну, как это там реализовано. Спасибо!

В общем остановился на scmRTOS_CONTEXT_SWITCH_SCHEME = 0. Так проще пока для меня. ОСь стабильно работает.

Ну вот и следующий вопрос. Хочу сделать оговорку, он, конечно, мало относится к этой оси, но все же.

Хочу прикрутить TCP/IP стек. В настоящее время мое внимание сосредоточено на lwIP и TCP/IP стек от Юрия Темкина (www.tnkernel.com).

Не могу определится с окончательным выборомом. Что от стека нужно:
1. ICMP.
2. TCP.
3. UDP.
4. DHCP.

На базе стека планируется использовать web server (возможно понадобится ftp server, telnet server).

Сосбственно сам вопрос: что лучше - взять и прикрутить lwIP, либо TCP/IP tnkernel? С одной стороны есть примеры интеграции обоих стеков в оси (для первого это FreeRTOS, для второго - сама TNkernel). Но все же. Что, согласно идеологии scmRTOS, для нее больше подойдет в качестве сетевого стека?

Спасибо!