Здравствуйте!
Никак не могу правильно прочитать данные из COM-порта.

Мой процессор отправляет в компорт в бесконечном цикле (каждые 156 мкс) int-число и две эскейп последовательности в таком виде

int d = 123;
printf("%d"\r\n, d); //отправляю в порт

Теперь моя задача считать на компьютере эти данные в такую же переменную. Посредствам стандартных средств в СBuilder я заливаю всё что передаёться в COM-пот в массив чаров buf зармером 255.

Вопрос: как считывать последовательно эти данные из массива buf в переменную типа int?
Как я понимаю нужно как то логически в цикле разделять набор чисел в массиве buf, а затем преобразовывать в int. Но конструкцию никак не придумаю(((((
буду признателен за любую помощь.

printf("%d\r\n", d);

Используйте функцию стандартную atoi.

Что за аtoi ?

Функция printf посылает в порт микроконтроллера числа. Со стороны микроконтроллера всё впорядке. Мне же нужно со стороны хоста(бытовой компьютер) разобрать по сути непрерывный поток чаров в буфере buf и получить числа int, которые в этом потоке передаются, разделяемые esc-последовательностями (\n\r)



Блин, опять с чужого компа зажёл... сорри)

Сообщение отредактировал Zelepuk - Feb 21 2011, 13:16

Как организован доступ к вашему буферу?
Какому числовому значению равны ваши \n,\r?
Какая длина вашего int в байтах?
Почитайте вот это Кольцевой буфер

У вас какая скорость передачи в COM? Скорее всего не выше 115200 baud, т.е. 8,7 мкс на бит. Стандартная посылка 8+1 стоп. Итого 9 бит на байт. Вы посылаете int (вроде как 4 байта для TigerShark) + CRLF. Итого 6*9*8,7 = 469 мкс.

Вы шлете данные каждые каждые 156 мкс. И что вы хотите читать?

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

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main (int argc, char ** argv)
{
char buf[] = "32321\n\r32322\n\r32323\n\r", *pb = NULL;

// здесь полагаем, что buf мы прочитали из COM порта

pb = buf;

for(;;)
{
// проверяем есть ли начало escape последовательности
char *ptr = strstr(pb, "\n\r");
if (!ptr)
break;

// если да, то завершаем найденный указатель на \0
// чтобы функция atoi() смогла отработать
*ptr = '\0';
int a = atoi(pb);
// теперь в a бинарное представление строки
// выводим в консоль прочитанное число
if (a)
printf("I've just read %d!\n", a);

// смещаемся на начало новой строки
pb = ptr + 1;
}

return 0;
}

только это вариант для статического буфера buf, а у меня он меняется, так как данные идут непрерывно, но думаю теперь это не проблема, главное концепция ясна.

Функция printf имеет "зеркальную" функцию scanf (или родственные ей - fscanf, sscanf) - на персоналке используйте одну из них. Символы \n\r имеют шестнадцатиричные коды 0A и 0D - "перевод строки" и "возврат каретки".

А если прибавить стартовый бит, ситуация ещё более усугубляется

я посылаю строку в COM-порт. эта строка соответствует набору чмсел в int.
Короче данные идут(это видно в терминале).

Пардон!)) данные идут каждые 1 мс)

Поясню для чего я это делаю. Просто мой процессорный модуль, который шлёт данные, выступает в качестве некоего АЦП, который оцифровал синусоиу и шлёт данные (числа - это отсчёты синуса). Так вот, получается что скорость передачи данных накладывает ограничения на частоту дискретизации этого виртуального "синуса"

Сообщение отредактировал TigerSHARC - Feb 21 2011, 18:40

Запомните, atoi() НЕ является стандартной ANSI функцией. По этой причине ее нет в доброй половине библиотек.

Вы обладаете могучим талантом запудривания мозгов!

Для завершения советую прочитать где-нибудь на просторах inet'a, что называется (и почему) esc-последовательностью.

А если приглядеться внимательнее к передаваемому формату, то для 32-битового числа со знаком получается ±2147483648, итого 12 байтов. x10 = 120 битов. x8.7 = 1042us


atoi как раз является... только она здесь не нужна.

здесь я их использовал для того чтобы данные отображались в терминале красиво, столбиком. Толкьо и всего. Но никак для разделения чисел как таковых.
ничего я не запудриваю просто вы щите подвоха в постановке задачи. А тем временем она уже решена))
код выше я уже прикладывал.
ВОТ!



как не нужна? код выше работает!





Сообщение отредактировал TigerSHARC - Feb 21 2011, 19:21

Ну автор же дошел до светлой мысли (глядя в осцилограф), что COM оказывается сильно тормозит его ADC. Потом додумается и до того, что его "протокол" мягко говоря ...

Я думал, речь про передачу идет.
Т.е., сначала вы строку преобразовываете в целое, а потом выводите целое в виде строки?!
А просто строку вывести что-то мешает?