Проблема с размером байта Arduino Ethernet

Я использую Arduino (duemilanove) с официальным экраном Ethernet для отправки данных на контроллер для управления светодиодной матрицей. Я пытаюсь отправить некоторые необработанные 32-битные беззнаковые значения int (временные метки unix) на контроллер, взяв 4 байта в 32-битном значении на рабочем столе и отправив его в Arduino как 4 последовательных байта. Однако всякий раз, когда значение байта больше 127, клиентская библиотека Ethernet возвращает 63.

Ниже приведен базовый пример того, что я делаю на стороне Arduino. Кое-что убрано для наглядности.

byte buffer[32];
memset(buffer, 0, 32);

int data;
int i=0;

data = client.read();
while(data != -1 && i < 32)
{
  buffer[i++] = (byte)data;
  data = client.read();
}

Итак, всякий раз, когда входной байт больше 127, переменная data в конечном итоге будет иметь значение 63! Сначала я думал, что проблема находится дальше по строке (раньше буфер был char, а не byte), но когда я распечатываю «данные» сразу после чтения, все равно 63.

Есть идеи, что может быть причиной этого? Я знаю, что client.read () должен выводить int и внутренне считывать данные из сокета как uint8_t, который является полным байтом и без знака, поэтому я должен иметь возможность, по крайней мере, перейти к 255 ...

РЕДАКТИРОВАТЬ: Верно, Ганс. Не понимал, что Encoding.ASCII.GetBytes поддерживает только первые 7 бит, а не все 8.


person Adam Haile    schedule 07.01.2011    source источник
comment
Кодировка UTF-8 не дала бы 63 ... Имеет ли ввод 63 также дает 63 на выходе? Сдвигаются ли вообще последующие байты.   -  person Ben Voigt    schedule 07.01.2011


Ответы (3)


63 - это код ASCII для?. Это имеет какое-то отношение к значениям, ASCII не имеет кодов символов для значений более 127. Кодировщик ASCII обычно заменяет недопустимые коды, подобные этому, знаком вопроса. Например, поведение по умолчанию для кодировщика .NET Encoding.ASCII.

Не совсем понятно, где это может произойти. Определенно не в вашем фрагменте. Наверное, на другом конце провода. Пишите байты, а не символы.

person Hans Passant    schedule 07.01.2011

Я больше склонен подозревать передающую сторону. Вы уверены, что передающая сторона работает правильно? Вы проверяли с помощью захвата wirehark или чего-то подобного?

person Karl Bielefeldt    schedule 07.01.2011
comment
Но обратите внимание, что данные не могут быть байтами, поскольку тогда 255 vs EOF будут неоднозначными. - person Ben Voigt; 07.01.2011

+1 для Ганса Пассанта и Карла Билефельдта.

Можете ли вы просто отправить данные без кодирования? Как отправляются данные? TCP / UDP / IP / Ethernet определенно поддерживает отправку двоичных данных без ограничений. Если это невозможно, возможно, преобразование данных в шестнадцатеричный формат решит проблему. Base64 также будет работать (лучше), но это значительно больше работы. Для небольших объемов данных шестнадцатеричный код, вероятно, является самым простым и быстрым решением.

+1 еще раз Карлу и Бену за упоминание wirehark. Неоценим для устранения подобных сетевых проблем.

person Peter Schaeffer    schedule 06.11.2013