Таймер не работает

[VladislavS]

TEPEM писал(а):

Там регистры в FSMC в адовом количестве

Если их поделить на количество nCSx, то фиг да не фига остаётся. Меньше чем в GPIO.

ЗЫ: личку глянь.

[TEPEM]

[del]

Добавлено after 20 minutes 13 seconds:
stm32412g_discovery.c
hsram.Instance = FSMC_NORSRAM_DEVICE;
hsram.Extended = FSMC_NORSRAM_EXTENDED_DEVICE;
В районе 827 линии.
Кто то знает что передают эти строчки гоняя по кругу регистры?
Это ужас какой то, все перепробовал что только можно. Уже что только не записывал. С ними работает, без них нет, и если без первой просто тупит, то без второй черный экран. Весь интернет перерыл, уже даже по иностранным статейкам пробежал.
Экстендед по дефайнам меняет три состояния, много где участвует, но как я понял везде как донор и не подвергается перезаписи. Чудеса

[VladislavS]

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

[bevice]

TEPEM писал(а):

Либо стандартный пример из куба отчистить от ереси, я уже почти сделал это но застрял жестко. У меня пока с подвижки только в виде проекта с таймером, настроенными ногами на FSMC, и шим на подсветку. Что бы Вы посоветовали?

Очистить от ереси стандартный пример в кубе. Он хоть и может быть косячный, но работает. В чем затык с очисткой вышел? Я когда шаблоны под cmake перепиливал справлялся за полчаса с новым камнем

Добавлено after 47 minutes 52 seconds:
Народ, зачем вы мучаетесь с extern "c"?
сделайте в заголовке макрос

Код:

#ifdef __cplusplus
#define SAFECALL extern "C"
#else
#define SAFECALL
#endif



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

Код:

SAFECALL void SysTick_Handler(){...}

[VladislavS]

Мучаемся, ночами не спим. Ну и богатая же у тебя фантазия У меня у всех обработчиков прерываний нужен extern "С". Куда как проще написать эти 9 мучительных букв, чем подключать какой-то заголовочный файл и писать не пойми что скрывающие в себе 8 букв SAFECALL.

[bevice]

VladislavS писал(а):

Мучаемся, ночами не спим. Ну и богатая же у тебя фантазия У меня у всех обработчиков прерываний нужен extern "С". Куда как проще написать эти 9 мучительных букв, чем подключать какой-то заголовочный файл и писать не пойми что скрывающие в себе 8 букв SAFECALL.

#define С SAFECALL
и пишете одну букву. экономия. Но я вас понял, если для всех и всегда - тогда не проще ли поправить уже таблицу векторов и не писать лишнего?

[VladislavS]

Имена векторов прерываний определил производитель чипа, они фигурируют в его документации и библиотеках. В большинстве IDE при создании проекта стартап будет на C или ASM. Зачем я буду его переписывать? Ради вашей extern "С" фобии? Да сношайся оно конём По сравнению с template <typename... T> static constexpr inline auto Foo(T... t){} да ещё с какими-нибудь атрибутами, extern "С" так безобидно выглядит.

[bevice]

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

[VladislavS]

bevice писал(а):

Вы пишете на плюсах, при этом вектор лежит в ассемблерном файле и использует символы C. И это не кажется извращением, да?

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

bevice писал(а):

Ну так напишите таблицу векторов на плюсах,

Не говорите мне что делать и я не скажу куда вам идти.

bevice писал(а):

там и наследоваться на прерываниях можно будет и еще что-нить приятное придумать можно, позднее связывание хотя бы.

Позднее связывание на векторах прерывания? Можно я просто пальцем у виска покручу?

[bevice]

Позднее связывание на векторах прерывания? Можно я просто пальцем у виска покручу?

Покрутите, если сможете объяснить, что в этом плохого.

[VladislavS]

Объясню, если сможете показать, как это сделать.

[Reflector]

VladislavS писал(а):

Объясню, если сможете показать, как это сделать.

Перенести таблицу векторов в RAM?

Код:

Timer2 tim2;
tim2.init(0, 36'000'000 - 1);
tim2.setCallback([] { tim2.clearInterruptFlags(); redLed.toggle(); });
tim2.enableInterrupts<TimInt::Update>();
tim2.enable();

[VladislavS]

И руками её заполнить? Ну вот оно и первое почему это "хорошо".

[Reflector]

VladislavS писал(а):

И руками её заполнить? Ну вот оно и первое почему это "хорошо".

Все заполнять не нужно, только реально используемое. На самом деле подход довольно распространенный, даже в каком-то порте ардуино для ARM такое видел.

[VladislavS]

Если взять какой-нибудь ARM926, где адреса обработчиков прерываний надо при инициализации в VIC записывать, то это ещё как-то вяжется. Но у Cortex-M всё сделано для упрощения. Зачем же на ровном месте усложнять?

[Reflector]

VladislavS писал(а):

Зачем же на ровном месте усложнять?

Ситуации разные бывают, кому-то может просто нравится, что можно на ходу менять обработчики, а кто-то так делает ради повышения производительности и большей предсказуемости. Например, если взять F4 с 5WS, то он сначала полезет в таблицу векторов, что сбрасывает кеш и заставляет ждать лишние 5 тактов, потом то же самое происходит второй раз когда из таблицы получен адрес и выполняется переход на сам обработчик прерывания. Если используется callback, то придется дополнительно читать адрес из переменной и переходить по нему в третий раз. Итого потери могут составить 5+5+5 тактов и что еще хуже, она может быть меньше, т.к. не известно какие данные накешировал ART, может у него все необходимое есть и ждать чтения из флеша не нужно... А если таблица в RAM, то ART не задействуется, если еще и сама функция в RAM, то после чтения адреса из таблицы векторов прыгаем сразу на нее с детерминированной и относительно небольшой задержкой.
Но основная причина думаю все-же в простоте использования, вызвал usart.init() и он автоматически подключил обработчик прерывания...

[jcxz]

Reflector писал(а):

Но основная причина думаю все-же в простоте использования, вызвал usart.init() и он автоматически подключил обработчик прерывания...

Некая "простота использования" против "безопасности использования" с таблицей векторов во флешь? Сомнительный выигрыш....

[Reflector]

jcxz писал(а):

Некая "простота использования" против "безопасности использования" с таблицей векторов во флешь? Сомнительный выигрыш....

Смотря что подразумевать под "безопасностью использования"... Если usart.init(...) сам прописывает обработчик прерывания, сам определяет текущую частоту, в него нельзя передать неправильные пины, а AF тоже определяется автоматически, то такая функция с определенной точки зрения будет максимально безопасной, т.к. оставляет минимальную возможность сделать что-то не так. Конечно на АЭС такое устройство лучше не ставить, да и в лифт тоже, но на любительском уровне это и не нужно.

[jcxz]

Reflector писал(а):

Смотря что подразумевать под "безопасностью использования"... Если usart.init(...) сам прописывает обработчик прерывания, сам определяет текущую частоту, в него нельзя передать неправильные пины, а AF тоже определяется автоматически, то такая функция с определенной точки зрения будет максимально безопасной, т.к. оставляет минимальную возможность сделать что-то не так.

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

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

[bevice]

jcxz писал(а):

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

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

jcxz писал(а):

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

Можно спросить более развернуто: зачем вообще нужно программировать на плюсах? Любую иерархию классов можно разрулить ветвлением. Более того, все это можно сделать на ассемблере, причем работать скорее всего будет быстрее. Но удобства они такие, могут даже заставить шаблонами пользоваться