Микроконтроллеры STC: первые впечатления.
-
Serg S
- Родился
- Сообщения: 14
- Зарегистрирован: Пт сен 06, 2024 15:42:31
- Откуда: Заречный Свердловской
Re: Микроконтроллеры STC: первые впечатления.
Да уж. В мануале попозже от 2024/12/24 этого нет и версий две. А может я чего не увидел. На всех моих 'D'.
- Реклама
- Александр Д.
- Встал на лапы
- Сообщения: 113
- Зарегистрирован: Вс май 12, 2024 12:41:38
- Откуда: Подмосковье
Re: Микроконтроллеры STC: первые впечатления.
аналогично
но мои все не D точно
но мои все не D точно
Верните прошлое! там было такое прекрасное будущее...
Re: Микроконтроллеры STC: первые впечатления.
В ходе экспериментов с констукторами с Алиэкспресс написал библиотеку для работы с STC15W408AS https://github.com/mgoblin/STC15lib. В первую очередь для удобного использования в среде Platformio.
Пример одной из поделок с использованием библиотеки https://github.com/mgoblin/ElectronicHourGlassKit
Надеюсь, будет полезно.
Пример одной из поделок с использованием библиотеки https://github.com/mgoblin/ElectronicHourGlassKit
Надеюсь, будет полезно.
Последний раз редактировалось mgoblin Вт май 12, 2026 22:04:19, всего редактировалось 1 раз.
Re: Микроконтроллеры STC: первые впечатления.
////////////
Re: Микроконтроллеры STC: первые впечатления.
Написал сообщение, потом подумал, что поспешил, и удалил. Сделал другую плату, поставил контроллер с большим объемом памяти (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) очень не рекомендую.
Я тут выше высказывал много восхищений библиотекой 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) очень не рекомендую.
- Реклама
Re: Микроконтроллеры STC: первые впечатления.
Сегодня написал автор об этом баге. Через час он баг исправил и ответил:
Ваш анализ верен, спасибо за сообщение об ошибке!
gpio-hal изначально предназначался для упрощения работы с группами битов, поэтому я реализовал его именно таким образом.
Оказалось, что эта возможность оказалась полезной только при взаимодействии с параллельными модулями ЖК-дисплеев.
Я внес небольшую модификацию в gpio-hal.c, чтобы он использовал предложенную вами оптимизацию.
К сожалению, я больше не использую 8051, поэтому оставляю тестирование на ваше усмотрение.
Вот так вот. Можно дальше пользоваться =)
Ваш анализ верен, спасибо за сообщение об ошибке!
gpio-hal изначально предназначался для упрощения работы с группами битов, поэтому я реализовал его именно таким образом.
Оказалось, что эта возможность оказалась полезной только при взаимодействии с параллельными модулями ЖК-дисплеев.
Я внес небольшую модификацию в gpio-hal.c, чтобы он использовал предложенную вами оптимизацию.
К сожалению, я больше не использую 8051, поэтому оставляю тестирование на ваше усмотрение.
Вот так вот. Можно дальше пользоваться =)
Re: Микроконтроллеры STC: первые впечатления.
А сообщение о баге было примерно такое:
Недавно я столкнулся с одним багом, и мне кажется он лежит в основании всей библиотеки: это некорректная работа с 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;
-----
В обновленной версии автор сделал модификацию при использовании одного пина. Но при использовании группы пинов на одном порту баг сохранится.
Недавно я столкнулся с одним багом, и мне кажется он лежит в основании всей библиотеки: это некорректная работа с 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;
-----
В обновленной версии автор сделал модификацию при использовании одного пина. Но при использовании группы пинов на одном порту баг сохранится.
Re: Микроконтроллеры STC: первые впечатления.
Не очень понятно зачем автор UNI-STC читает состояние пинов всего порта, а только затем маской меняет один бит.ks0 писал(а): Пн май 25, 2026 17:45:34 При использовании P3_4 = 0 программа нормально работает, а при использовании gpioWrite(&gpioPwr, 0) UART пропадает.
В обновленной версии автор сделал модификацию при использовании одного пина. Но при использовании группы пинов на одном порту баг сохранится.
Пины порта ввода/вывода адресуются побитно. Это значит, что если нужно менять состояние одного пина, то можно и нужно писать в стиле P3_4 = 1 (установка пина в единицу) или P3_4 = 0 (сброс пина в ноль). Компилятор преобразует P3_4 = 1 в ассемблерную инструкцию SETB, а P3_4 = 0 в CLR. Просто, читаемо, эффективно, а не это вот ваше все gpioWrite(&gpioPwr, 0)
Re: Микроконтроллеры STC: первые впечатления.
обратить внимание на режимы "Чтение - Модификация - Запись"...
Весьма актуально для классики MCS51 и PICовых среднемладших.
Как работает у STC - надо документацию вычитывать, там ведь несколько регистров порт обслуживают...
Весьма актуально для классики MCS51 и PICовых среднемладших.
Как работает у STC - надо документацию вычитывать, там ведь несколько регистров порт обслуживают...


