Перейти к содержанию
    

wild.hamster

Участник
  • Постов

    12
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Посетители профиля

433 просмотра профиля
  1. использую SDK_1418B07SIM800C32_BT_EAT, сравнил с предыдущими версиями SDK , у них файлы core.lib идентичны, кроме него больше ничего линковать не требуется (кроме стандартной либы RVCT, которая к SDK не относится). В последней версии SDK только заголовочные файлы изменились, + API индивидуальное я так понял для конкретных заказчиков. Потому велика вероятность(проверю еще раз но маловероятно что есть ошибка) что это все в последней версии прошивок и sdk.
  2. прошивка 1418B09SIM800C32_BT_EAT, ядро сразу не отвечу, как посмотреть? :-). Могу функции для проверки пунктов 1-2 написать, там не больше 10 строк, все видно сразу. Про SIM_DET тож могу написать но это не в эту тему
  3. >>> Особых косяков не обнаружено, а что касается 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 оптимальное решение.
  4. Про open-cpu лучше сразу забыть, смотрел я их исходники - я в первом классе лучше писал, такое г. просто редкость. EAT - гораздо лучше, но очень много косяков, есть функции которые не работают, UART наполовину нерабочий, а при написании чего то чуть более сложного перезагружается, короче надо долго приспосабливаться и обходить "ловушки". В китае очень разочаровался. Telit выглядит достойнее, намного лучше документация, проще программируется. Я его особо не щупал, только на этапе выбора модуля, сейчас бы выбрал его. Но задачка совсем примитивная так что думаю EAT подойдет. есть еще модули от cinterion - BGS5 и wavecom (что там сейчас не знаю), модули в два раза дороже но это того стоит, тем более если штучные изделия. BGS5 программируется на Java ME, все просто, документация отличная, тех поддержка отзывчивая и готова исправлять баги достаточно быстро (найти их будет крайне тяжело).
  5. Прежде чем отвлекать людей имею привычку проверять и перепроверять все возможные варианты. 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 как раз работает.
  6. Хотелось бы протестировать B09. Подскажите пожалуйста, на какой email можно отправить запрос и его формат.
  7. Если примерно знать протокол TCP, можно использовать Wireshark все становится ясно, кто в чем виноват. Протестировал SIM800c, работает корректно. Как было сказано, есть операторы, которые перестают обслуживать GPRS канал после определенного времени простоя и никаких признаков не подают, мертвый канал определяет противоположная сторона несколькими попытками ретрансмита. Лечится это PING'ом, но я использую keepalive (SIM800 имеет настройку - 1 команда и проблем нет).
  8. CADiLO, спасибо большое за информацию! Попробую связаться с Цырен. EAT использую B08. B09 пока не знаю где достать. Обычно прошивки беру с simcom.ee, они офф. дистрибьютор Эстонии, выкладывают прошивки и обновляют периодически. Это проект дешёвого модема (на 30-40% дешевле аналогов), поэтому решил использовать EAT, все что можно сделать софтово для меня не проблема и реализовано, нужен только способ управления периферией к чему у меня вопросов не было до последнего момента т.к. в hardware design все написано, все режимы. >>>Мелочью занимаемся мы, можно сказать по собственной инициативе. За это отдельное спасибо и уважение.
  9. Ат команда упр.потоком AT+IFC при использовании EAT всегда выдает ошибку. С чтением из UART проблем быть не должно а вот с записью хуже, если я набил в буфер передачи 2 Кб, а приемник сбросил сигнал готовности то SIM все равно будет их выдавать из порта. Если бросать в буфер по 2-3 байта и контролировать по событию опустошения буфера или завершения передачи то из за того что работает система сообщений будут наблюдаться задержки и увеличение межсимвольного интервала при выдачи. И самое интересное что официальные дистрибьюторы на письма не отвечают. Походу они работают только с организация которые у них большие партии модулей покупают :mad: CADiLO, я посмотрел в ваш профиль, увидел что вы из Гаммы. Этот вопрос я отправлял в mt-system 3 дня назад, ответа нет. Час назад в Гамму отправлял но в другой офис, не в Днепр. Думаю вряд ли дождусь ответа.
  10. Можно задать вытекающий вопрос. Как организовать управление потоком если модуль не может формировать сигналы исходя из состояния заполнения буферов UART1? Реагировать на тоже не может. В EAT нет API для реализации этих функций.
  11. Спасибо за ответ. Но если бы так все работало то эти сигналы должны ретранслироваться на удаленную сторону (от компа к компу) с большой скоростью. Допустим, мне нужно принять данные из UART и передать через GPRS. Удаленная сторона готова принять данные но я не могу их передать, приемный буфер UART должен заполниться и сбросить сигнал CTS , пока оператор не заберет данные из передающего буфера сокета модема. Получается локальный комп хочет прередать данные, удаленный может принять, а модем ничего в этот момент не может.
  12. Добрый день! Понадобилось задействовать пины управления потоком CTS/RTS SIM800C (пины 3 и 4). Используется EAT. В документации написано что эти пины в этом режиме по умолчанию. Произвожу запись в порт (в модуль) но не читаю из порта в EAT, CTS не работает. Записываю в порт из модуля, получаю данные, но не реагирует на состояний линии RTS - данные всегда выдаются. Указание режима ни чего не меняет. Может кто нибудь знает в чем может быть проблема.
×
×
  • Создать...