Ядро RTOS

[EfiR]

Сообщение от VoVaN

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

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

[Debian]

завтра все напишу я спать моск фаулт...

[Debian]

Сообщение от EfiR

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

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

Менеджер памяти

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

Планировщик

Какая будет выбрана стратегия планирования задач.
----
Будет ли код для работы с периферией выгружаться загружаться динамически а не находится в ядре, тогда нужно пхать его в отдельные модули, хотя это уже не монолит а гибрид получается.

Ну вообщем стадия проектирования куда более важна, чем набивание кода, я так думаю!

ну довайте думать
http://ru.wikipedia.org/wiki/%D0%AF%...B5%D0%BC%D1%8B - прочитав вот это я думаю что проще всего будет делать монолитное ядро, клиент - сервер, да, кошерно, но учитывая тот факт что я вообще дубовый в вопросах работы ОС ... пока отпадает

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

так и есть...
я вот думаю про динамическое выделение и распределение памяти
только в таком режиме надо будет постоянно следить на приложением
опять таки памяти немного и она ограниченна 56кб ...
но можно все лишнее выгружать, например в ту же внешнюю NAND память до востребования.

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

думаю весь код будет сидеть в ядре...не windows мы пишем...
если железо поменяется просто перекомпилим

[Debian]

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

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

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

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

• смотрим сколько оперативной памяти требует приложение, создаем поток, строим структуру в ОЗУ (память, место под стек, место под сохранение регистров процессора)
• настраиваем прерывание по таймеру
• запускаем поток

-----------------------------------------------------------------------
ядро системы - это тоже поток, с отдельным адресным пространством
то есть если работает 1 приложение процессор обрабатывает 2 потока...1 ОС, 2-приложение
естественно ОС не должна нагружать процессор, быстро реагировать на прерывания.
-----------------------------------------------------------------------
если запущено несколько приложений, то, мы просто переключаемся между процессами по системному таймеру

• приложение выполняется, происходит прерывание по таймеру
• система сохраняет копию стека программы,указателя стека, значения всех переменных и значения регистров проца в ОЗУ.
• переносит копию стека след. приложения в стек процессора, так же значения переменных и регистров... ставит указатель стека на нужное место.. тем самым активирует работу след процесса.
• далее ждем след прерывания от таймера

ну вот как-то так....
это примерные наброски...естественно нюансов очень много.

[VoVaN]

Сообщение от EfiR

Любой проц имеет атомарные инструкции

Спасибо, Кэп!

ПС Дэб, а как насчет микролинукса? ))

[Debian]

Сообщение от VoVaN

ПС Дэб, а как насчет микролинукса? ))

портировать надо долго и нудно...не поддерживает он эти камни

[VoVaN]

Сообщение от Debian

портировать надо долго и нудно...не поддерживает он эти камни

*хлопает себя по лбу* блин, всё забываю что ты под ПИК32 делаешь. У нас тут щас как раз перспективы этого дела обсуждаются. Есессно, под ЛПЦ ))

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

А зачем копировать стек, всё-тки? Просто менять SP тебе не катит?

[Debian]

*хлопает себя по лбу* блин, всё забываю что ты под ПИК32 делаешь. У нас тут щас как раз перспективы этого дела обсуждаются. Есессно, под ЛПЦ ))

да, мисье, я знаю толк в извращениях!

А зачем копировать стек, всё-тки? Просто менять SP тебе не катит?

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

[EfiR]

глядя в мануалы аж страшно становится, ну да ладно, идущий осилит путь!

я вот думаю про динамическое выделение и распределение памяти только в таком режиме надо будет постоянно следить на приложением, опять таки памяти немного и она ограниченна 56кб ...

вкратце определимся с понятиями о памяти и числами. По ссылке на модель которую дали, повторюсь 128Кб ОЗУ



карта физического ап из PIC32MX5XX/6XX/7XX Data Sheet для модели PIC32MX695F512L



по поводу "динамически", то нужно строить карту памяти используя mdl списки, по поводу "определять сколько нужно приложению памяти" обычно это известно из самого файла с программой. Вот в какой формат компилит их компилер и в какой компанует линкер или в чистый бинарник или надо свой придумывать формат???

Из мануала известно что используется два набора адресов - физическое ап и виртуальное ап. Также оказывается возможности управлять проекцией нет, проекция фиксирована. Размером областей можно управлять с помощью регистров BUS MATRIX. Пространство ядра делится на 4 части по 512MB, из них KSEG0 KSEG1 проецируется на одну и ту же область физ ап, разница в том что KSEG0 кешируется процом а KSEG1 соответственно нет. Конфигурационные периферийные регистры мапятся только на некэшируемую KSEG1.

короче с памятью для меня все понятно впринципе. Сейчас вкратце изучаю регистры CPU.

Debian а есть сорцы загрузчиков, посмотреть?

[Debian]

http://www.microchip.com/stellent/id...pnote=en536741

вот, есть пример через RS232

[EfiR]

Сообщение от EfiR

... Вот в какой формат компилит их компилер и в какой компанует линкер или в чистый бинарник или надо свой придумывать формат????

смотрю сорцы, - unix-овый elf формат используется, можно было догадаться

[Debian]

пападробнее
можно?

[EfiR]

Сообщение от Debian

пападробнее
можно?

ща качну компилер и MPLAB IDE и расскажу подробней

[EfiR]

В общем что касается форматов файлов и базонезависимой загрузки. Ничего своего они не придумывают а используют уже существующее, тоесть можно собирать сорцы как в elf так и в coff формат, а это оба формата во-первых базонезависимых, тоесть в самом файле есть поле - предпологаемый базовый адрес загрузки, если этот адрес в озу занят другим модулем, загрузчик грузит его по другому базовому адресу и пересчитывает релоки. Релоки - это элементы, которые зависят от базового адреса. Например: базовый адрес загрузки модуля равен 5, а некий элемент в коде этого модуля указывает на адрес 10, если загрузчик обнаружил что адрес 5 занят а 6 свободен, он загружает этот модуль по адресу 6, но элемент по прежнему указывает на 10 а это неверно так как весь модуль сместился на 1 байт, поэтому загрузчик подправляет этот элемент чтобы он указывал уже на адрес 11. Во-вторых формат спроектирован так что его необязательно грузить целиком а только по мере использования, но без возможности управлять проекцией виртуального ап, это фишка просто ненужна.

[Debian]

а теперь русским языком)
и еще одно
ПОЖАЛУЙСТА скажи где можно прочесть про всю эту кухню...времени не пожалею

Почесав затылок, юзер дописал через 6 минут

Сообщение от Debian

а теперь русским языком)
и еще одно
ПОЖАЛУЙСТА скажи где можно прочесть про всю эту кухню...времени не пожалею

хм...
http://www.google.com.ua/search?q=%D...client=firefox

[EfiR]

Сообщение от Debian

хм...
http://www.google.com.ua/search?q=%D...client=firefox

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

каталог и таблицы страниц

вкратце о них своими словами. Это относится в той или иной степени к архитектурам x86 и IA-64. Эти таблицы используются самим процессором, находятся в рам и подготавливаются ядром ОС. Не вдаваясь в подробности процессор оперирует виртуальными адресами, которые транслируются им в физические через эти таблицы страниц, тоесть: программа пишет по адресу 1, процессор интерпретирует эту единичку как виртуальный адрес и лезет в таблицу страниц и оттуда берет физический адрес, например 5 и производит операции с этими данными. Что это значит? А это значит что мы можем поменять 5 на любое другое значение и при обращении программы снова по адресу 1 уже будут производится операции с другими данными. Теперь как все относится к PIC32, у этой архитектуры нет возможности управлять этими таблицами и ссответственно проекция фиксирована(постоянна).

по форматам файлов могут дать только ссылки, объяснять просто слишком долго. доки на английском

coff формат

elf формат

и еще, из мануала известно что компиляция по умолчанию происходит в coff формат. опциями можно выбрать elf. в общем после билда в один из этих форматов, запускается прога pic32-bin2hex.exe, которая преобразовует в чистый бинарник. Дело в том что я на размер глянул объектника elf(из того примера загрузчика, который дали выше) а там нифигасе получился 258Кб, и от я теперь непойму чего он такой большой, а бинарник нормальный 18кб.

[Debian]

ооо...я начинаю постигать эту религию
но вот, что курить надо было, чтоб такое придумать
но прикольна, да

Efir, я хоть начал понимать что ты говоришь LOL)
ну нету в 32 линейке защищенного режима...пока...значит приложение придется грузить в ОЗУ целиком

[EfiR]

Сообщение от Debian

ооо...я начинаю постигать эту религию

принимай поздравления )

но вот, что курить надо было, чтоб такое придумать

вот как раз чтобы такое придумывать, курить ненадо )

Efir, я хоть начал понимать что ты говоришь LOL)
ну нету в 32 линейке защищенного режима...пока...значит приложение придется грузить в ОЗУ целиком

таки да

[EfiR]

Сообщение от EfiR

... в общем после билда в один из этих форматов, запускается прога pic32-bin2hex.exe, которая преобразовует в чистый бинарник.

оказывается файл hex, это не бинарь а текстовый вообще. Вот здесь про формат http://ru.wikipedia.org/wiki/Intel_Hex

Debian а в каком формате ты шьешь, я так понял в этом, тоесть это формат для прошивальщика?

[Debian]

bin, hex
но как правило в НЕХ

[EfiR]

Сообщение от EfiR

по поводу "динамически", то нужно строить карту памяти используя mdl списки...

тут ошибся, vad списки а не mdl. у mdl другое назначение.

[Debian]

я вот тут смотрю на Cortex все таки совсем другой уровень
заодно можно помучать Андроид и СЕ

[EfiR]

отличный девайс наверное, про андроид ниче не знаю, а у се прикладной интерфейс win32, правда урезанный, ядро свое вроде. Если кодил приложения под нт, то будет несложно и под се.

[Dale]

Нашел в инете описание, вот бы ещё батарейку прикрутить и в корпус собрать будет планшетник с выбором OS Хотя я уже давно думаю об этом девайсе.