FAQ по STM8

[STM32F0]

Это не обясняет, почему при прерывании по обеим фронтам всё начинает работать корректно, в то время как по отрицательному фронту - нет.

Глядя на вашу реализацию и код вообще трудно что-то объяснить.

1. PB4 и PB5 - In the open-drain output column, "T" defines a true open-drain I/O (P-buffer, weak pull-up, and protection diode to VDD are not implemented). Значит рискуете вообще убить оба входа.
2. Какие ещё функции в прерывании? Вам время девать некуда?
3. unsigned short time; - а почему не переопределения типа uint16_t?
4. time = TIM1-›CNTRH‹‹8 | TIM1-›CNTRL; - вы упорно продолжаете не верить в чудеса оптимизации? Почему не на две строки? Вы уверены, что TIM1-›CNTRH‹‹8 будет верным в плане оптимальности?
5. Никто вам ничего не подскажет, нет целостности картины. Возьмите логанализатор, заведите пару тестовых пинов и дрыгайте ими в прерывании. Тогда сравнивая входные сигналы с тестовым ногодрыгом в прерывании вы увидите что к чему, т.е. полную картину происходящего.

[tanq]

1. PB4 и PB5 - In the open-drain output column, "T" defines a true open-drain I/O (P-buffer, weak pull-up, and protection diode to VDD are not implemented). Значит рискуете вообще убить оба входа.

В схеме стабилитроны на 4.7В стоят. На случай замыкания этих линий на 12В питания вентилятора. В питании вентиляторов PTC. Подтягивающие резисторы 10К.

2. Какие ещё функции в прерывании? Вам время девать некуда?

В этом прерывании - никакие. Вычисление RPM из временных меток делается в прерывании таймера TIM1, имеющего тот же приоритет. В этом устройстве время экономить нет смысла - это контроллер кулера. Там единственное критическое место - приём команд через uart. Дал ему наивысший приоритет.

3. unsigned short time; - а почему не переопределения типа uint16_t?

А зачем? Мне так удобнее. Компилятор после препроцессора всё равно получит на вход unsigned short.

4. time = TIM1-›CNTRH‹‹8 | TIM1-›CNTRL; - вы упорно продолжаете не верить в чудеса оптимизации? Почему не на две строки? Вы уверены, что TIM1-›CNTRH‹‹8 будет верным в плане оптимальности?

Про сдвиг на 8 бит - уверен. Листинг смотрел.

5. Никто вам ничего не подскажет, нет целостности картины. Возьмите логанализатор, заведите пару тестовых пинов и дрыгайте ими в прерывании.

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

[true71]

Люди!!!
Подскажите, плз, какая среда программирования сейчас наиболее адекватная?
Скорый пробег по гуглу результатов не дал, скорее дал, но слишком размыто.
Не хочется засорять компьютер, перебирая разные среды и компиляторы.

ЗЫ: Когда изучал программирование под АНДРОИД наустанавливал столько всего, что в итоге пришлось переустанавливать систему. Не хочется этого.

[STM32F0]

ИАР или Космик. Я предпочитаю ИАР.

[woroba]

Я предпочитаю ИАР.

+100
Правда редактор у него ну очень спартанский, но есть возможность прикрутить внешний. Я geany пользую.

[true71]

А версия которая ?
Обычно последние версии грешат глюками.

[STM32F0]

В последней вроде глюков не добавили. Старые глюки пофиксили, в основном.

[Full_zero]

Дррратуте всем. Люди добрые помогите, уже все волосы вырвал на голове. Перерыл все что можно. Мне необходимо реализовать счетчик внешних импульсов с помощью TIM1. Суть задачи: по импульсам от внешнего устройства прибавлять счет таймера на один, при достижении регистра сравнения генерировать прерывание. Счет не останавливать, счетчик обнулять автоматически. Например: считаем до 300, когда досчитали до 300 генерируем прерывание, обнуляем счетчик и считаем дальше. Камень STM8Sxx3. Cosmic. И если можно с помощью SPL. Спасибо.

[tanq]

Подскажите, как правильно использовать буферизацию в АЦП с одновременной сменой каналов. Проц STM8S003. Мне надо оцифровать 1 канал 10 раз и усреднить, оцифровать 2 канал 10 раз и тоже усреднить. Очевидный метод решения задачи не работает: если в обработчике прерывания тупо менять номер канала, то АЦП впадает в ступор. Если предварительно сбросить бит CONT, то он тоже впадает в ступор, потому что DBUF может использоваться только с флагом CONT. Если же сбрасывать DBUF перед сбросом CONT, а потом всё включать назад, то оцифровка идёт верно, но не совсем - в каких-то из 10 регистров оказываются не те значения. Как с этим бороться?

[AR_Favorit]

Непонятку словил в IAR EW.

Есть структура,

struct key_unit
{
  uint32_t u32_number;
  uint16_t u16_counter;
  uint8_t  u8_buttons;          
  uint8_t  u8_state;            
};//8 байт

являющаяся членом другой структуры

struct eeprom_unit
{
  struct key_unit       st_keys[10];               
  struct phone_unit     st_phones[5];            
  uint8_t               lock_state[2];              
  uint16_t              u16_autoclose_time;     
  uint8_t               u8_alarm_time;             
  uint8_t               u8_open_button_mode;  
  
  uint8_t               CRC;                        
} //237 bytes (up to 299)

структура изначально объявлена в EEPROM, но для проверки перенес в RAM

struct eeprom_unit ST_EEPROM;

Есть переменная
uint8_t u8_last_command

Работаем с 8-битным членом структуры key_unit - u8_buttons

значение u8_last_command: 0x60
значение ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons: 0x24
эти значения вижу и в отладчике, но...

 
       if (u8_last_command == ((ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons ‹‹ 4 ) + (ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons & 0xF0)))
        {
            //do something...
        }

Результат проверки условия в if - "ложь", "do something" не выполняется.

А вот так выполняется:

        if (u8_last_command == (uint8_t)((ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons ‹‹ 4 ) + (ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons & 0xF0)))
        {
            //do something...
        }

и вот так тоже

        if (u8_last_command == ((uint8_t)(ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons ‹‹ 4 ) + (ST_EEPROM.st_keys[u8_serv_tmp].u8_buttons & 0xF0)))
        {
            //do something...
        }

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

Глюк или нормальное поведение?

Когда структуры не было, и всё хранилось отдельными массивами, всё работало без приведения.