Linux4avr?

Ты уже дос свой или что там у тебя дописал?

Ресурсов совсем не хватает для завершения того что я задумал.

Имею ввиду тех. ограничения DOS.

https://habrahabr.ru/post/177425/ Вот кстати.

Два часа на базовую загрузку(init=/bin/bash). Ещё 4, чтобы войти в Ubuntu(exec init), и потом залогиниться. Запуск иксов ещё дольше. Эмулированная скорость около 6.5 килогерц. Как ни странно, но после загрузки, система даже порой юзабельна. Ответ на команду в терминале приходит примерно через минуту. SD карточка форматировалась день. Я думаю, что это самый медленный, дешёвый и легкособираемый компьютер на Linux'е.

Это анальный костыль с эмуляцией MIPS на AVR. Кому оно надо?

http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/

Зато убунта, а у тебя нечто не понятное и линукс тут будет совсем ни при чём.

Я первый!

Хм, ну попробуй на этой «убунте» вим запустить.

Часик на запуск, ничего ведь, зато настоящий писишный линукс!

Удачи без (IO)MMU.

P.S. Блин, прочитай Танненбаума, а потом в ОСи лезь, на это смотреть смешно. А лучше получи профильное образование в хорошем ВУЗе и пиши свои уберОС с пониманием того, что происходит. У тебя нереальная каша в голове и налицо мания величия. Язабан.

Если тебя пугает дос, то что говорить о AVR...

Меня пугает то, что FPC генерирует огромный код на выход и его огроменный rtl, который он не умеет резать на «заюзанное\незаюзанное»

Да, ты первый, ещё и на русском :-)

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

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

Почему бы тебе не взять что-нибудь получше? Например, те же STM32? Это тоже микроконтроллер. Все спецификации доступны и есть куча статей на соответствующую тематику. Так что для тебя не составит труда вручную подёргать GPIO, понастраивать таймеры и т. д. Однако при этом версии на ядре ARM Cortex-M4 имеют аппаратную защиту памяти, а значит на их базе можно запустить ОС общего назначения (где одно приложение не может залезть в память другого). А ещё можно запускать код не только из флеша, но и из ОЗУ и вообще это всё в общем адресном пространстве (Гарвардская архитектура AVR доставит тебе немало хлопот, когда ты будешь писать свою ОС). И точно также ресурсы относительно ограничены, поэтому Linux из коробки не заработает и тебе придётся обмазываться сишечкой, чтобы что-то там портировать и это будет не менее интересно.

То что под STM32 нет Arduino IDE (на самом деле есть, но с плясками с бубном) не аргумент, потому что если ты собрался запилить свою ОС с шахматами и поэтессами тебе всё равно придётся научиться всё делать руками, а после этого написать 3.5 обёртки типа digitalWrite не составит труда (если тебе прямо совсем без них грустно).

Цена тоже не аргумент, потому что на Ali плата на базе STM32F103C8 стоит столько же сколько и Arduino Nano при этом превосходит её в разы по всем параметрам. Правда, там нет аппаратной защиты памяти, а платы с ней будут подороже, ну так и в 32 КБ atmega328 у тебя настолько серьёзный проект не влезет.

К тому же у STM32 встречаются аппаратные USB Host, контроллер внешней ОЗУ/флеша, интерфейс камеры, экрана. То есть чисто теоретически можно даже замутить MiniPC, пусть и очень слабый. Зато ты получишь полный кайф от разработки своей оконной системы и т. д. И в отличии от AVR, если не быдлокодить, то у тебя есть все шансы сделать так, что оно будет вполне юзабельно.

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

Если не нравится STM32, то можно взять другой ARM-микроконтроллер. Просто по STM32 достаточно большое количество информации и обилие недорогих китайских плат, а с другими производителями могут возникнуть проблемы.

Назови хоть одну причину, почему тебе нужно данный проект делать именно на AVR (AVR хорош для некоторых задач, но явно не для этой)?

AVR'ом интересуюсь с 7 класса.

Почему цель - дуина? Ответ прост: пока не находил времени все спаять вместе.

К слову о digitalWrite, это же анальная обертка над portX.

Я тебе хотел сказать, что AVR не предназначен для запуска чего-то сложнее FreeRTOS и имеет определённые принципиальные архитектурные ограничения (например, отсутствие аппаратной защиты памяти), в которые ты обязательно упрёшься, если будешь пытаться сделать аналог полноценных ОС. И если даже сейчас ты это не понимаешь, то когда поймёшь тебе будет очень обидно за потраченное время. Если хочется экзотики в виде запуске ОС на микроконтроллере (понимаю, это интересно, ведь ты можешь контролировать всю аппаратуру и на всё есть даташиты), то посмотри в сторону ARM (и уже как совет - линейка STM32 как наиболее распиаренная и про которую есть куча статей).

Я это говорю тебе не просто так. Я сам когда-то писал свою ОС. И не одну. Действовал итерациями «написать до того момента, когда она начинает падать и никак не можешь найти причину - психануть и забить - начать сначала». Правда, я писал ОС для x86. И как ни странно, в это время я тоже был школьником. Классе в 7-8 наверное начал. Убийцы винды так и не получилось, но максимум, чего я достигал была ОС, которая грузилась с дискетки, умела виртуальные терминалы, можно было ходить по каталогам на дискете с помощью командной строки и запускать новые приложения (однако приложение было только одно - командная строка). И это всё в 64-битном режиме, да. А ещё архитектура была микроядерной. То есть у меня был отдельный процесс отвечающий за консоль, отдельный процесс отвечающий за дисковод, за файловую систему и, наконец, командная строка, которая со всеми этими процессами обменивается сообщениями.

В качестве пруфа - однажды мне стало скучно и я решил поделиться своей мудростью и родил цикл статей на тему разработки ОС - http://subscribe.ru/catalog/comp.soft.myosdev.

Сейчас я разработкой ОС в привычном смысле этого слова не занимаюсь, меня больше тянет к микроконтроллерам и роботам. И тут опять же я много чего тыкал. Я работал с AVR (это были мои первые микроконтроллеры), MSP430 и STM32. Причём для MSP430 и ARM я писал свою реализацию USB-стека и она успешно работала. Опять же пруф (реализация USB Device для MSP430) - https://github.com/KivApple/libmsp430usb.

Я мечтаю разработать свой фреймворк для программирования микроконтроллеров, который был бы не сильно сложнее Arduino, однако открывал доступ ко всем возможностям конкретных архитектур. В настоящий момент я занимаюсь разработкой своего компилятора (точнее транслятора с моего языка на plain C), потому что C++ меня не удовлетворяет по некоторым причинам.

Я не призываю тебя присоединиться ко мне, тем более что я не знаю твой уровень квалификации и не уверен в том, что ты не забьёшь на всё это через небольшой период времени. Но если ты таки запилишь свою ОС общего назначения на микроконтроллере (то есть с оконной подсистемой, USB и т. д.), то я очень хотел бы посмотреть на это чисто из любопытства. Поэтому я прошу тебя прислушаться к моим словам и либо забить на эту затею, либо выбрать другой микроконтроллер нежели AVR.

И да, объективных причин использовать AVR для данной конкретной задачи у тебя нет (если бы ты просто хотел помигать светодиодиком или сделать электронный замок, то я бы промолчал - на вкус и цвет все фломастеры разные). Только «я так привык». Однако помни, что эта фраза является одним из самых мощных тормозов прогресса.

Посмотрим, может быть когда нибудь потом и STM попробую.

x86 не меньше увлекаюсь чем AVR.

Ну и на засыпку, как ты юзал прерывания биоса в х64, они же тогда не доступны, не?)

Ну смотри, я просто тебя предупредил...

Ну и на засыпку, как ты юзал прерывания биоса в х64, они же тогда не доступны, не?)

Я их не юзал. С клавиатурой (не USB, разумеется, а PS/2) и текстовым экраном не сложно работать и напрямую через регионы памяти и порты ввода-вывода (вывод через видеобуфер по физическому адресу 0xB8000, ввод через не помню уже какой порт).

С дисководом немного сложнее, но тоже можно работать напрямую. С жёстким диском - проще. Разумеется, я использовал PIO вместо DMA, но на моих задачах разница всё равно была бы незаметна (но и DMA при желании можно прикрутить).

В интернете есть статьи на эту тему, по ним и делал.

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

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

знаеш что такое VESA? так вот оно поддерживается вообще всем,и на это и пишут драйвера(опенсурс),манов десятки

также есть колибриОС,она на асемблере и x86 онли

но в любом случае-портировать колибри на АВР будет более работоспособно чем линукс

ни хрена ты не сделаешь

ядро придется переписать с нуля
monobogdan3

проблемы с доступом к linux.org.ru? добавьте цифру Пи, чтобы получилось monobogdan3,14

Ресурсов совсем не хватает для завершения того что я задумал.

Имею ввиду тех. ограничения DOS.

Меня пугает то, что FPC генерирует огромный код на выход и его огроменный rtl, который он не умеет резать на «заюзанное\незаюзанное»

 type 
 	TFileIO = record 
 		FileID: Integer; 
 		FileObj: TextFile; 
 	end; 
 
 
 var 
 	Files: array[0..16] of TFileIO; 
 	FileCounter: Integer; 

 function FindFileByID(FileID: Integer): TFileIO; cdecl; 
 var 
 	i: Integer; 
 begin 
 	for i := 0 to SizeOf(Files) do 
 	begin 
 		if Files[i].FileID = FileID then 
 		begin 
 			Result := Files[i]; 
 			break; 
 		end; 
 	end; 
 end; 

procedure OpExec(Interpreter: TObject; args: String);
var
	ProgramName: String;
	ProgramArgs: String;
	CmdInterpreter: TCommandInterpreter;
begin
	ProgramName := args;
	ProgramArgs := args;
	CmdInterpreter := TCommandInterpreter(Interpreter);
	if Pos(' ', ProgramName) <> 0 then
	begin
		Delete(ProgramName, Pos(' ', ProgramName), Length(ProgramName) - Pos(' ', ProgramName) + 1);
		Delete(ProgramArgs, 1, Pos(' ', ProgramArgs));
		if FileExists(CmdInterpreter.GetCurrentDirectory() + '/' + ProgramName) then
		begin
			Exec(CmdInterpreter.GetCurrentDirectory() + ProgramName, ProgramArgs);
		end
		else
		begin
			CmdInterpreter.PutString('Failed to execute "' + CmdInterpreter.GetCurrentDirectory() + '/' + ProgramName + '"');
		end;
	end
	else
	begin
		if FileExists(CmdInterpreter.GetCurrentDirectory() + '/' + ProgramName) then
		begin
			Exec(CmdInterpreter.GetCurrentDirectory() + '/' + ProgramName, '');
		end
		else
		begin
			CmdInterpreter.PutString('Failed to execute "' + CmdInterpreter.GetCurrentDirectory() + '/'  + ProgramName + '"');
		end;
	end;
end;

Это с таким то трэш кодингом, тебе даже ассемблер не поможет...

Я имел ввиду нормальный драйвер с 3D, а не просто разрешение менять. И я помню, что VESA это сервис BIOS. Насколько реально его дергать в 64-битном режиме?

А с KolibriOS опять же будут проблемы на AVR. Всё те же - гарвадская архитектура и отсутствие аппаратной защиты памяти. В итоге получится тот же DOS с общим адресным пространством.

Ну а хули, мы же в 21 веке живем, ООП не помешает.

Для начала хотелось бы спросить вкурсе ли ты о AVR32 или At91? - если нет - самое время познакомится. Чуть сложнее классических восьмибитников но намного более ближе к требованиям линукса.

А потом советую прочитать вот это: http://wiki.osdev.org/Beginner_Mistakes и дальше по ссылкам.

Впринцыпе это сильно прокачивает скилы но в реально отдаленной перспективе