Глюки МикроСи. Выявление, исправление (обход скользких мест) и личный опыт борьбы с аномалиями компилятора

Работаю с Пиками больше 20 лет. С 2013 года использую MicroC. Сталкивался с разными глюками, кстати их вообще-то не так уж и много. Но например приходится ставить уровень оптимизации 0. В некоторых разработках не смог понять почему при другом уровне программа глючит. Нашел решение чисто интуитивно. С тех пор оптимизацией не пользуюсь в принципе.
Язык неплохой, все разговоры о том, что МикроСИ это игрушки - не имеют реальной основы. Компилятор любой имеет право глючить. У меня разработки на этом компиляторе работают в коммерческой сфере лет так... Ну в общем долго и эффективно.
Есть ли у кого примеры глюков (личный опыт борьбы), которые проявляются именно в МикроСи ?

0

Сообщение от DanHunter Компилятор любой имеет право глючить.

Пользуюсь GCC (правда не для PIC). Глюков не заметил. Их просто нет. От оптимизации не отказываюсь в том числе и от LTO.
Так что вы не правы, глюков в компиляторе не должно быть. Даже если они обнаружены, о них следует сообщить разработчикам которые обязаны устранить ошибки в кротчайшие строки, иначе меняйте компилятор. Потому что это не дело думать в чем ошибка в коде или в компиляторе. Когда код состоит из нескольких десятков тысяч строк понять может быть не просто где глюк в коде или в компиляторе.

Сообщение от DanHunter У меня разработки на этом компиляторе работают в коммерческой сфере

Я бы не стал пользоваться глючным компилятором для коммерческих разработок. Себе дороже!

Сообщение от DanHunter личный опыт борьбы

Выше написал - обращайтесь к разработчикам и требуйте их исправить. Если отказываются - меняйте компилятор (я бы заодно посоветовал сменить контроллеры на более современные).

1

У меня есть давний приятель. Он всю свою жизнь ищет контроллер, самый - самый... И постоянно находит все лучше и лучше. Правда не сделал реального продукта. Всю жизнь в поиске. Сейчас уже на пенсии. Ну да ладно, я это к тому, что все компиляторы пишутся людьми. Также как и контролеры разрабатываются людьми. Человеческий фактор неотвратимо присутствует. Кто-то знает как его исключить? Тогда и глюки также неотвратимы. Просто одни разработчики уже столкнулись с ними, другие в розовом неведении считают, что какой-то язык идеальной, а модерновые контроллеры лишены изъянов.
Я работаю с тем, что доступно и работает. Мои разработки работают, после тщательной отладки идеально для тех условий, для которых созданы. Поэтому мне нет смысла менять проверенное на неизвестное. Кот в мешке в коммерческом проекте не нужен. Дорого обходится. Очень дорого.
Кстати, насколько я знаю, в зарубежных аналогах используются суперновые контроллеры. Вот только беда в том, что эти самые аналоги по функциям мелко плавают. А мои железки работают. Может дело не в новизне железа, а в зашитых алгоритмах?

0

Сообщение от DanHunter я это к тому, что все компиляторы пишутся людьми.

Есть разница когда комиплятор разрабатывает 1 человек и пользуются им скажем 1000 человек и когда компилятор разрабатывает команда из 10 тысяч человек и пользуются им все население земли (речь не только про компилятор, но и при приложения созданные им). В первом случае вероятность багов гораздо выше чем во втором.
Компилятор GCC под очень много платформ. Он не только для микроконтроллеров, но и для компа и др. Им собирают операционную систему Linux которая существует под очень много платформ, включая мобильные и встраиваемые (в вашем смартфоне Android, который базируется на Linux). Наличие багов компилятора - непозволительная роскошь.
Это я к тому что когда много людей пользуются компилятором и приложениями собранными им, а ток же при большой команде разработчиков компилятора, вероятность найти баг многократно выше и его устранение произойдет оперативно. Большинство багов (99.99%) выявляются на этапе тестирования новой версии компилятора до его официального релиза.
А в случае компиляторов микроэлектроники, разработчиков мало, тестеров мало вот и баги которые годами не устраняются.
Вы проинформировали микроэлектронику о найденных багах? Может они их не устраняют потому что просто не знают о них?

Сообщение от DanHunter Поэтому мне нет смысла менять проверенное на неизвестное. Кот в мешке в коммерческом проекте не нужен.

Судя по вашему описанию "Кот в мешке" это баги в компиляторе микроэлектроники.
Есть всемирно признанные и проверенные контроллеры, компиляторы и IDE для них которыми пользуется весь мир. Вот к примеру можете посмотреть в соседнем разделе что народ использует в своих разработках в том числе коммерческих.

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

Ваших железок мы не видели и даже не представляем какие задачи они выполняют...

Сообщение от DanHunter Может дело не в новизне железа, а в зашитых алгоритмах?

В смысле криптографии или защиты от чтения прошивки? Современные контроллеры содержат аппаратные криптографические блоки, а прошивку при желании можно считать с любого МК. Все дело в цене вопроса. И как показывает практика из современных МК нелегально получить прошивку сложнее и дороже чем с тех что появились раньше. Во первых, древние МК давно научились взламывать и от этого цена ниже, а современные еще нужно взломать и разработчики МК учитывая существующие методы взлома, пытаются по максимуму устранить их возможность в современных МК.

0