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

[scorpi_0n]

Тогда зачем было повторяться?

[axillent]

а зачем отвечать не читая?
там выше все есть

[a5021]

в этой части мне даже не пришлось переделывать код после AVR, хоть там и порядок другой
конструкции типа ниже работают в любом случае верно:

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

word = b0 | (b1 << 8);

Мне вот такой алгоритм укладывания не нравится своей громоздкостью, а уж сдвиг со сложением -- это вообще прием из курса знакомства с ардуиной.

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

  for (uint8_t i = 0; i < BMP180_PROM_DATA_LEN / 2; i++) {
    *buf = i2c_read();
    *--buf = i2c_read();
    buf += 3;
  }

[axillent]

Мне вот такой алгоритм укладывания не нравится своей громоздкостью, а уж сдвиг со сложением -- это вообще прием из курса знакомства с ардуиной.

ИМХО это вы накручиваете
для Си логические И и сдвиги совершенно нормальные операнды
если читали классику по Си то согласитесь, что они придуманы лет за 40 до ардуины
я не смотрел листинги (не было интереса), но могу предположить, что машинный код моего и вашего варианта плюс минус равнозначны

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

  for (uint8_t i = 0; i < BMP180_PROM_DATA_LEN / 2; i++) {
    *buf = i2c_read();
    *--buf = i2c_read();
    buf += 3;
  }

да пожалуйста. Что мешает указатель не инкрементировать, а декриментировать? Код по размеру будет тот же, но порядок поменяется
Это то, что я выше назвал - все равно перекладывать, в каком направлении класть без разницы

[a5021]

ИМХО это вы накручиваете

Любую оптимизацию можно попытаться охаять в таких формулировках.

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

А я смотрел и профилировал. Причем, выбирал из трех вариантов (правда, для stm32): а) сдвиг + сложение; б) манипуляции с указателем (приведенный выше); в) считывание по i2c в массив с использованием DMA + проход со свопом байтов. Самым быстрым и компактным оказался вариант "б".

[axillent]

ИМХО - это признак высказанного личного скромного мнения
не ищите критику (охаивание) там где ее нет

какой выигрышь в варианте б по отношению к а? интересно, пусть это и STM32
и какой уровень оптимизации/компилятор были?

[Alexeyslav]

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

[axillent]

Если говорить про оптимальность той или иной конструкции в Си обективный критерий только один - эфыективность полученоого машинного кода. Оптимизация влияет на это прямым образом

Наглядность важная вещь, но не абсолютная. Комментарии в этом важнее

[a5021]

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

Насчет "передача дольше", у меня трансфер по i2c выполняется с использованием слипа, т.е. загрузили данные в регистр, стартовали передачу и спать. Окончание передачи будит ядро. Запустили чтение и опять спать, пока весь байт не приползет. А вот дальше надо все делать максимально быстро, т.к. в это время энергопотребление максимально и в моем случае -- это самый важный ресурс, который надлежит оптимизировать.

[Alexeyslav]

Боюсь тут не всё однозначно в плане потребления. Максимально быстро не всегда означает максимально экономично в энергетическом плане. Статическое потребление контроллером не зависит от скорости выполнения, но и оно довольно небольшое. Количество энергии потраченное на обработку данных будет зависеть исключительно от количества переключений и не всегда это коррелирует с количеством тактов, особенно когда задействованы разные инструкции.
Кстати, а как по энергетике будет отражаться вход/выход из спящего режима? Это может убить всю экономию...

[a5021]

Выход из режима sleep для F030 по времени занимает четыре такта. Именно столько времени проходит с того момента, как случился ивент, до начала исполнения инструкции, следующей после WFE. Других никаких накладных расходов нет.

Говорить о том, что какие-то инструкции более энергоэффективны, а какие-то менее, не имеет смысла до того момента, пока дело не касается какой-то конкретной последовательности машинных команд. Однако, расходы связанные с неизменными энергозатратами по выполнению единичной команды, позволяют утверждать, что чем этих команд меньше, тем для энергоэффективности лучше. Правило, чем меньше команд, тем меньше затраты энергии, будет работать во многих, если не в большинстве, случаев. По любому, разница между энергоэффективностью разных команд намного меньше, чем разница между активным состоянием и режимом сна. Чем раньше уйдем в сон, тем больше сэкономим энергии.

[axillent]

что я делаю не так?
настроил UART1 на STM8S003F3
настроил RX с прерыванием:

Спойлер

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

void uart1_init(uint16_t uart1_div){

   // GPIO
   PD_DDR_bit.DDR5 = 1;   //TX for output
   PD_DDR_bit.DDR6 = 0;   //RX for input

   PD_CR1_bit.C16 = 0;      // floating RX
   PD_CR2_bit.C26 = 0;      // no external interrupts for RX

   // baud rate registers
   UART1_BRR2 = (uart1_div & 0x000f) | (uart1_div >> 12);
   UART1_BRR1 = (uart1_div >> 4) & 0x00ff;

   UART1_CR1_PIEN = 0;      // no parity
   UART1_CR1_PCEN = 0;      // no parity control
   UART1_CR1_M = 0;      // 8 bit
   UART1_CR1_UART0 = 0;   // switch uart ON

   UART1_CR2_TIEN = 0;      // no interrupt on tx buffer underflow
   UART1_CR2_TCIEN = 0;   // no interrupt on tx transfer complete

#ifdef UART1_RX_BUFFER_SIZE
   UART1_CR2_RIEN = 1;      // 0/1 no/yes interrupt on rx
   uart1_rx_clear();
#else
   UART1_CR2_RIEN = 0;      // 0/1 no/yes interrupt on rx
#endif

   UART1_CR2_ILIEN = 0;   // no interrupt on line free
   UART1_CR2_TEN = 1;      // switch on transmitter
   UART1_CR2_REN = 1;      // switch on receiver
   UART1_CR2_SBK = 0;      // no break char
   UART1_CR3_STOP = 0;      // 1 stop bit
}

нарисовал обработчик по вектору:

Спойлер

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

#pragma vector=UART1_R_RXNE_vector
__interrupt void uart_rx_interrupt(void){
   uint8_t data = UART1_DR;
   //uart1_rx_push(data);
}

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

[a5021]

Флаг прерывания сбрасывать надо, прямо в обработчике.

[axillent]

так?

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

UART1_SR_RXNE = 0;

а как же информация о том, что он сбрасывается после чтения из UART_DR?

This bit is set by hardware when the content of the RDR shift register has been transferred to the
UART_DR register. An interrupt is generated if RIEN=1 in the UART_CR2 register. It is cleared by a
read to the UART_DR register. In UART2 and UART3, it can also be cleared by writing 0.
0: Data is not received
1: Received data is ready to be read.

[a5021]

У меня есть подозрение, что чтение регистра данных в обработчике компилятор вообще вынес, т.к. дальше с этими данными никаких операций не производится.

[axillent]

У меня есть подозрение, что чтение регистра данных в обработчике компилятор вообще вынес, т.к. дальше с этими данными никаких операций не производится.

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

[a5021]

А посмотрите в отладчике, есть реальное чтение регистра данных?

[axillent]

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

пока что у меня ерунда выходит. С другого МК через RS485 шлю бакет со стартовым символом
по началу мусор прилетал
поставил паузу после переключения у передатчика max485 на передачу в 100мсек, стартовый символ поймал
но остальные данные - опять нули...

т.е. пока у меня прием на STM8 не работает, где то я ошибаюсь
хотя передача уже отлажена, в обратную сторону все работает на ура

[a5021]

Я бы осциллографом посмотрел для начала.

[axillent]

Заработало, было две проблемы - косяк в организации буфера и потребовалось вставить задержки после переключения max485 перед передачей и задержка после передачи до возврата в режим чтения

Задержки сделал тупыми циклами. А как правильно делать задержки в единицы и десятки мсек?