Приветствуем на Форум Херсона. Форум Херсонской молодежи.. На данный момент Вы находитесь на форуме как Гость и имеете очень ограниченные возможности и права. Что бы писать или отвечать в темах, загружать картинки, файлы на форуме Вам нужно зарегистрироваться, что совершенно бесплатно. Регистрация очень быстрая, не откладывайте эту процедуру! Если возникнут проблемы с регистрацией напишите нам. |
|
Программирование Все вопросы по написанию программ |
Просмотр темы (Новые вначале) |
08.09.2010 16:45 | ||||
Dale | Нашел в инете описание, вот бы ещё батарейку прикрутить и в корпус собрать будет планшетник с выбором OS Хотя я уже давно думаю об этом девайсе. | |||
08.09.2010 15:11 | ||||
EfiR | отличный девайс наверное, про андроид ниче не знаю, а у се прикладной интерфейс win32, правда урезанный, ядро свое вроде. Если кодил приложения под нт, то будет несложно и под се. | |||
08.09.2010 14:21 | ||||
Debian |
я вот тут смотрю на Cortex все таки совсем другой уровень заодно можно помучать Андроид и СЕ |
|||
08.09.2010 12:03 | ||||
EfiR | тут ошибся, vad списки а не mdl. у mdl другое назначение. | |||
14.03.2010 11:51 | ||||
Debian |
bin, hex но как правило в НЕХ |
|||
14.03.2010 11:16 | ||||
EfiR |
Цитата:
Debian а в каком формате ты шьешь, я так понял в этом, тоесть это формат для прошивальщика? |
|||
04.03.2010 14:14 | ||||
EfiR |
принимай поздравления ) Цитата:
Цитата:
|
|||
04.03.2010 12:49 | ||||
Debian |
ооо...я начинаю постигать эту религию но вот, что курить надо было, чтоб такое придумать но прикольна, да Efir, я хоть начал понимать что ты говоришь LOL) ну нету в 32 линейке защищенного режима...пока...значит приложение придется грузить в ОЗУ целиком |
|||
03.03.2010 09:37 | ||||
EfiR |
это называется линейная адресация памяти. Почему я говорю виртуальная, чтобы не запутать вас вообще окончательно. Дело в том что физическое ап оно так же линейно как и линейное(виртуальное). Но называется виртуальным потому что косвенный метод преобразования (через некие таблицы). А вот ссылка на почитать про эти таблицы каталог и таблицы страниц вкратце о них своими словами. Это относится в той или иной степени к архитектурам x86 и IA-64. Эти таблицы используются самим процессором, находятся в рам и подготавливаются ядром ОС. Не вдаваясь в подробности процессор оперирует виртуальными адресами, которые транслируются им в физические через эти таблицы страниц, тоесть: программа пишет по адресу 1, процессор интерпретирует эту единичку как виртуальный адрес и лезет в таблицу страниц и оттуда берет физический адрес, например 5 и производит операции с этими данными. Что это значит? А это значит что мы можем поменять 5 на любое другое значение и при обращении программы снова по адресу 1 уже будут производится операции с другими данными. Теперь как все относится к PIC32, у этой архитектуры нет возможности управлять этими таблицами и ссответственно проекция фиксирована(постоянна). по форматам файлов могут дать только ссылки, объяснять просто слишком долго. доки на английском coff формат elf формат и еще, из мануала известно что компиляция по умолчанию происходит в coff формат. опциями можно выбрать elf. в общем после билда в один из этих форматов, запускается прога pic32-bin2hex.exe, которая преобразовует в чистый бинарник. Дело в том что я на размер глянул объектника elf(из того примера загрузчика, который дали выше) а там нифигасе получился 258Кб, и от я теперь непойму чего он такой большой, а бинарник нормальный 18кб. |
|||
03.03.2010 00:16 | ||||
Debian |
а теперь русским языком) и еще одно ПОЖАЛУЙСТА скажи где можно прочесть про всю эту кухню...времени не пожалею Почесав затылок, юзер дописал через 6 минут Цитата:
хм... http://www.google.com.ua/search?q=%D...client=firefox |
|||
02.03.2010 18:38 | ||||
EfiR | В общем что касается форматов файлов и базонезависимой загрузки. Ничего своего они не придумывают а используют уже существующее, тоесть можно собирать сорцы как в elf так и в coff формат, а это оба формата во-первых базонезависимых, тоесть в самом файле есть поле - предпологаемый базовый адрес загрузки, если этот адрес в озу занят другим модулем, загрузчик грузит его по другому базовому адресу и пересчитывает релоки. Релоки - это элементы, которые зависят от базового адреса. Например: базовый адрес загрузки модуля равен 5, а некий элемент в коде этого модуля указывает на адрес 10, если загрузчик обнаружил что адрес 5 занят а 6 свободен, он загружает этот модуль по адресу 6, но элемент по прежнему указывает на 10 а это неверно так как весь модуль сместился на 1 байт, поэтому загрузчик подправляет этот элемент чтобы он указывал уже на адрес 11. Во-вторых формат спроектирован так что его необязательно грузить целиком а только по мере использования, но без возможности управлять проекцией виртуального ап, это фишка просто ненужна. | |||
02.03.2010 17:29 | ||||
EfiR | ща качну компилер и MPLAB IDE и расскажу подробней | |||
01.03.2010 23:50 | ||||
Debian |
пападробнее можно? |
|||
01.03.2010 13:45 | ||||
EfiR | смотрю сорцы, - unix-овый elf формат используется, можно было догадаться | |||
01.03.2010 12:54 | ||||
Debian |
http://www.microchip.com/stellent/id...pnote=en536741 вот, есть пример через RS232 |
|||
01.03.2010 11:43 | ||||
EfiR |
глядя в мануалы аж страшно становится, ну да ладно, идущий осилит путь! Цитата:
карта физического ап из PIC32MX5XX/6XX/7XX Data Sheet для модели PIC32MX695F512L по поводу "динамически", то нужно строить карту памяти используя mdl списки, по поводу "определять сколько нужно приложению памяти" обычно это известно из самого файла с программой. Вот в какой формат компилит их компилер и в какой компанует линкер или в чистый бинарник или надо свой придумывать формат??? Из мануала известно что используется два набора адресов - физическое ап и виртуальное ап. Также оказывается возможности управлять проекцией нет, проекция фиксирована. Размером областей можно управлять с помощью регистров BUS MATRIX. Пространство ядра делится на 4 части по 512MB, из них KSEG0 KSEG1 проецируется на одну и ту же область физ ап, разница в том что KSEG0 кешируется процом а KSEG1 соответственно нет. Конфигурационные периферийные регистры мапятся только на некэшируемую KSEG1. короче с памятью для меня все понятно впринципе. Сейчас вкратце изучаю регистры CPU. Debian а есть сорцы загрузчиков, посмотреть? |
|||
01.03.2010 11:00 | ||||
Debian |
Цитата:
Цитата:
хотя с другой стороны, конечно, намного быстрее было бы просто указатель менять |
|||
01.03.2010 10:55 | ||||
VoVaN |
*хлопает себя по лбу* блин, всё забываю что ты под ПИК32 делаешь. У нас тут щас как раз перспективы этого дела обсуждаются. Есессно, под ЛПЦ )) Цитата:
|
|||
01.03.2010 09:55 | ||||
Debian | портировать надо долго и нудно...не поддерживает он эти камни | |||
01.03.2010 09:32 | ||||
VoVaN |
Спасибо, Кэп! ПС Дэб, а как насчет микролинукса? )) |
|||
01.03.2010 00:26 | ||||
Debian |
вообщем я тут прикинул систему...а вы покритикуйте... учитывая, что я с этим никогда дела не имел...выродил такую систему .................................................. .................................................. 1. при включении системы запускается вшитый в камень загрузчик его задачи
когда все выполнено начинается запуск приложений .................................................. ................................................
ядро системы - это тоже поток, с отдельным адресным пространством то есть если работает 1 приложение процессор обрабатывает 2 потока...1 ОС, 2-приложение естественно ОС не должна нагружать процессор, быстро реагировать на прерывания. ----------------------------------------------------------------------- если запущено несколько приложений, то, мы просто переключаемся между процессами по системному таймеру
это примерные наброски...естественно нюансов очень много. |
|||
28.02.2010 14:56 | ||||
Debian |
Цитата:
ну довайте думать http://ru.wikipedia.org/wiki/%D0%AF%...B5%D0%BC%D1%8B - прочитав вот это я думаю что проще всего будет делать монолитное ядро, клиент - сервер, да, кошерно, но учитывая тот факт что я вообще дубовый в вопросах работы ОС ... пока отпадает Цитата:
я вот думаю про динамическое выделение и распределение памяти только в таком режиме надо будет постоянно следить на приложением опять таки памяти немного и она ограниченна 56кб ... но можно все лишнее выгружать, например в ту же внешнюю NAND память до востребования. Цитата:
если железо поменяется просто перекомпилим |
|||
27.02.2010 23:19 | ||||
Debian | завтра все напишу я спать моск фаулт... | |||
27.02.2010 17:49 | ||||
EfiR | кстати что касается изменений одной переменной, длиной byte word dword, то никакие программные методы синхронизации(семафоры например) ненужны. Любой проц имеет атомарные инструкции, тоесть выполняются без прерываний(аппаратная синхронизация). Но есть и куча нюансов, короче их тоже надо учитывать.. | |||
27.02.2010 10:48 | ||||
EfiR |
если честно, задача слишком тяжела для одного двух человек. Ну если ничего не останавливает то набросай приблизительно архитектуру оси, точнее не набросай, а используй уже существующие решения только воплощать в своем коде. Например Архитектура системы монолит клиент сервер уровневая ??? так как нужна многозадачность и переносимость прикладного уровня, уровневая модель отпадает. Клиент сервер самая ништяковая - надежность, масштабируемость бла бла, но сложна в реализации, поэтому тоже отпадает. Монолит - системные сервисы это часть ядра, думаю эта модель подойдет лучше всего. Менеджер памяти надо подробно изучать спецификацию, важные такие моменты, можно ли в этих камнях управлять проекцией физического ап на виртуальное, если да, то можно ли менять линейные адресные пространства, как это в х86. Хотя наверно нельзя и все прикладные проги крутятся в одном линейном пространстве адресов. Какая будет стратегия выделения памяти и т.д. Планировщик Какая будет выбрана стратегия планирования задач. ---- Будет ли код для работы с периферией выгружаться загружаться динамически а не находится в ядре, тогда нужно пхать его в отдельные модули, хотя это уже не монолит а гибрид получается. Ну вообщем стадия проектирования куда более важна, чем набивание кода, я так думаю! |
|||
24.02.2010 22:59 | ||||
Debian |
раздуплил внутрисхемный программатор... определяется по USB как PICkit2... для этих камней хватит с головой читает, пишет, проверяет, т даже отлаживать внутрисхемно может вот как-то так... хотя сначала было неприодолимое желание написать слово из 3х букаф...но быглядело бы попсово... и еще я тут смотрю стандартные библиотеки... там кучу всего намучено, перемучено... думается мне писать надо все с нуля. ну по крайней мере библиотеки для работы с периферией... а там всякие GUI, TCP/IP если дело дойдет... тогда заюзаем готовые как думаете? |
|||
24.02.2010 21:35 | ||||
Debian |
вот во всю так сказать шас отладчик внутрисхемный собираю, и программатор в доске в тяму привожу правда, блин, в комплекте нету 32 пиков :( есть 24 серия и dsPIC33 оба 16 разрядные... ну то фик с ними главное инструменты подготовить, а купить всегда можно |
|||
24.02.2010 15:31 | ||||
EfiR | до дядьки я еще не дорос ). как успехи в подготовке к осеписательству | |||
24.02.2010 12:23 | ||||
Debian | это проц кочегарит) куллер надо! | |||
24.02.2010 11:51 | ||||
VoVaN | А у тебя там тёпленько. | |||
В этой теме более 30 ответов(а). Нажмите здесь, чтобы перезагрузить эту тему. |