Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: мнение насчет TNKernel v.2.4
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
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
Цитата(Bender @ May 3 2007, 12:24) *
Хотелось бы высказать 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
Цитата(DASM @ May 5 2007, 06:11) *
Вы мне напоминаете курортную тетеньку, едущего по путевке от турфирмы. А экскурсии будут ? ...

А мне Вам предупреждение вынести или Вы сами прекратите подобную практику общения?
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 прерывания действительно могут быть запрещены.
но между пунктами может произойти переключение задач, и надо следить чтобы успеть вычитать данные, ибо мы уже успели получить наш указатель и уменьшить очередь, и вот тогда на это место и могут записать новые данные.

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

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

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

Т.о. проблему я надумал smile.gif
Alex B._
ну да. причем фиксированные блоки памяти могут не только для сообщений использоваться
Bender
А все-таки нет ли более простого и более экономного способа передать данные? а то ведь через fmem_get нельзя получить блок менее 4 байт. Для уарта получается большой перебор
ig_z
Цитата(Bender @ Nov 2 2007, 15:43) *
А все-таки нет ли более простого и более экономного способа передать данные? а то ведь через fmem_get нельзя получить блок менее 4 байт. Для уарта получается большой перебор


С точки зрения банальной эрудиции smile.gif в байтовом канале можно передавать данные в пакетной либо потоковой манере. Простейший пример пакета - текстовая строка. Рациональный способ обмена - сообщение и/или очередь сообщений.
Потоковый обмен нужно(в смысле наиболее эффективно) использовать посредством фифо.
Для более глубокого понимания данных сущностей советую почитать соотв. разделы из доки сцмртос.


Все вышесказанное мое глубокое имхо и не претендует на истину в какой либо инстанции
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.