Электронный миссионер

У меня скопилось достаточно большое количество законченных и не описанных проектов. Сил закончить их нашёл, а пороха написать полноценную объёмную статью уже найти не могу. Поэтому, чтобы материал окончательно не пропал, буду делать некоторые заметки на полях, под названием "Проекты в стол".

Когда я ковырялся с BIOS, мне хотелось найти подходящий пример, чтобы проиллюстрировать свою статью Разработка BIOS на языках высокого уровня. Надо было, чтобы это был BIOS, проект был разработан на GCC и т.п. В результате я нашёл прекрасный проект польского студента техникума maniekx86, необыкновенно талантливого парня. Проект был демки в виде небольшой операционной системы для дискетки "Portal ending "Still Alive" as operating system", проще говоря демка из игры Portal. Там были ошибки, проект изначально был как монолитный си-файл, и работал только на дискетках. В результате, взял этот проект, склонировал и переписал, так чтобы он работал в BIOS, при этом раскидал это всё по раздельным файлам. Как оказалось, maniekx86 не тестировал его на реальном железе, и мы ещё исправляли возникшие ошибки и проблемы вживую. Не всё было доведено до идеала, но лучшее - враг хорошего, проект работает и теперь в виде BIOS.

Результатом есть благодарность в README.md проекта: Special thanks to @dlinyj for helping and testing! и куча моих коммитов в истории этого прекрасного проекта. Ну, а для вас снял ещё в марте месяце два крутых демо, которые вы можете лицезреть сегодня.

1. Still Alive on 386 DX in BIOS ROM
Демка на старом железе, на 386 процессоре. Видно, что процессор не вытягивает копирование таких больших областей памяти и там требуется оптимизация, однако демка звучит и показывает. Внимание: может быть громкий звук.



2. Still Alive on Pentium 4 in BIOS ROM
Тут мощности процессора хватает, чтобы всё просто летало. Но в силу особенностей реализации железа инициализации BIOS, для корректной работы здесь пришлось прилично попотеть. Тезисно, пришлось дополнительно копировать код программы (не элегантно, но работает).





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

Покуда одни при каждом удобном случае мажут хабр грязью, я с большим удовольствием на нём выуживаю полезные для меня статьи, в частности:
Как защититься от переполнения стека (на Cortex M)?

Я, к сожалению, не такой лютый погромист всяких STM32 и прочих 32-х битных МК. Но таки срыв стека ловил, как раз когда переписывал предзагрузчик на одном весёлом MIPS-процессоре. Там я работал вообще на вольных хлебах, в том смысле, что весь стек инициализировался линкерным скриптом, в котором я тогда воообще не волок и брал готовый (сейчас не сильно больше волоку). В общем, суть была такова, что при вложении функции больше трёх - у меня ребутился проц. Понял я это не сразу, а путём экспериментов. В результате я тогда написал свой менеджер памяти, благо переменных было не очень много, но очень много данных и память (32 метра) была вся в моём распоряжении.

Так вот, ещё тогда я задумался, что стек - это больное и узкое место. Даже если у сильных мира сего, на которых бегает линукс, бывает срыв стека, то что бывает с маленькими процами. А что говорить про всяких ардуинщиков, которые даже об этом не думают и уверен, что у них 90% проблем - это срыв стека.

Так вот, исходя из статьи выше, я внезапно открыл для себя замечательные опции компилятора gcc -fstack-usage и... Я немного прифигел. После компиляции с этой опцией, появляется тьма файлов *.su (soviet union stack usage). Заглядываем в них, и тут я немного фигею:

...
reader.c:260:5:run_mode	48	static
reader.c:276:5:get_data_from_reader	1088	static
reader.c:293:6:free_recive_buffer	1056	static
reader.c:300:10:get_raw_data	64	static
...

Открываем функцию free_recive_buffer. Данная функция - это грязный хак-затычка, которая высасывает всё что есть в буфере uart, перед началом работы, чтобы иметь чистый буфер. Исключительно удобна при всяких опытах.

void free_recive_buffer (void) {
	uint8_t free_data [MAX_DATA_SIZE] = {0};
	get_from_reader(free_data,MAX_DATA_SIZE,100);
}

Ничего особенного, но оказывается, что переменная free_data располагается на стеке (MAX_DATA_SIZE = 1024).

Вопрос к знатокам. Я понимаю, что система у меня толстая, стек большой (кстати, а как узнать его размер в линукс?), но ведь это не есть хорошо? А если, вот я укажу там не 1024 в дефайне, а какую-нить дичь, типа 100000000? В чём преимущество размещения на стеке, в чём недостаток?

Так же, накидайте мне ещё каких-нить полезных опций компилятора gcc?

UPD Размер стека в Linux https://stackoverflow.com/questions/2275550/change-stack-size-for-a-c-application-in-linux-during-compilation-with-gnu-com

Да, я сделал это! Я написал таки свою первую программу для этой чудесной платы!



Программа элементарна, как день, ну для тех кто вдруг в танке, покажу:

int main(void) {
printf("Dlinyj krutoj megacoder!!!\n");
printf("http://dlinyj.livejournal.com\n");
}
Синтаксис подсвечивать не стал ;)

Чтобы оценить степень моей гемморойной замороченности, нужно представить что мне было лень грузится в линух, и я для этого на свеже поднятый mihhru сервак, залил арм компилятор, который там распаковал (не стал морочится с рутовскими правами и всё прописывать). Там написал эту программу, скомпилировал, перекачал far-ом на флешку, дальше запустил, как вы ввидите. Очень нехватает USB-клавиатуры. Виртуальная клава очень неудобна!

Хочу обратить внимание, как расположен дисплей и что линукс обрёл английский вид! В отличии от винце - этот линух умеет(!) сохранять настройки! Плюс, это тот самый линукс, который стоит в нокиа таблет. И под него есть великолепный SDK: http://qtextended.org/modules/mydownloads/viewcat.php?cid=4 (предпоследний в списке).

Прежде чем скомпилить консольное приложение, я пытался сделать графическую оболочку. Накидать кнопочек и т.п. Но у меня не вышло ничего скомпилировать, ибо я ни разу не работал с QT :(. Хотя внешний вид, и ЧУДОВИЩНОЕ(!!!) количество доков и примеров, даже на русском просто поражает! Может кто обучит меня QT? В цело очень порадовал интерфейс, но я совершенно неумею работать с визуальными языками (ну разве что кнопочки на панель таскать... Тема офигительная. Круто было бы с кем-нить посидеть в выходные и покодить, никто не желает покодить для армов? :D
P.S. Да, я налажал с chmod ;)

Я таки решил изучать Си серьёзно (ну по совместительству с++, хотя пока не делаю на него упор). По совету cluster_d прикупил две книжечки



Моя цель изучить си и писать на нём под линукс, компилировать программы и драйвера. В общем разобратся в синтаксисе. Немного почитав книжечку для чайников, я понял что примеры в книге не компилятся в линухе. В результате, под чутким руководством vshmuk я написал свою первую программу Хелоу Ворд. Что приятно, уважаемый товарищ описал процесс обучения в своём автономном блоге, который (о ЧУДО!) транслируется теперь в ЖЖ: http://geotechnoblog.livejournal.com/ рекомендую! Я искренне надеюсь, что многоуважаемый vshmuk и cluster_d (которыый показал уже пример арифметических выражений), не сочтут за труд отвечать на глупые вопросы. Так же сегодня попробовал тупо скомпилить для AVR (!) программу cluster_d. Одна скомпилировалась вполне успешно (мигание светодиодом), вторая заругалась, и отказалась компилится (не разбирался). Сцал кипятком. Теперь хочу понять как компилировать софт для роутера, на КОМПЕ! Пока задача минимум вкурить в синтаксис си, поигратся с примитивными программами (матрицы всякие, циклы и т.п.). Понять особенности си под линь, и начать шпарить.
Вторая задача, это найти исходники (ага, даже не знаю с чего начать) драейвера USB клавиатуры под линукс, и скомпилировать её под роутер (Вы что, наивно полагаете, что после отпуска я остыл к этой железяке?). И написать другой драйвер, для управления дисплеем. Ну и может скомпилировать драйвер FT232. В общем вкурить во все тонкости. Пока особо интересует работа с железом под линуксом на си.

Написал сумбурно, эмоционально, но надеюсь для тех кто в теме понятно.
З.Ы. gorl я помню твоё обещание ;). Но пока немного сам вкурю.