Чтение длинного текста из GPRS Shield с помощью Arduino

У меня ад с этим, и я знаю, что это, вероятно, очень просто. Я пытаюсь прочитать текстовое сообщение с экрана Seeed GPRS. У меня щит настроен как серийный номер программного обеспечения, и я отображаю информацию, полученную от GPRS, на серийный монитор. В настоящее время я отправляю все AT-команды по последовательному порту, пока работаю над своим кодом. Чтобы отобразить данные из серийного номера программного обеспечения на серийный монитор, я использую следующий код.

while(GPRS.available()!=0) { 
Serial.write(GPRS.read()); 
}

Очевидно, что GPRS — это мой серийный номер программного обеспечения. Проблема в том, что текст длинный, и я получаю от него только несколько символов. Что-то вроде этого.

+CMGR: "REC READ","1511","","13/12/09,14:34:54-24" Добро пожаловать в TM eos8

Этот текст представляет собой текст «Добро пожаловать в T-Mobile», который намного длиннее. Последние несколько отображаемых символов зашифрованы. Я провел некоторое исследование и увидел, что могу изменить размер последовательного буфера на 256 вместо 64 по умолчанию. Я хочу избежать этого, потому что уверен, что есть более простой способ. Есть идеи?


person Jaret Burkett    schedule 10.12.2013    source источник


Ответы (3)


Вы пробовали читать массив символов по одному байту за раз? Посмотрите, поможет ли это:

if (GPRS.available()) { // GPRS talking ..
    while(GPRS.available()) { // As long as it is talking ..
    buffer[count++]=GPRS.read();     
    // read char into array
    if(count == 64) break; // Enough said!
}
Serial.write(buffer,count); // Display in Terminal
clearBufferArray();
count = 0;
}

Вам необходимо правильно объявить переменные 'buffer' и 'count' и определить функцию 'clearBufferArray()'.

Позвольте мне знать, если это помогает.

person Sun Bee    schedule 18.01.2014

Похоже, это просто результат отсутствия управления потоком во всех последовательных соединениях Arduino. Если вы не можете ускорить свою последовательность входных байтов GPRS() до скорости, которая гарантирует, что входной FIFO не может переполниться, тогда ваш Serial.write() заблокируется, когда заполнится выходной FIFO. В этот момент вы будете отбрасывать новые входные байты GPRS до тех пор, пока последовательный вывод не освободит больше места.

Поскольку захваченный вывод явно очищен примерно до 64 байт, это предполагает
а) 64-байтный буфер,
б) скорость передачи данных GPRS намного выше, чем последовательная, и
в) что мусор данные на самом деле являются случайным допустимым байтом из более поздней части последовательности.

Вы можете убедиться в этом, протестировав код возврата из Serial.write. Если вы вернете ноль, этот байт будет потерян.

Если бы вы использовали 9600 для Serial и 57600 для GPRS, я бы ожидал, что пройдет несколько более 64 байтов, прежде чем вывод будет искажен, но если скорость GPRS более чем в 64 раза превышает скорость Serial, весь выходной FIFO может заполниться в течение время передачи одного выходного байта.

Захват в промежуточный буфер должен решить вашу проблему, если он достаточно велик для всего сообщения. Точно так же должно работать увеличение размера исходного (в сочетании с тестированием Serial.write) или целевого (без дополнительного кода) FIFO до максимального размера дейтаграммы.

person user3485419    schedule 12.05.2014

У меня была такая же проблема, когда я пытался читать сообщения и получать 64 символа. Я преодолел это, добавив «задержку (10)» в цикл, вызывающий функцию, которая выполняет чтение из GPRS. Кажется, достаточно, чтобы преодолеть сценарий гонки. - Использование Ардуино Мега.

    void loop() {
      ReadmyGPRS();
      delay(10);  //A race condition exists to get the data.  
    }

    void ReadmyGPRS(){
      if (Serial1.available()){ // if data is comming from GPRS serial port
        count = 0;  // reset counter
        while(Serial1.available())          // reading data into char array 
      {
      buffer[count++]=Serial1.read();     // writing data into array
      if(count == 160)break;
     }
     Serial.write(buffer,count);
    }

}

person Ken    schedule 03.10.2019