wild.hamster

использую SDK_1418B07SIM800C32_BT_EAT, сравнил с предыдущими версиями SDK , у них файлы core.lib идентичны, кроме него больше ничего линковать не требуется (кроме стандартной либы RVCT, которая к SDK не относится). В последней версии SDK только заголовочные файлы изменились, + API индивидуальное я так понял для конкретных заказчиков. Потому велика вероятность(проверю еще раз но маловероятно что есть ошибка) что это все в последней версии прошивок и sdk.

прошивка 1418B09SIM800C32_BT_EAT, ядро сразу не отвечу, как посмотреть? :-). Могу функции для проверки пунктов 1-2 написать, там не больше 10 строк, все видно сразу. Про SIM_DET тож могу написать но это не в эту тему

>>> Особых косяков не обнаружено, а что касается UART, то там вопрос только к буферу - многим он не нужен, поэтому переписывают работу без него прямо через API. тогда такой вопрос, какое API нужно использовать используется? скажу сразу, то что проверяется 1 строчкой кода: 1. функция eat_uart_get_free_space не работает, все время возвращает 2048 (буфер пуст) даже если вызывать сразу после записи в порт. Если записывать не ориентируясь на свободное место, UART повисает, и больше не выдает данные. 2. EAT_EVENT_UART_READY_WR никогда не приходит. это к пункту 1 вопрос когда же можно записывать следующую порцию данных что бы UARt не повис. 3. уже не 1 строчкой кода. Если при установленном TCP соединении, включенным EAT_EVENT_UART_SEND_COMPLETE и низкой скоростью (проверял на 1200 бит/с, с 115200 работает) отправить данные то модуль перезагружается (стек около 5 вхождений - переполнение маловероятно, запись в UART производилась в callback от сокета, можно попытаться завернуть на очередь сообщений , но все это не очевидно , идем по граблям). это к пункту 2, EAT_EVENT_UART_READY_WR этим способом заменить не получится. Остается только 1 функция - eat_uart_get_send_complete_status которая еще работает (пока не выявил в ней косяков, но это еще не последнее слово). Как переписать без буфера, он не отключается, записывать по 1 символу и в цикле ждать eat_uart_get_send_complete_status? модуль уйдет по своим делам и жди межсимвольный интервал по 5 мс. По поводу SMS, ADC проблем пока не выявлено , но я пока еще его особо не тестировал. GPIO тож нормально за исключением пина SIM_DET, если его настроить как EINT то при изменении состояния модуль перезагружает. для конкретной задачи, EAT оптимальное решение.

Про open-cpu лучше сразу забыть, смотрел я их исходники - я в первом классе лучше писал, такое г. просто редкость. EAT - гораздо лучше, но очень много косяков, есть функции которые не работают, UART наполовину нерабочий, а при написании чего то чуть более сложного перезагружается, короче надо долго приспосабливаться и обходить "ловушки". В китае очень разочаровался. Telit выглядит достойнее, намного лучше документация, проще программируется. Я его особо не щупал, только на этапе выбора модуля, сейчас бы выбрал его. Но задачка совсем примитивная так что думаю EAT подойдет. есть еще модули от cinterion - BGS5 и wavecom (что там сейчас не знаю), модули в два раза дороже но это того стоит, тем более если штучные изделия. BGS5 программируется на Java ME, все просто, документация отличная, тех поддержка отзывчивая и готова исправлять баги достаточно быстро (найти их будет крайне тяжело).

Прежде чем отвлекать людей имею привычку проверять и перепроверять все возможные варианты. N-ное раз прочитал hardware design. После включения модуля на CTS он выдает "0" (~0В, и это он правильно делает, разрешение на передачу). На RTS программой-терминалом включал и выключал этот сигнал, на соответствующий пин приходил нужный сигнал (уровень однозначный 0 или 2.8В, если бы перепутал было что то непонятное в зависимости от того какой выход мощнее). Даже делал чтение как с gpio и он читался притом верно. Отправляю кучу данных и не читаю - CTS не гаснет, сбрасываю RTS но данные все равно выдаются. >>>Сигналы RТS/CTS обычно достаточно инертные - срабатываю по 3/4 или 1/2 буфера. С инертностью буфера согласен но она не причем, выдавал 1 символ каждую секунду, RTS сброшен - все равно выдает его на TX. >>>Еще, возможно, аппаратное управление потоком не работает в режиме команд... В EAT я для ат команд назначаю UART2. UART1 и USB настраиваю на режим передачи данных. А вот в режиме команд аппаратное управление потоком UART1 как раз работает.

Хотелось бы протестировать B09. Подскажите пожалуйста, на какой email можно отправить запрос и его формат.

Если примерно знать протокол TCP, можно использовать Wireshark все становится ясно, кто в чем виноват. Протестировал SIM800c, работает корректно. Как было сказано, есть операторы, которые перестают обслуживать GPRS канал после определенного времени простоя и никаких признаков не подают, мертвый канал определяет противоположная сторона несколькими попытками ретрансмита. Лечится это PING'ом, но я использую keepalive (SIM800 имеет настройку - 1 команда и проблем нет).

CADiLO, спасибо большое за информацию! Попробую связаться с Цырен. EAT использую B08. B09 пока не знаю где достать. Обычно прошивки беру с simcom.ee, они офф. дистрибьютор Эстонии, выкладывают прошивки и обновляют периодически. Это проект дешёвого модема (на 30-40% дешевле аналогов), поэтому решил использовать EAT, все что можно сделать софтово для меня не проблема и реализовано, нужен только способ управления периферией к чему у меня вопросов не было до последнего момента т.к. в hardware design все написано, все режимы. >>>Мелочью занимаемся мы, можно сказать по собственной инициативе. За это отдельное спасибо и уважение.

Ат команда упр.потоком AT+IFC при использовании EAT всегда выдает ошибку. С чтением из UART проблем быть не должно а вот с записью хуже, если я набил в буфер передачи 2 Кб, а приемник сбросил сигнал готовности то SIM все равно будет их выдавать из порта. Если бросать в буфер по 2-3 байта и контролировать по событию опустошения буфера или завершения передачи то из за того что работает система сообщений будут наблюдаться задержки и увеличение межсимвольного интервала при выдачи. И самое интересное что официальные дистрибьюторы на письма не отвечают. Походу они работают только с организация которые у них большие партии модулей покупают :mad: CADiLO, я посмотрел в ваш профиль, увидел что вы из Гаммы. Этот вопрос я отправлял в mt-system 3 дня назад, ответа нет. Час назад в Гамму отправлял но в другой офис, не в Днепр. Думаю вряд ли дождусь ответа.

Можно задать вытекающий вопрос. Как организовать управление потоком если модуль не может формировать сигналы исходя из состояния заполнения буферов UART1? Реагировать на тоже не может. В EAT нет API для реализации этих функций.

Спасибо за ответ. Но если бы так все работало то эти сигналы должны ретранслироваться на удаленную сторону (от компа к компу) с большой скоростью. Допустим, мне нужно принять данные из UART и передать через GPRS. Удаленная сторона готова принять данные но я не могу их передать, приемный буфер UART должен заполниться и сбросить сигнал CTS , пока оператор не заберет данные из передающего буфера сокета модема. Получается локальный комп хочет прередать данные, удаленный может принять, а модем ничего в этот момент не может.

Добрый день! Понадобилось задействовать пины управления потоком CTS/RTS SIM800C (пины 3 и 4). Используется EAT. В документации написано что эти пины в этом режиме по умолчанию. Произвожу запись в порт (в модуль) но не читаю из порта в EAT, CTS не работает. Записываю в порт из модуля, получаю данные, но не реагирует на состояний линии RTS - данные всегда выдаются. Указание режима ни чего не меняет. Может кто нибудь знает в чем может быть проблема.