мнение насчет TNKernel v.2.4, что понравилось (+) и не понравилось (-) Опции

[Bender]

Хотелось бы высказать cвоё мнение насчет TNKernel v.2.4
(Касательно LPC22xx и Кейла)
В связи с тем, что у FreeRtos нет порта под RV и Кейл отказался от поддержки своего компилятора, пришлось делать выбор: или писать свой порт или посмотреть еще раз TNKernel(от более ранних версий отказался из-за отсутствия поддержки THUMB).
Итак, что понравилось (+) и не понравилось (-) в TNKernel v.2.4:

1. (-) По каким-то причинам не используется VIC, хотя добавить его ничего вроде не мешает. (проверил, работает)
2. (-) В примерах системное прерывание сидит на PWM0, ожидалось на каком нибудь из таймеров (поправил).
3. (-) Нет возможности запустить задачу в строго заданное время (нет аналога task_delay_until()).
4. (-) Раздельные acquire (lock, send...) и polling. Хотелось бы указывать нулевое время ожидания для поллинга.
5. (-) Нет мониторинга стека, надо самому писать.

6. (+++) Расширенный сервис (мютексы и события) по сравнению с FreeRtos
7. (+) Задание для RoundRobin времени выполнения до переключения.

Вот такое первое впечатление.

[viael]

Хотелось бы высказать cвоё мнение насчет TNKernel v.2.4
(Касательно LPC22xx и Кейла)
В связи с тем, что у FreeRtos нет порта под RV и Кейл отказался от поддержки своего компилятора, пришлось делать выбор: или писать свой порт или посмотреть еще раз TNKernel(от более ранних версий отказался из-за отсутствия поддержки THUMB).
Итак, что понравилось (+) и не понравилось (-) в TNKernel v.2.4:

1. (-) По каким-то причинам не используется VIC, хотя добавить его ничего вроде не мешает. (проверил, работает)
2. (-) В примерах системное прерывание сидит на PWM0, ожидалось на каком нибудь из таймеров (поправил).
3. (-) Нет возможности запустить задачу в строго заданное время (нет аналога task_delay_until()).
4. (-) Раздельные acquire (lock, send...) и polling. Хотелось бы указывать нулевое время ожидания для поллинга.
5. (-) Нет мониторинга стека, надо самому писать.

6. (+++) Расширенный сервис (мютексы и события) по сравнению с FreeRtos
7. (+) Задание для RoundRobin времени выполнения до переключения.

Вот такое первое впечатление.

Мне понравился больше чем FreeRtos.Внятно написан,полно сервисов,ничего не мешает поправить прерывания "под себя".Олично работает и в THUMB и в ARM.
Уже портировал под нее USB CDC for SAM7(из тогоже FreeRtos), вот теперь хочу TCP/IP пркрутить.

[DASM]

Минусы надуманы. КГ/АМ. С viael согласен.

[Bender]

Проставленные минусы - это не минусы TNKernel, а только то, что не понравилось при первом знакомстве.

Ладно,теперь задам вопросы.
Как узнать системное время?
Обработает ли TNKernel переполнение счетчика времени?
Как запустить задачу в строго заданное время?

[DASM]

Вы мне напоминаете курортную тетеньку, едущего по путевке от турфирмы. А экскурсии будут ? А кормить будут три раза в день ? Ручками все, ручками. Причем даже с нуля приведенные вопросы решаются минут за 10, мне бы было лень их даже задавать. К тому же - если нравится FreeRTOS - так флаг в руки, или мы должны убедить Вас в правильном её выборе ? Нет. Решайте сами. Вообще в той же Nucleus подобные задачи тоже требуют участия рук, а ось уже совсем недетская и совсем небесплатная.

[Bender]

2 DASM: Есть что по существу вопроса?

[DASM]

1. Перменную воткнуть. g_sys_time. И функцию её получения
2. Нет. Исходники же перед глазами.
3. Вопрос привычки - кто-то привык, а кому-то и не надо это вовсе. Непонятно кто мешает первым оператором в теле фции поставить tn_task_delay

[IgorKossak]

Вы мне напоминаете курортную тетеньку, едущего по путевке от турфирмы. А экскурсии будут ? ...

А мне Вам предупреждение вынести или Вы сами прекратите подобную практику общения?

[Bender]

Часть 2.
Получение данных из очереди.
Немного обсуждения здесь:
TNKernel
Получается что при получении данных из очереди мы: получаем линк на них, длина очереди при этом уменьшается, и ничто не мешает более приоритетному процессу/прерыванию затереть (в случае если они помещают данные в эту очередь) их до получения.
Это так? если так, то как с этим быть?
Или я надумал проблему?
(Версия ОС 2.4)

[Alex B._]

да где вы увидили выделение памяти для элементов очереди * размер элемента? Выделить нужно массив указателей на void*. Размер массива и будет глубиной очереди.

>> и ничто не мешает более приоритетному процессу/
>> прерыванию затереть (в случае если они помещают
>> данные в эту очередь) их до получения.

в очереди передаются не данные, а указатели!

Код

/* ЗАДАЧА А */
/* помещаем в очередь указатель на d, шедуллер отбирает управление у задачи, если сообщения уже ждет более приоритетная задача или очередь заполнилась  */
tn_queue_send(&dqu, &d, TN_WAIT_INFINITE);

/* ЗАДАЧА B */
/* Ждем сообщения из очереди. Планировщик передает управление этой задаче, если очередь не пустая */

void * zzz;
tn_queue_wait(&dqu, &zzz, TN_WAIT_INFINITE);

/* Теперь zzz указывает на переданное сообщение */

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

[Bender]

"Идиот." - "Согласен" (с)
Да, ступил я насчет копирования данных в очередь.
Пока не могу осмыслить ситуацию при чтении данных.
1.получаем указатель на данные.
2.забираем куда надо.
на время исполнения пп.1и2 прерывания действительно могут быть запрещены.
но между пунктами может произойти переключение задач, и надо следить чтобы успеть вычитать данные, ибо мы уже успели получить наш указатель и уменьшить очередь, и вот тогда на это место и могут записать новые данные.

Чегото пазл не собирается

[Alex B._]

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

допустим одна задача (А) передает в очередь указатель на локальную структуру. Если есть задача (Б), которая ждет данные из этой очереди, то она получит управление.
Т.е. (Б) будет иметь адрес по которому находится локальная структура в (А).
структуру, которая находится в контексте (А) никто испортить не может, пока (А) опять не получит управление.

[Bender]

а-а, тут дело оказывается проще, есть удобный механизм fmem_get и fmem_release
Концепция работы проясняется вроде:
1. Источник получает через fmem_get указатель на свободное место
2. он же кладет туда свои данные
3. он же через queue_send сообщает где лежат эти данные
4. перейдя на пункт 1 он получит уже следующий адрес (если место еще есть) или тормознется на этом шаге, до освобождения памяти в п.С(ниже)

A. Приемник получает указатель на элемент данных queue_receive
B. обрабатываем этот элемент
C. элемент не нужен - освобождаем под место fmem_release, т.е. элемент мы не испортим никаким образом, пока не освободим место.

Т.о. проблему я надумал

[Alex B._]

ну да. причем фиксированные блоки памяти могут не только для сообщений использоваться

[Bender]

А все-таки нет ли более простого и более экономного способа передать данные? а то ведь через fmem_get нельзя получить блок менее 4 байт. Для уарта получается большой перебор