Работа с модемом

@moumty · Регистрация: 09.02.2015

Студворк — интернет-сервис помощи студентам

Добрый день, использую TNKernel и ST.
Есть GSM модем, работу с модемом сделал через queue.
Сделал кольцевой буфер в который пишутся все входящие байты с модема.
Когда подряд пришли байты 0x0D и 0x0A отправляем очередь перед этим поставив окончание (0х00) в буфер после входящего сообщения от модема, в очереди передаем начало сообщения, чтобы потом в задаче обработчике очереди выдернуть из буфера пришедшую строку из модема. Проблема возникает, когда нужно получить от модема входящий пакет данных.
Когда на модем приходят данные, то он выдает строчку, например +RESP: "recv".
После, которой нужно отправить команду чтобы считать данные,
AT+READDATA=1000

После чего модем отвечает: +READDATA, <кол-во байтов данных>
и дальше уже выдает сами данные.
Так вот, т.к мы используем очереди, то получается, что можем входящее сообщения обрабатывать с небольшой задержкой, т.е пока мы обрабатывали одну строчку, то от модема пришла вторая строчка и поместилась в очередь. Поэтому когда в обработчике очереди мы видим, что модем сейчас начнет выдавать данные, то эти данные уже поместились в следующую очередь (не знаю как менее коряво объяснить :D)).
Думал сначала сделать проще: получили событие от модема, узнали сколько байтов нам ждать и потом в прерывании уже просто при получении байта отнимать от кол-ва ожидаемых байтов и так до тех пор пока не получили нужное кол-во...
Но по факту получается, как я выше описал, что к тому времени когда мы обработали сообщения от модема, о том, что нужно принимать данные, эти самые данные начали записывать в следующую очередь...
Можно в самой очереди выдернуть данные из модема, но тут проблема в том, что данные могут приходить не только текстовые, но и бинарные, а это значит, что символ окончания строки может уже помешать нам.
В общем, в некотором ступоре нахожусь, не понимаю какой лучше алгоритм тогда использовать. От очередей отказываться не охота, т.к они спасут от "потерянных" данных от модема, а потеря какого-нибудь отклика или события модема очень чревато.
В идеале как-то заставить в прерывании записывать в отдельный буфер данные, но как... :(
Может, кто-то работал с модема, у кого был опыт? Заранее благодарен.

@SVM · 13.02.2015, 05:37

moumty, Вы сможете сами расшифровать алгоритмы работы модемов. Нужно переписать Ваш вариант алгоритма в классическом виде. Это подробно описано в "Основы дискретной математики" В.А. Горбатов, 1986 г.
Вариант "упрощения" для этих устройств не получится. Передача пакетов практически всегда идёт в режиме диалога обоих модемов.

@Ymk · 08.04.2015, 23:53

очереди (фифо) - это одно, парсер ответов модема - другое. грубо говоря, на прерываниях от uart все надо класть в фифо как есть, и ничего не додумывать. а в каком-то процессе читать этот фифо как успеется и делать соотв. работу. и будет как бы 2 режима: читать до конца строки и читать ровно n байт. и никаких заморочек.

каким образом это относится к дискретной математике?

@Sovo · 09.04.2015, 11:15

Я всегда делал два буфера. В один принимается строка, по окончании копируется во второй буфер и отдаётся на анализ.

@Ymk · 09.04.2015, 15:37

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

Я всегда делал два буфера. В один принимается строка, по окончании копируется во второй буфер и отдаётся на анализ.

всегда делал (и если работало) - хорошо. но хорошо бы и объяснение - почему именно так, а не иначе.

тут-то проблема в том, что есть 2 вида данных: строки и бинари.

@Sovo · 09.04.2015, 17:03

Хорошо, объясняю. Приём всегда идёт в свободный буфер. Разборка пакета всегда с собственным буфером. Не важно, сколько времени займёт проверка буфера, лишь бы эта процедура закончилась до окончания приёма второй посылки. Динные всегда разделены и находятся в безопасности. Для полной безопасности можно добавить мютекс или передавать запрос на сообщение флагом.
Это крайний случай FIFO буфера, всего на два значения.
К видам данных это не имеет прямого отношения, для приёмника всё равно, что принимать.

Новые блоги и статьи Все статьи Все блоги /
My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .
Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача №1: при указании работ (справочник РаботыПоРемонтуСпецтехники),. . .

@moumty 0 / 0 / 0 Регистрация: 09.02.2015 Сообщений: 35

	Работа с модемом 12.02.2015, 22:28. Показов 7338. Ответов 5 Метки нет (Все метки) Добрый день, использую TNKernel и ST. Есть GSM модем, работу с модемом сделал через queue. Сделал кольцевой буфер в который пишутся все входящие байты с модема. Когда подряд пришли байты 0x0D и 0x0A отправляем очередь перед этим поставив окончание (0х00) в буфер после входящего сообщения от модема, в очереди передаем начало сообщения, чтобы потом в задаче обработчике очереди выдернуть из буфера пришедшую строку из модема. Проблема возникает, когда нужно получить от модема входящий пакет данных. Когда на модем приходят данные, то он выдает строчку, например +RESP: "recv". После, которой нужно отправить команду чтобы считать данные, AT+READDATA=1000 После чего модем отвечает: +READDATA, <кол-во байтов данных> и дальше уже выдает сами данные. Так вот, т.к мы используем очереди, то получается, что можем входящее сообщения обрабатывать с небольшой задержкой, т.е пока мы обрабатывали одну строчку, то от модема пришла вторая строчка и поместилась в очередь. Поэтому когда в обработчике очереди мы видим, что модем сейчас начнет выдавать данные, то эти данные уже поместились в следующую очередь (не знаю как менее коряво объяснить :D)). Думал сначала сделать проще: получили событие от модема, узнали сколько байтов нам ждать и потом в прерывании уже просто при получении байта отнимать от кол-ва ожидаемых байтов и так до тех пор пока не получили нужное кол-во... Но по факту получается, как я выше описал, что к тому времени когда мы обработали сообщения от модема, о том, что нужно принимать данные, эти самые данные начали записывать в следующую очередь... Можно в самой очереди выдернуть данные из модема, но тут проблема в том, что данные могут приходить не только текстовые, но и бинарные, а это значит, что символ окончания строки может уже помешать нам. В общем, в некотором ступоре нахожусь, не понимаю какой лучше алгоритм тогда использовать. От очередей отказываться не охота, т.к они спасут от "потерянных" данных от модема, а потеря какого-нибудь отклика или события модема очень чревато. В идеале как-то заставить в прерывании записывать в отдельный буфер данные, но как... :( Может, кто-то работал с модема, у кого был опыт? Заранее благодарен. 0

@SVM 0 / 0 / 0 Регистрация: 11.02.2012 Сообщений: 2
	13.02.2015, 05:37
	moumty, Вы сможете сами расшифровать алгоритмы работы модемов. Нужно переписать Ваш вариант алгоритма в классическом виде. Это подробно описано в "Основы дискретной математики" В.А. Горбатов, 1986 г. Вариант "упрощения" для этих устройств не получится. Передача пакетов практически всегда идёт в режиме диалога обоих модемов. 0

@Ymk 0 / 0 / 0 Регистрация: 18.03.2010 Сообщений: 2,230
	08.04.2015, 23:53
	очереди (фифо) - это одно, парсер ответов модема - другое. грубо говоря, на прерываниях от uart все надо класть в фифо как есть, и ничего не додумывать. а в каком-то процессе читать этот фифо как успеется и делать соотв. работу. и будет как бы 2 режима: читать до конца строки и читать ровно n байт. и никаких заморочек. каким образом это относится к дискретной математике? 0

@Sovo 0 / 0 / 0 Регистрация: 05.10.2007 Сообщений: 498
	09.04.2015, 11:15
	Я всегда делал два буфера. В один принимается строка, по окончании копируется во второй буфер и отдаётся на анализ. 0

@Sovo 0 / 0 / 0 Регистрация: 05.10.2007 Сообщений: 498
	09.04.2015, 17:03
	Хорошо, объясняю. Приём всегда идёт в свободный буфер. Разборка пакета всегда с собственным буфером. Не важно, сколько времени займёт проверка буфера, лишь бы эта процедура закончилась до окончания приёма второй посылки. Динные всегда разделены и находятся в безопасности. Для полной безопасности можно добавить мютекс или передавать запрос на сообщение флагом. Это крайний случай FIFO буфера, всего на два значения. К видам данных это не имеет прямого отношения, для приёмника всё равно, что принимать. 0