Программирование STM8

[Asmodey]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3764772#p3764772"]а читать нечего.[/uquote]
А я даташит на STM8L151 читал, RM читал, интернет читал, но так и не разобрал, возможно ли тактирование МК от внутреннего генератора с внешней частотозадающей RC цепочкой? Например, задать частоту LSE OSC подключая резисторы и конденсаторы к выводам OSC32_OUT и OSC32_IN.

[shads]

Привет котофеи!
Я тут во всю использую STM8S + IAR, полет нормальный, но достает одно обстоятельство, хочу вас попытать, мож подкинете ценной инфы...
Суть в том что у меня один базовый проект в котором дефайнами включаются, выключаются разные модули, ну то бишь функционал нужный задействую...
В том числе иногда использую разные контроллеры, либо STM8S003 либо STM8S103... так вот для смены контроллера, кроме того что я настраиваю в дефайнах параметры памяти под соответствующий контроллер, так потом еще приходится лезть в настройки проекта, и указывать там сам контроллер...
Есть ли вариант определять контроллер не в настройках проекта, а так же дефайнами чтобы при компиляции, компилятор сам определил какой контроллер нужно использовать ?
Или это уже от лукавого хотелки?)))
Просто если бы я а майне поправил несколько дефайнов то это было бы намного комфортнее, чем каждый раз лазить в разных местах...

[VladislavS]

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

#if defined(STM8S003)
  //
  // Код для STM8S003
  //
#elif defined(STM8S103) 
  //
  // Код для STM8S103
  //
#else
  #error "Controller type not defined"
#endif

[shads]

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

[Eddy_Em]

У 003 и 103 периферия почти не отличается, поэтому можно в Makefile сделать простую проверку для включения нужных опций sdcc и дефайнов, а компилять с make -D_103 или make -D_003 …

[VladislavS]

[uquote="shads",url="/forum/viewtopic.php?p=3788731#p3788731"]Я тут во всю использую STM8S + IAR,[/uquote]
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3788814#p3788814"]для включения нужных опций sdcc[/uquote]Ты хоть когда-нибудь будешь читать что люди пишут?

[Eddy_Em]

Дурной какой-то движок у форума: свое сообщение удалить нельзя…

[Asmodey]

Удалить можно, но только до тех пор, пока кто-то не запостил сообщение ниже твоего.

[Eddy_Em]

Asmodey, я не нашел, где нужная "галочка" или "кнопочка". И даже когда после моего сообщения ничего нет, удалить не могу.
Вот так напишу дурь какую-нибудь, потом передумаю - а фигвам! Не удалишь сообщение... Остается лишь отредактировать и написать другую дурь.
P.S. Чьорт побьери! Не увидел...

[Z_h_e]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3789342#p3789342"]Asmodey, ... Остается лишь отредактировать и написать другую дурь.[/uquote] Напишите вместо дури "del" и все поймут.

[musor]

это зашита ядра от тролизма
есть любители задним числом править старые посты...

[Asmodey]

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

Вопрос возник в ходе экспериментов с автоматическим переключением источников тактового сигнала. Микроконтроллер STM8L151 на беспаечной макетке в которую воткнут кварцевый резонатор 4 МГц. Микроконтроллер мигает светодиодом посредством таймера TIM1 предделитель и регистры ARRx которого настроен так, что светодиод мигает с периодом 4 секунды. Сначала я подумал, что железо само решит, когда ему начинать тактирование CPU и прочего и установил следующие настройки переключения тактового сигнала.

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

  
  CLK_SWR = 0x04; // Тактирование от высокочастотного кварцевого генератора HSE
  
  CLK_SWCR_bit.SWEN = 1; // Разрешить переключение источников тактового сигнала
  
  CLK_CSSR_bit.CSSEN = 1; // Разрешить аварийное автоматическое переключение источников тактового сигнала 

В результате выполнения этого система тактирования тут же переключается на внутренний высокочастотный RC-генератор с частотой 16 МГц, что проявляет себя увеличением частоты мигания светодиода в 4 раза, с периодом 1 секунда.

Немного поразмыслив я решил, что железо само по себе ничем тут не рулит, и микроконтроллер переключается на внутренний RC-генератор из-за того, что к моменту выполнения CLK_CSSR_bit.CSSEN = 1; кварцевый генератор продолжает колбасить по всякому после включения. Сделал программную задержку до поднятия флага HSERDY в регистре CLK_ECKR.

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

  CLK_SWR = 0x04; // Тактирование от высокочастотного кварцевого генератора HSE
  
  CLK_SWCR_bit.SWEN = 1; // Разрешить переключение источников тактового сигнала
  
  while(CLK_ECKR_bit.HSERDY == 0){} // Задержка до поднятия флага HSERDY (установившийся режим тактового генератора)
  
  CLK_CSSR_bit.CSSEN = 1; // Разрешить аварийное автоматическое переключение источников тактового сигнала 

Теперь все работает корректно, светодиод мигает с частотой 0,25 Гц до тех пор, пока я не выдергиваю кварц из макетки. После удаления кварца светодиод начинает мигать с частотой 1 Гц. Значит микроконтроллер переходит на тактирование от внутреннего RC-генератора только после аварии генератора кварцевого, как и задумывалось.

То есть, необходимо непременно контролировать состояние флага HSERDY вплоть до устаканивания работы кварцевого генератора, если разрешено автоматическое переключение источников тактового сигнала? Я правильно понял?

[Asmodey]

С огромным энтузиазмом занялся сегодня изучением шины I2C в STM8 и... кажется спалил микроконтроллер. Или не спалил... Подключил к линиям SDA и SCL STM8L151 самодельный анализатор протоколов PICkit Serial Analyzer, но поторопился и перепутал провода. Надо было назначение выводов PKSA напечатать на бумажке и наклеить на корпус, а я поленился. Кажется подал +3,3 (а возможно и +5) питания на линию SCL микроконтроллера. Как теперь определить, сдох I2C модуль в МК или нет?

Попробовал "дергать" ногами порта соответствующим шине I2C. Вроде все нормально, импульсы присутствуют. Как думаете, сдох I2C интерфейс или нет?

[GARMIN]

I2C использует обычные порты. Если они дёргаются из под программы, то остальное должно быть исправно.

[Asmodey]

Действительно, работает. После ковыряния в коде I2C стал подавать признаки жизни. Спасло его то, что забыл я включить тактирование I2C модуля, без чего бит PE не устанавливался, модуль не включался и линии портов оставались в состоянии входа.
/не забыть бумажку распечатать на корпус анализатора последовательных протоколов/

[PombI4]

Всем доброго дня!
Изучаю stm8s-discovery и при работе с uart'ом столкнулся с проблемой. Сделал функцию синхронной отправки байта... С ее помощью отправляю строку.
При отправке строки, пропадает первый символ (байт).

Условно говоря, я отправляю в uart строку "Hello world!", а приходит - "ello world!"

Проблема проявляется только при отправке первого символа после подачи питания на отладочную плату. На любых скоростях.

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

Содержимое функции отправки байта простое:
- Кладем в регистр DR байт
- Ждем окончания передачи выставлением флага TC в статусном регистре...

В чем может быть проблема?

[oleg110592]

TC: Transmission complete This clear sequence is recommended only for multibuffer communications
TXE: Transmit data register empty This bit is set by hardware when the content of the TDR register has been transferred into the shift register.

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

// Отправка байта
void uart_tx_byte(unsigned char data)
{
  while(!UART1_SR_TXE);
  UART1_DR = data;
}

[PombI4]

Спасибо...
Т.е. еще есть задержка между записью байта в регистр DR и его копированием в сдвиговый регистр...

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

[oleg110592]

В документации есть же, попробовал гуглом перевести:
Однобайтовая связь
Очистка бита TXE всегда выполняется путем записи в регистр данных.
Бит TXE устанавливается аппаратно и указывает:
• Данные были перемещены из TDR в регистр сдвига, и передача данных началась.
• Регистр TDR пуст.
• Следующие данные могут быть записаны в регистр UART_DR без перезаписи предыдущих данных.
Этот флаг генерирует прерывание, если установлен бит TIEN.
Когда происходит передача, инструкция записи в регистр UART_DR сохраняет данные в регистр TDR.
Данные копируются в регистр сдвига в конце текущей передачи.
Когда передача не происходит, инструкция записи в регистр UART_DR помещает данные непосредственно в регистр сдвига, начинается передача данных, и бит TXE устанавливается немедленно.
Если передача кадра завершена (после стоп-бита) и установлен бит TXE, устанавливается бит TC.
Прерывание генерируется, если TCIEN установлен в регистре UART_CR2.
После записи последних данных в регистр UART_DR необходимо дождаться, пока для TC будет установлено значение «1», прежде чем переходить в режим остановки или отключать UART.
Для сброса бита TC требуется следующая программная последовательность:
1. Считать из регистра UART_SR
2. Записать в регистр UART_DR
(см. Рис. 116: поведение TC / TXE при передаче)
далее симпатичная картинка с диаграммами

[PombI4]

Все заработало. Спасибо!