STC-ISP это программа для прошивки? Убунту у меня, я без нее. И насколько знаю все заголовочные файлы и примеры от производителя идут для Кейла.
Вот такой проект нашел https://codeberg.org/20-100/uni-STC
Буду смотреть. Хотя хотелось бы в одном файле, без вот этого развесистого дерева.

Инклюды STC8G и STC8H из STC-ISP (V6.94K). Для кейла, иара, sdcc и ассемблера.
STC-ISP рекрасно под вайном работает. Сделать winetricks mfc42, а если создать симлинк на /dev/ttyUSB0 под именем com-порта с любым свободным номером в ~/.wine/dosdevices/ - то даже шьет.

Не могу понять назначение регистра ADCTIM (АЦП). Конкретно на STC8G.
Делитель задается в регистре ADCCFG. Но зачем нужен ADCTIM?
Написано: ADC timing control register (ADCTIM)
бит: CSSETUP: ADC channel selection time control Tsetup
биты: CSHOLD[1:0]: ADC Channel selection hold time control Thold
биты: SMPDUTY[4:0]: ADC analog signal sampling time control Tduty (Note: SMPDUTY must not be less than 01010B)

Потом приводит диаграмма, в которой видно, что время работы АЦП складывается двух этапов. Что выполняется на первом этапе?

Добавлено after 4 minutes 34 seconds:
И в догонку еще один вопрос по АЦП. Указано, что The maximum speed of the STC8G series ADC is 800K for 12-bit ADC (800,000 ADC conversions per
second), and 500K for 10-bit ADC (500,000 ADC conversions per second)
Но я не вижу, чтобы в регистрах задавалась разрядность, которая мне нужна. А по окончании конвертации сразу выставляется бит ADC_FLAG в регистре ADC_CONTR.
А какая разрядность получена-то?! А если я на 24 МГц запускаю АЦП с делителем 32 (это 750 К) я что получаю?!
Экспериментальным путем я разницы в результатах не заметил.

Вообщем по первому вопросу более-менее понятно.
Вот здесь статья есть https://developerhelp.microchip.com/xwi ... tion-time/
В ней сказано, что sampling time требуется для заряда конденсатора, на котором будет производится измерение, и зависит от выходного импеданса источника сигнала. Регистр добавлен в STC8G или может STC8A, в ранних контроллерах его не было.

Свои 5 копеек. Отладка с помощью Monitor-51
1. Монитор загружается из оболочки программирования AIapp-ISP-vX.XXX.exe на вкладке Keil ICE Settings -> Set targe MCU as ICE
2. В Кейле на вкладке Options -> Debug выбираем STC Monitor-51 Driver. В Settings указываем порт и скорость (57600 или 115200)
3. Запускам отладку

Отладка у меня плохо работает с точками останова, зато пошагово - отлично.

Искал замену AVR MCU. Почитал тему. Windows у меня нет, поэтому искал IDE for MCS-51 для Linux. Нашел "An embedded development environment for mcs51/stm8/avr/cortex-m/riscv on VsCode."
Это плагин для VsCode - "A c/c++ development environment for mcs51/stm8/cortex-m/riscv microcontrollers".
https://github.com/github0null/eide
https://em-ide.com/

В качестве компилятора можно установить SDCC.
Требуется установка NET 6 runtime (инструкция по установке dot net: https://stackoverflow.com/questions/740 ... -debian-11),
нужны aspnetcore-runtime, dotnet-runtime.

Заголовочные файлы: https://github.com/cch1997/SDCC-STC-header-file

HEX файл blink получил.

создал раздел по STC
Пишу на Bascom-51
http://bascomavr.bbok.ru/viewforum.php?id=58
Пробовал несколько МК, очень доволен документацией!
STC8H1K08, STC8H1K28 и STC8H8K64U

Прошу помощи! Что я делаю не так?
Установил Keil uVision5, настроил на работу с STC, решил попробовать готовые библиотеки с сайта STC.
И тут возникло непредвиденное: в процессе компиляции компилируются все добавленные в проект библиотеки, даже если они не были включены директивой #include. При этом настройка оптимизации C51 = 1 Dead Code Elimination абсолютно не помогает.
Также использую Keil для STM32 - такой фигни нет.

Идем дальше. Библиотеки вообще не причем. Все еще хуже.
Если объявить прототип и создать пустую реализацию функции, то код увеличивается на 1 байт.
Если в main() вызвать эту пустую функцию, то код увеличивается еще на 3 байта.
Я не понимаю этого.

Кто нибудь пробовал программировать MCU STC в Keil uVision5 С51 (как и рекомендует производитель)?
У вас такого нет? Какой версией Keil кто пользуется.

У меня:

µVision V5.38.0.0

Tool Version Numbers:
Toolchain: PK51 Prof. Developers Kit Version: 9.60.7.0
Toolchain Path: C:\Keil_v5\C51\BIN
C Compiler: C51.exe V9.60.7.0
Assembler: A51.exe V8.2.7.0
Linker/Locator: BL51.exe V6.22.4.0
Librarian: LIB51.exe V4.30.1.0
Hex Converter: OH51.exe V2.7.0.0
CPU DLL: S8051.DLL V3.125.1.0
Dialog DLL: DP51.DLL V2.69.0.0

Директива #include - это не про добавление библиотек. Она про другое.

А на сколько он должен увеличиваться по вашему?
Да - в STM32 пустая функция занимает 2 байта. Так как команда BX LR - 2-байтовая.
Видимо в x51 возврат из функции - 1-байтовая команда. Логично?

Не очень понятно - что именно вас не устраивает? И сколько вы ожидали?
Очевидно 3 байта это: 1байт(пустая_функция) + 2байта(команда_её_вызова). Логично?

Я привык к хорошему. Если библиотека и добавлена в структуру проекта, но никуда не включена директивой #include, ее и компилировать ее нечего.

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

Добавлено after 1 minute 36 seconds:
Повозился с этим вопросом и пришел к неутешительным выводам. Получается какое-то программирование вроде на Си, но явно в стиле ассемблера. Нельзя сказать, что оптимизация не работает вообще - размер кода на выходе меняется при изменении уровня оптимизации, но оптимизация какая-то странная:
1. Если уж создал функцию, то будь добр ее использовать. Место в памяти она будет занимать по любому.
2. Объявил переменную (обычную, не volatile) – место в памяти она будет занимать, даже если ее не использовать.
3. Объявил переменную (обычную, не volatile) и три раза подряд совершил с ней некоторые действия (например, логические операции с битовыми масками) – все это прямиком летит в исполняемый код. Компилятор совершенно не в силах просчитать и вычислить результат заранее.
4. Из-за этих особенностей практически невозможно использовать библиотеки, любезно предоставленные STC. Они написаны очень универсально и без оптимизации неиспользуемого кода занимают совершенно невменяемое количество памяти.
5. Похоже в STC ужа сами сообразили, что что-то не так. В библиотеках для STC8 (в отличии от более старых библиотек для STC15) широко используются директивы условной компиляции (чтобы хоть как-то минимизировать проблему).
6. И самое главное - из-за всего вышеизложенного делать более-менее серьезный проект для STC из-под Keil не представляется возможным.

Зачем гадать? Просто скомпилите проект, а затем загляните в полученные .lst-файлы и в .map-файл. Там всё должно быть видно.

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

PS: Если хочется поработать с 8-битниками, то имхо - лучше взять STM8. Но и на нём не стоит ожидать оптимизации кода, сравнимой с оптимизацией для ARM-процессоров.
Если же хочется максимальной оптимизации и максимальных возможностей компиляторов, то следует выбирать самые массовые ядра. Т.е.: ARM, x86, etc. Естественно что компиляторы под них максимально вылизываются.

PPS: Если же хочется максимально оптимального кода для 8-битника, то нужно садиться изучать его ассемблер.

PPPS: Кстати - то что вы хотите (исключение неиспользуемого кода/данных) - это функция оптимизации не компилятора, а компоновщика. Может стоит поискать среди ключей компоновщика - что вы не включили? Может там можно разрешить удалять неиспользуемый код/данные. Я сам давно Кейл не использовал....

Да мне, собственно, хотелось именно на STC по причине их копеечной цены и наличия в корпусе DIP40. Наоборот, пранировал перести проект с другого МК.

Хочется не максимально оптимального кода, а хотя бы чтобы неиспользуемые функции не попадали в прошивку. Я уже понял, что компилятор наверное так и застрял в 80-х.

Я совершенно не спорю.
Чем мне казался удобен кейл, это что не надо самому заполнять make файлы и тому подобное. Поставил в нужном месте галочку - и готово.
А тут вроде и галочка на привычном месте есть, и по описанию должна делать то, что нужно, но результата нет.
Вот я и прошу подсказать, может кто знает, что мне конкретно нужно сделать. Или это так и должно быть и остается только смириться.

Совершенно не понимаю...
Вижу - STC в DIP40 на ~600руб. Вы про него?
Так на том же али есть куча отладочных плат на STM8S103F3P6 по цене в 6 раз ниже. По размерам - примерно такой же DIP (ширина, шаг - такие же; правда ног меньше).
Ну и самое главное: STM8 имеет внутрисхемный отладчик/эмулятор. Как в ARM-ах. А значит перенос/отладка кода на нём будет на порядок проще/быстрее, чем на x51.
Да и на "народном" STM32F103 там тоже куча дешёвых плат примерно такого же размера.

Если уж переносить на другой МК, то лучше на STM8 или ARM, а не на древний неудобный x51. Смысла нет в наше время писать/адаптировать какой-то код для x51. Кроме особых случаев (типа CY7C68013A).

Ну, во первых меня заинтересовала позиция 5 шт. за 500 руб.
А во вторых, наш с вами разговор потерял всякий смысл. Я прошу помощи в решении конкретной технической проблемы, если оно есть. А вы мне пытаетесь советовать куда идти и чем заняться, с чем я вполне могу справиться и сам.
Все, что вы написали в последнем сообщении, мне вполне известно.

Тут такое написано: Linker optimizations are performed by the LX51 Linker only. The BL51 Linker does not perform any optimizations.

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

Компилятор не вырезает неиспользуемые функции, т.к. не знает будет ли она использоваться или нет, возможно к ней будет вызов из другого файла. Он же для каждого си-файла делает свой объектный файл.
Задача убрать неиспользуемые функции лежит на компоновщике, надо его ключи смотреть.
дед-код элиминейш работает всегда по умолчанию, если вы, например, сделал int a=10, а потом сразу a=20, то компилятор первое присваивание уберет. Также недостижимые блоки внутри функции тоже уберет, например
if(a>10) ...
else if(a<=10) ...
else что-то уже уберет, если а не volatile.

Чтобы компоновщик мог вырезать неиспользуемые функции/данные, надо чтобы компилятор создавал для каждой такой функции или блока данных отдельную секцию. Только в этом случае компоновщик сможет удалить её (так как манипулирует входными секциями целиком и не может вырезать из них куски). Вот такой ключ (помещать каждую функцию в отдельную свою секцию .obj-файла) и нужно найти и включить в компиляторе.
Иначе - для каждого файла исходного кода генерится одна секция. В которой находятся код всех функций этого файла в виде единой секции. И если хотя-бы одна из функций этой секции где-то используется, то вся секция будет включена в выходной образ прошивки. Даже если там 99 функций - не используется, а используется только одна.
С другой стороны - с точки зрения оптимальности (минимального размера кода) оптимальнее создавать единую секцию кода на один исходный файл. Поэтому - как именно будет поступать компилятор - неизвестно. Может поступать так или иначе. В зависимости от ключей оптимизации или каких-то своих внутренних правил.

Так что в общем случае - отключение неиспользуемого кода при помощи препроцессора (#if...#endif) должно давать более компактный код в любом случае. Так как в этом случае: ненужный код исключается на этапе препроцессинга (компилятором); бОльшее число функций объединяется в более крупные секции .obj-файла; код становится короче и быстрее за счёт оптимизации размерностей переходов/вызовов п/п. Особенно это касается слабых 8-битников.

Добавлено after 3 minutes 42 seconds:
Современные оптимизирующие компиляторы - да. Но ядро x51 - устаревшее. Вряд ли у компиляторостроителей есть желание упираться ради мало кому нужного ядра. Поэтому не факт, что текущие компиляторы x51 делают даже такие простые оптимизации.
Писал уже выше об этом.

Довольно странно видеть "страдания" по поводу недостаточной "умности" компилятора. Кто, как не сам программист, должен следить за ненужными функциями и неиспользуемыми переменными?! Есть подсказки компилятора о unused - хорошо, нет - сидим и самостоятельно вылизываем код, что можно делать хоть "глазками", хоть самодельным парсером. А если подобные сложности вызывают негативные эмоции, это повод задуматься о переквалификации в рубщики дров - одна из немногих профессий, где никогда (или редко) нужно заботиться об уборке за собой мусора.

Как кто? Компьютер, ав-то-ма-ти-чес-ки!

"Камень мощный, успеет" (знакомый молодой разработчик)

Эх. Сразу видна "старая школа".
Сейчас время-деньги!
"да не хочу я разбираться в этих регистрах! Скачал библиотеку- там всё есть. А что лишнего много и память жрёт как не в себе - так взял STM32 помощнее и всё ОК! Клиент заплатит, куда денется! Зато быстро сделал!" (всё тот же молодой знакомый)