[stepper88 0]

Недавно соорудил управление Quectel M10 аналогии с проектом для MSP430 с сайта AlexandrY (тест GSM-модема) - вроде бы, когда отправляю комманды модему во время звонков или инициализации - все работает нормально. Но не знаю, как сделать отлов сообщений от модема типа RING или сигнала о пришедшей SMS. Подскажите пожалуйста - работаю с Keil RTX на LPC2378.

[Артём__ 0]

Но не знаю, как сделать отлов сообщений от модема типа RING или сигнала о пришедшей SMS. Подскажите пожалуйста - работаю с Keil RTX на LPC2378.

А может и не нужно делать отлов этих сообщений?

Статус входящего соединения можно запросить командой (для sim900 команда +CPAS).

СМСки можно запросить командой AT+CMGL.

 

[zebrox 0]

Думаю "отлов" это единственно правильный метод. Если "отлов" не ловит 100% сообщений от модема, то и нет гарантии, что ответ на запрос будет правильно обработан и получен вообще. Если бы модем только отвечал на запросы, и никогда сам ничего не генерил, то отлов не нужен был бы. А если есть хоть малая вероятность того, что модем сам что-то выдаст, то нужно быть готовым в любой момент, обработать любую строку от модема.

 

У меня так:

const char READ_SMS_descriptor[] = "+CMGR:";

 

 

потом в где-то в основмном цикле

if(CPUSearchInArray(READ_SMS_descriptor, GL_BUFFERS.GSM))

{

GL_INTERRUPTS.SMS_IS_COMING = SMSPreprocessSMSMessage();

}

 

[megajohn 3]

делаю всё как AlexandrY но с некоторыми отличиями:

Все строковые AT-ответы свожу к битам, и тогда при отправке ждем тупо маски at_send( "AT+BLA\r", mdm_tx_ok + mdm_tx_dialing, MY_TIMEOUT, RETRIES_QNTY )

Сама работа делается через сообщения: типо отправь смс #1, #2 и позвони. Эти сообщения помещаются в очередь, и выполняются по очереди. Если в момент выполнения приходит ассинронное сообщение, то оно размещается в очереди (к примеру что пришлс смс с порядковым номером 3). И после выполнения текущей пользовательской операции, обрабатывается если есть ассинхронные сообщения, с оповещением юзеру.

[Артём__ 0]

Думаю "отлов" это единственно правильный метод. Если "отлов" не ловит 100% сообщений от модема, то и нет гарантии, что ответ на запрос будет правильно обработан и получен вообще.

Вы уверены, что в документации на модем описаны все 100% сообщений, которые может выдать модем?

[jack_avenger 4]

Думаю что речь не идет о 100% парсинге, а только о 100% приеме

[stepper88 0]

to megajohn

А как у вас построенна эта обработка асинхронных сообщений?

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

[vassabi 0]

...Как сделать так, чтоб в этот момент или задача, следящая за RING или смс вообще не лезла в буфер ...

А зачем RX и TX пихать в один буфер?

 

 

[jack_avenger 4]

to megajohn

А как у вас построенна эта обработка асинхронных сообщений?

По логике модем не должен пихать unsolicited в промежуток между отправкой эха команды и результатом выполнения команды.

[zebrox 0]

Ловить надо только то, что нас интересует.

 

В том то и дело, что модем никому ничего не должен.

Он черный ящик, может отработать, может нет, может отвалится в любой момент может нет.

 

Задача должна занимать порт модема, на определенное время.

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

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

 

Если пришел юрц, то просто обрабатываем его, и если он нас интересует, записываем в буфер, какое действие надо сделать.

И сделаем его, как только порт освободится.

 

По такому принципу сделан прием смс.

В любой момен приходит юрц, с позицией смса в буфере симки.

Эта прозиция сохраняется.

И когда порт будет свободен, смс вычитывается из той позиции.

 

Получается конечный автомат занятия юарта процессами.

 

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

[jack_avenger 4]

Думаю "отлов" это единственно правильный метод. Если "отлов" не ловит 100% сообщений от модема, то и нет гарантии, что ответ на запрос будет правильно обработан и получен вообще.

Ловить надо только то, что нас интересует.

Какая из мыслей окончательная у Вас?

 

В том то и дело, что модем никому ничего не должен.

Он черный ящик, может отработать, может нет, может отвалится в любой момент может нет.

Поведение модема должно соответствовать даташиту.

Хотя попадался мне модем который даже после команды ATV0 на некоторые команды внутреннего TCP/IP стека отвечал <CR><LF>OK<CR><LF>.

 

Задача должна занимать порт модема, на определенное время.

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

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

 

Если пришел юрц, то просто обрабатываем его, и если он нас интересует, записываем в буфер, какое действие надо сделать.

И сделаем его, как только порт освободится.

 

По такому принципу сделан прием смс.

В любой момен приходит юрц, с позицией смса в буфере симки.

Эта прозиция сохраняется.

И когда порт будет свободен, смс вычитывается из той позиции.

 

Получается конечный автомат занятия юарта процессами.

 

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

А я вот не могу себе позволить такую роскошь - несколько процессов для работы с одним только модемом

[stepper88 0]

А зачем RX и TX пихать в один буфер?

Буферы действительно разные, но охота, чтоб задача, которая ожидает RING, не мешала получить ответы на комманды

А если с помощью мьютекса не пускать задачу, ожидающую RING, когда идет набор номера или прием смс нормальным будет решением?

[zebrox 0]

Какая из мыслей окончательная у Вас?

А я вот не могу себе позволить такую роскошь - несколько процессов для работы с одним только модемом

 

Окончательная мысль в том, что получаем все строки от модема, те которые нас не интереуют в данный момнет, пропускаем мимо "ушей").

ЮРЦ нас инересуют всегда и везде, но только те которые нас интересуют.

 

Под процессом я подразумеваю функцию, которой требуется доступ к юарту.

У меня сделано так, что раз в секунду проц заходит во все функции, которым может потребоваться модем. Если функции есть "что сказать" модему и модем готов слушать (т.е. порт не знат, т.е. никакая другая функция модему уже ничего не сказала), то она занимает порт на определенное время и передатет сообщение модему.

 

При приходет ответа, функция разбора ответа, видит, что порт занят, той функцией, и обрабатывает ответ в ее контексте.

Если ответ подразумевает отпускание юарта, то он отпускается.

 

В общем, как-то так)

 

А если с помощью мьютекса не пускать задачу, ожидающую RING, когда идет набор номера или прием смс нормальным будет решением?

Это не нормальное, это правильное решение!

Изменено 22 марта, 2013 пользователем zebrox

[jack_avenger 4]

Окончательная мысль в том, что получаем все строки от модема, те которые нас не интереуют в данный момнет, пропускаем мимо "ушей").

ЮРЦ нас инересуют всегда и везде, но только те которые нас интересуют.

А как Вы обрабатываете ситуацию когда URC приходит непосредственно перед отправкой команды модему?

 

[zebrox 0]

А как Вы обрабатываете ситуацию когда URC приходит непосредственно перед отправкой команды модему?

 

Для этого, этого использую контроль потока.

Процессок, перед проходом по "отправляющим" функциям, выставляет сигнал РТЦ.

После выхода, убирает.