topic Re: sizeof problem in LPCXpresso IDE

sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:40 GMT

Content originally posted in LPCWare by dragilla on Sat Jan 28 14:41:17 MST 2012
Hey,
I'm having a bad day I think... nothing seems to work

Not it's time for basic functions: sizeof seems to well ignore me.
I have the following code

#define UART_RING_BUFSIZE256
uint8_t buffer[UART_RING_BUFSIZE];
uint8_t z = (uint8_t)sizeof(buffer);

Why would z equal to zero (0) ?
When I a simple test aside, on my linux box:

#include <stdio.h>
#include <stdlib.h>
#define SIZE 10
int main()
{
        int a[SIZE];
        printf("size of a=%i\n", (int)sizeof(a));
        return 0;
}

it prints "size of a=40".

ps: sizeof(uint8_t); gives me 1, so my guess would be to get 256*1 from sizeof(buffer)... wtf?

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:41 GMT

Content originally posted in LPCWare by dragilla on Sat Jan 28 14:51:18 MST 2012
Wow, this is getting better and better:
I put this instead of using sizeof, because I know the size, right?

uint8_t buflen = (uint8_t)UART_RING_BUFSIZE;

Again the compiler just didn't care and I got buflen equal to zero!

Oh shit I just got to the definition of uint8_t - it's
typedef unsigned char uint8_t;

Why is it called int if it's a char?

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:41 GMT

Content originally posted in LPCWare by ex-kayoda on Sat Jan 28 14:56:15 MST 2012
Are you kidding?

What do you think is (uint8_t)256 = (uint8_t)0x100 ?

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:42 GMT

Content originally posted in LPCWare by dragilla on Sat Jan 28 14:57:11 MST 2012


#include <stdio.h>
#include <stdlib.h>
#define SIZE 10
typedef unsigned char uint8_t;
int main()
{
        uint8_t a[SIZE];
        printf("size of a=%i\n", (uint8_t)sizeof(a));
        return 0;
}

This still gives me "size of a=10" (on my linux box), so why doesn't this work on lpc1769?

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:42 GMT

Content originally posted in LPCWare by dragilla on Sat Jan 28 14:58:38 MST 2012

Quote: kayoda
Are you kidding?
What do you think is (uint8_t)256 = (uint8_t)0x100 ?

I don't understand... what is it?

Oh my god, you're right - I'm totally .... well not my day... it's 255 (max value for 8bit number) + 1, which is zero...
damn it. Sorry...

edit: no, I'm still stupid. Changing it to uint32_t (which is unsigned int) doesn't help at all, I still get 0 for sizeof(buffer).

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:43 GMT

Content originally posted in LPCWare by dragilla on Sat Jan 28 15:16:23 MST 2012
Ok. I will describe exactly what I'm doing because I going crazy here

in 1 place I call this this function:

bytes = UARTReceive((LPC_UART_TypeDef*)LPC_UART0, buffer, (uint32_t)sizeof(buffer));

The function is defined as:

uint32_t UARTReceive(LPC_UART_TypeDef *UARTPort, uint8_t *rxbuf, uint32_t buflen);

When I put a breakpoint in the first line of this function and read the value of buflen - it's zero (0).
Even if I pass 256 and not sizeof - it's still zero!

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:44 GMT

Content originally posted in LPCWare by ex-kayoda on Sat Jan 28 16:06:36 MST 2012

Quote: dragilla
Why is it called int if it's a char? :(

Google is your friend:

http://en.wikipedia.org/wiki/C_data_types

Fixed width integer types:
The[B][COLOR=Red] C99 standard[/COLOR][/B] includes definitions of several new integer types to enhance the portability of programs[2]...

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:44 GMT

Content originally posted in LPCWare by atomicdog on Sat Jan 28 19:37:34 MST 2012

Quote:
When I put a breakpoint in the first line of this function and read the value of buflen - it's zero (0).
Even if I pass 256 and not sizeof - it's still zero!

Have you stepped through the code in the function? What does the code look like in the function? what optimization setting are you using?

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:45 GMT

Content originally posted in LPCWare by Rob65 on Sat Jan 28 23:57:06 MST 2012
Hm,

I think we start to need a moderator in this forum...

Why start swearing ???
Things like shit, wft or o my god do not belong in this forum so I kindly ask you to refrain from using these things in the future.

I use sizeof a lot and it always works for me - even om my lpc1769.
And what did you think ???

Quote:

........ I just got to the definition of uint8_t - it's
typedef unsigned char uint8_t;

Why is it called int if it's a char? :(

What else is a data type than a representation of some bytes or words in memory :eek:

I use uit8_t .. uint64_t on different platform. The nice thing is that I now have one datatype specifying the exact amount of bits. While on the ARM an unsigned int may be 32 bits, on some other processors I used, an (unsigned) int was 64 bits and on yet another one 16 bits.

Rob

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:45 GMT

Content originally posted in LPCWare by dragilla on Sun Jan 29 01:16:50 MST 2012
Rob, you're of course right, sorry for that.

Quote: atomicdog

Have you stepped through the code in the function? What does the code look like in the function? what optimization setting are you using?

I use no optimization (0).
The receive function is declared as follows:

uint32_t UARTReceive(LPC_UART_TypeDef *UARTPort, uint8_t *rxbuf, uint32_t buflen)
{
    uint8_t* data = (uint8_t *) rxbuf; <--- BREAKPOINT HERE SHOWS 0 FOR buflen !
    uint8_t temp_tail;
    uint8_t prev = 99;
    uint32_t bytes = 0;

/* Temporarily lock out UART receive interrupts during this
   read so the UART receive interrupt won't cause problems
   with the index values */
UART_IntConfig(UARTPort, UART_INTCFG_RBR, DISABLE);

// check for cr lf (\r\n) in the rb buffer. if found -> copy all from
// the beginning to the \r\n and move everything after to the beginning.
temp_tail = rb.rx_tail;
while(!(__BUF_IS_EMPTY(rb.rx_head, temp_tail)) && bytes < UART_RING_BUFSIZE) {

*data = rb.rx[temp_tail];
data ++;
bytes ++;

if(prev == '\r' && rb.rx[temp_tail] == '\n') { // gotcha

// set rb.rx_tail
__BUF_INCR(temp_tail);
rb.rx_tail = temp_tail;

*data = '\0';

// enable interrupt
UART_IntConfig(UARTPort, UART_INTCFG_RBR, ENABLE);

// return bytes to say we have a full line
return bytes;
}
prev = rb.rx[temp_tail];
__BUF_INCR(temp_tail);
}

/* Re-enable UART interrupts */
UART_IntConfig(UARTPort, UART_INTCFG_RBR, ENABLE);

// if we are here it means a whole line was not found -> return 0
    return 0;
}

I call the function like this:

bytes = UARTReceive((LPC_UART_TypeDef*)LPC_UART0, buffer, (uint32_t)256);

ps: the sizeof works. My problem was trying to fit 256 into an 8-bit variable.

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:46 GMT

Content originally posted in LPCWare by dragilla on Sun Jan 29 01:34:39 MST 2012
Ok. I've found the reason for bad readouts. The function had two definitions. One in the file where it was called and the second in the file where it was declared. I only changed it in one place (the place of declaration), so it was still called with uint8_t.

Re: sizeof problem

lpcware — Thu, 16 Jun 2016 02:52:46 GMT

Content originally posted in LPCWare by Rob65 on Sun Jan 29 05:55:37 MST 2012

Quote: dragilla
Rob, you're of course right, sorry for that.

Seems like we both had a bad week.

I tend to skip to this forum whenever I'm stuck in some kind of problem and need a break - I am trying to create a PC program that interfaces with my LPC solution and had a lot of problems getting the GUI to work in Qt - almost bit my tongue of twice this weekend :eek: - I'm just not experienced enough in C++ yet

Quote:
ps: the sizeof works. My problem was trying to fit 256 into an 8-bit variable.

Use a bigger hammer :D

Quote:

The function had two definitions. One in the file where it was called and the second in the file where it was declared.

Been there, done that ...
I never ever (well ...) do this anymore. I make only one declaration in a header file that gets included everywhere. The compile will then perform the type casting and warn me if I'm doing anything funny.
My goal is to have no warnings at all in my code. I have learned that a lot of the warnings are actually errors - or exceptions that should be solved using some type casting.

At work we have even set the compiler to handle all warnings as errors (i.e. no executable gets generated).

Rob