SIM900. Что хотелось бы видеть в области TCP/IP Опции

[Frolov Kirill]

Было бы неплохо порекомендовать авторам ПО SIM900 ввести
в наборе команд относящихся к "TCP/IP application toolkit"
команду противоположную AT+CIPRXGET=3,... -- то-есть
чтоб AT+CIPSEND, или другая команда, позволяла передавать
данные не в бинарном виде, а в HEX (по-аналогии с CIPRXGET=3).

И, кроме того, неплохо было бы иметь возможность непосредственного
приёма данных (без AT+CIPRXGET=1) тоже в HEX. Точно также, например,
как сообщение +CUSD содержит в себе данные в HEX. А не как сейчас
сделано, когда данные передаются в бинарном виде (+IPD<длин>:данные...)

Сейчас практически невозможно надёжно разделить поток данных и команд
модему, если данные передаются в бинарном виде (нет возможности отличить
сообщения модема от принятых данных). Если не использовать AT+CIPRXGET
или AT+CIPMODE=1. Что неудобно. Но в "прозрачном режиме" (AT+CIPMODE=1)
трудно работать с некоторыми UDP-протоколами (например, TFTP), потому,
что нет информации о размере данных в пакете. A при отправке данных в
бинарном виде (AT+CIPSEND сейчас подразумевает только этот вариант) тоже
возникают трудности с уже имеющимся ПО, лучше HEX (строки в языке C и код 0).

Сообщение отредактировал Frolov Kirill - Sep 8 2011, 11:36

[butthead2]

когда данные передаются в бинарном виде (+IPD<длин>:данные...)

Сейчас практически невозможно надёжно разделить поток данных и команд
модему, если данные передаются в бинарном виде (нет возможности отличить
сообщения модема от принятых данных).

Как это невозможно? Очень даже возможно и надежно - словил +IPD и длину и дальше вычитываешь данные. Может имеете в виду что нет в конце данных разделителя \r\n и вобще невозможно разобрать всю посылку как строку?
Для удобства в будущем - было бы неплохо. Но и так в общем то прекрасно работает.

[Frolov Kirill]

Как это невозможно? Очень даже возможно и надежно - словил +IPD и длину и дальше вычитываешь данные.

Это только так кажется. Тут же комплексная проблема. А что если микроконтроллер перестартовал когда модем в таком состоянии находился? А что если модем в этот момент перезапустился? Уже нужны костыли и подпорки. И архитектура ПО странная: в одном канале получается 2 разных протокола. Один текстом, другой бинарный. Может формально и возможно, но практически это всё обрастает ненужными сложностями. Не зря в стандарте все бинарные данные в HEX кодируются (SMS, записная книжка, команды SIM-карты, USSD...)

[Velund]

Проще говоря, предлагается сделать как у Моторолы в G24/G24L/G30?

[butthead2]

Это только так кажется. Тут же комплексная проблема. А что если микроконтроллер перестартовал когда модем в таком состоянии находился? А что если модем в этот момент перезапустился? Уже нужны костыли и подпорки. И архитектура ПО странная: в одном канале получается 2 разных протокола. Один текстом, другой бинарный. Может формально и возможно, но практически это всё обрастает ненужными сложностями. Не зря в стандарте все бинарные данные в HEX кодируются (SMS, записная книжка, команды SIM-карты, USSD...)

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

Единственное для чего симкомовцам надо сделать эту фишку - для единообразия и более-менее совместимости с другими производителями.