Глюк приёма данных по USART - Страница 4

H4LF · 02.04.2017, 19:33

dgrishin, ага, работающим, но не всегда. Вот значит как... значит я когда-то написал на C сферического коня в вакууме, а не простенькую, но работающую GSM сигнализацию...
Я в общем-то тоже не вижу больше смысла писать тут, свой путь я указал, пас отдал... Надеюсь топикстартер так или иначе выкарабкается. Пусть даже и с отстреленными конечностями

akegor · 02.04.2017, 19:33

Сообщение от H4LF

после того как конечный автомат(КА) определил

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

Сообщение от H4LF

он так работает

В модеме крутится RTOS и у нее не стоит высшим приоритетом непрерывность передачи сообщений, у модема первоочередные задачки посерьезней. Это для ТС-а.

AR_Favorit · 02.04.2017, 20:05

Сообщение от NewWriter

У вас там что, используется целая куча высокоприоритетных прерываний, задержка обработки которых грозит ядерной катастрофой, чтоль?

Это наследие тяжких времен, тактовая частота один мегагерц, аппаратный стек несколько байт, прерывания неприоритетные, а то и ваще одно на всё, ну вы понели. С тех пор и затаился первобытный страх в генах - "не ставь в прерывание ничего, кроме флажка, обрабатывай его в мейне!" Вот и ставят флажки до сих пор, и на 40 мегагерцах, и на 100)))
Хотя и в те стародавние времена, если головой работать, то почему-то получались у людей неплохие программы, исполняющиеся полностью в прерываниях.

H4LF · 02.04.2017, 20:12

Сообщение от akegor

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

А, кажется понял про какой это счётчик. У меня он считал только байты самой строки, без CR LF. По окончанию строки (и после её обработки) он обнулялся. Да, по нему можно определять наезд "головы" на "хвост" (в терминах уробороса

) если придёт сплошная строка больше размера буфера. Но зачем декремент? У обоих индексов кольцевого буфера тоже всегда инкремент... Или всё же я чего-то не понял...

AR_Favorit · 02.04.2017, 20:15

Сообщение от H4LF

Но зачем декремент?

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

Но так делать необязательно

H4LF · 02.04.2017, 21:07

AR_Favorit, Вообще то я предложил (и делал) кольцевой буфер. Там не нужен декремент и не представляю для чего может быть нужен (если не считать обработку в этом буфере поступивших строк). Заполнение я определяю по разнице индекса головы и индекса хвоста:

Цитата:

Проверка на наличие данных в буфере происходит очень просто - если idxIN не равен idxOUT, то в буфере есть данные, в противном случае данных в буфере нет.

Зачем ещё какой-то счётчик? Ну кроме того что в КА считает длину поступающей строки.
Можно конечно взять для приёма (и передачи) не кольцевой буфер, но я сторонник принципа KISS.
На STM32 с его DMA и другими плюшками может быть проще и надёжнее будет сделать как-то по другому, я не знаю.
Про наследие - спасибо, посмешили

но если это про меня - то я не настолько суров. И вообще у меня мало опыта. PIC мне как-то не очень люб, если не ошибаюсь это у него был аппаратный стек. Ну и у какого-то младшего AVR без RAM. Полностью на прерываниях... сейчас всё больше полностью на delay_ms... Ну и я в общем-то даже не против, главное чтобы какой нибудь Therac-25 не сделали. Ну а затупить можно любое количество мегагерцев, даже число Пи до эпического знака после запятой не нужно для этого вычислять

А по теме - тут в основном не о задержках обработки прерываний, фиг с ними, а о правильном (надёжном) приёме данных по UART от модема.

akegor · 02.04.2017, 21:13

Сообщение от H4LF

Зачем ещё какой-то счётчик?

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

AR_Favorit · 02.04.2017, 21:26

Сообщение от H4LF

Проверка на наличие данных в буфере происходит очень просто - если idxIN не равен idxOUT, то в буфере есть данные, в противном случае данных в буфере нет.

Иногда удобнее работать с отдельной переменной.

Сообщение от H4LF

о если это про меня

Неееее, это про боязнь ставить любые обработки в прерывания и летящие тапки в кодера, такие обработки практикующего. Сам - практикую вполне успешно.

Сообщение от H4LF

на delay_ms

ИМХО вообще не нужная штука ни для чего, кроме первоначального ознакомления с контроллером. Нужна задержка - ну и отсчитываем ее в соответствующем состоянии КА. Зачем все стопорить-то?

Сообщение от H4LF

о правильном (надёжном) приёме данных по UART от модема

а вот тут печаль-беда. Без аппаратного управления потоком либо наличия ну очень больших ресурсов это недостижимо. Модем теоретически может наплевать unsolicited-ов так много и невовремя, что сломает любую нашу обработку, вмещающуюся в среднестатистический МК, особенно, если этот самый МК помимо общения с модемом делает что-то еще важное. Поэтому просто принимаем как данность, что мы всегда могли что-то пропустить и повторяем запросы, на которые нет ответа, СМСки периодически проверяем сами, а не надеемся только на отловленное CMTI и т.д.

STM32F0 · 02.04.2017, 22:19

Сообщение от AR_Favorit

это про боязнь ставить любые обработки в прерывания и летящие тапки в кодера, такие обработки практикующего.

Это ПЫХ-АВРовская детская болячка, называется "зашли быстро, еще быстрее вышли, лучше если вышли ещё до того как зашли". Связана с убогостью данных МК.

akegor · 02.04.2017, 22:35

Сообщение от STM32F0

Связана с убогостью данных МК.

Не только. Убогость мыслительного аппарата тоже этому способствует. Если приветствуется не разумная необходимость и достаточность, а слепое бездумное подражание авторитетам.