ap77

Под вистой работаю с виртуальной машиной (WinXP), рекомендую

Да, спасибо. там как-раз и написано: "In order to print from the beginning of a new line, the combination of \r\n will be used"

Спасибо!! Большой респект Romashki и CADiLO! Наши украинские коллеги гораздо внимательнее моего поставщика

Хорошо, попробую. Плату промывал, да. Ноги прозвонил, замыкания нет (и она бы не программировалась иначе). Собственно вывод происходит нормально, если строку вывожу целиком программно. Проблема именно при вводе. Во входном буфере поток "застревает". UPD: Кстати, длину посылки эта функция определяет по завершающему 0, насколько понимаю. Входной параметр строка-константа, а завершитель у нее 0 ведь

Спасибо! *.cla пришел. Правда скомпилировать тест без остальных файлов не получится.

Может кто сталкивался с такой проблемой. В SIM900 EAT прошиваю простой тест (код ниже). Работаю через DEBUG, скорость 115200, настройки порта стандартные. Все посылки "туда" режутся по 4 символа (лог ниже). Т.е. если послать строку 5 байт, 4 из них будут возвращены по прерыванию, а пятый символ "застрянет" в буфере до следующей посылки. Первая плата такого глюка не имела, а вторая макетка стала вести себя так сразу после запуска. void fl_entry() { bool keepGoing = TRUE; FlEventBuffer flEventBuffer; ebdat7_00EnterDebugMode(); ebdat9_04SetUartdataToFL(TRUE); ebdat9_03SetModemdataToFL(TRUE); ebdat7_01DebugTrace( "test2\r\n"); while (keepGoing == TRUE) { memset((u8*)&flEventBuffer,0x00,sizeof(flEventBuffer)); eat1_02GetEvent(&flEventBuffer); switch(flEventBuffer.eventTyp) { case EVENT_MODEMDATA: { flEventBuffer.eventData.modemdata_evt.data[flEventBuffer.eventData.modemdata_evt.length] = 0; ebdat7_01DebugTrace( "M:[%s]", flEventBuffer.eventData.modemdata_evt.data ); break; } case EVENT_UARTDATA: { flEventBuffer.eventData.uartdata_evt.data[flEventBuffer.eventData.uartdata_evt.length] = 0; if ( DATA_SERIAL == flEventBuffer.eventData.uartdata_evt.type ) { ebdat7_01DebugTrace( "U:[%s]", flEventBuffer.eventData.uartdata_evt.data ); } else { ebdat7_01DebugTrace( "D:[%s]", flEventBuffer.eventData.uartdata_evt.data ); ebdat9_01SendToModem(flEventBuffer.eventData.uartdata_evt.data, flEventBuffer.eventData.uartdata_evt.length); } break; } case EVENT_INTR: { ebdat7_01DebugTrace("EVENT_INTR:\r\n"); break; } ... Включаю, подаю в порт DEBUG несколько раз строку "AT+CRWP=1\r\n" Имею, такой лог: IIIIÿÿÿÿtest2 M:[ +CFUN: 1 +CPIN: READY ]EVENT_SERAILSTATUS: M:[ Call Ready ]EVENT_SERAILSTATUS: D:[AT+C]M:[AT+C]D:[RWP=]M:[RWP=]D:[1 A]M:[AT+CRWP=1 A]M:[1 A]D:[T+CR]M:[T+CR]D:[WP=1]M:[WP=1]D:[ AT]M:[ AT]D:[+CRW]M:[+CRW]D:[P=1 ]M:[AT+CRWP=1 ]M:[P=1 ]D:[AT+]M:[AT+]D:[CRWP]M:[CRWP]D:[=1 ]M:[AT+CRWP=1 ]M:[=1 ]D:[AT+C]M:[AT+C]D:[RWP=]M:[RWP=]D:[1 A]M:[AT+CRWP=1 A]M:[1 A]D:[T+CR]M:[T+CR]D:[WP=1]M:[WP=1] В каком случае порт ввода\вывода может ограничивать длину ввода?

Либо по почте ap<сбк>li.ru, либо по фтп. Там правда 32мега, почтовый ящик наверно не выдержит. У меня предыдущее ядро.

Поделитесь пож-та прошивкой 1137B03V01SIM900M64_ST_EAT. Поставщик "завис" - менять его будем однозначно. Работа стоит. Буду очень благодарен.

Нужда прижала обновить прошивку. для SIM900 EAT, указанная в этой теме прошивка - последняя? (1137B01V03SIM900M64_ST_EAT_FOR_TEST_20110307) А то вроде бы она для тестирования. Или были изменения? Если были изменения, можно их как-то получить?

а разве при прошивке скорость не изменяется? работаю на 9600, а прошиваю на 115200, проблем не встречал (SIM900 EAT) или это специфика SIM900B?

У меня EAT, второй версии... тоже самое. Поставлю третью версию, может полегчает

полезная информация, спасибо! еще бы в причинах разобраться ) некомфортно, когда только методом тыка подобрано

Мне не понятно другое, 1) у меня задержек никаких нет вообще. работаю по получению ответа или таймауту. Т.е. предполагаю, что когда команда присылает ответ (OK или ERROR + что-то еще по мануалу) можно двигаться дальше. Это не всегда так? Не для всех команд? 2) в мануале написано, что CIPCSGP+CIPSTART можно подавать, когда статус возвращает IP INITIAL. Именно так и делаю... и все-же иногда возвращается PDP:DEAC... вот это тоже странно... только что статус вернул IP INITIAL, а при старте уже неактивный контекст? А задержки, они вообще для чего? если у нас диалог...

Да, почитал свое сообщение, изложил неточно. т.е. ситуация как и у вас.. в конечном счете. CIPSHUT тоже типа срабатывает всегда, имелось ввиду - возвращает SHUT OK, но при этом статус в IP INITIAL не устанавливается. И вот тогда при попытке повторного CIPSTART тоже возвращает STATE: PDP DEACT....CONNECT FAIL. ну и далее.. через некоторое время, сервер закрывает сессию, у меня модем присылает CLOSED и жизнь налаживается... как-то так. ...с интересом жду результатов тестирования "длинного варианта"

Нет, имеется ввиду закрытие сессии по инициативе сервера (того, с которым установлено TCP соединение). У меня сессия после отправки пакета не закрывается, т.е. один раз CIPSTART и много CIPSTATUS+CIPSEND, а когда CIPSTATUS возвращает не CONNECT OK, тогда пытаюсь сделать CIPCLOSE, CIPSHUT (которые не помогают в некоторых случаях). Но у меня по таймауту, если небыло сообщений, сервер закрывает подключение.. и соответственно, тогда CIPSHUT с повторным подключением к серверу нормально срабатывают. Это конечно не вариант нормальной работы, но как пища для размышлений )