Планировщик Задач На Базе 1Мгц Таймера - Не Могу Найти Баг :(

[rusefi]

Зашёл в тупик - не могу найти ошибку в программе своей, может быть кто-то сможет помочь? К сожалению частей движущихся слишком много, нужно будет подумать как упростить воспроизведение проблемы

stm32f4 + chibios, пытаюсь программно генерировать несколько ШИМ разной частоты используя один 32-битный таймер 1МГц. шим здесь просто частный случай планирования сигналов, велосипед вообще изобретаю вместо аппаратных таймеров на каждую задачу потому что так таймеров не хватит

Базовые файлы:

1) 32-битный будульник 1МГц, просто планирует вызов через заданное время: http://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/hw_layer/microsecond_timer.c

2) 64-битные часы поверх счётчика циклов процессора - http://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/util/efilib2.cpp

3) структура данных очереди событий: https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/controllers/algo/event_queue.cpp

каждый генератор ШИМ - высчитывает время следующего переключения пина, ставит будильник на это время, ставит в очередь следующий вызов, и всё по циклу - https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/controllers/system/pwm_generator_logic.cpp

Полные исходники: https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/

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

а картинке мы видим, что четыре ШИМа какое-то время генерируются - третий самый быстрый, там событий 100 отрабатывает - а потом что-то идёт не так. к сожалению в этом дизайне достаточно одного несработавшего будильника, чтоб вся цепочка сломалась.

Для включения тестовой генерации нужно разкомментировать строчку52 в https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/controllers/PwmTester.cpp

будет 4 сигнала:

1Hz on PB9

10Hz on PB8

1000Hz on PE3

33Hz on PE5

может быть, кто-то увидит проблему? Что-то я немного в тупике.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[tightenloop]

rusefi,

При всём ..... такие вещи так не пишутся. Такой подход это задрачивание проца!!! Скоростные ШИМ (частотой больше 100 Гц) пишцться только на железе.

ничко скоростные сделай периодическое прерывание 0.1 мС это даст тебе возможность независимо программно реализовывать очень много ШИМов причём абсолютно независимо. Если необходимы частоты более низкие замени char на int.

#define PWM1_PIN .............. Номер пина
#define PWM1_PORT ....... указывай регистр порта для максимальной скорости.

volatile unsigned char pwm1_duty, pwm1_counter, pwm1_period;

void IRQ100us(void)
{
if (++pwm1_counter == pwm1_period)
{
pwm1_counter=0;
PWM1_PORT&=~(1<<PWM1_PIN);
}
else
{
if (pwm1_counter==pwm1_duty) PWM1_PORT|=(1<<PMW1_PIN);
}

}

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[rusefi]

Как я пытался озвучить - ШИМ здесь частный случай, основная задача - абстрактный планировщик нескольких потоков событий на одном аппаратном таймере.

На stm32f4 скоростях процессора я совсем не понимаю, как 1КГц будет напрягать процессор - тезис, что 100Гц является пределом нагрузки процессора мне кажется странным. Но всё-таки мы не о том - всё-таки основной вопрос, где же баг в том коде.

[Реклама]

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[tightenloop]

На stm32f4 скоростях процессора я совсем не понимаю, как 1КГц будет напрягать процессор - тезис, что 100Гц является пределом нагрузки

100 Гц с разрешением duty 1% = 100Hz * 100 = 10000hZ = 100uS.

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

В остальном не думаю , что мы поймём друг друга.

[rusefi]

100 Гц с разрешением duty 1% = 100Hz * 100

Это важный момент. Программистам хватает двух прерываний на полный цикл ШИМ 100Hz * 2 = 200Hz, а народу - если нужно обязательно умножить на 100 - действительно непросто. Так что это видимо топик для программистов.

[impartial]

А что это такое? (выделено жирным)

CH_IRQ_HANDLER(STM32_TIM5_HANDLER) {

CH_IRQ_PROLOGUE();

if (((TIM->SR & 0x0001) != 0) && ((TIM->DIER & 0x0001) != 0))

callback();

TIM->SR = (int) ~STM32_TIM_SR_UIF; // Interrupt has been handled

CH_IRQ_EPILOGUE();

}

Изменено 7 мая, 2014 пользователем impartial

[rusefi]

if (((TIM->SR & 0x0001) != 0) && ((TIM->DIER & 0x0001) != 0))

первый 0x0001 TIM_SR_UIF - это Update interrupt Flag?

второй 0x0001 TIM_DIER_UIE - Update interrupt enable?

TIM->SR = (int) ~STM32_TIM_SR_UIF;

сброс флага прерывания?

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

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

попробовал несколько вариантов - поведение везде такое же, работает секунду-полторы, потом умирает

[impartial]

А вот так что получается?

TIM->SR = (unsigned short) 0;

[rusefi]

Попробовал и так тоже - никакой разницы, немного работает, потом ломается.

[rusefi]

Новая информация:

void setHardwareUsTimer(int timeUs) {

TIM->ARR = timeUs - 1;

TIM->EGR |= TIM_EGR_UG; // generate an update event to reload timer's counter value

TIM->CR1 |= TIM_CR1_CEN; // restart timer

lastSetTimerTime = getTimeNowUs();

isTimerPending = TRUE;

timerRestartCounter++;

}

Похоже что если будильник ставить на малое время - например передавать параметром 5 или 11, то срабатывания не происходит. Если параметр 300 и больше - то всё работает. Осталось понять, почему и что с этим делать.

[impartial]

Просто не хватает времени на обработку прерывания. Запретите прерывания на время обработки. Но в этом случае получите не контролируемые временные интервалы.

По идее все должно работать при тактовой проца 168мгц и, если, внутри нет какой нибудь операционки или неизвестного кода.

Запустите задачу в профайлере и выловите проблему.

Вы пользуетесь отладкой по SWD?

[rusefi]

Запрет на прерывания там есть, но сейчас он происходит не сразу - попробую поднять выше.

Сейчас там

register uint32_t tmp asm ("r3") = CORTEX_BASEPRI_KERNEL; \

asm volatile ("msr BASEPRI, %0" : : "r" (tmp) : "memory"); \

В профайлере или в дебагере? Если в профайлере, то какой профайлере под ARM вы посоветуете?

Отладка пока STLink, аппаратный идёт по почте пока.

[impartial]

В профайлере или в дебагере? Если в профайлере, то какой профайлере под ARM вы посоветуете?

Отладка пока STLink, аппаратный идёт по почте пока.

STLink это и есть аппаратный.

Я пользуюсь профайлером из среды IAR 6.30.

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