[asnoeuh 0]

On 11/15/2019 at 12:13 PM, Eddy_Em said:

 Ставите прерывание на получение символа '\n' 

В STM32 так можно?

[xmailer 0]

20 minutes ago, asnoeuh said:

В STM32 так можно?

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

[asnoeuh 0]

То что он дальше пишет у меня не вызвало вопроса.

Специально для вас, фраза целиком:

Quote

Ставите прерывание на получение символа '\n' и формируете буфер средствами DMA (либо можете в прерывании по RXNE формировать буфер, без DMA, но анализировать на '\n' внутри прерывания).

 

[Eddy_Em 1]

1 hour ago, asnoeuh said:

В STM32 так можно?

Конечно. В STM32F0. Я такое вытворял, но народ говорит, мол, не очень это хорошо при сильных помехах на линии.

[esaulenka 5]

3 hours ago, Eddy_Em said:

Конечно.

Конечно же, это не так.

Правильный ответ "можно в некоторых сериях камней". Например, в F0, L0, L4, F3, F7. Ключевое слово для поиска в референс мануале - "Character match flag".

[HardEgor 63]

23 часа назад, SapegoAL сказал:

Сейчас, я совершенно случайно увидел вот такое...
stm32f7xx_hal_adc.c
stm32f7xx_ll_adc.c

А еще вы не видели stm32h7xx_hal_adc_ex.c  :)

[jcxz 184]

В 16.12.2019 в 10:27, asnoeuh сказал:

То что он дальше пишет у меня не вызвало вопроса.

"Можно" - "не можно" - всё равно. Лучше просто так не делать.

В 16.12.2019 в 11:17, Eddy_Em сказал:

Конечно. В STM32F0. Я такое вытворял, но народ говорит, мол, не очень это хорошо при сильных помехах на линии.

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

'\n' может прийти, может не прийти - вне зависимости от протокола - программа не должна падать от этого.

[Eddy_Em 1]

А она и не будет падать от переполнения буфера. Просто буфер будет выброшен как невалидная команда, и начнет заполняться сначала. Правда, в следующий заход опять получится невалидная команда, ну и ладно...

Совершенно аналогичная ситуация будет и с посимвольным разбором в прерывании. Точно так же при дохождении до конца буфера содержимое будет выброшено как невалидное.

[Harbinger 10]

10 минут назад, jcxz сказал:

'\n' может прийти, может не прийти

Автор темы вроде не писал, что там текст. М.б. какой-нибудь бинарный протокол с пакетами переменной длины для полного счастья.

[jcxz 184]

4 минуты назад, Harbinger сказал:

Автор темы вроде не писал, что там текст. М.б. какой-нибудь бинарный протокол с пакетами переменной длины.

Да и я вроде не писал про текст.   Без разницы что там.

4 минуты назад, Eddy_Em сказал:

Правда, в следующий заход опять получится невалидная команда, ну и ладно...

Вот именно. И так далее... 

Причём так может выкинуться не один, а сразу много пакетов.

Цитата

Совершенно аналогичная ситуация будет и с посимвольным разбором в прерывании. Точно так же при дохождении до конца буфера содержимое будет выброшено как невалидное.

Но следующий кадр не будет потерян.

[Eddy_Em 1]

Очень даже будет. Никакой разницы нет, DMA у вас с прерыванием по символу, или же побайтный разбор строки с поиском этого же символа. Если строка невалидная, она в обоих случаях будет выброшена вместе с частью следующей строки (что сделает ту тоже невалидной).

А насчет передачи бинарных данных - это всегда плохо, т.к. платформозависимо. Понятно, что для МК и программиста это лучше — МК меньше работы по парсингу, программисту меньше клавиши давить. Но с точки зрения интерфейсов... Ведь при текстовом формате вы просто подключаете терминал и пишете/читаете. А если формат бинарный, придется писать какую-то прослойку между клавиатурой/экраном и каналом передачи данных. Неудобно, однако.

Изменено 17 декабря, 2019 пользователем Eddy_Em

[Harbinger 10]

3 часа назад, jcxz сказал:

Причём так может выкинуться не один, а сразу много пакетов.

Это тайм-аутами разрулить можно. Теми самими 50...100 мс, что в стартпосте.

[Kurator 0]

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

Написал программу на ассемблере для STM32F103C8T6 с выводом на I2C2 в IAR. Программа с ожиданием признаков I2C2 работает без проблем. Когда перешел на прерывания от I2C2, программа при входе в прерывания  стала выскакивать в HardFault_Handler. Перекомпилировал в Keil, переходил на  I2C1, пробовал еще на двух экземплярах микросхем – тот же результат. При расследовании кой-что накопал:

 

HardFault_Handler

        NOP

        NOP

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

 

HardFault_Handler

        NOP

        POP {R0-R7}

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

 

        POP {R0-R7}

        POP {R0-R7}

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

 

0x8000031 – адрес Reset_Handler

0x20000400  - начальный стек

0x800014a – адрес возврата из прерывания

 

HFSR = 40000000: FORCED - 1.  Попытка выполнить команду SVC/BKPT из обработчика SVCall/Debug monitor или из обработчика другого исключения с таким же или более высоким приоритетом.

2.  Отказ произошёл из-за того, что соответствующий обработчик запрещён или не может быть запущен по причине маскирования исключения или же выполнения

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

 

Дальше я в тупике, может у кого есть идеи.

 

 

 

 

 

[Kurator 0]

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

Написал программу на ассемблере для STM32F103C8T6 с выводом на I2C2 в IAR. Программа с ожиданием признаков I2C2 работает без проблем. Когда перешел на прерывания от I2C2, программа при входе в прерывания  стала выскакивать в HardFault_Handler. Перекомпилировал в Keil, переходил на  I2C1, пробовал еще на двух экземплярах микросхем – тот же результат. При расследовании кой-что накопал:

 

HardFault_Handler

        NOP

        NOP

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

http://img.radiokot.ru/files/26998/24bjo02sip.png

 

HardFault_Handler

        NOP

        POP {R0-R7}

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

http://img.radiokot.ru/files/26998/24bjnpj2ks.png

 

        POP {R0-R7}

        POP {R0-R7}

        LDR R8,=CFSR

        LDR R9,[R8]          ;Чтение MMFSR

        LDR R10,[R8,#4]      ;Чтение HFSR

        LDR R11,[R8,#8]      ;Чтение DFSR

        LDR R12,[R8,#20]     ;Чтение AFSR

        BKPT #2

        B main_end

http://img.radiokot.ru/files/26998/24bjmutugn.png

 

0x8000031 – адрес Reset_Handler

0x20000400  - начальный стек

0x800014a – адрес возврата из прерывания

HFSR = 40000000: FORCED:

- Попытка выполнить команду SVC/BKPT из обработчика SVCall/Debug monitor или из обработчика другого исключения с таким же или более высоким приоритетом.

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

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

 

Дальше я в тупике, может у кого есть идеи.

 

 

 

 

[Aurochs 0]

On 2/4/2020 at 2:09 PM, Kurator said:

Дальше я в тупике, может у кого есть идеи.

Хардфолтное исключение обрабатывается с САМЫМ ВЫСОКИМ приоритетом. И никакое другое исключение (а команда BKPT генерирует исключение) этот обработчик ПРЕРВАТЬ НЕ МОЖЕТ.