Electronic – how to convert bytes into ASCII in C language

Here's part of a minimalistic printf implementation I've been using. It was originally written by Georges Menie of www.menie.org, according to the GPL notice at the top of the file. I have been modifying the implementation as a whole, and haven't really been keeping track of the changes, though, so you probably should use the original which seems to be available at http://www.menie.org/georges/embedded/#printf

The function listed below converts an int to its ascii string. You can try to follow the code and strip out the parts which you don't need. There are calls to prints in the function, which deals with padding and handling the width of the string. It also does the actual sending of chars via putchar. I haven't included that function here to reduce clutter. You should implement your own function to to do that here, which basically would send out each of the chars via your serial/rs232/uart peripheral until you encounter \0.

static int printi(char **out, int i, int b, int sg, int width, int pad, int letbase)
{
    char print_buf[PRINT_BUF_LEN];
    register char *s;
    register int t, neg = 0, pc = 0;
    register unsigned int u = i;

    if (i == 0) {
        print_buf[0] = '0';
        print_buf[1] = '\0';
        return prints (out, print_buf, width, pad);
    }

    if (sg && b == 10 && i < 0) {
        neg = 1;
        u = -i;
    }

    s = print_buf + PRINT_BUF_LEN-1;
    *s = '\0';

    while (u) {
        t = u % b;
        if( t >= 10 )
            t += letbase - '0' - 10;
        *--s = t + '0';
        u /= b;
    }

    if (neg) {
        if( width && (pad & PAD_ZERO) ) {
            printchar (out, '-');
            ++pc;
            --width;
        }
        else {
            *--s = '-';
        }
    return pc + prints (out, s, width, pad);
}

Buffer = sector RAM buffer. UART buffer = UART internal buffer.

"Just a matter of programming" :-)

I've not looked at the fine detail of your method or specific device resources - the following general solution applies as long as the available RAM is not crucially limited:

Arrival rate is about 1,000,000/ 115,200 uS/bit = 8.68 uS/bit or 87 uS/byte

SD card write rate is 1800 uS/512 bytes ~= 3.5 uS/byte.

So long term if there are no other major overheads you have a write rate far faster than the arrival rate. The only problem is trying to walk and chew gum while storing the buffer.

If you can write SD and read UART easily at the same time you can use an exact size buffer. As long as you get the first byte out of the buffer within 87 uS of it being written the UART will never know you are there.

If the code is very time critical elsewhere you may be able to turn off interupts and poll a "talk to me" flag when you have time. As long as you can do this and respond before the UART buffer is full each time you can win

A death defying high wire method is to work out when the buffer is just full enough that if you start transferring THEN, the UART will deliver the final buffer byte as the SD card requires it. Good luck achieving that. It does have the advantage of not requiring any extra buffer resources IF you can manage it 'just right'.

A far easier method (assuming a wrap around buffer) is to increase the buffer size by enough bytes plus a little more such that when the buffer has enough data in it for an SD write you start writing SD data while the UART writes the "extra" buffer space. When the bufffer writer hits the buffer top it just restarts at buffer bottom, blissfully unaware that you are snaffling 512 byte blocks when they are ready. This requires you to repoint the buffer reader top and bottom pointers and to manage the "buffer full" pointer or counter etc - but is otherwise "trivially easy" [tm].

Easier again is to use two buffers and flip the writer to the other one when the current onbe is full. This doubles the buffer RAM needed which may or may not be a problem.