Jump to content

    

jeka

Свой
  • Content Count

    439
  • Joined

  • Last visited

Community Reputation

0 Обычный

About jeka

  • Rank
    Administrator
  • Birthday 06/14/1980

Контакты

  • ICQ
    Array

Recent Profile Visitors

5471 profile views
  1. А не пробовали сделать низкоскоростной процесс (по таймеру например), анализирующий факты перехода через 0 у таймеров энеодеров? Чуть сложнее, но я на похожей задаче делал, вариант рабочий.
  2. Спасибо за замечание, учту. Я не настолько глубоко копался в этом чтоб все идеально сделать.
  3. Всё верно. Я про ресет с помощью простой передачи управления по адресу. Запускал так бутлоадер прямо из irq. Ибо надо было не ресетить коммуникацию, иначе связь порвётся. получается очень легкий механизм заточеный на событийную коммуникацию. Замена RTOS в части многопоточности и сигнализирования обслуживающих коммуникацию потоков. заменяя цепочку irq периферии->сообщение RTOS->wakeup процесса->IRQ планировщика->переключение контекста->обработка, на irq->переключение контекста->обработа
  4. нет, я про софт-ресет чисто программный, а не про ресет установкой бита ресета
  5. жаль. (хотя я софт-ребут из IRQ делал и вроде всё сбрасывалось, но могу и ошибаться). Значит стек на возврат настроить и выполнить возврат, сразу в нужное место. А вот с восстановлением вопрос. Видимо так же.
  6. IPSR bit definitions Bits 8:0 ISR_NUMBER: This is the number of the current exception: 0: Thread mode, все что не 0 - по логике handler mode т.е. если ISR_NUMBER сбросить в 0, как я понимаю, процессор перейдет в thread mode и можно стек переключить на PSP. (в handler mode опытка переключения стека вызывает hardfault, а так бы было то что надо). Но нужно предварительно замаскировать более низкие прерывания, чтоб не нарушить логику работы контроллера прерываний. Как я понял, при изменении ISR_NUMBER NVIC сразу доступные для вызова приоритеты обновит. (может и ошибаюсь, поправьте меня кто знает)
  7. Почему только? PSR почему бы не подправить если очень хочется
  8. Как раз наоборот. Когда начал им пользоваться, сам удивился насколько им приятно пользоваться. Ибо крайне компактный и быстрый, позволяющий в большинстве случаев обойтись без дерганья контекстов, сообщений, вейкапа процессов, очередей, как это бы делалось в RTOS (отсюда простота и выше скорость). И при этом код вполне понятный.
  9. Когда rtos ставить не хочется, а state машину внутри IRQ городить некрасиво, родилась мысль сделать механизм, который работает как yield(), но внутри IRQ. Т.е. выходит из IRQ, а при следующем вызове возобновляет исполнение с этого же места и сохраненным контекстом. exec_task: push {r0-r11,lr} mov32 r1,#core_task_sp str sp,[r1] ldr sp, [r0] ; sp=inline task stack pop {r0-r11,lr} bx lr task_yield: push {r0-r11,lr} ; save inline task state mov r12,sp mov32 r0,#core_task_sp ldr sp,[r0] ; sp=core stack pop {r0-r11,lr} str r12,[r0] bx lr end int init_task(uint32_t* task_stack_top, void* routine) { task_stack_top[-1]=(int)routine; return (int)(task_stack_top-13); } И простейший пример использования: init: task_common_sp=init_task_fpu(TASK_COMMON_STACK_TOP, (void*)&thread_in_irq); int result; TransferComplete_IRQHandler() { result=DGRAM_SENT; // timeout irq cancel exec_task_fpu(&task_common_sp); } Timeout_IRQHandler() {// во всех IRQ, которые вызывают один и тот же процесс, должен быть одинаковый приоритет result=TIMEOUT; // tx dma cancel exec_task_fpu(&task_common_sp); } int send_dgram(char* dgram) { // ... запускаем отправку через DMA, устанавливаем irq таймаута task_yield();// ждём окончания отправки return result; } int wait(int time) { // start_timeout_timer... task_yield(); } void thread_in_irq() { while (1) { int res=send_dgram("init"); if (res==TIMEOUT) ...; wait(100); res=send_dgram("bbb"); if (res==TIMEOUT) ...; wait(100); } } Сделал реализацию, всё работает, но есть одно но. Стек для каждого такого процесса приходится выделять с учетом того, что могут вызываться вложенные IRQ. А RAM порой хочется поэкономить. Поэтому хочется во время вызова потока внутри IRQ использовать стек процесса (PSP). Но в handler mode можно пользоваться только MSP. Думаю, как лучше сделать. Мысли такие: - внутри IRQ переключаться в THREAD MODE и на стек PSP, а IRQ маскировать с помощью BASEPRI. Но тут вырисовывается проблемка в совместимости с RTOS: RTOS для маскировки IRQ тоже использует BASEPRI (при некоторых вызовах callFromIRQ), но при выходе он BASEPRI сбрасывает в ноль (и ставит топорно, не проверяя что быдо до вызова), а не в то значение, которое было при вызове. Поэтому во всех IRQ нельзя будет пользоватся этим механизмом freertos на приоритетах >=процессного IRQ, либо сделать доработку для freertos, либо что-то еще придумать. Пока вырисовывается дополнительная опция freertos, добавляющая проверку и восстановление BASEPRI. p.s. Предвидя сообщения в стиле "так никто не делает и вообще это не правильно", просьба воздержаться от этого и писать по существу. Ибо инструмент в работе показал себя очень хорошо (красивые реализации получаются если делать тайм-ауты и несколько источников возобновления исполнения), только хочется подружить его со RTOS.
  10. STM32H7 RMII

    upd: нашел косяк. в одном из доменов не включил тактирование. Теперь всё работает.
  11. STM32H7 RMII

    я этот момент проверял, дескрипторы и пакеты находятся в sram3.
  12. STM32H7 RMII

    Ковыряюсь, никак не могу обмен по RMII запустить (через hal). Из mcu при попытке отправки пакета через hal на ноги ничего не выходит (сами пины перепроверил, сконфигурированы правильно). Когда RMII в STM шлёт пакет, так же ничего не вижу (по осциллографу на пинах данные есть). В DMACSR все нули, кроме RBU. TBU после попытки передачи пакета устанавлиается. Ошибок hal не возвращает. Прерываний при поступлении пакеты ethernet не генерирует (разрешены RIE, TIE, NIE, AIE, FBEE), в dma ничего не прилетает. MDIO работает, статусы получаю, физика успешно автосогласовывает скорость. Таблицу дескрипторов поизучал (на приём 6 штук), есть странности. Почему третьи строчки нулевыми указателями на буфера, непонятно. DMACTxRLR и RxRLR почему-то содержат число дескрипторов - 1, хотя в даташите написано что это число дескрипторов. У кого-то есть положительный опыт запуска ethernet на h7 (конкретно h747xi)?
  13. Все верно. Задача ослабления - уменьшить ЭДС мотора. Думаю как лучше автоматом определять ток, на котором магнитный поток от статора и ротора уравновешиватся. может инжектом немного модулировать id, и смотреть отклик на модуль питающего напряжения? при известном ЭДС несложно посчитать. Или есть получше метод?
  14. Когда всё напряжение в мотор вкачивает и дальнейшее увеличение напряжения невозможно
  15. можно так - когда регулятор упёрся в 100% шим, он начинает регулировать id, опираясь на потребляемую мощность. Если не нужен очень быстрый отклик, простой и вполне рабочий вариант.