asnoeuh 0 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба On 11/15/2019 at 12:13 PM, Eddy_Em said: Ставите прерывание на получение символа '\n' В STM32 так можно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmailer 0 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба 20 minutes ago, asnoeuh said: В STM32 так можно? Нельзя. Прерывание ставится на получение указанного кол-во байт. Вы как-то выхватили фразу из контекста. Там же дальше человек пишет подробнее что он имел ввиду под этой фразой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
asnoeuh 0 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба То что он дальше пишет у меня не вызвало вопроса. Специально для вас, фраза целиком: Quote Ставите прерывание на получение символа '\n' и формируете буфер средствами DMA (либо можете в прерывании по RXNE формировать буфер, без DMA, но анализировать на '\n' внутри прерывания). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 2 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба 1 hour ago, asnoeuh said: В STM32 так можно? Конечно. В STM32F0. Я такое вытворял, но народ говорит, мол, не очень это хорошо при сильных помехах на линии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба 3 hours ago, Eddy_Em said: Конечно. Конечно же, это не так. Правильный ответ "можно в некоторых сериях камней". Например, в F0, L0, L4, F3, F7. Ключевое слово для поиска в референс мануале - "Character match flag". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 83 16 декабря, 2019 Опубликовано 16 декабря, 2019 · Жалоба 23 часа назад, SapegoAL сказал: Сейчас, я совершенно случайно увидел вот такое... stm32f7xx_hal_adc.c stm32f7xx_ll_adc.c А еще вы не видели stm32h7xx_hal_adc_ex.c :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба В 16.12.2019 в 10:27, asnoeuh сказал: То что он дальше пишет у меня не вызвало вопроса. "Можно" - "не можно" - всё равно. Лучше просто так не делать. В 16.12.2019 в 11:17, Eddy_Em сказал: Конечно. В STM32F0. Я такое вытворял, но народ говорит, мол, не очень это хорошо при сильных помехах на линии. Не в помехах дело. Внешний интерфейс для программы МК - это именно внешний интерфейс. Программа должна быть построена так, чтобы не сходить с ума при любых событиях на внешних интерфейсах. '\n' может прийти, может не прийти - вне зависимости от протокола - программа не должна падать от этого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 2 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба А она и не будет падать от переполнения буфера. Просто буфер будет выброшен как невалидная команда, и начнет заполняться сначала. Правда, в следующий заход опять получится невалидная команда, ну и ладно... Совершенно аналогичная ситуация будет и с посимвольным разбором в прерывании. Точно так же при дохождении до конца буфера содержимое будет выброшено как невалидное. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbinger 10 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба 10 минут назад, jcxz сказал: '\n' может прийти, может не прийти Автор темы вроде не писал, что там текст. М.б. какой-нибудь бинарный протокол с пакетами переменной длины для полного счастья. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба 4 минуты назад, Harbinger сказал: Автор темы вроде не писал, что там текст. М.б. какой-нибудь бинарный протокол с пакетами переменной длины. Да и я вроде не писал про текст. Без разницы что там. 4 минуты назад, Eddy_Em сказал: Правда, в следующий заход опять получится невалидная команда, ну и ладно... Вот именно. И так далее... Причём так может выкинуться не один, а сразу много пакетов. Цитата Совершенно аналогичная ситуация будет и с посимвольным разбором в прерывании. Точно так же при дохождении до конца буфера содержимое будет выброшено как невалидное. Но следующий кадр не будет потерян. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 2 17 декабря, 2019 Опубликовано 17 декабря, 2019 (изменено) · Жалоба Очень даже будет. Никакой разницы нет, DMA у вас с прерыванием по символу, или же побайтный разбор строки с поиском этого же символа. Если строка невалидная, она в обоих случаях будет выброшена вместе с частью следующей строки (что сделает ту тоже невалидной). А насчет передачи бинарных данных - это всегда плохо, т.к. платформозависимо. Понятно, что для МК и программиста это лучше — МК меньше работы по парсингу, программисту меньше клавиши давить. Но с точки зрения интерфейсов... Ведь при текстовом формате вы просто подключаете терминал и пишете/читаете. А если формат бинарный, придется писать какую-то прослойку между клавиатурой/экраном и каналом передачи данных. Неудобно, однако. Изменено 17 декабря, 2019 пользователем Eddy_Em Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbinger 10 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба 3 часа назад, jcxz сказал: Причём так может выкинуться не один, а сразу много пакетов. Это тайм-аутами разрулить можно. Теми самими 50...100 мс, что в стартпосте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kurator 0 4 февраля, 2020 Опубликовано 4 февраля, 2020 · Жалоба Я уже начал задумываться о бубне и веточке с тряпочками в решении проблемы. Написал программу на ассемблере для 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 4 февраля, 2020 Опубликовано 4 февраля, 2020 · Жалоба Я уже начал задумываться о бубне и веточке с тряпочками в решении проблемы. Написал программу на ассемблере для 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 11 февраля, 2020 Опубликовано 11 февраля, 2020 · Жалоба On 2/4/2020 at 2:09 PM, Kurator said: Дальше я в тупике, может у кого есть идеи. Хардфолтное исключение обрабатывается с САМЫМ ВЫСОКИМ приоритетом. И никакое другое исключение (а команда BKPT генерирует исключение) этот обработчик ПРЕРВАТЬ НЕ МОЖЕТ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться