По первому — да, конечно, кто ж спорит. Только вот ссылку на это я сейчас полчаса искал — и это я знал, что искать! Документация на FreeRTOS оставляет желать лучшего, прямо скажем.
По второму — как вы, наверное, тоже в курсе, эта защита от переполнения не является идеальной (по вашей ссылке так и написано); полностью спастись можно только с MPU, которое есть далеко не всегда.
На мой взгляд основной минус использования ОС — это трудноуловимые баги. Два дня сидишь, взявшись за голову, потому что вообще непонятно, что происходит. Просто HardFault в случайный момент времени, в стеке вызовов мусор.
А потом оказывается, что...
При использовании FreeRTOS на stm32 прерывания, которые используют системные вызовы, обязательно должны иметь приоритет ниже, чем прерывание, которое вызывает диспетчер. Источник. Конечно, это должен проверять ассерт, жаль, что он по-умолчанию выключен!
Ну или
что в какой-то момент происходило прерывание, которое переполняло стек текущего потока, залезая в стек другого потока, который падал в совсем другой момент.
И это я молчу про "классические" обычные многопоточные баги.
Если же все написано в автоматном стиле, то все как-то сильно проще отлаживается.
Ну, с первым можно слегка поспорить — ибо есть некоторые предупреждения, которые компиляторы выдают надежнее, чем PVS (например, "не все поля класса были проинициализированы в конструкторе").
Но в целом вы правы, конечно.
Мне больше интересно, что у них за компилятор такой. Предупреждения на "нет возврата в non-void функции" и "переменная используется неинициализированной" вроде бы уже любой нормальный компилятор сам выдает.
Компилятор и библиотека, конечно, свои, но стандартная библиотека на то и стандартная. Должны же, наверное, быть заранее предусмотренные места для переопределения.
Спасибо за статью!
Интересно, а каков истинно-верный способ перенаправления printf?
Скажем, в Кейле очень часто используется переопределение fputc, а не _write.
Да, это понятно. Я просто мечтал о том, как могло бы быть.
Помнится, натыкался на пост о проблемах в D, где описания типов могут занимать дофигища места из-за декорирования имен. Во, нашел.
Create a chain of 12 calls to square above and the symbol length increases to 207,114. Even worse, the resulting object file for COFF/64-bit is larger than 15 MB and the time to compile increases from 0.1 seconds to about 1 minute. Most of that time is spent generating code for functions only used at compile time.
Я понимаю, что очень плохо представляю насколько все это сложно и не претендую на экспертное мнение. Просто вздыхаю.
Я имел в виду, что вся статья вроде как решает именно эту проблему, просто окольными путями.
Хотя и тут можно сказать что если есть проблемы с дизайном, когда нужен даункастинг.
Это само собой, я не пытался продумать все нюансы, просто хотелось показать, как бы я хотел это видеть.
У Вас лично в практике была такая надобность? Можете описать?
Сходу что-то конкретное не могу вспомнить, но периодически натыкаюсь на необходимость "прыгать через обручи" — делать кучу специализаций шаблонов, потому что нельзя просто написать switch по типу (я понимаю, что это не рантайм, но синтаксис мог бы быть простым) или делать type-tag из enum'a руками, а потом свитчится по нему.
Я понимаю, что это не очень часто нужно и, наверное, затраты на разработку такой фичи того не стоят. Но каждый раз, когда приходится изобретать обходные пути, становится грустно.
Вот рефлексия, допустим, тоже не слишком-то часто нужна, но без нее тоже грустно (имхо это достаточно близкие вещи).
Просто грустно, что когда это все-таки нужно, приходится извращаться. Насколько это технически сложно — судить не берусь, но так обидно, что тип вроде вот он на этапе компиляции, руку протяни только. И пропадает.
Может быть, вы имеете в виду, что регистр SP другой (не MSP, а PSP)?
Спасибо, я уже в курсе.
По первому — да, конечно, кто ж спорит. Только вот ссылку на это я сейчас полчаса искал — и это я знал, что искать! Документация на FreeRTOS оставляет желать лучшего, прямо скажем.
По второму — как вы, наверное, тоже в курсе, эта защита от переполнения не является идеальной (по вашей ссылке так и написано); полностью спастись можно только с MPU, которое есть далеко не всегда.
На мой взгляд основной минус использования ОС — это трудноуловимые баги. Два дня сидишь, взявшись за голову, потому что вообще непонятно, что происходит. Просто HardFault в случайный момент времени, в стеке вызовов мусор.
При использовании FreeRTOS на stm32 прерывания, которые используют системные вызовы, обязательно должны иметь приоритет ниже, чем прерывание, которое вызывает диспетчер. Источник. Конечно, это должен проверять ассерт, жаль, что он по-умолчанию выключен!
что в какой-то момент происходило прерывание, которое переполняло стек текущего потока, залезая в стек другого потока, который падал в совсем другой момент.
И это я молчу про "классические" обычные многопоточные баги.
Если же все написано в автоматном стиле, то все как-то сильно проще отлаживается.
Боже. Полагаю, спрашивать, зачем им в 2019 году совместимость с BeOS, бесмысленно?
Ну, с первым можно слегка поспорить — ибо есть некоторые предупреждения, которые компиляторы выдают надежнее, чем PVS (например, "не все поля класса были проинициализированы в конструкторе").
Но в целом вы правы, конечно.
Ндаа. Знаете, смеяться как-то не очень хочется.
Но это как-то совсем странно. Предупреждения отключены что ли у них? Или их просто не читают?
Мне больше интересно, что у них за компилятор такой. Предупреждения на "нет возврата в non-void функции" и "переменная используется неинициализированной" вроде бы уже любой нормальный компилятор сам выдает.
Интересно!
А расскажите поподробнее, как вы с задержкой видео боролись?
В С++ для этого вроде как можно использовать пользовательские литералы.
Плюсую за Octotree.
Просто и
_writeиfputcвроде как стандартные. Я правда не знаю, кто из них "ниже".Компилятор и библиотека, конечно, свои, но стандартная библиотека на то и стандартная. Должны же, наверное, быть заранее предусмотренные места для переопределения.
Спасибо за статью!
Интересно, а каков истинно-верный способ перенаправления printf?
Скажем, в Кейле очень часто используется переопределение
fputc, а не_write.А как же Шерешевский (он же "мнемонист Лурии", он же "пациент Ш.")?
"Мульти-символьные символьные литералы"- это даже звучит как оксюморон.
Мне давно интересно, зачем их вообще в язык добавили и кто их использовал.
Да вроде даже в С++11 можно было не указывать пустые круглые скобки, если у лямбды параметров не было.
Сериализация-десериализация без рефлексии — это, как правило, боль и унижение. Хотя Rust справился.
Да, это понятно. Я просто мечтал о том, как могло бы быть.
Помнится, натыкался на пост о проблемах в D, где описания типов могут занимать дофигища места из-за декорирования имен. Во, нашел.
Я понимаю, что очень плохо представляю насколько все это сложно и не претендую на экспертное мнение. Просто вздыхаю.
Я имел в виду, что вся статья вроде как решает именно эту проблему, просто окольными путями.
Это само собой, я не пытался продумать все нюансы, просто хотелось показать, как бы я хотел это видеть.
Сходу что-то конкретное не могу вспомнить, но периодически натыкаюсь на необходимость "прыгать через обручи" — делать кучу специализаций шаблонов, потому что нельзя просто написать switch по типу (я понимаю, что это не рантайм, но синтаксис мог бы быть простым) или делать type-tag из enum'a руками, а потом свитчится по нему.
Я понимаю, что это не очень часто нужно и, наверное, затраты на разработку такой фичи того не стоят. Но каждый раз, когда приходится изобретать обходные пути, становится грустно.
Вот рефлексия, допустим, тоже не слишком-то часто нужна, но без нее тоже грустно (имхо это достаточно близкие вещи).
Просто грустно, что когда это все-таки нужно, приходится извращаться. Насколько это технически сложно — судить не берусь, но так обидно, что тип вроде вот он на этапе компиляции, руку протяни только. И пропадает.