Пишу програмку регистрации данных напряжения с 5-канального АЦП. Данные приходят, но имеют вот такой вид:"ёИЙф™ёиШИИёШЙи9(". Как мне преобразовать их для построения соответствующих графиков?

А не надо ничего "преобразовывать".
Просто не смотри на поступающие данные как на коды печатных символов)

Тоесть каждому символу соответствует 1байт шестнадцатиричного кода? А как по ним графики построить?

К производителю уже обращался?

Очеь правильный совет дал Сергей М. - бы вообще зачем на данные как на буковки смотришь? Каждой буковке соответствует циферка. Вот на нее и смотри.
Другое дело - что это циферка означает? Тут уже документацию на АЦП смотреть надо.

> Anatoly Podgoretsky ©   (31.03.11 13:58) [3]
>
> К производителю уже обращался?


Это ж не наш метод - мы ж кулибины)
Научный тык - вот что движет прогрессом)

Производитель не известен. мне дали железяку на PIC16F870, и велели написать программу приема и обработки данных от 5 датчиков. По описпнию контроллера на выходе АЦП последовательно выводится по 1 байту с каждого из 5 каналов. А чё прилетает на самом деле и как это обработать...

> последовательно выводится по 1 байту с каждого из 5 каналов.

Скорее уж по 2 байта.

Почему именно по 2?

> Почему именно по 2?

Дошло.
Так как разобрать принятые данные? В итоге должны получитьсяя числа с точностью до тысячных

> мне дали железяку на PIC16F870


обратиться к тому, кто дал. Или предлагаешь нам погадать ?

Нужен документированый протокол

> выводится по 1 байту с каждого из 5 каналов.
> Скорее уж по 2 байта.
ммм...
> ёИЙф™ёиШИИёШЙи9(
что-то мне кажется, что все-таки один...
ё уж больно часто встречается...через каждые 5 байт, может и совпадение конечно...

> что-то мне кажется, что все-таки один...
> ё уж больно часто встречается...через каждые 5 байт, может
> и совпадение конечно...

Может и не совпадение. Тогда значит железяку делал либо троешник, либо извращенец. Тогда просто трудно придумать что в этих трех комбинациях из пяти байт передаётся.

ИШ абсолютно прав. Нужно
> обратиться к тому, кто дал.

Или послать того, кто дал. :)

> по 1 байту
...
> с точностью до тысячных

- значит значение надо аккумулировать, а если аккумулировать - то надо знать где начало и конец посылки...

Выборку побольше собери, и в Hex-представлении бинарного потока(BinToHex), чтобы не гадать сколько раз кодировка кракозяб изменилась при копировании...

И надеюсь там нигде не было преобразования строк UCS<=>ANSI...

А как мне отобразить этот поток в десятичном виде?

> Палыч ©   (03.04.11 13:05) [15]
>
> А как мне отобразить этот поток в десятичном виде?
>

В десятичном не наглядно. Лучше в шестнадцатиричном c помощью IntToHex.

> Германн  (03.04.2011 14:36:16)  [16]

Лучше в двоичном, особо наглядно

> Лучше в двоичном, особо наглядно
>

Не соглашусь.

> Германн  (03.04.2011 16:26:18)  [18]

Ну как же, во столько раз шире

> Ну как же, во столько раз шире
>

Это шутка? Или что?

> А как мне отобразить этот поток в десятичном виде?

- что узнать как демультиплексировать данные бинарного потока, надо для начала увидеть дамп этого потока...
Твой вопрос относится к области - "сделайте мне хорошо"...
А пока могу посоветовать только Random...

> - что узнать как демультиплексировать данные бинарного потока,
>  надо для начала увидеть дамп этого потока...


Описание протокола от производителя намного предпочительнее. Вдруг там нормальный поток байт, а не интеловский? И CRC в нормальных протоколах бывает.

> Вдруг там нормальный поток байт, а не интеловский?

Это как это?
Старший байт первый? Это нормальный поток?

> Старший байт первый? Это нормальный поток?

- это как раз нормальный network order поток - дампы гораздо проще читать...
Не путайте с тупоконечным...