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

[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]

[uquote="igor48",url="/forum/viewtopic.php?p=4663465#p4663465"]в процессе компиляции компилируются все добавленные в проект библиотеки, даже если они не были включены директивой #include.[/uquote]Директива #include - это не про добавление библиотек. Она про другое.

[uquote="igor48",url="/forum/viewtopic.php?p=4663465#p4663465"]Также использую Keil для STM32 - такой фигни нет.
...
Если объявить прототип и создать пустую реализацию функции, то код увеличивается на 1 байт.[/uquote]А на сколько он должен увеличиваться по вашему?
Да - в STM32 пустая функция занимает 2 байта. Так как команда BX LR - 2-байтовая.
Видимо в x51 возврат из функции - 1-байтовая команда. Логично?

[uquote="igor48",url="/forum/viewtopic.php?p=4663465#p4663465"]Если в main() вызвать эту пустую функцию, то код увеличивается еще на 3 байта.
Я не понимаю этого.[/uquote]Не очень понятно - что именно вас не устраивает? И сколько вы ожидали?
Очевидно 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]

[uquote="igor48",url="/forum/viewtopic.php?p=4663573#p4663573"]Я ожидал, что если функция не вызывается, то и место ей в памяти отводить не надо.
А если вызывается пустая функция, то компилятор должен сообразить, что нет никаких действий, ничего не надо вызывать и отводить место в памяти.[/uquote]Зачем гадать? Просто скомпилите проект, а затем загляните в полученные .lst-файлы и в .map-файл. Там всё должно быть видно.

[uquote="igor48",url="/forum/viewtopic.php?p=4663573#p4663573"]6. И самое главное - из-за всего вышеизложенного делать более-менее серьезный проект для STC из-под Keil не представляется возможным.[/uquote]Имхо - ядро x51 в настоящее время уже устаревшее и неактуальное. Вряд-ли стоит от компиляторо-строителей ожидать каких-то серьёзных усилий по оптимизации под него. Сами подумайте - как много народу его использует? А сколько из этого народу используют именно Кейл? А сколько из последних легально покупают этот самый Кейл, оплачивая работу разработчиков? Хрен целых 0 десятых? Вы то сами его купили?
А бесплатно никто работать не станет. Все кушать хотят.

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

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

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

[igor48]

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

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

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

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

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

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

[jcxz]

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

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

[igor48]

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

[Adrift]

[uquote="igor48",url="/forum/viewtopic.php?p=4663465#p4663465"]У меня:

µVision V5.38.0.0

Linker/Locator: BL51.exe V6.22.4.0[/uquote]
Тут такое написано: 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]

[uquote="ks0",url="/forum/viewtopic.php?p=4663880#p4663880"]Компилятор не вырезает неиспользуемые функции, т.к. не знает будет ли она использоваться или нет, возможно к ней будет вызов из другого файла. Он же для каждого си-файла делает свой объектный файл.
Задача убрать неиспользуемые функции лежит на компоновщике, надо его ключи смотреть.[/uquote]Чтобы компоновщик мог вырезать неиспользуемые функции/данные, надо чтобы компилятор создавал для каждой такой функции или блока данных отдельную секцию. Только в этом случае компоновщик сможет удалить её (так как манипулирует входными секциями целиком и не может вырезать из них куски). Вот такой ключ (помещать каждую функцию в отдельную свою секцию .obj-файла) и нужно найти и включить в компиляторе.
Иначе - для каждого файла исходного кода генерится одна секция. В которой находятся код всех функций этого файла в виде единой секции. И если хотя-бы одна из функций этой секции где-то используется, то вся секция будет включена в выходной образ прошивки. Даже если там 99 функций - не используется, а используется только одна.
С другой стороны - с точки зрения оптимальности (минимального размера кода) оптимальнее создавать единую секцию кода на один исходный файл. Поэтому - как именно будет поступать компилятор - неизвестно. Может поступать так или иначе. В зависимости от ключей оптимизации или каких-то своих внутренних правил.

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

Добавлено after 3 minutes 42 seconds:
[uquote="ks0",url="/forum/viewtopic.php?p=4663880#p4663880"]дед-код элиминейш работает всегда по умолчанию, если вы, например, сделал int a=10, а потом сразу a=20, то компилятор первое присваивание уберет.[/uquote]Современные оптимизирующие компиляторы - да. Но ядро x51 - устаревшее. Вряд ли у компиляторостроителей есть желание упираться ради мало кому нужного ядра. Поэтому не факт, что текущие компиляторы x51 делают даже такие простые оптимизации.
Писал уже выше об этом.

[smacorp]

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

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

[uquote="smacorp",url="/forum/viewtopic.php?p=4663908#p4663908"]Кто, как не сам программист, должен следить за ненужными функциями и неиспользуемыми переменными?![/uquote]Как кто? Компьютер, ав-то-ма-ти-чес-ки!

[uquote="smacorp",url="/forum/viewtopic.php?p=4663908#p4663908"]Есть подсказки компилятора о unused - хорошо, нет - сидим и самостоятельно вылизываем код, что можно делать хоть "глазками"[/uquote]"Камень мощный, успеет" (знакомый молодой разработчик)

[uquote="smacorp",url="/forum/viewtopic.php?p=4663908#p4663908"]повод задуматься о переквалификации в рубщики дров[/uquote]Эх. Сразу видна "старая школа".
Сейчас время-деньги!
"да не хочу я разбираться в этих регистрах! Скачал библиотеку- там всё есть. А что лишнего много и память жрёт как не в себе - так взял STM32 помощнее и всё ОК! Клиент заплатит, куда денется! Зато быстро сделал!" (всё тот же молодой знакомый)

[igor48]

Тут много раз высказывались про то, что ядро x51, на котором базируются STC, устаревшее. А в чем конкретно это будет проявляться при написании и исполнении кода? По сравнению с другими 8-разрядными МК и при равной тактовой частоте.

А вот по поводу "...взял STM32 помощнее и всё ОК! Клиент заплатит..." мне кажется как раз наоборот. В настоящее время новые производительные камни обычно и стоят дешевле. Пока разработчик "старой школы" будет по привычке разбираться в регистрах, "молодой" уже выполнит заказ и будет попивать пивко. Да, он будет использовать библиотеки типа SPL или даже HAL (вот негодяй) и у него останеться на 20% меньше свободной памяти. Зато продажи уже идут и заказчик тоже попивает мартини.

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

Частично соглашусь со второй частью Вашего сообщения. Иногда так и есть
Но на то надо иметь некий опыт проектирования, особенно на первой стадии - планировании.
Я не поленился и продумал алгоритм. Мой код работает на МК 8051 (в партии из 100 шт он стоит 3 юаня, грубо 45р), его - на каком-то STM32 за 850р. В год они продают 150-200 изделий.

Про "моральное устаревание" 8051
Был удивлён, но в применяемых мною компиляторах получилось весьма парадоксально: один и тот же код на ЯВУ, но скомпилированный под AVR и 8051, дал меньший по размеру bin именно под 8051. А когда я переписал SPI с программного на аппаратный, то и еще меньше.
Да, и про скорость: Тут вообще весело ))
Был код для AVR, тактовая - 16 МГц. Дисплей монохромный st7920 на SPI. Когда запустил на STC 8051 - дисплей не работал. Пришлось его тактовую снизить до 6 МГц.

а вообще, это уже халивары: кто stm8 хвалит, кто молится на STM32, а ретрограды типа меня фыркают и мимишкаются с avr и 8051

[jcxz]

[uquote="igor48",url="/forum/viewtopic.php?p=4664000#p4664000"]А в чем конкретно это будет проявляться при написании и исполнении кода? По сравнению с другими 8-разрядными МК и при равной тактовой частоте.[/uquote]В меньшей скорости исполнения и бОльшем объёме кода. В среднем.
В каких-то отдельных случаях, зная особенности ядра (систему команд, регистры и т.п.), конечно можно так написать код, что на данном конкретном ядре под конкретным компилятором этот код будет быстрее/меньше, чем на другом.

[uquote="igor48",url="/forum/viewtopic.php?p=4664000#p4664000"]Пока разработчик "старой школы" будет по привычке разбираться в регистрах, "молодой" уже выполнит заказ и будет попивать пивко. Да, он будет использовать библиотеки типа SPL или даже HAL (вот негодяй) и у него останеться на 20% меньше свободной памяти. Зато продажи уже идут и заказчик тоже попивает мартини.[/uquote]....а когда завтра обнаружится баг (внутри использованной "либы"), то попивавший пивко ничего с ним сделать не сможет. Ибо надо разбираться и в тоннах кода чужой "либы" и ещё + разбираться в регистрах. Чего он не умеет. И просто молча сольётся, кинув заказчика.
А написавший код сам (разбираясь в регистрах) найдёт и исправит баг. Ведь код он писал сам, а в своём коде разбираться многократно проще, чем в чужом. Да и разбираться нужно просто меньше (регистры он уже знает, и свой код - много меньше чем чужие "либы", так как написан под данную задачу, без всякого лишнего мусора).

И так как правило и случается всегда. А баги - они всегда были и будут.
Как правило такие кодонаписатели потом заявляют: "Баг не у меня, а в либе. И нужно подождать пока авторы либы его исправят". И заказчику приходится ждать неопределённое время или смириться с тем что есть.