Комментарии 35
критические отзывы приветствуются
Зачем PDF, если книга не версталась под печать? Лучше выложить на GitHub Pages. Так будет гораздо удобнее и быстрее принимать исправления.
Права на данный текств полном объёме принадлежат КомпанииЭРЕМЕКСи защищены законодательством Российской Федерации об авторском праве и международными договорами.
На условиях какой лицензии я могу копипастить код из книги?
Никакая часть настоящей книги ни в каких целях не может быть воспроизведена в какой быто ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения КомпанииЭРЕМЕКС.
Ни на каких, ясно, понятно. ┐(￣ヘ￣)┌
Спасибо за отзыв.
Изначально планировалась печать, потом планы поменялись и все отложилось на неопределенный срок. Переформатирование под github pages требует времени, которого пока нет, может быть, впоследствии появится.
Лицензия впоследствии может быть пересмотрена, там приведена стандартная шапка для документации. Код можно копировать свободно. Но зачем… Код из книги почти во всех случаях неполный с вставкой многоточий вместо фрагментов, его цель — демонстрация принципа и не более того. Зато тот же полноценный и компилирующийся код, который лежит в репозитории, доступен на условиях BSD-лицензии, копипастить лучше оттуда.
Изначально планировалась печать, потом планы поменялись и все отложилось на неопределенный срок. Переформатирование под github pages требует времени, которого пока нет, может быть, впоследствии появится.
Лицензия впоследствии может быть пересмотрена, там приведена стандартная шапка для документации. Код можно копировать свободно. Но зачем… Код из книги почти во всех случаях неполный с вставкой многоточий вместо фрагментов, его цель — демонстрация принципа и не более того. Зато тот же полноценный и компилирующийся код, который лежит в репозитории, доступен на условиях BSD-лицензии, копипастить лучше оттуда.
От меня наоборот спасибо за PDF. Я может несколько консервативен, но читая книгу, даже электронную, хочу читать именно книгу, с постраничной разбивкой и нормальной версткой.
Если я конвертну книгу в gh pages (пример) и сделаю PR письменное разрешение оформите?
Я уточню, сейчас сезон отпусков, но скорее всего нет. И дело тут в том, что хотелось бы, чтобы весь контент был в одном месте, чтобы его легко было обновлять.
Так документация будет в вашем же репозитории вместе с md файлами из которых будет генерироваться содержимое. Или это не то самое "одно место"?
Disclaimer: я сейчас свое личное мнение выражаю, а не мнение компании, которой принадлежит контент.
«Одно место» это не в смысле чужие сайты, а то, что PDF (и word из которого он генерится) все же нужен. Чтобы отдать редактору или корректору например, когда-нибудь в светлом будущем или вообще издательству. Если контент форкается в markdown и начинает существовать в двух форматах, то их нужно синхронизировать между собой на что нужно временные и прочие ресурсы.
Если markdown сделать основным и генерировать и word и PDF из него… Не знаю, по моему опыту markdown все же word и все его возможности заменить не может по части ссылок, оформления, генерации оглавления и так далее. Поэтому удалить word-оригинал — очень смелый шаг на который пока никто не готов. Не удалять его = поддержка двух вариантов текста со всеми вытекающими из этого последствиями.
«Одно место» это не в смысле чужие сайты, а то, что PDF (и word из которого он генерится) все же нужен. Чтобы отдать редактору или корректору например, когда-нибудь в светлом будущем или вообще издательству. Если контент форкается в markdown и начинает существовать в двух форматах, то их нужно синхронизировать между собой на что нужно временные и прочие ресурсы.
Если markdown сделать основным и генерировать и word и PDF из него… Не знаю, по моему опыту markdown все же word и все его возможности заменить не может по части ссылок, оформления, генерации оглавления и так далее. Поэтому удалить word-оригинал — очень смелый шаг на который пока никто не готов. Не удалять его = поддержка двух вариантов текста со всеми вытекающими из этого последствиями.
функционал ядра
функциональность
1. Заинтересовался книгой и FX-RTOS.
2. Пошел на сайт
3a) Скачал книгу.
3б) Скачал пример мигания 3 светодиодами под FX_RTOS.
4. Открыл пример.
5. Увидел строчку
6. Перестал интересоваться FX-RTOS.
7. Про книгу отпишусь позже.
2. Пошел на сайт
3a) Скачал книгу.
3б) Скачал пример мигания 3 светодиодами под FX_RTOS.
4. Открыл пример.
5. Увидел строчку
MDR_PORTB->RXTX &= ~1;6. Перестал интересоваться FX-RTOS.
7. Про книгу отпишусь позже.
Остается только позавидовать уровню вашего перфекционизма, что единственная строка, способна полностью отбить охоту смотреть остальные тысячи строк :-)
Вообще демо к самой fxrtos отношения не имеет, и, кстати, что с ней не так, с этой строкой?
Вообще демо к самой fxrtos отношения не имеет, и, кстати, что с ней не так, с этой строкой?
1. Если данная программа расположена в разделе «демо» в официальном разделе, посвященном рассматриваемой операционной системе, на сайте фирмы, которая планирует продавать данную ОС, то она имеет отношение к самой ОС.
2. Более того, логично предположить, что демонстрационные программы писали программисты, имеющие прямое отношение к разработке ОС как таковой.
3. Самый простой способ навсегда потерять репутацию программиста встроенных систем в моих глазах (если Вас не устраивает моя скромная персона, то посмотрите на признанных авторитетов в этой области) — это написать прямую установку или сброс бита в регистре так, как сделано в этой строке (ключевое слово — макросы Аскольда).
4. В данном контексте (3 асинхронные задачи под шедулером по таймеру) подобное обращение к регистру управления светодиодами выглядит особенно пикантно.
2. Более того, логично предположить, что демонстрационные программы писали программисты, имеющие прямое отношение к разработке ОС как таковой.
3. Самый простой способ навсегда потерять репутацию программиста встроенных систем в моих глазах (если Вас не устраивает моя скромная персона, то посмотрите на признанных авторитетов в этой области) — это написать прямую установку или сброс бита в регистре так, как сделано в этой строке (ключевое слово — макросы Аскольда).
4. В данном контексте (3 асинхронные задачи под шедулером по таймеру) подобное обращение к регистру управления светодиодами выглядит особенно пикантно.
1. Я не совсем это имел в виду, но пусть будет так.
2. Так и есть.
3. Здесь наши мнения расходятся. Философия этой ОС — KISS в его самом незамутненном виде, поэтому, в частности, для любого М3 может использоваться один и тот же бинарник ядра, даже не исходник.
Если для битов есть символьные константы, или можно использовать простые числа вроде 1 и 0, то я считаю что именно так и нужно делать. Рассуждения о том, что «программист может перепутать», могут завести не в ту сторону. А если он названия переменных перепутает? Это все от лукавого. Не нужно умножать сущности без необходимости, особенно в демо-примере из 100 строк в одном файле.
Макросы в С нужны в совсем терапевтических количествах, потому что они скрывают реализацию и мешают понять, что происходит на самом деле. Что вынуждает разбираться в их реализации, тратить время. Код на С должен выглядеть кодом на С и быть понятным с первого взгляда, нужно дважды и трижды подумать, прежде чем усложнять. Такая вот позиция.
4. Это as designed :) Нужно исходить из того, в чем была задача, собственно. А она была не в том, чтобы диоды мигали строго по очереди, а в том, чтобы визуально, при взгляде на плату было видно, что потоки переключаются и диоды как-то мигают. Можно с тем же смыслом было написать:
MDR_PORTB->RXTX = RANDOM();
Да, иногда возможна ситуация что переключившийся поток сотрет изменения, внесенные другим потоком. Но никаких негативных последствий это не повлечет. Если бы там были не диоды, а устройство, которое требует синхронизированной записи в несколько регистров, то все было бы сделано совсем иначе, с мьютексом.
P.S. Вообще, комменты плохо подходят для дискуссии, пользуясь случаем, приглашаю на наш телеграм-канал, где можно обсудить кодстайл и прочее в более интерактивном режиме :)
2. Так и есть.
3. Здесь наши мнения расходятся. Философия этой ОС — KISS в его самом незамутненном виде, поэтому, в частности, для любого М3 может использоваться один и тот же бинарник ядра, даже не исходник.
Если для битов есть символьные константы, или можно использовать простые числа вроде 1 и 0, то я считаю что именно так и нужно делать. Рассуждения о том, что «программист может перепутать», могут завести не в ту сторону. А если он названия переменных перепутает? Это все от лукавого. Не нужно умножать сущности без необходимости, особенно в демо-примере из 100 строк в одном файле.
Макросы в С нужны в совсем терапевтических количествах, потому что они скрывают реализацию и мешают понять, что происходит на самом деле. Что вынуждает разбираться в их реализации, тратить время. Код на С должен выглядеть кодом на С и быть понятным с первого взгляда, нужно дважды и трижды подумать, прежде чем усложнять. Такая вот позиция.
4. Это as designed :) Нужно исходить из того, в чем была задача, собственно. А она была не в том, чтобы диоды мигали строго по очереди, а в том, чтобы визуально, при взгляде на плату было видно, что потоки переключаются и диоды как-то мигают. Можно с тем же смыслом было написать:
MDR_PORTB->RXTX = RANDOM();
Да, иногда возможна ситуация что переключившийся поток сотрет изменения, внесенные другим потоком. Но никаких негативных последствий это не повлечет. Если бы там были не диоды, а устройство, которое требует синхронизированной записи в несколько регистров, то все было бы сделано совсем иначе, с мьютексом.
P.S. Вообще, комменты плохо подходят для дискуссии, пользуясь случаем, приглашаю на наш телеграм-канал, где можно обсудить кодстайл и прочее в более интерактивном режиме :)
1. Начал читать книгу
2. Проглядел по диагонали первые 22 страницы и не очень понял, зачем они.
3. На странице 23 увидел псевдокод
4. Задумался, как бы написать это лучше в виде псевдокода
5. Раз уж мы пошли по пути абстракций, надо идти до конца и изолироваться от железа насколько возможно, а вот реализовывать функцию ready следует в самый последний момент.
PS. дошел до страницы 28, увидел фразу
2. Проглядел по диагонали первые 22 страницы и не очень понял, зачем они.
3. На странице 23 увидел псевдокод
while (my_device->status != <код готовности устройства>);4. Задумался, как бы написать это лучше в виде псевдокода
while (my_device->status != <код готовности устройства>); // откровенно неудачно - очень близко к железу но, скорее всего, на реальном железе не пойдет
while !equal_status(my_device->status,<код готовности устройства>); // все еще слишком близко к железу, указан конкретный код
while !ready(my_device->status); // все равно близко к железу, указан конкретный регистр
while !ready(my_device); // а вот так хорошо5. Раз уж мы пошли по пути абстракций, надо идти до конца и изолироваться от железа насколько возможно, а вот реализовывать функцию ready следует в самый последний момент.
PS. дошел до страницы 28, увидел фразу
Блок кода, выполняемый с запрещенными прерываниями называется, задумался ЧЯДНТ, начинаю терять интерес к книге.
критической секцией.
дошел до страницы 28, увидел фразу
Что с ней не так?
Запрещение/разрешение прерывания — это вовсе не единственный вид мьютекса.
Там нигде и не говорится, что это единственный вид, на 28 странице-то. Это единственный вид гарантированно доступный на большинстве железа, которое в той главе обсуждается, скажем так. Мьютексы как мьютексы будут только в 6 главе.
Но определение Вы дали навсегда?
Например, во FreeRTOS для критических секций определенного типа применяется специальный флаг, который предотвращает переключение задач, но не запрещает прерывания вообще никак.
Например, во FreeRTOS для критических секций определенного типа применяется специальный флаг, который предотвращает переключение задач, но не запрещает прерывания вообще никак.
Насколько я помню — нет, но я могу ошибаться. Критическая секция в более общем смысле обсуждается, например, на странице 183. Но, может быть, не совсем внятно. Наверно, это следствие многозначности самого термина, это и участок кода и одновременно примитив синхронизации в некоторых ОС и спинлоки и т.д.
Спасибо, стоит пропдейтить этот момент и в главе 2 назвать критической секцией «взаимоисключающийся» фрагмент кода, а каким образом это исключение достигается, вынести за скобки.
Спасибо, стоит пропдейтить этот момент и в главе 2 назвать критической секцией «взаимоисключающийся» фрагмент кода, а каким образом это исключение достигается, вынести за скобки.
2. Наверно не получилось у меня донести мысль. Если расписать словами, то она такая: 1 глава — «что нам хотелось бы получить»; 2 глава — «что у нас есть»; 3 глава — «какие у нас есть способы получить то, что нам хотелось бы из того что есть», здесь приходим к идее о том почему и зачем нужна ОСРВ. Начиная с 4 главы реализуем ее.
4. За код спасибо, да, приведенный вариант более абстрактный, учту в следующих редакциях.
4. За код спасибо, да, приведенный вариант более абстрактный, учту в следующих редакциях.
Надеюсь, Вы не обидитесь на мои излишне пристрастные замечания. Вашу идею о подобной книге поддерживаю полностью, на русском языке подобных материалов совсем немного, поэтому хотелось бы, чтобы читатели ее учились на лучших примерах, выполненных в блестящем стиле.
Нет конечно, не обижаюсь :) Здоровая критика — всегда на пользу, я учту все замечания, когда руки дойдут.
Первоначально планировалось что это все-таки будет бумажная книга, которая пройдет редактуру, корректуру, верстку, рецензирование и прочее. Но все эти планы пока были поставлены на паузу и контент доводился силами самих программистов со всеми вытекающими… Поэтому я даже в тексте упомянул, что работа не закончена, но было решено ее выложить хоть так, чем оставить пылиться во внутреннем репозитории.
Первоначально планировалось что это все-таки будет бумажная книга, которая пройдет редактуру, корректуру, верстку, рецензирование и прочее. Но все эти планы пока были поставлены на паузу и контент доводился силами самих программистов со всеми вытекающими… Поэтому я даже в тексте упомянул, что работа не закончена, но было решено ее выложить хоть так, чем оставить пылиться во внутреннем репозитории.
Бегло пролистал — мне понравилось. Всё разжёвано, термины объясняются, сложность доступна для понимания, изложено хорошо.
Пишите ещё!
Нужно было голосование прикрутить, нужен пост про саму ОС или нет… или можно ограничиться развернутым комментарием с ответами на вопросы вроде «почему вы не взяли готовый и распространенный FreeRTOS».
НЛО прилетело и опубликовало эту надпись здесь
У меня по ссылке выскакивает «Forbidden. Access denied.»
Есть вот такая серия книжек:
www.fysnet.net/osdesign_book_series.htm
Книгу 3 я даже купил несколько лет назад, т.к. надо было поработать со странным устройством IDE на странном онтроллере, а самому ходить по граблям — не хотелось. В принципе, все по делу, нашел пару ммм… неточностей, есть в Errata.
www.fysnet.net/osdesign_book_series.htm
Книгу 3 я даже купил несколько лет назад, т.к. надо было поработать со странным устройством IDE на странном онтроллере, а самому ходить по граблям — не хотелось. В принципе, все по делу, нашел пару ммм… неточностей, есть в Errata.
Если на микроконтроллере вам не хватает конечных автоматов, и приходится городить ртось, то вы явно что-то не так делаете: либо в довесок к МК надо нормальный процессор с MMU прикрутить, либо руки не из того места растут!
Очень категоричное заявление) Приведу пару доводов против него.
1. Невозможность воткнуть «нормальный процессор с MMU». Особенно стало остро с появление STM32H7. Встречал несколько проектов, где из-за требований к мелким габаритам ставили BGA минимального размера. И еще более мелкую DRAM к нему. RTOS там необходима была. По сути, там была часть для обычного МК +«тяжелые вычисления», которые гонялись на M7. Тут логичнее бы поставить просто одноплатник на QNX (есть требования к реальному времени) + МК, со своим ETH и все на прерываниях. Но увы. Габариты. В итоге все +- норм.
2. Конечные автоматы бывают порой настолько адовыми, что лучше не надо. И в таких случаях я склоняюсь к внедрению вообще виртуальной машины + скриптовые языки.
Сам в принципе против РТОС в МК, но порой это позволяет сделать проект читаемым и легко поддерживаемым. Порой даже приходится дописывать ту или иную РТОС (не ядро, а дополнительные меанизмы), чтобы снизить издержки, но все таки. Ясное дело, что ставить в STM32F030 РТОС не надо)))
1. Невозможность воткнуть «нормальный процессор с MMU». Особенно стало остро с появление STM32H7. Встречал несколько проектов, где из-за требований к мелким габаритам ставили BGA минимального размера. И еще более мелкую DRAM к нему. RTOS там необходима была. По сути, там была часть для обычного МК +«тяжелые вычисления», которые гонялись на M7. Тут логичнее бы поставить просто одноплатник на QNX (есть требования к реальному времени) + МК, со своим ETH и все на прерываниях. Но увы. Габариты. В итоге все +- норм.
2. Конечные автоматы бывают порой настолько адовыми, что лучше не надо. И в таких случаях я склоняюсь к внедрению вообще виртуальной машины + скриптовые языки.
Сам в принципе против РТОС в МК, но порой это позволяет сделать проект читаемым и легко поддерживаемым. Порой даже приходится дописывать ту или иную РТОС (не ядро, а дополнительные меанизмы), чтобы снизить издержки, но все таки. Ясное дело, что ставить в STM32F030 РТОС не надо)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очередная книга про разработку операционных систем