Whit tou use uint8_t buffer to receive uart data?

[Gardin]

So, this is problably a dummy C question but I'm gonna ask here anyway.

In the function

Code: Select all

int uart_read_bytes(uart_port_t uart_num, uint8_t* buf, uint32_t length, TickType_t ticks_to_wait)

Why not to use a char* buffer to hold incoming data?

Thanks in advance!

--
Gabriel Gardin

[mad_planter]

One reason why I would use uint8 instead of char is on many platforms char isn't necessarily the same size as uint8.

[PeterR]

https://stackoverflow.com/questions/406 ... r/40679845

I guess the answer is one of symantics, that the data format is unknown, a char * suggests a string etc.
A char is the same size as unit8_t (according to above). Both uses seem somewhat flawed IMHO but in the main I would think string when meeting a char *.
I would just get on with typing & leave this for the compiler standards ppl
To quote the bard; A uint8_t is a char by any other cast.

EDIT: In other languages a char may not be 8 bits e.g. C# but in C it will be 8 bits as referenced above.

[Gardin]

Thanks PeterR that make sense!!

[Scott.Bonomi]

The other issue is that often people forget that they have to have allocated the space for a received buffer, not just a pointer to it. If you say char * MyPtr = malloc(128); that sort of limits you to the number of characters you can receive and is a perfectly valid way to get there. Right up to character 129.

The suggestion of using address of uint8_t[] instead makes the size issue a bit more visible.
The other half of the question of signed or unsigned is how you want to handle control characters. Everything after 127 falls into the bucket we used to call unprintable. As a signed value it is less than zero, but if copied to a longer value will get sign extension and set lot of extra bits. Avoiding the sign extension issue if probably the best reason to use unsigned for character IO.

[PeterR]

Yea, I agree. <stdint.h> types are a lot clearer about sizes & should be used (in our work). I never understood why printable data was a char (int8_t) because you cannot print much of that! 'C' was a great invention though. Some of us (back in the day) were also on PLM and FORTRAN. All respect to C authors. By those standards C rocked and does through its children.
The concept of what a 'char' is has changed through the various developments; C, Java, C# etc.
Not going to do a taxonomy n heritage discussion but think you know what I mean.
So ppl took existing terms and redefined. Bit naughty IMHO. Sort of a programming language imperialism, an attack on the (C) definition of a char? Or just got bored n time to hit the bar? Think latter.
I think we might have hijacked this post.
There should be a forum for 'old programmers'
Perhaps ESP could arrange a fire side, maybe even some hand pumped beer?