Перейти к содержанию
Поиск
    

VslavX

Свой
 Профиль  Обзор контента

  • Постов

    1 046

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные VslavX

  1. Опубликовано · Пожаловаться

    Вот на чем хранить всё то, что терять никак нельзя?

    Ежедневно вся работа бэкапится на флешку

    Ежемесячно вся работа бэкапится на вторую флешку

    Раз в несколько месяцев вся работа бэкапится на однократный DVD+R с избыточной информацией в архиве для восстановления.

    Время от времени бэкапится на NAS с дисковым массивом RAID5 - вся работа + семейные видео и фотоархивы

    Также время от времени фото и видео бэкапится на независимый сервер на базе PC, тоже с RAID-ом

    Года до 2007-го бэкапил на CD-R. Недавно читал пару дисков годов 98-99 - нормально все прочлось.

     

  2. Опубликовано · Пожаловаться

    Именно. Причем по моему опыту сброс через внешний вход ~RESET не помогает. После стирания битов еще приходится делать Power Cycling - тогда только защита гарантировано отключается.

    Я прошу прощения - я думал что речь идет о Code Read Protection - вот он только по Power Cycling снимается.

    А GPIO LCKR должен бы по любому сбросу процессора деактивироваться.

  3. Опубликовано · Пожаловаться

    Не замечал. У меня с Cortex-M3 всё ок. В чём именно глюк?

    Если что-то не работает при оптимизации - в первую очередь надо обратить внимание на свой код и в последнюю - на компилятор. имхо

    Угу - в этой теме проблема описана

     

  4. Опубликовано · Пожаловаться

    если не секрет то за какое время выполняется подпись ключом 2048bit?

    Я пока до RSA не добрался. Есть "советский" 34.310/34.311, украинский 4145-2002, и беларусский 1176.2.

    34.310 и 1176.2 тоже на модульной арифметике основаны, поэтому результаты подобные RSA будут - то же самое модульное возведение в степень.

    1176.2 при длине 2462 бита дает 680мс на выработку подписи.

     

    У меня F207 и на либах из PolarSSL получилось 2.7с без оптимизации и 1.5 с полной оптимизацией (IAR). Но при полной оптимизации дохнет драйвер ethernet от ST :-)

    IAR начиная с 6.2x глючит при оптимизации, никак они не исправят, откатитесь на 5.x.

    PolarSSL - хорошо и аккуратно написан и структурирован код. Но с точки зрения ресурсов/скорости - имхо, скорее середнячок.

     

  5. Опубликовано · Пожаловаться

    По смыслу цитаты речь идёт о сбросе контроллера.

    Именно. Причем по моему опыту сброс через внешний вход ~RESET не помогает. После стирания битов еще приходится делать Power Cycling - тогда только защита гарантировано отключается.

     

  6. Опубликовано · Пожаловаться

    Кто ни будь пробовал разгонять мк этого семейства от ST? Что максимально получилось при устойчивой работе? F10x пишут что гнались как раз до рабочей частоты F2xx, а что с самими двухсотыми?

    ST32F100 у меня случайно (ошибка в инициализации тактового генератора) до 48МГц разогнался (по даташиту 24МГц макс) и несколько дней беспроблемно работал (пока не заметил ошибку), в том числе исполняясь без waitstates из флеша :wacko:

    ST32F217 я сознательно уже разогнал до 144МГц (уже выставив правильно waitstates) - пару дней погонял - работало нормально.

    Еще немножко гнал LPC1788, но цифр уже не помню. Кстати, при одинаковых тактовых (120МГц) F2xx процентов на 10 быстрее чем LPC1788 - и по Dhrystones, и по времени переключения контекста ОС, и по моим криптографическим тестам (ЭЦП и поточное шифрование). Видимо сказывается более эффективный контроллер флеша - более развитый кеш.

    Но оверклокинг - то дело такое, имхо, сугугбо удел энтузиастов, в серийном изделии можно проблем изрядно огрести.

  7. Опубликовано · Пожаловаться

    Будет время - я попрофайлю свой стек, потому как не совсем понятно куда время процессорное ушло.

    Много времени прошло :)

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

     

    Достижения для LPC1768@100 такие (полезного TCP потока, из теоретически возможных ~96Mbps):

    - передача на удаленный хост 88.8Mbps при 75-процентной загрузке проца

    - прием от удаленного хоста 79.1Mbps при 85-процентной загрузке проца

    На все сетевые буфера взято 16К памяти. Отключение контроля IP/TCP сумм дает примерно 20 процентов процессороного времени - на STM32F2xx с аппартными суммами станет полегче с загрузкой.

     

    MPC8347@533MHz с гигабитным портом на оптимизацию кода отреагировал значительно более бурно,

    было 398Mbps на прием, и 280MBps на передачу при ~100-процентной загрузке, после оптимизации

    - передача на удаленный хост 343Mbps при 60-процентной загрузке проца

    - прием от удаленного хоста 832Mbps при 70-процентной загрузке проца

    Предположительно передатчик тормозится системой предотвращения заторов - наверное буду еще разбираться.

    Да, все фреймы обычные - 1518 байт, на Джумбе должно быть еще немного веселее :)

     

  8. Опубликовано · Пожаловаться

    VslavX

    Спасибо за скрипт! Никогда не понимал людей, пишущих на перле :)

    Берется книжка типа "Перл за 24 часа" и такой скрипт пишется за 10 минут :). Очень уж мощная штука Perl для обработки всяких текстов.

     

    Если я правильно понял, то делает он не совсем это. IarBuild (только сейчас проверил) вообще ничего в stderr не выводит. А вот

    IarBuild может быть и не выводит, а компилятор который он запускает - вроде бы ругается исключительно в stderr. По крайней мере версии 4.x точно так делали, а в stdout был молчок - никаких ошибок. То же самое касается GCC - ругается об ошибках исключительно в stderr. Поэтому без перенаправления - ошибки фильтрующим скриптом не хаваются.

     

    если в качестве компилятора для студии прописать какой-нибудь .bat-файл, а в нём написать:

    Я использую сразу gmake - он многопоточную компиляцию поддерживает (ключик -j), на многоядерном процессоре выигрыш значительный - почти кратный числу ядер.

     

    то тогда в студии добавиться ошибка в Error List (строчка делает echo в stderr). Так что студия добавляет ошибки в Error List только если они пишутся в stderr.

     

    А строка "2>&1 | " копирует в stdout, то, что IarBuild выводит в свой stderr (чисто на всякий случай, как я понял), а потом результат всего вывода (оператор "|" считывает выходные данные одной команды и записывает их на вход другой команды) перенаправляется в перл скрипт (т.е. и выводы stdout и stderr).

    Хм, странно, вроде бы мой скрипт выводит именно в stdout, а не в stderr. Может быть в Студии-2010 что-то поменяли.

     

    У меня нет интерпретатора перл, и ставить его лень, щас на c# по быстрому парсер напишу и выведу в stderr ошибки :)

    Ну идею Вы поняли. Кстати, впервые такой фильтр-конвертор сообщений об ошибках еще в BC3.1 был прикручен - там были примеры проектов для таких фильтров и как их вкрутить в среду.

     

  9. Опубликовано · Пожаловаться

    borman11, я тоже думал, что не придётся :)

    Было бы неплохо ещё, чтобы ошибки сразу в Error List студии добавлялись, а не в Output Window, но и так тоже не плохо.

    Легко - пропускаете Output компилятора через Perl со скриптом - скрипт конвертирует сообщения об ошибках формата IAR-а в формат студии. Запускать компилятор из студии так:

     

    <путь и имя исполняемого файла компилятора> <параметры компилятора> 2>&1 | <исполняемый файл интерпретатора Perl> <имя файла скрипта>

     

    (угловые скобки, ессно, не пишем - ограничивают имена в примере)

    "2>&1" нужно чтобы перенаправить stderr компилятора в stdout, который поступит на вход Perl-а с указанным скриптом.

    Скрипт для MSVC2005 и IAR (пробовал от 3.x до 6.41) в приложении (переименуйте .txt в .pl - форум не дает аттачить скрипты с таким расширением)

     

     

     

     

    iar2vc.txt

  11. Опубликовано · Пожаловаться

    Запустил на F205, настройки такие же (72 МГц, 2 waitstate на флеши), IAR 6.30, получилось 2.38 мкс.

    Наконец запустил свою плату на F207, IAR 6.30 + TNКernel

    72МНz, 2WS, IAR6.30 - 2.16 мкс

    120МНz, 3WS, IAR6.30 - 1.30 мкс

    Да, еще измерил обратное переключение при засыпании приоритетной задачи на ожидании объекта - 1.63 мкс (для 120МГц).

     

     

    Продолжим замеры? :)

    Замерил скорость переключения контекста на STM32F4DISCOVERY.

    168 МГц, 5ws.

    Получилось 964 нс. Это просто ракета! :)

    STM32F4DISCOVERY у меня тоже есть - в столе лежит :), но руки дойдут не скоро :(. И не думаю что TNKernel на нем на 168МГц из микросекунды "выбежит", поэтому в целом согласен - новая версия SCM чуточку быстрее.

     

  12. Опубликовано · Пожаловаться

    Запустил на F205, настройки такие же (72 МГц, 2 waitstate на флеши), IAR 6.30, получилось 2.38 мкс.

    205-ый покруче 1xx, у него типа акселератор флеша есть. У меня как раз сейчас 217-ый в запуске, потестирую при случае.

     

    TCB большой.

    Что есть - то есть. Там еще пару элементов можно в отладку убрать, но это несильно сократит размер.

     

    Ломает глаз обилие указателей на void.

    Да вроде не особо? Ну стек представлен как массив указателей void*. И параметр функции входа в поток имеет тоже тип void. Указатель на фукцию - то да, зря там PVOID стоит, надо бы правильный тип вкрутить.

     

  13. Опубликовано · Пожаловаться

    Хм, тут в теме такая жара, а я со своим контекстом лезу :)

    Собрал из своих исходников файл с функцией tn_sem_signal() - собственно инкрементирует семафор и освобождаем ожидающую задачу. По возможности почистил от всяких фич других портов (оставил только относящееся к Cortex-M3), TN_ASSERT-ы, отладочные фичи и прочее, н еотносящее к вопросу. Файл даже компилируется - при желании можно посмотреть листинг.

     

    Порядок исполнения такой:

    - tn_sem_signal() - ставим семафор

    - task_wait_complete() - пробуждаем ждущую задачу

    - task_to_runnable() - переводим задачу в исполняемое состояние

    - переключение контекста при первом же разрешении прерываний tn_unlock_interrupt() (PendSV)

     

    Функция find_next_task_to_run() при этом даже не используется - нужна только при засыпании задачи, когда нужно выбрать задачу для исполнения из осташихся.

     

    Если разблокируемая задача ждала без тайм-аута (с бесконечным таймаутом), то при пробуждении она удаляется из списка ожидания объекта и вставляется в список диспетчера - две операции со списками. Если был конечный тайм-аут - то задача удаляется еще и из списка системного таймера. В-общем, тут round-robin-а вообще не видно - естественно, он не исключен, просто никак на процесс пробуждения задачи не влияет.

     

     

    не учитывает развитие периферии современных микроконтроллеров

    "Огласите весь список пжлста" © "современных микроконтроллеров".

    А у меня вот такой пример - PowerPC MPC83xx от Фрискейла, там PCI/PCIe, SATA, GbE, USB HS и еще всякая мелочь, линейка разработки 2005-2011 годов. Там нормально так периферия развита - куда уж современнее. И, представляете, оно вообще не поддерживает вложенные прерывания. И где Вы с Вашим подходом окажетесь? :biggrin: А, ну да, щаз скажете что Линукс наше фсе :biggrin:

    tn_test.rar

  14. Опубликовано · Пожаловаться

    Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями?

    Линукс не подходит по ряду причин. Готовые приемы использую не я, а дизайнеры, мне приходится их интересы тоже учитывать. И, честно говоря, их доводы мне кажутся убедительными. scmRTOS не использую

    сортировать и выделять непосредственно http-query. А потом, с интерпретатором и скриптами, уже никакой гонки нет.

    Пример. Один клиент HTTP-сервера просто через CGI скрипты запрашивает состояние датчиков и строит на экране диспетчеру графики параметров в реальном времени. Второй клиент в это время хочет получить статистическую выборку из внутренней базы данных устройства. Эта база может быть где угодно, ну допустим даже не крайний случай - на SD-карте лежит. Чтобы сделать выборку надо прочесть с карты полста мегабайт данных, обработать и вернуть коротенький результат. Или другой вариант - по запросу прорулить исполнительным устройством, которое вообще через-какой нить удаленный SCADA-шлюз управляется. В любом случае - скрипт CGI отдает управление стороннему коду, и надолго, на секунды/десятки секунд. И люди которые писали этот сторонний код ни про какой кооператив ни сном ни духом. Что делать с первым клиентом? Прекратить диспетчеру графики давать, потому что сторонний запрос надолго и "некооперативно" забрал управление? В-общем, мое мнение, кооператив - это ограниченное решение для ограниченных условий, когда мы всем можем прорулить и учесть все факторы. Трудно расширяемое и неуниверсальное, поэтому я перед применением кооператива долго и нудно думаю - что нужно сейчас, а что затребуют прицепить потом, а как надо поделить время между разнородными задачами и т.д. В общем же случае - кооператив вообще нормально не работает (вспоминаем Win16).

     

  15. Опубликовано · Пожаловаться

    Дык, если время блокировки объекта соизмеримо или меньше затрат на инверсию приоритетов

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

     

    Нет, scmRTOS мне очень нравится - красиво и талантливо написана, очень шустрая, опять-таки на C++ (подтверждает тот факт что "кошек надо уметь готовить"). Но некоторые архитектурные ограничения - расстраивают. Понятно почему так сделано и откуда оно появилось. Но дальше, имхо, будет становиться печальнее - 32-битники уже серьезно на рынке, давят в том числе ценой тоже. Мелкобитники, конечно, не умрут, но ниша их пожмется хорошо так. И архитектурные ограничения принятые ради мелкобитников будут расстраивать все сильнее и сильнее :(. Поэтому я в своих портах TNKernel на мелкобитники сознательно "забил" - тоже свого рода ограничение.

     

    Мне тоже не ясно, как у вас получается, что работа со списками - а работа со списками никогда быстродействием не отличалась - получается такая же, как работа с битовой маской. Наверное, чтобы понять это, надо по листингу кодогенерации смотреть.

    ОК, мне сейчас поработать нужно. Вечером, если еще остануться силы, выложу цепочку исполнения при переключении контекста, вроде все посчитать можно - где какие списки модифицируются. Там основная фишка - инлайнирование функций работы со списками, они мелкие, и при этом еще и общий размер кода усох, и скорость сильно выросла.

     

  16. Опубликовано · Пожаловаться

    Давайте всё же уточним, что это не Пастернак, а сильно допиленное чудовище Франкенштейна, причём в данный момент никем, кроме самого Франкенштейна не проверяемое :)

    О как завернули. Да не вопрос - приглашаю в гости на демонстрацию, если, канешна, Франкенштейна не боитесь :). Ну еще могу, например, уважаемого ReAl в гости пригласить в качестве независимого арбитра :). Или скажете, что я арбитра пивом напоил и он не те цифры подтвердит? :biggrin:

     

    ЗЫ. У меня, кстати, получилось 2.55 мкс (scmRTOS 4.0/GCC).

    Да, GCC (начиная с 4.x) очень неплохой компилятор, и я очень серьезно думаю о переходе на него. Но это не завтра, но как поробую - отпишусь о результатах.

    Вы мне лучше скажите почему SCM такая медленная? Я тут почитал Пастернака посмотрел исходники - перевод процесса из NonReady->Ready делается действительно коррекцией битовой маски. TNKernel же делает кучу работы - удаляет процесс из списка синхрообъекта, где тот коротал время в состоянии non-runnable, переносит в список активных диспетчера, и все равно - разницы во времени даже несчастных 40 процентов нету :biggrin:

     

  17. Опубликовано · Пожаловаться

    Я видимо чего-то упустил, но по-моему CGI основано на использовании .dll в серверах на ПК? При чем тут scmRTOS для малых 8-ми разрядных чипов?

    CGI это несколько более широкая концепция. Имхо, под CGI следует понимать такое - поступает HTTP-запрос, сервер принимает заголовок запроса, определяет имя ресурса. Если это имя является именем скрипта (неважно на каком языке написанном - Ява, Перл, Питон, ПХП, или это вообще может быть приложение на С/С++), то сервер запускает этот скрипт и дальнейший поток данных входящего HTTP-запроса (тело, если оно есть) перенаправляется в stdin порожденного скрипта. А поток stdout, генерируемый скриптом, сервером также перехватывается и отправляется как ответ на HTTP-запрос удаленному хосту. Так вот, веберы (разработчики сайтов) поднакопили некоторый багаж алгоритмов и опыт разработки таких скриптов, принудить их поддерживать явный кооператив сложновато. К тому же обычно из этих скриптов (во встраиваемом сервере это просто процедуры на C/C++ выполняемые в отдельном порожденном потоке) требуется доступ к аппаратуре или внутренним базам данных устройства, например, оно как выдаст "SELECT к внутреннему SQL-серверу" - какой уж тут кооператив.

     

    Возвращаясь к scmRTOS, жесткое использование приоритета как идентификатора процесса имеет еще один недостаток - приоритет не может быть динамически изменен. Значит все протоколы управления приоритетами, предназначенные для борьбы с инверсией приоритетов, также не могут быть реализованы даже теоретически :(.

     

  18. Опубликовано · Пожаловаться

    Посмотрим-посмотрим:)

    Да нету там никаких 40 процентов :)

    Исходные условия:

    - STM32F103RG

    - тактовая частота ядра 72МГц

    - тактовая частота шины периферии 36МГц

    - исполнение из флеша с 2 тактами ожидания

    - печатная плата - стартеркит от Терраэлектроники

    - компилятор IAR 6.30

    - максимальные оптимизации по скорости

     

    Тестовый алгоритм такой:

    - имеется две задачи - 1 и 2

    - приоритет задачи 1 выше (более приоритетная) чем у задачи 2

    - задача 1 в бесконечном цикле

    {

    ждет синхрообъект (семафор для TNKernel и ef для scmRTOS)

    после срабатывания синхрообъекта сбрасывает тестовый пин GPIO

    }

    - задача 2 в бесконечном цикле

    {

    спит 10 мс

    устанавливает тестовый пин GPIO

    сигналит синхрообъектом задаче 2

    }

     

    В итоге осциллографом наблюдаем импульсы положительной полярности длительностью несколько микросекунд с частотой следования 100 Герц.

     

    Примечание:

    Для SCM выполнена дополнительная оптимизация кода (отличие от релизной версии) предложенная AHTOXA - внесена инструкция

    "bl os_context_switch_hook" в файле OS_Target_asm.s

     

    Для SCM за основу взял проект 1-EventFlag для порта на STM32F1xx. Tрадиционно помучался со средой (а почему это у вас там есть конфигурация Release которая нихрена не компилируется?), в итоге пришлось проходить все опции ручками - выбирать тагет, включать оптмизации, и прочее. Вкрутил свой код настройки тактовой частоты и флеша. Итоговый результат - длительность тестового импульса 2.72мкс.

     

    Потом взял свой проект на TNKernel, тот же самый код инициализации тактового генератора, тот же самый тестовый алгоритм.

    Отключил отладку и всякие плюшки типа профайлера времени исполнения задачи - оп-па, импульс 4.04 мкс. Не, такого не бывает, я же железобетонно уверен. Ага - забыли оптимизацию по скорости включить - 3.56 мкс. Ну не может быть. Полез ковыряться, в итоге нарыл у себя глюк в порту - запрос PendSV избыточно вызывался дважды (это я давно перестраховался при разработке порта и потом забыл убрать, так что уже сегодняшний вечер провел с пользой :biggrin: ). Откорректировал, тестим - 2.88мкс. Та не (ТМ), ага - 5.41 компилируется, а надо 6.30 (как было для SCM). Берем 6.30 - итого 2.76мкс :biggrin: . Кстати 6.30 глючный при высоких степенях оптимизации, я его не использую. Еще немного поигрался с оптимизациями - но начали видимо играть начальные выравнивания функций, уже тут эти такты выловить сложно - было от 2.64 до 3.10 мкс, поэтому за пруф результат все-таки принимаю 2.76.

     

    Итоговый результат длительностей наблюдаемых импульсов:

    scmRTOS - 2.72 мкс

    TNKernel - 2.76 мкс

     

    Ессно, никаких 40 процентов тут и близко нету, так что "Пастернака надо-таки читать", ага :tongue:

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

    Но то что двухуровневый диспетчер с round-robin-ом вещь совсем не аццки сложная и медленная - это экспериментально доказанный факт.

     

    Update: поигрался с конфигурацией scmRTOS, отключил отладку - добился еще снижения до 2.69 мкс. Почему оно так повлияло - явного места в коде ОС не нашел, видимо опять смещения начала функций и циклов отыграли. В-общем, общая картина понятна, на этом завязываю - дальше наносекунды ловить смысла большого нет.

     

  19. Опубликовано · Пожаловаться

    Это хорошо на 32-битном проце, одна инструкция. На мелочи манипуляции с указателями вместо битов уже не так красиво выглядят.

    Да, это я уже сообразил - одновременно с Вами апдейт своего поста написал.

     

    в TCB. А как, скажем, достичь такой функциональности: Event Flag, когда его сигналят, переводит все процессы, которые встали на ожидание флага, в готовые к выполнению - своего рода широковещательный "подъём" спящих, но не broadcast, а multicast - т.е. не просто всех поднять, а выборочно, только тех, кто "записался" на ожидание? В случае битовых карт процессов с уникальными приоритетами это делается одной командой по маске.

    Наверное да - тут проще OR сделать на маску активных процессов. Но тут есть нюанс - у меня редко (я даже не могу вспомнить такой случай) бывает что какой-то объект с автосбросом ждет несколько процессов. Такое может быть с мьютексом - но там нужно выбрать и пробудить один самый приоритетный процесс (unicast, Вашими словами). Критическая секция на семафоре - то же самое - пробудить один процесс, первый в очереди.

     

     

  20. Опубликовано · Пожаловаться

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

    Угу, именно это я называю "кооператив". Если система одновременно не поддерживает несколько процессов одинакового приоритета, то остается только такой выход. Хороший кооператив - это тоже достаточно непросто, вон мой HTTP-сервер в основном потоке кооперативный, и то потребовалось внутри три очереди создавать, а как дошло дело до скриптов CGI тут чистый кооператив сдох, пришлось выносить скриптовую часть в чистую вытесняйку.

     

    А идентификация задачи как производится?

    По значению указателя на TCB (task control block, аналог экземпляра TBaseProcess, если не ошибаюсь). И с объектом TCB сразу можно работать - не надо преобразовывать id (приоритет) в указатель. Понятно что это извлечение из массива, но - надо сделать ldr адреса массива (ага, из очен-но быстрой флеши), потом сам ldr из массива (ну тот уже в RAM).

     

    И каждый сервис при переводе процесса в спячку или пробуждении оперирует с этим значением, которое всегда доступно и однозначно определяет процесс.

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

     

    P.S. Ага, я посмотрел листиг - таки round-robin потребовал при переключении одной дополнительной инструкции subs для коррекции указателя списка в указатель на TCB. Одна инструкция - это как, подъемная цена за round-robin среди процессов одного приоритета? И количество процессов не будет ограничено.

     

    Update: я как-то упустил из вида что scmRTOS на 8/16-битных платформах тоже работает (мой порт TNKernel исключительно предусматривался для 32-х разпядных - как минимум предполагает что операции загрузки/сохранения указателей атомарны). На 8-битной платформе идентификация процесса по уровню приоритета вероятно даст выигрыш по размеру и быстродействия кода. Но для 16/32-битных платформ это уже становится явных архитектурным ограничением.

  21. Опубликовано · Пожаловаться

    Предсказываю процентов 40 выигрыша scmRTOS. Потому что это всё равно что-то (реализация round-robin, пусть даже при грамотной структуре данных) против ничего (две инструкции для выбора младшей единицы в слове-карте процессов).

    Это все из серии "Пастернака не читал - но осуждаю" :biggrin:. TNKernel точно так же ищет младший бит в битовой маске приоритетов - для кортекса юзается та же банальная инструкция CLZ (а для ARM7TDMI остроумный алгоритм из 5-6 инструкций)

     

    //________________________________________________________________
//
//  Функция быстрого поиска номера младшего установленного бита
//
//  Входные параметры:
//      value	- исходное 32-битовое слово
//  Возвращает:
//      номер самого младшего единичного бита + 1;
//      (для бита 0 - возвращается 1, для бита 31 - 32)
//		если исходное значение было нулевое, то возвращается 0
// 
INLINE_FORCED
DWORD   
ffs_asm(DWORD value)
{
 value = value & (0 - value);
 value = 32 - __CLZ(value);
 return value;
}

    А round-robin там списком реализован, поэтому TCB новой планируемой задачи при переключении максимум дополнительно извлечения указателя потребует (и то я не уверен в этом, TNKernel элемент списка встраивает прямо в объект, поэтому просто возможна банальная коррекция указателя инструкцией ADD/SUB #const вместо извлечения нового указателя).

    То есть - SCMRTOS ищет самый приоритетный бит и берет из массива указатель на TCB по индексу этого бита. А TNKernel по индексу бита извлекает из того же массива указатель на список round-robin, и потом из этого указателя делает указатель на TCB. Вот и вся разница, делов-то. Если где и будет некоторый расход ресурсов - так это в таймере, который будет тикать и листать список round-robin - переходить на следующий TCB. Но собственно к переключению контекста оно никак не относится. Так что какие там 40 процентов :laughing:

  22. Опубликовано · Пожаловаться

    У меня нет ни IAR-а ни LCP17xx :)

    BTW, а не было ли среди ваших оптимизаций TNKernel-а отключения round-robin? :biggrin:

    Не-а, оно вообще-то условными флагами не отключается (не было надобности в таких флагах). Тестировался полнофункциональный релизный вариант.

    Я постараюсь при возможности попробовать scmRTOS 4.0 на той же платформе. Думаю что результаты будут очень близкими. Потому как при грамотной структуре данных реализация round-robin не так уж и страшна.

  23. Опубликовано · Пожаловаться

    ваш вариант TNKernel : 2.83uS для LPC1768, @100МГц,

    scmRTOS: 2.55uS STM32F103 @72MHz (приведённое к 100МГц - 1.83uS).

    Более чем в полтора раза однако :)

    Та не™ :biggrin:

    Сравнивать надо на одинаковых процах, одинаковый прикладной код, одинаковым методом (скопом импульс на одной и той же ножке наблюдаем, например), с одинаковыми опциями компилятора, и исполнением из одного и того же места (из флеша, да :), и с одинаковыми waitstates). В упомянутой теме апдейт давний написан - включаешь у компилятора оптимизацию по скорости - и уже имеем 2.50uS на 1768@100МГц для TNKernel. BTW, я там еще оптимизаций добавил, надо бы потестить - а то что-то давно я ерундой не страдал :biggrin:

     

     

  24. Опубликовано · Пожаловаться

    Это что считать наклАдным. Переключение контекста сама по себе приличная по объёму инструкций операция. И отдельный стек. Я понимаю, что при наличие 32К оперативы выделить лишних полкилобайта особых вопросов не вызывает. Но чем это лучше, чем просто выполнять задания по очереди в одном процессе?

    Оперативы ровно столько же - ведь меняется только схема приоритетов, а количество процессов и их стеки остаются теми же самыми. Или Вы про "сознательный" встроенный кооператив с явными yield говорите? Такой кооператив не всегда приемлем - в тех же CGI - там скрипты давно понаписаны, к тому же пишу их не я, зачем людей (да и специализация у них на сайтостроительстве и контенте) еще и кооперативом грузить. Я кооператив не отрицаю и не так уж редко им пользуюсь (для той же экономии числа процессов и стеков), но, увы, оно не всегда "в тему".

     

    Чудес-то не бывает. Если планировщик более сложный, то и время его работы тоже будет больше. В своё время сранивал с uC-OS/II, там карта процессов состоит из распределённой структуры и приоритет вычисляется в два приёма - время передачи управления было в 2-2.5 раза больше. При прочих равных. Именно время передачи управления, а не переключение контекстов. Время переключения контекстов само по себе зависит от размера контекста, от процессора и его тактовой, но не от ОС.

    От процессора зависит само собой. И от ОС зависит - от планировщика, схемы данных диспетчера, от активированных фич и просто от качества кода. Я сравнивал uC/OS, FreeRTOS, SCM и TNKernel - есть вот такая тема, там проведено практическое исследование вопроса (в разрезе по ОС и процессорам :)). Поэтому я продолжаю настаивать что "не так уж оно и накладно" :).

     

    Это почему ещё? Это зависит от приложения. Кто сказал, что МАСи должны иметь одинаковые приоритеты? Если по одному из них трафик большой, а по второму малый, то вот и разница.

    Я просто привел в качестве примера проект из своей практики где MAC-и абсолютно идентичны, таких проектов у меня было несколько - не такая уж это и редкая ситуация. Кстати, схема приоритетов с поддержкой round-robin для меня была одним из плюсов, который повлиял на мой выбор ОС.

     

     

    Тем более, зачем тут лишние накладняки на передачу управления в непредсказуемый момент?

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

    Я не хочу сейчас дискутировать о достоинствах и недостатках кооперативной и/или вытесняемой многозадачности. Просто у пользователей TNKernel всегда есть выбор между кооперативом и вытесняйкой, а вот у пользователей SCM - выбора нет, только кооператив (ессно, речь о задачах с одинаковым приоритетом).

     

  25. Опубликовано · Пожаловаться

    Я согласен, что введение одинаковых приоритетов будет накладно.

    Не очень-то оно и накладно. Например, TNKernel поддерживает и уровни приоритетов и round-robin в пределах каждого приоритета, а время планирования и переключения контекста такое же (или даже лучше, правда новую версию SCM4.0 я не тестил) как у SCM. И реально этот round-robin используется, недавний конкретный пример - потоки выполнения CGI в HTTP-сервере. С точки зрения системы, как бы не должны обработчики двух одновременных HTTP-запросов между собой по приоритетам отличаться. Или если у процессора два абсолютно одинаковых MAC-а. ИМХО, некрасиво если потоки драйвера одинакового "железа" будут иметь различные приоритеты.

     

×
×
  • Создать...