Ядро RTOS

[Debian]

Я тут че подумал
тут новые процы пришли
думаю пора, во первых опыт
во вторых надо! для работы
в третих интересно епта!

че у нас есть
значить
тактовая частота 80 Мегагерц
частота периферии 80 Мегагерц
Флеш - целых 512кб пачти как говорил Билли...
с ОЗУ дела обстоят послабее 65кб
из периферии
Ethernet
USB host
USB OTG
CAN - сам не знаю зочем она мне но поставлю
RS-232 - будет 2!
еще будет стоять цветной TFT мегадисплей 320*240 с тачскринам
я вообще хотел 640 * 480 а еще лучше 800 * 600 но цены на такие матрицы такие, что [Censored]

на уровне ядра буду реализовывать такие функции
1.Работа с USB Mass Storage Device
2.Работа с Ethernet TCP/IP
3.Работа с ФС FAT12/16/32
4.Управление приложениями (выделение процессорного времени в зависимости от приоритета)

вопрос по многозадачности
естественно она будет псевдопараллельной
максимальное количество задач - 10

как заставить процессор переключатся между задачами по требованию? как это в x86 серии происходит?

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

и так прыгать...?

[VoVaN]

омг.
Одна задача = одна подпрограмма. Ядро работает по прерываниям таймера. Прерывание сработало (надо дать квант времени другому потоку):
1. запоминаем точку возврата того потока, который мы прервали
2. переключаем указатель на стек со стека прерваного потока на стек запускаемого (каждый имеет свой стек). Большие процы умеют это делать - позволяют ручками менять регистр - указатель вершины стека, а это-то нам и нужно.
3. выходим из прерывания передавая управление на сохраненную ранее точку возврата, а не на туда откуда оно было вызвано (тут тоже нужно подтасовка фактов в стеке, зависит от архитектуры камня).

очень просто и для потоков выглядит прозрачно. Каждый поток (подпрограмма) работает со своим стеком. Можно добавить приоритеты по потокам, можно добавить тайм-критикал секции, можно добавить"добровольную" сдачу неиспользованного остатка времни следующим процессам (т.е. временную задержку, останавливающую процесс) - можно хоть что-то вроде гипертреадинга поднять благодаря этому (т.е. когда поток ждет ответа переферии, например, внешней ээпром-памяти - он не тупо крутит проц впустую, а отдает это время другим потокам, тут только нужно реализовать точный возврат управления по времени).
Примерно так реализовано ядро РТОС в одном из наших компьютеров на ЛПЦ2478, работает классно.

[Debian]

о! кЭп!
пашол в стеке пароюсь
я вот копчиком чуял, что без стека тут ну никак

[EfiR]

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

как это в x86 серии происходит?

в x86 реализовано аппаратное переключение задач. Есть такая структура, программно подготавливается, которая используется процессором, - GDT (глобальная дескрипторная таблица) - массив дескрипторов, так вот есть несколько типов этих дескрипторов, один из них называется дескриптор задачи или TSS(сегмент состояния задачи), и в отличии от других типов, из которых проц берет только селектор кодового сегмента (cs) и указатель инструкции (ip) и перегружает соответствующие регистры, TSS представляет собой сегмент содержащий весь контекст задачи, тоесть регистры общего назначения, сегментные, отладочные, флагов и т.д. и всю эту кухню перегружает. В winnt и linux, например, TSS для переключения задач неиспользуется, там происходит программное переключение так как более гибко и быстрее. Одну только точку возврата мало сохранить, надо сохранять весь контекст. При возникновении прерывания или исключения проц сохраняет в стек текущей задачи регистры eflags cs eip и код ошибки(не всегда есть), а далее (ядро винды например) формирует структуру трапфрэйм в которую весь контекст и сохраняется и указатель на нее пишется в структуру KTHREAD. после возврата из прерывания, из KTHREAD берется указатель на трапфрэйм и все в обратном порядке, - восстанавливается содержимое регистров, в стек записывается eflags cs eip и по iretd процом из стека перегружается в регистры.

[Debian]

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

[EfiR]

а что за процы хоть, есть даташит?

[Debian]

есть вот

http://www.microchip.com/stellent/id...cName=en545659

[EfiR]

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

[Debian]

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

начинаю с нуля
щас листаю аппноты и смотрю сайтик
http://www.freertos.org/
не совсем то, но интересное есть

[EfiR]

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

[VoVaN]

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

проще под ось писать приложения
многозадачность
гибкость
меньше времени на разработку и отладку
прибитая элементная база

Но граблей может вылезти - заотлаживаешься Например, прикольно получается если по невнимательности в условии какого-то ветвления(или просто в выражении) сравнить глобальную переменную с функцией и не предусмотеть, что потеря потоком управления может произойти в тот момент, когда функция уже вернула значение, но сравнение (математическая операция) еще не выполнилась, особенно если при этом значение глобальной переменной где-то в другом потоке изменится. В итоге получается неуловимый мистический баг (например, отрицательная дельта времени), который выскакивает раз на 10000 вызовов этого кода. Помни о семафорах. И о том, что выполнение кода может быть прервано на полуслове и выполнены любые другие операции с памятью. И "Memento mori" тоже. )))
На правах факапа

[EfiR]

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

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

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

[VoVaN]

Ваш пост огорчает быдлокодеров, которые пили пиво вместо лекций по теории операционных систем! *огорчился и ушел дальше кодить на делфях*

[EfiR]

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

*огорчился и ушел дальше кодить на делфях*

не огорчайтесь ) , все относительно, мой пост всего лишь теория, практик я слабый

Debian а как осуществляется boot? дело в том что некоторые аппаратные структуры подготавливаются загрузчиком, например ivt(векторная таблица прерываний) в PC заполняется BIOS. проц как известно стартует в риалмод. в протектедмод процом используется IDT (дескрипторная таблица прерываний) и подготавливается уже загрузчиком оси до перевода его в этот режим.

[EfiR]

прикольно, в нем аппаратный отладчик есть. А как вы отлаживате проги. Я это, - немогу в спецификации найти описание program execution registers, где оно?

[Debian]

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

[VoVaN]

JTAG рулит. Однозначно. Я высказался. ))) На симуляторе далеко не уедешь.

Насчет бутлоадера - воспользовался б тем хавту, что мне кидал - про юсб-хост. И интересно, и удобно. Хотя повозиться придется. Лайт-версия - сделать автопрошиватор с какой-нить SD/MMC, там по железу вообще элементарный SPI, да и в контроллере ничего сложного. Тем самым вообще уходишь от необходимости прошивать камень.

ПС што там мои детали на телепортатор - приехали, али где-то по пути в лед вмерзли? )

[Debian]

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

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

определимся со схемотехникой
итак что нам надо
сам проц PIC32MX695F512L - это есть
LCD Дисплей с тачскрином - это закажем (плачет ...)
SD карточка, или может NAND память? ... склоняюсь к ммм SD
USB порт
Ethernet порт
GPS приемник
GSM модуль
звуковая карта на основе чипа VS1011
можно еще поставить RS-232 порт


вот собственно пока такие хотения

Почесав затылок, юзер дописал через 1 минуту
и еще вопрос по поводу ОЗУ
*чешет затылок...
в проце 65кб...
внешнюю как я понял поставить невозможно

[EfiR]

ни 65 а 64, хотя в той модели на которую дали ссылку 128кб рам

[VoVaN]

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

ни 65 а 64

В этих камнях совсем не обязательно "круглое" количество памяти. Дело в том, что она частично распределена между разными имеющимися на борту подсистемами (напр. эзернет, ДМА, и др), поэтому вместе могут получаться всякие фантастические числа вроде 65кб, 130кб и.т.д.

[EfiR]

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

[Debian]

что, б*я, не ждали?
а я вот да)
наконец-то запалучил отладочную плату, теперь можно проводить эксперементы и размышления щас напишу на 18F4550 бутлодер / прошивальшик и можно будет творить великие тела)

[EfiR]

и сколько стоит такая коробочка?

[Debian]

о! дядьку я вас ждал

[VoVaN]

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

что, б*я, не ждали?

А у тебя там тёпленько.

[Debian]

это проц кочегарит) куллер надо!

[EfiR]

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

о! дядьку я вас ждал

до дядьки я еще не дорос ). как успехи в подготовке к осеписательству

[Debian]

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

до дядьки я еще не дорос ). как успехи в подготовке к осеписательству

вот во всю так сказать
шас отладчик внутрисхемный собираю, и программатор в доске в тяму привожу
правда, блин, в комплекте нету 32 пиков :(
есть 24 серия и dsPIC33 оба 16 разрядные...
ну то фик с ними главное инструменты подготовить, а купить всегда можно

[Debian]

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

и еще я тут смотрю стандартные библиотеки... там кучу всего намучено, перемучено...
думается мне писать надо все с нуля. ну по крайней мере библиотеки для работы с периферией...
а там всякие GUI, TCP/IP если дело дойдет... тогда заюзаем готовые
как думаете?

[EfiR]

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

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

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

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

Планировщик

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

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