FAQ по STM8

[MikeF]

Столкнулся с забавным расположением данных в hex и s19 файлах генерируемых Cosmic - адреса идут не по порядку, а блоками в перемешку. Например так:

:0890800000000096000003E966
:20908B00AE17FF9490CE9088AE908AF62725A5602717BF08E E03BF0BBE08EE0190F6F75C9A
:2090AB00905C90B30B26F5BE08909390EE031C000520D8AE0 0002002F75CA3000E26F9AE2C
:2090CB0001002002F75CA3010026F9CD90DB20FE350850C67 2185011721850123506530C32
:2090EB00725F530D357D530E7214530072105304721053017 21053009AAE0000CD918BAEE5
:20910B009080CD915B24067218500F20047219500FAE0000C D918BAE9084CD915B25DAAE9B
:20912B000000BF02AE0000BF0020CE8080808080808080808 0808080AE0000A601CD917B5A
:20914B0072115302808080808080808080808080B604F1261 AB605E101260CB606E10226AD
:20916B0006B607E10327089C2403A6FF81A60181EB03E7032 4096C0226056C0126017C81CE
:12918B0088F6B704E601B705E602B706E603B7078481A5
:209000008200908B8200913782009138820091398200913A8 200913B8200913C8200913D98
:209020008200913E8200913F8200913682009136820091408 20091418200914282009143A9
:2090400082009150820091518200915282009153820091548 20091558200915682009157DC
:2090600082009158820091598200915A82009136820091368 200913682009136820091363F
:03908800908B00CA
:00FFFF0101

Хотя казалось бы логичным чтобы адреса в файле следовали линейно друг за другом (как генерирует например Atmel Studio) и файл выглядел бы вот так :

:209000008200908B8200913782009138820091398200913A8 200913B8200913C8200913D98
:209020008200913E8200913F8200913682009136820091408 20091418200914282009143A9
:2090400082009150820091518200915282009153820091548 20091558200915682009157DC
:2090600082009158820091598200915A82009136820091368 200913682009136820091363F
:0890800000000096000003E966
:03908800908B00CA
:20908B00AE17FF9490CE9088AE908AF62725A5602717BF08E E03BF0BBE08EE0190F6F75C9A
:2090AB00905C90B30B26F5BE08909390EE031C000520D8AE0 0002002F75CA3000E26F9AE2C
:2090CB0001002002F75CA3010026F9CD90DB20FE350850C67 2185011721850123506530C32
:2090EB00725F530D357D530E7214530072105304721053017 21053009AAE0000CD918BAEE5
:20910B009080CD915B24067218500F20047219500FAE0000C D918BAE9084CD915B25DAAE9B
:20912B000000BF02AE0000BF0020CE8080808080808080808 0808080AE0000A601CD917B5A
:20914B0072115302808080808080808080808080B604F1261 AB605E101260CB606E10226AD
:20916B0006B607E10327089C2403A6FF81A60181EB03E7032 4096C0226056C0126017C81CE
:12918B0088F6B704E601B705E602B706E603B7078481A5
:00FFFF0101

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

[MikeF]

Возник вопрос по использованию printf для вывода в UART. С одним UART всё понятно, как быть при попеременном выводе в оба UART у stm8? Судя по другим контроллерам и компиляторам можно как-то воспользоваться функцией fprintf, но в Cosmic я её не вижу. Хотелось бы решить это элегантно, без флагов в putchar.

[akegor]

Хотелось бы решить это элегантно

Я обычно вывожу в строку, а потом строку - куда угодно. Вывод в УАРТ-ы у меня из буфера на прерываниях, потому идет подряд и без задержек.

[MikeF]

Т.е. sprintf и свой вывод в порты, понятно, спасибо. Может ещё кто-нибудь предложит варианты?

[eddy]

sprintf

Разве что самописный.
Я тоже сначала формирую текстовый буфер, а потом отправляю его куда нужно. Правда, с STM8 не так хорошо, как с STM32 — DMA у STM8S нет, поэтому приходится на прерываниях отправку организовывать...

[MikeF]

поэтому приходится на прерываниях отправку организовывать

Я вот тоже о прерываниях думаю, только не пойму как это будет работать с printf и putchar, на практике проверить руки пока не дошли.

[eddy]

Да элементарно будет: формируем помаленьку буфер. Как только набрали нужное количество символов (или же сформировали строчку с данными), копируем этот буфер во внутренний буфер передачи UART'а и выставляем флаг - счетчик данных для передачи. Все, КА отправки данных "сам все сделает". На прием же полезно делать двойную буферизацию: первый буфер заполнили (дошли до '\n', буфер кончился или еще что), выставили флаг готовности, заполняем другой буфер...
Можно вообще сделать эдакий аналог stdio с построчной буферизацией: самопальный putchar постепенно заполняет буфер, а как только дело дошло до конца буфера или '\n', инициирует отправку.

[akegor]

Можно на кольцевых. Вот так сделано в CV:

#define DATA_REGISTER_EMPTY ( 1 ‹‹ UDRE )
#define RX_COMPLETE ( 1 ‹‹ RXC )

#define FRAMING_ERROR ( 1 ‹‹ FE )

#define PARITY_ERROR ( 1 ‹‹ UPE )

#define DATA_OVERRUN ( 1 ‹‹ DOR )


// USART Receiver buffer
#define RX_BUFFER_SIZE 8
char rx_buffer[RX_BUFFER_SIZE];

#if RX_BUFFER_SIZE ‹= 256
unsigned char rx_wr_index=0,rx_rd_index=0;
#else
unsigned int rx_wr_index=0,rx_rd_index=0;
#endif

#if RX_BUFFER_SIZE ‹ 256
unsigned char rx_counter=0;
#else
unsigned int rx_counter=0;
#endif

// This flag is set on USART Receiver buffer overflow
bit rx_buffer_overflow;

// USART Receiver interrupt service routine
interrupt [USART_RXC] void usart_rx_isr(void)
{
char status,data;
status=UCSRA;
data=UDR;
if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))==0)
   {
   rx_buffer[rx_wr_index++]=data;
#if RX_BUFFER_SIZE == 256
   // special case for receiver buffer size=256
   if (++rx_counter == 0) rx_buffer_overflow=1;
#else
   if (rx_wr_index == RX_BUFFER_SIZE) rx_wr_index=0;
   if (++rx_counter == RX_BUFFER_SIZE)
      {
      rx_counter=0;
      rx_buffer_overflow=1;
      }
#endif
   }
}

#ifndef _DEBUG_TERMINAL_IO_
// Get a character from the USART Receiver buffer
#define _ALTERNATE_GETCHAR_
#pragma used+
char getchar(void)
{
char data;
while (rx_counter==0);
data=rx_buffer[rx_rd_index++];
#if RX_BUFFER_SIZE != 256
if (rx_rd_index == RX_BUFFER_SIZE) rx_rd_index=0;
#endif
#asm("cli")
--rx_counter;
#asm("sei")
return data;
}
#pragma used-
#endif

// USART Transmitter buffer
#define TX_BUFFER_SIZE 8
char tx_buffer[TX_BUFFER_SIZE];

#if TX_BUFFER_SIZE ‹= 256
unsigned char tx_wr_index=0,tx_rd_index=0;
#else
unsigned int tx_wr_index=0,tx_rd_index=0;
#endif

#if TX_BUFFER_SIZE ‹ 256
unsigned char tx_counter=0;
#else
unsigned int tx_counter=0;
#endif

// USART Transmitter interrupt service routine
interrupt [USART_TXC] void usart_tx_isr(void)
{
if (tx_counter)
   {
   --tx_counter;
   UDR=tx_buffer[tx_rd_index++];
#if TX_BUFFER_SIZE != 256
   if (tx_rd_index == TX_BUFFER_SIZE) tx_rd_index=0;
#endif
   }
}

void putchar(char c)
{
while (tx_counter == TX_BUFFER_SIZE);
#asm("cli")
if (tx_counter || ((UCSRA & DATA_REGISTER_EMPTY)==0))
   {
   tx_buffer[tx_wr_index++]=c;
#if TX_BUFFER_SIZE != 256
   if (tx_wr_index == TX_BUFFER_SIZE) tx_wr_index=0;
#endif
   ++tx_counter;
   }
else
   UDR=c;
#asm("sei")
} 

Взял это за основу и перепиливаю по нужде и разумению.

[MikeF]

Да элементарно будет: формируем помаленьку буфер. Как только набрали нужное количество символов (или же сформировали строчку с данными), копируем этот буфер во внутренний буфер передачи UART'а и выставляем флаг - счетчик данных для передачи. Все, КА отправки данных "сам все сделает".

Вы здесь описываете, так понимаю, самопальный вариант, а я говорю про стандартный printf, который наверное сделан через цикл из которого не выйдешь пока всё не отправишь, соответственно как в него внедрять прерывание по отправке байта?
Вы для чего используете прерывания при отправке, чтобы пока байт отправляется, основная прога исполнялась?

[MikeF]

Вот так сделано в CV:

А можно целиком этот пример увидеть, так понимаю в нем как раз работают через стандартную stdio?