C-code; array of struct ? (Atmel Studio 6)

[c4757p]

You need to know whether you are using a C compiler or a C++ compiler. There are quite a few differences between C and C++ that can trip you up if you think you are using C++ but you actually have C.

Most of the big compilers like GCC will switch modes by file extension. Not sure about the dedicated MCU compilers, though.

[IanB]

Most of the big compilers like GCC will switch modes by file extension. Not sure about the dedicated MCU compilers, though.

Indeed. But in light of David's comment below, it seems highly likely his compiler is expecting C and not C++:

The only combination i can get to compile is:

Code: [Select]

struct Button
{
unsigned int top;
unsigned int left;
unsigned int height;
unsigned int width;
char *caption;
};

struct Button Buttons[4];

I needed to add the struct keyword to my draw procedure:

Code: [Select]

void Draw_Button(struct Button Btn);
But it does compile.  I'll be able to test it at work tomorrow.

[David_AVD]

Atmel Studio does seem to support both C and C++ files.  When you add a new file to the project (via wizard) it does give options for each.  I chose C each time.

As I mentioned earlier (perhaps in the other thread), I will stick with C for now as it will help me when I do more coding with PICs and XC8 or XC32.

[David_AVD]

When you get everything straightened out, you probably want:

Code: [Select]

void Draw_Button(const Button *Btn);
Otherwise, you're passing a copy of the entire struct.

Good call.  I don't have a handle on the syntax for calling the function and accessing the structure inside yet.

[IanB]

Atmel Studio does seem to support both C and C++ files.  When you add a new file to the project (via wizard) it does give options for each.  I chose C each time.

As I mentioned earlier (perhaps in the other thread), I will stick with C for now as it will help me when I do more coding with PICs and XC8 or XC32.

Right you are then. But in doing that, you may (will) find many "nice" features of C++ are absent, such as declaring variables in the middle of a block, using structs without the "struct" keyword, using the "const" keyword, passing variables by reference, and so on. Make sure your reference books and internet searches are specifically for "C" and not "C++".

[David_AVD]

OK, got that figured out now.   

Code: [Select]

Draw_Button(&Buttons[0]);
And inside the routine:

Code: [Select]

LCD_PRINT(Btn->caption,Btn->left+3,Btn->top+3,0);
Now I just need to work out why the assignments to caption are not working correctly.  The last assignment seems to be affecting all structures instances.

[IanB]

Now I just need to work out why the assignments to caption are not working correctly.  The last assignment seems to be affecting all structures instances.

Be careful with char *caption;

That's a pointer to a string of characters stored outside your structure.

However, if you write:

Code: [Select]

Buttons[0].caption = "First button";
That should only set the caption on Buttons[0] and should not affect any other buttons.

[David_AVD]

Now I just need to work out why the assignments to caption are not working correctly.  The last assignment seems to be affecting all structures instances.

Yeah, just saw what I did.  For whatever (brain fart) reason, I was using strcpy() instead of a simple = for the caption.  Thanks.

[westfw]

Our code style guide would have liked:

Code: [Select]

typedef struct button { ...
} button_t;


If you initialize it to a value then that value will be stored in flash and get loaded into ram as needed.

For avr-gcc it will get loaded into RAM during program startup if it's global (as is the case here), on the assumption that since it's in your program, it WILL be needed.

[ToBeFrank]

Atmel Studio does seem to support both C and C++ files.  When you add a new file to the project (via wizard) it does give options for each.  I chose C each time.

As I mentioned earlier (perhaps in the other thread), I will stick with C for now as it will help me when I do more coding with PICs and XC8 or XC32.

Right you are then. But in doing that, you may (will) find many "nice" features of C++ are absent, such as declaring variables in the middle of a block, using structs without the "struct" keyword, using the "const" keyword

None of these are absent in standard C. First one is in C99 (on most compilers it's --std=c99), the second is done with a typedef, and the third, C of course has the const keyword. Although on the last one I suspect you meant C doesn't do const functions.

[c4757p]

Our code style guide would have liked:

Code: [Select]

typedef struct button { ...
} button_t;


Yep, very common.

None of these are absent in standard C. First one is in C99 (on most compilers it's --std=c99), the second is done with a typedef, and the third, C of course has the const keyword. Although on the last one I suspect you meant C doesn't do const functions.

Yeah, C hasn't been that stagnant over the past few decades! It's been a really long time since I've had a C compiler yell at me for mid-block declarations. I'd argue that "using structs without the 'struct' keyword" is useless obfuscation, but still, just throw in a typedef! And what about the 'const' keyword? C++ has one additional use of it, but all that does is declare the class pointer that's passed in implicitly as const. Everything else originated in C.

[David_AVD]

While you guys have been talking about C vs C++ I've now got a screen full of (30) buttons, all nicely laid out.   

I created some constants and calculations for the H & V spacing between buttons, so I can change the whole grid with only a couple of keystrokes.   

[IanB]

None of these are absent in standard C. First one is in C99 (on most compilers it's --std=c99), the second is done with a typedef, and the third, C of course has the const keyword. Although on the last one I suspect you meant C doesn't do const functions.

Fair enough. I guess the last time I used C was before C99 become commonly supported by compilers, and I must have had a brain fart about the const keyword. It's been so long since I was last constrained to using C that my memory has got fuzzy.

[c4757p]

IMHO it's long enough not to call it "constrained" any more. With the right libraries and coding techniques it's quite a decent language.

[David_AVD]

One (seemingly simple) task I am having trouble with is testing a string (actually the caption in the struct mentioned earlier) to see if it contains a decimal point.

No amount of fluffing about with the strchr function seems to give me a suitable result.  What I basically want to do is:

Code: [Select]

If(CharacterInString(Btn->Caption),'.')
  DoThis;
else
  DoThat;

[ve7xen]

Code: [Select]

if (strchr(Btn->caption, '.'))
  do_something_when_the_string_contains_a_period()
else
  do_something_else()

Don't forget to include string.h. Should work fine assuming Btn is type 'Button *' and caption is type 'char *'. If it's not the problem is likely elsewhere and we'll need to see more of your code to help...

Remember that C is C, it's often helpful to run bits of your code that don't depend on hardware on a PC where you have access to easier debugging and less involved testing, especially when you run into problems. I usually try to separate my hardware interface functions from logic functions, then you can usually just write a simple test shim as main.c and copy the rest of the code directly from your embedded tree into a test tree that will compile on your PC.

[madires]

Code: [Select]

If(CharacterInString(Btn->Caption),'.')
  DoThis;
else
  DoThat;

The code needs a little fix:

Code: [Select]

If(CharacterInString(Btn->Caption, '.'))
  DoThis;
else
  DoThat;

And CharacterInString() could be something like:

Code: [Select]

uint8_t CharacterInString(char *String, char Char)
{
  uint8_t            Flag = 0;

  if (String == NULL) return Flag;       /* sanity check */

  while (String[0] != 0)
  {
    if (String[0] == Char)
    {
      Flag = 1;
      break;
    }

    String++;
  }

  return Flag;
}


[IanB]

And CharacterInString() could be something like:

For illustration, maybe; but in production code why not just use strchr?

[c4757p]

That must be the most complicated CharacterInString() I have ever seen. Are you by any chance a Java programmer?

Code: [Select]

char CharacterInString (const char *s, char c)
{
    for (s; *s; ++s)
        if (*s == c) return c;
    return 0;
}

Of course, one small change makes strchr():

Code: [Select]

char const *strchr (char const *s, char c)
{
    for (s; *s; ++s)
        if (*s == c) return s;
    return NULL;
}

So you may as well use that.

I might as well take the chance to opine a bit on the "sanity check", because sometimes they are a good thing. I don't think it's useful in this case, though. If the code calling this function passes it a NULL string by mistake, there's something seriously wrong with it. You want it to crash as close to the bug as possible. If the function goes ahead and returns a legal response, the parent function could go on its merry way for god knows how long before the error is discovered. Also, for MCU applications I'd rather be extra careful about things like that and save the space in my code memory rather than compile in branches that will never be followed.

For desktop applications, a better way would be to include assert.h and then use assert(String != NULL). You can easily use the preprocessor to just drop all the assert() calls from the code if you're not compiling in debug mode, and it'll give you a nice line-number error message. If your device has any sort of debug interface, I'd recommend setting this up to receive assert() failures.

[madires]

That must be the most complicated CharacterInString() I have ever seen. Are you by any chance a Java programmer?

It's overdone on purpose. If I remove the variable and the pointer check, and replace the "break" with a "return" both are the same.

I might as well take the chance to opine a bit on the "sanity check", because sometimes they are a good thing. I don't think it's useful in this case, though. If the code calling this function passes it a NULL string by mistake, there's something seriously wrong with it. You want it to crash as close to the bug as possible. If the function goes ahead and returns a legal response, the parent function could go on its merry way for god knows how long before the error is discovered. Also, for MCU applications I'd rather be extra careful about things like that and save the space in my code memory rather than compile in branches that will never be followed.

Basically I agree, but there are some situations where you want the program to keep running or enter a safe mode. There might be some errors nobody noticed yet and testing didn't show any problems. Some lucky customer triggers the error by coincidence and a motor/heater/whatever keeps running. If you need to know about such errors set a global error variable or return a "2" in case of the CharacterInString() function and add a proper error handling. We add MOV/TVS/clamping diodes as input protection, shouldn't we add some software protection too if feasible and if risks are being imminent? MCUs got errors too and bits might be inversed by cosmic particles or high EMI.

For desktop applications, a better way would be to include assert.h and then use assert(String != NULL). You can easily use the preprocessor to just drop all the assert() calls from the code if you're not compiling in debug mode, and it'll give you a nice line-number error message. If your device has any sort of debug interface, I'd recommend setting this up to receive assert() failures.

If you want the program being terminated, yes.

PS: I'm not a Java programmer.

[c4757p]

We add MOV/TVS/clamping diodes as input protection, shouldn't we add some software protection too if feasible and if risks are being imminent?

Well that is a good point.

[nctnico]

That must be the most complicated CharacterInString() I have ever seen. Are you by any chance a Java programmer?

I agree with Madires: his code is pretty solid altough I might also test for the maximum length of the string. Adding tests like these prevent an error from spreading like an oil stain and cause a reset/failure/exception in an unrelated piece of code. Error checks help to keep errors inside a 'compartment' so they are easier to track down.

[grumpydoc]

That must be the most complicated CharacterInString() I have ever seen.

In that case you have never examined the GNU C library strchr source code.

The naïve implementations ignore that fact that, on most modern processors, it is more efficient to read memory in 32-bit (or 64-bit, or 128-bit) chunks rather than 8 bits at a time.

The point being that one should normally use the library routines supplied unless detailed analysis shows them to be sub-optimal - they are usually written by better programmers than you (or me, for that matter).

[c4757p]

The glibc version is quite clever. I like the documentation too, it's well written for its complexity.

Error checks help to keep errors inside a 'compartment' so they are easier to track down.

Only if you actually throw some sort of error condition though. If you just return 0 as if the function was successful the error will spread just the same.

[westfw]

We add MOV/TVS/clamping diodes as input protection

Yes, but not at the inputs to every gate in an FPGA...
Figuring out where to put error checking in SW should be a more difficult decision than "just put them everywhere."

No amount of fluffing about with the strchr function seems to give me a suitable result.

We need a more detailed explanation of what seemed to be wrong with the original attempts...