SIM800 + stm030 как правильно принимать по USART?

[NewWriter]

Разумеется есть. Я просто объясняю, как это работает

Конкретно, с использованием стандартной библиотеки, поиск некоторой строки, находящейся в буфере в произвольном месте - это функция strstr.
Но есть проблема - такой поиск находит в буфере не точное соответствие строки, а любое полное совпадение искомых символов в заданном порядке. В принципе, ничего страшного конкретно в данном случае.

ответ должно прийти OK[]= "\x0D\x0A\x4F\x4B\x0D\x0A";//

А теперь если перевести эту строку в понятное ANSI-представление, то получится
\r\nOK\r\n

то есть, отдельная терминальная строка, с переносом

OK

вот так.

[miwutka]

во, смотрю примеры несколько чужих а непонял что это за функция. Буду читать и юзать. Спасибо!

[miwutka]

да уж... прием данных и их расшифровка намного сложнее чем отправка ))
на команду ATE0 приходит то ОК то Call Ready SMS Ready..... Надо очень глубоко продумывать алгоритм.....
Думал может нужно после каждой команды делать задержку в 1 секунду например, потом функцией strlen смотреть сколько данных пришло. И потом уже их разбирать в зависимости от количества полученных данных в посылке...? Как думаете как это правильнее сделать? Или просто использовать счетчик необработанных данных Receive_C ......? И после обработки данных обнулять адрес буффера чтобы новые данные писались в начало буффера... Но так наверно можно затереть какието данные которые могут прийти не по плану, например входящий звонок...

void USART1_IRQHandler(void)
{
  if((USART1-›ISR & USART_ISR_RXNE)!=0)
  {

        Receive_buf[Receive_W] = USART1-›RDR;

        Receive_W++;
        Receive_C++;

     USART1-›CR1  |= USART_ISR_RXNE;
  }
}

int main(void)
{
   send_str("ATE0\r");
   Delay_ms(20000); 

   temp = strncmp(OK, Receive_buf+5,6); //на этом этапе в буффере то 13 то 26 значений то 28.
   while (temp != 0)
   {}

  send_str("AT+DDET=1\r");
  Delay_ms(20000);

 while(1){}
} 

[eddy]

eddy, я так понял что вот это мне надо?

Зависит от того, какая поставлена задача. Но явно понадобится модифицированная функция strchr для перехода к следующему полю. Чтобы лишних данных не вылезало, сразу же все ненужное надо прикрыть — у меня в коде это было.
[P.S. что-то я решил, что GPS нужен, с GSM работа несколько отличается]

это все в string.h есть

Прежде всего, нужно проверить, во что все это выльется. Возможно, компилятор ничего лишнего не запихнет — тогда можно радоваться, а возможно, добавит еще лишний килобайт к размеру кода — тогда нужно свою реализацию писать.
Ну, про printf и жирафу понятно, что библиотечный ни в коем случае нельзя использовать. А вот memcpy — вполне даже, т.к. он должен быть более оптимизирован чем тупое побайтное копирование.

поиск некоторой строки, находящейся в буфере в произвольном месте - это функция strstr.

Не представляю, чем strstr может помочь при работе с GSM. А вот strcmp там наверняка пригодится.

[eddy]

Да, забыл сказать: прежде, чем научиться работать с GPS/GSM на МК, я набросал нужный код на компе — все равно ведь "подноготная" будет одной и той же. Как отладил, так и стал переделывать под МК, выбрасывая все жирное.
А можно и на компе сразу все жирное повыбрасывать, и готовый код сразу на МК гонять.

[Someone]

Я думаю так:

Миш, так думают и пишут код правоверные индусы . Нормальные люди принимают всю строку в буфер, а потом используют стандартные функции из библиотеки "string.h", которая есть в любом компиляторе С/С++, так что Кэрригана с Ричи (не смотря на их древность, по прежнему актуальная книжка) в помощь - там ты можешь прочитать все подробности. Страшное слово "парсинг" можно заменить словами "разбор", "анализ" и прочие менее страшными.

[miwutka]

Ну, про printf и жирафу понятно, что библиотечный ни в коем случае нельзя использовать. А вот memcpy — вполне даже, т.к. он должен быть более оптимизирован чем тупое побайтное копирование.

Пытался понять как работает memcpy но чет так и не могу понять. Поэтому незнаю как его применить в моем случае.....

У меня буффер на 255 элементов. Все данные пишутся в него и это всё надо разбирать. Я вот думаю, когда приходят ответы писать их в разные буферы. Так наверно будет легче находить нужный текст... Или всё же както проще из одного буффера всё извлекать?

Я не доконца понимаю как происходит прием данных по USART. флаг RXNE устанавливается после приема каждого символа?

ну да после каждого... у меня ж счетчик ))

[Someone]

смотреть сколько данных пришло. И потом уже их разбирать в зависимости от количества полученных данных в посылке...?

Зачем? Когда ты ищешь подстроку в строке - библиотечная функция делает всё сама. Длина строки тебе совершенно не нужна.

[Someone]

Возможно, компилятор ничего лишнего не запихнет — тогда можно радоваться, а возможно, добавит еще лишний килобайт к размеру кода

тогда нужно свою реализацию писать.

Которая добавит к коду пару килобайт.

А вот memcpy — вполне даже, т.к. он должен быть более оптимизирован чем тупое побайтное копирование.

Шедевр. 5 Баллов.

Пытался понять как работает memcpy но чет так и не могу понять.

Работает просто - ведь это "тупое побайтовое копирование". Указывается в параметрах процедуры два адреса и число байт. Из одного данные копируются, в другой пишутся. Естественно, адреса указываются стандартным для С способом - операцией "взять адрес" после которого идёт имя переменной, в которой расположены данные. Смотри раздел "работа с указателями" в тех же Керригане с Ричи.

[mike-y-k]

Кстати при приёме в буфер для обработки стоит отбрасывать CR и LF, считая их признаком конца строки. Дополнительно выкидывать пустые строки.
Тогда будет идти обработка только значащих данных в строке.
Для приёма таки удобнее использовать два буфера для строк, тогда дольше не будет проблем с обработкой и логика прозрачнее.

Someone, Копирование может быть и не побайтным с анализом длины на четность. Работать будет несколько быстрее. Такие фокусы знакомы ещё с времён зари x86 - приходилось оптимизировать функции для обработки больших массивов, и каждый лишний такт там был целью.

А как реализованы функции в библиотеке - можно будет посмотреть или в отладчике или по дампу.