I'm using an Arduino Yun to read from a data file, which will then populate a data structure. The file.read() function "returns: The next byte (or character), or -1 if none is available."

This functionality is identical to the SD.read() function in the SD card library.

The data file will never have any value that exceeds 1 byte with all numbers in the range 0-255. If I print these numbers as a long string in the data file, each character is read as a byte. So I need to call file.read() 3 times to read in a single 0-255 value. And then do some additional processing to construct the final 8-bit value for storing.

I could reduce this to 2 calls by printing the Hex code in the data file, but this isn't much of an improvement.

Is there a way to encode a full byte in a single character?

Effectively , is there a particular way I can format my data file so that I can read in an 8-bit unsigned value in a single call to file.read()?

  • "Is there a way to encode a full byte in a single character?" I have no idea what you're asking here. Characters (in single-byte encodings) normally fit a byte regardless. Commented Sep 18, 2015 at 18:16
  • You need to save the values into a binary file, instead of converting the values to a human readable string, and saving that string.
    – Gerben
    Commented Sep 18, 2015 at 18:37

2 Answers 2


There's two parts to what you want to do, writing the file in the right form, and reading that format file.

The format of file is known as raw binary. Every byte in the file can store a separate value between 0 and 255, or between -128 and 127, dependin on how you interpret the data. At the end of the day, every byte in a file is just a collection of 8 bits yielding 2^8 = 256 combinations. What those combinations actually mean is more of a human thing than a machine thing.

We, as humans, have decided upon three main representations of those bytes: unsigned numbers from 0 to 255, signed numbers from -128 to 127 (lookup two's complement) and finally ASCII characters.

ASCII characters are more of a lookup table placed over one of the other two representations. Some systems use unsigned bytes and some signed bytes for the basis of that lookup tabe.

Writing text into the file results in looking up the corresponding byte values for each character in that text and placing those values in the file. When you read the file the reverse is done - the byte values are read and you look them up in the ASCII table to find the corresponding letters.

To store just numbers between 0 and 255 it is far more efficient to bypass that ASCII table and store the values directly as bytes. How you do that is entirely dependent on what language you are writing your software in. Since you haven't mentioned what that language is I can't advise you on that front' only give some examples in languages I know.

Such as in C you would store your data in an array of unsigned char or uint8_t. You then use the write() function to write raw data to the file.

In Perl you might use the pack() function to store your values as bytes in a string then write that string to a file.

When reading the data you are presented with a raw value. That may be given to you as a signed or an unsigned value depending on the underlying system. I don't know what the yun is off hand. Converting from whatever is handed to you by thr file.read() function to what you expect it to be though is a very simple matter, and is called casting.

int in = file.read();
uint8_t bval = (uint8_t)in;

The bit in brackets is the cast which converts the value in the integer in into a uint8_t (Unsigned INTeger 8-bit Type) which corresponds to whatever you wrote as an unsigned char or uint8_t at the other end.


This is a fragment (untested) of how you can do it:

char datafile[512];
int ch;
int index = 0;

while ((ch = file.read()) != -1) {
  datafile[i] = (char)ch;
  if (++i == 512)
  • I was having trouble with char as the standard ASCII encoding does not handle numbers greater than 127, resulting in errors when printing.
    – Rohan
    Commented Sep 19, 2015 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.