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

[Serg S]

Да уж. В мануале попозже от 2024/12/24 этого нет и версий две. А может я чего не увидел. На всех моих 'D'.

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

аналогично
но мои все не D точно

[mgoblin]

В ходе экспериментов с констукторами с Алиэкспресс написал библиотеку для работы с STC15W408AS https://github.com/mgoblin/STC15lib. В первую очередь для удобного использования в среде Platformio.


Пример одной из поделок с использованием библиотеки https://github.com/mgoblin/ElectronicHourGlassKit

Надеюсь, будет полезно.

[ks0]

////////////

[ks0]

Написал сообщение, потом подумал, что поспешил, и удалил. Сделал другую плату, поставил контроллер с большим объемом памяти (STC8H1K17). Ниже будет понятно почему. На новой плате убрал ошибки, все провода и сопли, все облепил конденсаторами. Получил тот же результат. Первоначальное сообщение:

Я тут выше высказывал много восхищений библиотекой uni-STC. Но убив на отладку простейших программ уже наверно десятки часов, мое восхищение рассеялось. Не то чтобы она косячная. Но в ней есть недоработки. И без широкого использования они так и останутся скрытыми и каждый следующий пользователь будет огребать на ровном месте.
Блокирующие вызовы, который могут повесить всю программу. Это сплошь и рядом, не только здесь. Отсутствие запрета на прерывания при некоторых критических операциях. Последней каплей стал неожиданный фокус когда при записи в порт P3.4 отваливался UART с портов P3.0, P3.1. Как оказалось банальная запись P3_4 = 0 работает, а библиотечная gpioWrite(&gpioPwr, 0) вызывает перезапись всего порта P3. И фиг знает почему, но на этих контроллерах при полной перезаписи порта, на котором активна альтернативная функция (по крайне мере UART1) этот самый UART1 отваливает.
Честно говоря с модулем gpio_hal, который должен бы быть простейший, автор сильно перемудрил. Это один из самых сложных файлов для восприятия из всей библиотеки.
А дисплейный драйвер с несколькими уровнями абстракции я и смотреть не хочу уже.
К слову об уровне абстракции uni-STC. Практически для нее контроллеры с 8 кб флеша непригодны. У меня любая программа получалась от 7 кб. Если я делаю вывод отладочной информации через puts или putchar она становится впритык к 8 кб. printf сразу выводит ее свыше 8. А программа еще ничего не делает. Только дрыгает ножками и выводит что-то на UART.
*************
Для серьезного применения я её (uni-STC) очень не рекомендую.

[ks0]

Сегодня написал автор об этом баге. Через час он баг исправил и ответил:
Ваш анализ верен, спасибо за сообщение об ошибке!
gpio-hal изначально предназначался для упрощения работы с группами битов, поэтому я реализовал его именно таким образом.
Оказалось, что эта возможность оказалась полезной только при взаимодействии с параллельными модулями ЖК-дисплеев.
Я внес небольшую модификацию в gpio-hal.c, чтобы он использовал предложенную вами оптимизацию.
К сожалению, я больше не использую 8051, поэтому оставляю тестирование на ваше усмотрение.

Вот так вот. Можно дальше пользоваться =)

[ks0]

А сообщение о баге было примерно такое:
Недавно я столкнулся с одним багом, и мне кажется он лежит в основании всей библиотеки: это некорректная работа с gpio.
Я использовал для отладки вывод на serial (P3.0, P3.1) и при этом включал ключ через порт P3.4. При записи в порт P3.4 нуля у меня пропал вывод на UART.
Контроллер STC8H1K17. Программа имеет примерено такой вид:

GpioConfig gpioPwr = GPIO_PIN_CONFIG(GPIO_PORT3, GPIO_PIN4, GPIO_BIDIRECTIONAL_MODE);
int main()
{
INIT_EXTENDED_SFR();
gpioConfigure(&gpioPwr);
serialConsoleInitialise(UART1, 9600, 0);
EA = 1;
puts("Hello");
while(1)
{
//gpioWrite(&gpioPwr, 0); // Incorrect(?!)
P3_4 = 0; // Correct(?!)
...
puts("...");
delay1ms(300);
P3_4 = 1;
}
}


При использовании P3_4 = 0 программа нормально работает, а при использовании gpioWrite(&gpioPwr, 0) UART пропадает.
По мнению чат-ботов это вызвано тем, что функция gpioWrite читает физический уровень на выводе и переписывает регистр-защелку (latch), в котором всегда должно быть записано 1, иначе альтернативные функции, которые используют тот же порт могут перестать работать.
Некоторые документы на 8051 рекомендуют использовать записи вида P3 |= 0x01 (они это называют read-modify-write командами) и очень не рекомендуют прием, который используется в gpioWrite(), а именно:

unsigned char temp;
temp = P3;
temp |= 0x01;
P3 = temp;

-----

В обновленной версии автор сделал модификацию при использовании одного пина. Но при использовании группы пинов на одном порту баг сохранится.

[mgoblin]

При использовании P3_4 = 0 программа нормально работает, а при использовании gpioWrite(&gpioPwr, 0) UART пропадает.

В обновленной версии автор сделал модификацию при использовании одного пина. Но при использовании группы пинов на одном порту баг сохранится.

Не очень понятно зачем автор UNI-STC читает состояние пинов всего порта, а только затем маской меняет один бит.

Пины порта ввода/вывода адресуются побитно. Это значит, что если нужно менять состояние одного пина, то можно и нужно писать в стиле P3_4 = 1 (установка пина в единицу) или P3_4 = 0 (сброс пина в ноль). Компилятор преобразует P3_4 = 1 в ассемблерную инструкцию SETB, а P3_4 = 0 в CLR. Просто, читаемо, эффективно, а не это вот ваше все gpioWrite(&gpioPwr, 0)

[BOB51]

обратить внимание на режимы "Чтение - Модификация - Запись"...
Весьма актуально для классики MCS51 и PICовых среднемладших.
Как работает у STC - надо документацию вычитывать, там ведь несколько регистров порт обслуживают...

[ks0]

Не очень понятно зачем автор UNI-STC читает состояние пинов всего порта, а только затем маской меняет один бит.

Функции позволяют конфигурировать и менять сразу группу бит на одном порту. Это у меня один требовался. Как чаще всего.

Автор ответил, что "gpio-hal изначально предназначался для упрощения работы с группами битов, поэтому я реализовал его именно таким образом. Оказалось, что эта возможность оказалась полезной только при взаимодействии с параллельными модулями ЖК-дисплеев."
В библиотеки довольно развесистый драйвер дисплеев, который и с графическими и с символьными работает, и по разным интерфейсам.
А для большинства реальных задач gpio-hal получился сильно замороченный. Именно внутри, а не снаружи. Снаружи все просто.

Про Чтение - Модификация - Запись в доках STC я ничего не нашел. Нашел в доках Atmel и Scilab.

[BOB51]

ЧМЗ (R-M-W) относится к ряду команд системы команд MCS51 (описание ищем в документации по системе команд).
В кратце для "стандартной" mcs51 это звучит так
"...чтение защелки порта -
модификация считанного -
запись в защелку порта..."
У "прародителей" есть, следовательно и для всех копирайтеров вполне может соблюдаться.
Жаль файлы документации велики (и сундук пока не работает)...

[ks0]

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

Докладываю)
За несколько месяцев я локальные файлы с репозитория автора не обновлял, а вот сегодня обновил, чтобы протестировать вчерашнее исправление. Но там накопились и другие. Сперва программа не собралась вообще, т.к. автор переименовал макросы (нафига, спрашивается). Потом собралась. GPIO заработал как надо, но ... отвалился I2C! Изменений в разных файлах было так много, что я с ходу причины найти не смог. Сперва они мне казались в основном косметическими. Начал подкидывать измененные файлы по частям. И, блин, причина опять где-то в этом gpio_hal. Там че-то опять намудрили с масками.

[mgoblin]

Не очень понятно зачем автор UNI-STC читает состояние пинов всего порта, а только затем маской меняет один бит.

А для большинства реальных задач gpio-hal получился сильно замороченный. Именно внутри, а не снаружи. Снаружи все просто.

Вот это очень правильный вывод про излишнюю замороченность.
Что на мой взгяд заморочено конкретно
Размер прошивки:
1. Компилятор SDCC не вырезает из файлов исходного кода в одном файле не используемые функции. При использовании в прошивке только части функционала gpio, в прошивку "зелезает" код всего модуля
2. При передаче в функцию ссылки в качестве параметра (&) компилятор генерирует достаточно много служебного кода. Это утверждение нужно проверить в новых версиях компилятора SDCC, но опять же размер прошивки начинает расти на ровном месте
Перемешаны стили работы с отдельными пинами и портом в целом

А как правильно?
- Вся игра в инициализацию режима работы пинов идет вокруг группы регистров PxM0 и PxM1, где x - номер порта. Каждый бит соответствует пину порта.
- Вся игра в запись пина идет вокруг Px_y = 0; Px_y = 1; Px_y = !Px_y, где x - номер порта, y - номер пина
- Вся игра в чтение пина идет вокруг uint8_t pin_value = Px_y; В переменную будет записаано или 0 или 1
- Если нужно поработать с портом целиком
1. Если какие то из пинов заняты периферией (UART, ADC итд), то не надо пытаться их использовать как GPIO (пины ввода/вывода общего назначения). Вы это прекрасно продемонстрировали. Пытаемся писать/читать пины, используемые UART - и UART перестает работать
2. Чтение всех пинов порта uint8_t port_value = P3, запись - P3 = 0x55;
3. Если нужно поработать с частью пинов порта как с одним целым - см про игру с пинами порта и учет п.1. Для особо одаренных возможно использование variadic функции и макросы в помощь.

При этом GPIO для микроконтроллеров одной серии (STC8) совместим внутри серии и не сильно отличается между сериями (по крайней мере между STC15 и STC8)
Собственно я попытался учесть вышеописанные грабли UNI-STC.

Вот библиотечный код инициализации GPIO STC15 https://github.com/mgoblin/STC15lib/blo ... ude/gpio.h в виде макросов. Для чтения/записи отдельных пинов и порта целиком никакого библиотечного кода не нужно.

В сухом остатке получаем код вида

Код: Выделить всё

/**
 * How to init pin (P14) in input only mode
 */

#include <stdint.h>
#include <gpio.h>

void main()
{
    // Инициализация пина P1.4 в режиме "только чтение" цифровых значений (0/1)
    pin_input_only_init(P1, 4);

    while (1)
    {
	uint8_t value = P14;
	// Далее можно писать обработку значения пина P1.4
    }
    
}

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