А какой компилятор использует кокос, gcc? Тогда в ваших примерах лучше вместо дефайна LED_ON использовать инлайн функции. С точки зрения скомпилированного кода результат будет одинаковый, но добавятся статические проверки в момент компиляции кода.
Тогда не сработает, возникнет прерывание, которое будет длиться дольше, чем 1 цикл переполнения. На подобные штуки нужно смотреть с другой стороны (тут разбираю вариант с while циклом):
1. Идеальный случай, никакого переполнения. Избыточность — 1 команда чтения, 1 команда сравнения, 1 команда условного перехода, которая сфейлится. Вероятность такого исхода зависит от конкретной программы, других возможных прерываний, скорости переполнения счётчика.
2. Неидеальный случай, который будет случаться иногда — дополнительно 1 чтение из памяти и одно чтение из регистра счётчика к варианту 1.
3. Плохой случай, если много прерываний, или они длинные. В этом случае придётся перечитывать много раз. Может случиться, если этот кусок кода имеет совсем уж низкий приоритет. Но работать будет.
Ваш вариант (в котором был баг) с точки зрения 1 и 2 случаев эквивалентен, но сфейлится в случае 3 (и ещё если просто очень долгое прерывание было). При этом с точки зрения количества исполненных инструкций он идентичен, разница только в команде, на которую будет указывать условный переход. На самом деле, вариант с while мне больше нравится даже с эстетической точки зрения.
Допустим, High = 10, счётчик переполняется при 1000.
TmpH=High; // = 10
TmpL= ReadReg(TimerCounter); // = 999
// тут случилось прерывание и High заинкрементилось
if (TmpH!=High) TmpL= ReadReg(TimerCounter); // TmpL = 001
return (TmpH<<sizeof(int))+TmpL; // Вернули 10.001
В оригинальном алгоритме вся мякотка заключается в while цикле — данные нижней части считаются валидными только в том случае, если верхняя за момент вычитывания не изменилась. У вас верхняя не перечитывается.
У выбранного вами STM32F103 есть аппаратный USB device, который так и просит, чтобы его вывели на разъём и через него отправляли диагностику в компьютер, который запитан через этот ИБП.
Ну как зачем, ноутбуки то нынче почти не греются, а так оптический модуль будет согревать долгими зимними ночами :) Современные 40g трансиверы, вроде, около 2 ватт тепла выделяют.
На сколько большой кластер можно собрать? Скажем, если использовать как объектное хранилище (типа Amazon S3), то сколько машин/петабайт можно максимум запихать?
Можно ли растянуть кластер на несколько ДЦ для отказоустойчивости? На сколько хорошо переживает пропадание 1/4 или 1/3 узлов сразу?
Если считать отношение количества софта к общему населению, то победит Израиль наверняка, т.к. там очень большой процент программистов на душу населения. Если же считать отношение софта к количеству разработчиков, то легко может победить Индия, все более-менее крупные компании аутсорсят туда разработку.
Ну предложение то простое — чтобы производители железа портировали свои патчи в новые версии самостоятельно, благо популярных открытых компилятора всего два.
То есть вот такую проблему http://www.linuxquestions.org/questions/linux-software-2/error-in-compiling-gcc-3-3-3-with-gcc-4-3-2-a-693559/ я сам придумал? Вот конкретно с 3.3.3 такая засада. Сейчас, кажется, они сделали хитрый бутстрепинг и стало получше, но проблемы могут возникнуть внезапно.
А дальше ваши вопросы про одно и то же, на самом деле. Вот есть bluetooth чипсет, очень популярный и недорогой, я хочу сделать под него свою кастомную прошивку. Что мне предлагает производитель? А он предлагает мне взять gcc 3.3.3 и не выёживаться. Мультиклет, как пишут по ссылке выше, вообще предлагает компилятор с поддержкой только C89. И команда OpenBSD пытается заставить свою ОС работать вот на подобных странных архитектурах. Именно про это пост, что производители железа не хотят вкладываться в развитие инструментов для разработчиков, а команды разработки gcc/clang не особо хотят поддерживать непопулярные платформы, потому что смысла большого в этом нету.
Судя по комментариям, вы не единственный. Изначально у OpenBSD было 2 посыла:
это ОС, разработчики которой постоянно думают над безопасностью её ядра и компонентов,
это ОС, которая работает на самом разном железе.
И автор статьи страдает именно по поводу второго аспекта. И дело даже не в endianess (тут как раз всё элементарно), и не в размере лонга (тут тоже ничего сложного). Дело в тулчейне для сборки кода.
Чтобы скомпилировать любой код, вам нужны компилятор, ассемблер и линковщик. И у производителей разных нестандартных процессоров есть два варианта: писать/купить свой проприетарный компилятор, который, конечно же, будет поддерживать в лучшем случае С++03, а скорее всего какой нибудь С99, либо делать патчи для GCC/CLang. Причём во втором случае, как показывает практика, это будет древний gcc, просто потому что когда-то под него уже делали патч при разработке архитектуры ядра процессора, а потом переносить под свежие версии не имеет смысла.
А теперь смотрите, вот есть процессор мультиклет, про боль работы с компилятором можно прочитать прямо на хабре: http://habrahabr.ru/company/embox/blog/265059/.
Я недавно изучал вопрос создания прошивки под суперпопулярный bluetooth чип CSR BC4 (он стоит во всех модулях HC-01 и подобных), они предлагают пропатченный gcc 3.3.3 (который был зарелизен в 2004 году. 2004, Карл!), собственный проприетарный ассемблер и линковщик, которые есть только под винду. Хотя бы патч приложили, и с этим патчем gcc даже можно скомпилировать, если осилишь! Некоторые предлагают существенно более свежие версии компилятора, типа 4.2.
Отдельная боль — это сборка gcc с нужными патчами. Нельзя просто так взять и собрать gcc! Команда, которая делает его, гарантирует только то, что можно собрать версию N+1 с помощью версии N. ВСЁ. Когда я пытался собрать тот самый gcc с патчами от CSR с помощью довольно таки древнего gcc 4.4 (версия 5-летней давности), у меня сходу не получилось. К счастью, в просторах интернета получилось найти патч, который кто-то выложил лет 8 назад, когда так же мучался, и который делает нужную мне часть исходников gcc совместимой с веткой 4.х, и только тогда собралось.
Вот так смотришь на это всё и думаешь: да ну его нафиг, взял бы ARM — давно бы уже девайс прошивал, а так только получилось собрать компилятор.
А вы хоть раз переключались на бэкап сайт в бою под настоящей нагрузкой? Есть ли требование от регулятора проделывать такую процедуру с некоторой периодичностью?
Ну и самая большая их проблема — отсутствие счётчика длины строки. Из-за этого некоторые в некоторых продуктах (например, nginx), сделаны собственные строки, которые состоят из структуры указатель + счётчик, ну и собственный набор функций для работы с такими строками. Конкретно в примере из статьи это решило бы проблему с важностью порядка сравнения строк.
А сейчас есть техническая возможность эту раннюю стадию отловить какими нибудь простыми анализами с маленькой вероятностью ложноотрицательного срабатывания теста? Небольшая вероятность ложноположительного срабатывания тоже желательна.
А разве про рак хоть где-то говорят в контексте «вылечился»? Кажется, во всех странах говорят «отсутствие рецидива в течение N лет», что уже говорит о том, что врачи на текущий момент считают нормальное излечение невозможным.
На самом деле конкретно тут и не нужно строку в ОЗУ хранить, достаточно 2-3 байт для хранения состояния парсера, ну и сотня-другая байт флешки для хранения кода парсера.
1. Идеальный случай, никакого переполнения. Избыточность — 1 команда чтения, 1 команда сравнения, 1 команда условного перехода, которая сфейлится. Вероятность такого исхода зависит от конкретной программы, других возможных прерываний, скорости переполнения счётчика.
2. Неидеальный случай, который будет случаться иногда — дополнительно 1 чтение из памяти и одно чтение из регистра счётчика к варианту 1.
3. Плохой случай, если много прерываний, или они длинные. В этом случае придётся перечитывать много раз. Может случиться, если этот кусок кода имеет совсем уж низкий приоритет. Но работать будет.
Ваш вариант (в котором был баг) с точки зрения 1 и 2 случаев эквивалентен, но сфейлится в случае 3 (и ещё если просто очень долгое прерывание было). При этом с точки зрения количества исполненных инструкций он идентичен, разница только в команде, на которую будет указывать условный переход. На самом деле, вариант с while мне больше нравится даже с эстетической точки зрения.
Допустим, High = 10, счётчик переполняется при 1000.
В оригинальном алгоритме вся мякотка заключается в while цикле — данные нижней части считаются валидными только в том случае, если верхняя за момент вычитывания не изменилась. У вас верхняя не перечитывается.
Можно ли растянуть кластер на несколько ДЦ для отказоустойчивости? На сколько хорошо переживает пропадание 1/4 или 1/3 узлов сразу?
А дальше ваши вопросы про одно и то же, на самом деле. Вот есть bluetooth чипсет, очень популярный и недорогой, я хочу сделать под него свою кастомную прошивку. Что мне предлагает производитель? А он предлагает мне взять gcc 3.3.3 и не выёживаться. Мультиклет, как пишут по ссылке выше, вообще предлагает компилятор с поддержкой только C89. И команда OpenBSD пытается заставить свою ОС работать вот на подобных странных архитектурах. Именно про это пост, что производители железа не хотят вкладываться в развитие инструментов для разработчиков, а команды разработки gcc/clang не особо хотят поддерживать непопулярные платформы, потому что смысла большого в этом нету.
это ОС, разработчики которой постоянно думают над безопасностью её ядра и компонентов,
это ОС, которая работает на самом разном железе.
И автор статьи страдает именно по поводу второго аспекта. И дело даже не в endianess (тут как раз всё элементарно), и не в размере лонга (тут тоже ничего сложного). Дело в тулчейне для сборки кода.
Чтобы скомпилировать любой код, вам нужны компилятор, ассемблер и линковщик. И у производителей разных нестандартных процессоров есть два варианта: писать/купить свой проприетарный компилятор, который, конечно же, будет поддерживать в лучшем случае С++03, а скорее всего какой нибудь С99, либо делать патчи для GCC/CLang. Причём во втором случае, как показывает практика, это будет древний gcc, просто потому что когда-то под него уже делали патч при разработке архитектуры ядра процессора, а потом переносить под свежие версии не имеет смысла.
А теперь смотрите, вот есть процессор мультиклет, про боль работы с компилятором можно прочитать прямо на хабре: http://habrahabr.ru/company/embox/blog/265059/.
Я недавно изучал вопрос создания прошивки под суперпопулярный bluetooth чип CSR BC4 (он стоит во всех модулях HC-01 и подобных), они предлагают пропатченный gcc 3.3.3 (который был зарелизен в 2004 году. 2004, Карл!), собственный проприетарный ассемблер и линковщик, которые есть только под винду. Хотя бы патч приложили, и с этим патчем gcc даже можно скомпилировать, если осилишь! Некоторые предлагают существенно более свежие версии компилятора, типа 4.2.
Отдельная боль — это сборка gcc с нужными патчами. Нельзя просто так взять и собрать gcc! Команда, которая делает его, гарантирует только то, что можно собрать версию N+1 с помощью версии N. ВСЁ. Когда я пытался собрать тот самый gcc с патчами от CSR с помощью довольно таки древнего gcc 4.4 (версия 5-летней давности), у меня сходу не получилось. К счастью, в просторах интернета получилось найти патч, который кто-то выложил лет 8 назад, когда так же мучался, и который делает нужную мне часть исходников gcc совместимой с веткой 4.х, и только тогда собралось.
Вот так смотришь на это всё и думаешь: да ну его нафиг, взял бы ARM — давно бы уже девайс прошивал, а так только получилось собрать компилятор.
Про доставку данных на мобилку понятно, но что с автономностью?