#include inside a struct declaration? What the hell?
I'm not a master in C programming, but to me it looks wrong?
Why don't you do it in the correct way, declaring the arrays properly?
At least use a define:
#define IMAGE1_DATA \
0x35, 9x44, 0x11, 0x42, 0x76, \
111, 104, 84, 10, 84, 92, \
'l', 'i', 'n', 'e', '3', \
You need add "\" to make it multiline \
This is the last line (No "\")
With that, you could simply type "IMAGE1_DATA" in the initialization array.
But it's not a tidy or proper way to do that...
I'm not telling you anything new, for sure you know far more more than me about C.
But this code hurts my eyes!
It's not about the fact he's including the txt file, it's about WHAT he's trying to achieve with it.
The txt file has just comma separated values, so how on earth would this work? (ignoring the fact it's being declared twice)
.arrImage_data =
{{
#include"TestImage_1.txt"
},{
#include"TestImage_1.txt"
}},
#include simply tells the compiler to search for resources in that file following the line where it was declared.
But that initialization actually does this, #include does absolutely nothing inside it:
.arrImage_data =
{{
},{
}},
It's like inserting any random preprocessor stuff:
.arrImage_data =
{{
#define This_does_nothing
},{
#define Neither_this
}},
Actually, it's strange that the compiler isn't dropping any error, because a random text not following any syntax would definitely shoudl fail.
Perhabs the compiler is ignoring it due not being a standard C file extension (.c, or .h).
@ricko_uk:
Please check if a simpler/test version of this works in your environment. I recommend you do this as a separate project. For example,
#include <stdint.h>
typedef struct {
uint32_t a;
int8_t b;
uint8_t c[2][64];
} data_struct;
data_struct test_data_struct = {
.a = 0xdeadbeef,
.b = -42,
.c = { {
1, 2, 3, 4, 5, 6, 7, 8,
-1,-2,-3,-4,-5,-6,-7,-8,
32,33,34,35,36,37,38,39,
47,46,45,44,43,42,41,40,
16,17,18,19,20,21,22,23,
24,25,26,27,28,29,30,31,
55,54,53,52,51,50,49,48,
56,57,58,59,60,61,62,63,
}, {
1,63,62,61,60,59,58,57,
56, 1,54,53,52,51,50,49,
48,47, 1,45,44,43,42,41,
40,39,38, 1,36,35,34,33,
32,31,30,29, 1,27,26,25,
24,23,22,21,20, 1,18,17,
16,15,14,13,12,11, 1, 9,
8, 7, 6, 5, 4, 3, 2, 1,
} },
};
The sum of test_data_struct.c[0] is 3944 (104, if you sum as uint8_t), and the sum of test_data_struct.c[1] is 1828 (36, if you use uint8_t), if you want to use a test loop to verify all the data is still there.
If you see at runtime zeroes here, then you have a minimal, complete verifiable example or MCVE, as needed for proper bug reports.
If this works correctly, then I'd expand the size, duplicating the shown data or using random data, up to around the same size as in your proper project. If it suddenly stops working, it means that your environment has a limit of how much it can initialize data. Perhaps it is running out of Flash/ROM, or perhaps it is some configurable limit.
It this works correctly as a separate example, but fails in your own project, then your project has a serious bug where something clears the memory after it has been initialized; most likely, your own code does an equivalent of memset(pointer, 0, size) where pointer, size, or both are bogus. A particular case I've seen is when supplied size is negative: since the parameter is of type size_t, the size is cast to an unsigned type, leading to a very large size.