Микроконтроллеры STC: первые впечатления.

[ks0]

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

[Shuspano]

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

[ks0]

Не могу понять назначение регистра 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 К) я что получаю?!
Экспериментальным путем я разницы в результатах не заметил.

[ks0]

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

[Kabron]

Свои 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. Запускам отладку

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

[octaprog]

Искал замену 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

[igor48]

Прошу помощи! Что я делаю не так?
Установил 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

[jcxz]

igor48 писал(а):

в процессе компиляции компилируются все добавленные в проект библиотеки, даже если они не были включены директивой #include.

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

igor48 писал(а):

Также использую Keil для STM32 - такой фигни нет.
...
Если объявить прототип и создать пустую реализацию функции, то код увеличивается на 1 байт.

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

igor48 писал(а):

Если в main() вызвать эту пустую функцию, то код увеличивается еще на 3 байта.
Я не понимаю этого.

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

[igor48]

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

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

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

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

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

[jcxz]

igor48 писал(а):

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

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

igor48 писал(а):

6. И самое главное - из-за всего вышеизложенного делать более-менее серьезный проект для STC из-под Keil не представляется возможным.

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

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

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

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

[igor48]

Если хочется поработать с 8-битниками, то имхо - лучше взять

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

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

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

это функция оптимизации не компилятора, а компоновщика. Может стоит поискать среди ключей компоновщика

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

[jcxz]

igor48 писал(а):

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

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

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

[igor48]

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

[Adrift]

igor48 писал(а):

У меня:

µVision V5.38.0.0

Linker/Locator: BL51.exe V6.22.4.0

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

[igor48]

Linker optimizations are performed by the LX51 Linker only

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

[ks0]

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

[jcxz]

ks0 писал(а):

Компилятор не вырезает неиспользуемые функции, т.к. не знает будет ли она использоваться или нет, возможно к ней будет вызов из другого файла. Он же для каждого си-файла делает свой объектный файл.
Задача убрать неиспользуемые функции лежит на компоновщике, надо его ключи смотреть.

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

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

Добавлено after 3 minutes 42 seconds:

ks0 писал(а):

дед-код элиминейш работает всегда по умолчанию, если вы, например, сделал int a=10, а потом сразу a=20, то компилятор первое присваивание уберет.

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

[smacorp]

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

[Александр Д.]

smacorp писал(а):

Кто, как не сам программист, должен следить за ненужными функциями и неиспользуемыми переменными?!

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

smacorp писал(а):

Есть подсказки компилятора о unused - хорошо, нет - сидим и самостоятельно вылизываем код, что можно делать хоть "глазками"

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

smacorp писал(а):

повод задуматься о переквалификации в рубщики дров

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