SIM900. Прием команд от TCP сервера., Как исключить коллизии в порту при приеме внешних команд? Опции

[Иван Плетнев]

Здравствуйте!

Разрабатываю устройство, которое собирает различные данные с датчиков и с периодичностью в одну минуту отправляет их на сервер посредством SIM900. Использую обычный режим AT-команд, не transparent, то есть команда AT+CIPSEND, приходит приглашение ">", отсылаю в порт строку, дожидаюсь SEND OK, всё. В данный момент добился надежной отсылки данных. Встал вопрос приёма команд от сервера. Все в общем, работает, за исключением случая, когда микроконтроллер ждет ответа от SIM900 и в этот момент приходит команда от сервера. Аппаратное управление потоком в этом случае вряд ли подойдет..
Подскажите, пожалуйста, кто как справился с этой проблемой?

[zebrox]

После снятия ртса сим выдаст следующую строку, проц выставит ртс, обработает ее, уберет ртс и так до тех пор, пока сим все строки не выдаст.

Большинство сообщений от сима имею заголовок, +IPR например. В програме заданы все заголовки на которые надо реагировать.
Если в пришедшей строке найден один из заголовков, то проц уходит в его обработчик, который знает в какой что читать.
ОК и ЕРРОР так-же определены как заголовки. При их приходе проверяется проверяется последняя переданная команда (храню условный номер).
Если на эту команду ответ должен быть ОК, а пришел ЕРРОР, то снова передаю ту команду.
Если пришел ОК то переход к слудующей команде. Это уже обычная машина сосостояний.

[tdocs.su]

Если пришел ОК то переход к слудующей команде. Это уже обычная машина сосостояний.

Не-а. Надо сначала "пропихнуть" автомат в следующее состояние, которое будет ждать прихода именно Ок.

Немного не понял про else. Что Вы имеете ввиду?

Вот - http://www.delphisources.ru/forum/showthread.php?t=6547 Обратите внимание, что case намного прозрачнее if. Но это его удобство, проще читать код, все видно хорошо.
А ссылку на статью давал, там есть рисунки с кодами автомата. Для возвртата в исходное состояние используется оператор goto. И под каждым case устанавливается следующее состояние.
Короче, все просто оказалось, но намучился с этим всем конкретно, когда шел не автоматным путем.

[Иван Плетнев]

Не-а. Надо сначала "пропихнуть" автомат в следующее состояние, которое будет ждать прихода именно Ок.

Вот - http://www.delphisources.ru/forum/showthread.php?t=6547 Обратите внимание, что case намного прозрачнее if. Но это его удобство, проще читать код, все видно хорошо.
А ссылку на статью давал, там есть рисунки с кодами автомата. Для возвртата в исходное состояние используется оператор goto. И под каждым case устанавливается следующее состояние.
Короче, все просто оказалось, но намучился с этим всем конкретно, когда шел не автоматным путем.

Да я ж говорю, что тоже на автоматах всё у меня

Код

            case 0:
                ExtraBufferCopyFlag = 1; //флаг копирования нужного фрагмента буфера (со смещением)
                send_command0(CIPSTATUS);                
                gprsstate++;
                response_timeout=2000;
                break;
            case 1:
                if (!response_wait) { //если дождались ответа
                    switch (response_code) {
                        case 15: // INITIAL STATE
                            gprsstate++;
                            ready_to_send=0;
                            break;
                        case 17: // PDP DEACT STATE (Отключен сетью)
                            gprsstate = 100; //закрываем все подключения
                            ready_to_send=0;
                            break;
                        case 16: //TCP CLOSED
                            gprsstate = 12;
//                            gsm_delay=300;
                            ready_to_send=0;
                            break;
                        case 18: //CONNECT OK
                            gprsstate = 20;
                            send_flag=1;
                            break;
                        case 20: //CONNECTING
                            gprsstate = 30;
                            break;
                        case 3:
                            gprsstate=30;
                            break;
                    }
                }

Ну и так далее.

Тоже определял конец строки по таймауту. Работало.
Потом перешел по \r\n. По \r\n оказалось более работоспособно, и нет никакой необходимости в знании сколько их будет в ответе. К примеру посмотрим на строку \r\nOK\r\nблаблабла\r\n, по первому \n мы видим что это начало строки (так как количество принятых байтов равно 2). По второму получаем ответ OK. По третьему получаем ответ блаблабла. Поэтому при разборе ответов, задача сводится к проверке "наборов байтов находящихся между \r\n". Единственное что портит всю картину это приглашение к вводу данных "> ", но и это обходится очень просто.

Это Вы в прерывании всё делаете? Если так, то приличный такой обработчик в прерывании будет крутиться. А если нет, тогда опять не ясно, как конец сообщения определить?