Форум РадиоКот

[uquote="YS",url="/forum/viewtopic.php?p=3129878#p3129878"]желание использовать SDCC у меня отпало когда я дочитал документацию по нему примерно до половины[/uquote]
если не секрет - что там было такого страшного, кроме туповатого линкера?

YS писал(а):о кросс-платформенности думать приходится, чтобы при необходимости использовать код коллег и делиться с ними своим кодом

в этой фразе - ключ к пониманию моего подхода. я работаю на себя, для себя и так, как хочу сам. я не связан по рукам и ногам разнообразием платформ - я развлекаюсь исключительно с AVR. весьма зыбкие планы приступить к играм с ARM, если вдруг решусь, то буду так же при помощи GCC делать.

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

Я, кстати, тоже по возможности использую GCC, и коллег, работающих со мной наиболее тесно, на него почти перетянул.

Единственно, как я уже говорил, меня очень огорчает отсутствие поддержки STM8. Правда, STM8 хороши по большей части ценой, из них я склонен использовать только младшие кристаллы.

если не секрет - что там было такого страшного, кроме туповатого линкера?

У него странная система вызовов, диковинные форматы файлов, неполная поддержка стандарта - это то, что помнится навскидку. А еще у меня возникло ощущение, что STM8 туда прикручивали по остаточному принципу.

чего уж говорить о любителях генерировать код визардами?!

Я скажу по секрету, что у нас среди разработчиков тоже есть любители генерировать код визардами. Это создает отдельные проблемы.

[uquote="YS",url="/forum/viewtopic.php?p=3130142#p3130142"]А еще у меня возникло ощущение, что STM8 туда прикручивали по остаточному принципу[/uquote]
вообще да) сначала он был под mcs-51, потом прикрутили z80, затем pic-и, еще чего-то. Порт stm8 емнип пилят полтора землекопа.

[uquote="YS",url="/forum/viewtopic.php?p=3130142#p3130142"]У него странная система вызовов, диковинные форматы файлов, неполная поддержка стандарта - это то, что помнится навскидку. А еще у меня возникло ощущение, что STM8 туда прикручивали по остаточному принципу.[/uquote]
попробуйте последний snapshot. Недавно делал проектик SDCC STM8 - код без правок копипастил для сравнения в ИАР, ИАР на ~100 байт меньше размер сделал. Оба варианта одинаково в железе работают. Никаких негативных ощущений не возникло, единственное SDCC при работе с битами периферии чудит (4 команды вместо bset/bres), решается проблема дополнительным peep файликом.

А по теме - GCC нынче "расширился" значительно, что иногда проще не переносить чужой код в другой компилятор. А GCC для микроконтроллеров сейчас делает вполне компактный выхлоп.
https://habrahabr.ru/post/315676/

oleg110592 писал(а):GCC нынче "расширился" значительно

жалко, что до сих пор для AVR не сделали пространство имен __eeprom аналогично тому, как сделали __flash.

ARV, по поводу трасировки, так как у вас дефайн log_i из кода, убираеться ?
Если он находится в debug.h то в релизной версии убирается и начинается ругань компилятора на неизвестную конструкцию. Как то так?

если макрос __DEBUG__ не определен, то все автоматически и убирается, ничего больше делать не надо.

Так так а вот про это по подробнее, как она автоматически убирается?
Допустим я использовал макрос log_i(x) где-то в майне, так вот после того как
выключаем макрос __DEBUG__ определение макроса log_i(x) убирается, при этом на пустую заглушку не изменяться.

по этому компилятор и выдаст ошибку на неизвестный дефайн(log_i(x)) так как он выключился.


PS:GCC не пользовался ни разу.

все макросы log_xxx продефайнены именно в обертке #if defined(__DEBUG__), поэтому при отсутствии этого макроса должны подставляться пустышки.