с, структура/данные/наполнение, как оптимизировать?!

[eddy]

sunjob, ты с разделом ошибся. Ну какие могут быть

#include ‹string.h›
#include ‹stdlib.h›
#include ‹stdio.h›

у аврки? Да и вообще микроконтроллера?

[Arbuzzo]

Тут дело не в АВРке и заголовочниках, а в построении иерархии программы.
Топикстартеру следует почитать литературу об общих принципах компоновки кода. В частности, раздел об уровнях абстракции кода, иерархии.
То есть, не следует из main-а вызывать всё подряд без разбора. Будет запутанная бессмысленная лапша, которую сложно будет поддерживать, редактировать.
Должны быть видимые и четкие разделения уровней абстракции, а взаимодействие между уровнями должно осуществляться через интерфейсный функционал.

В языке Си используется понятие модульности. Модуль - это "кирпичик" программы, функционально законченный элемент, имеющий реализацию и интерфейс взаимодействия с модулем. Реализация помещается в файле *.c, интерфейс - в файле *.h. Потоки данных в том или ином виде пересылаются через интерфейсы модулей. Интерфейс модуля позволяет отделить внутренние функции и данные модуля от внешних и не допустить случайных ошибок в вызовах функций и передаче данных.

[sunjob]

ты с разделом

эд, привет! ну ты по делу-то выскажись, что думаешь, куда думаешь послать, чем уничтожить...?! :о)

только без лишней пыли?!
все что по делу - я прочитаю, все остально - проигнорю, как обычно!
за любой пендиль по делу - всегда благодранен! :о)

[eddy]

Зачем помещать массив в один файл, а инициализировать - в другом? Вот у тебя косяк и выплыл: в struct.c свой массив, а в struct_cust.c - свой. И, хоть они одноименные, ничего общего между ними нет. У тебя в функции struct_list() должен быть сегфолт, т.к. по умолчанию глобальные переменные нулями инициализируются.
И как ты изменением макроса NUM "вуаля" добьешься? Тебе все равно инициализатор придется менять. Я бы эту структуру вообще typedef'ом определил. Массив лучше сразу же самих структур заводить, а не указателей. А в функции-инициализаторе заполнять.

[eddy]

Скачал твой архив. Запустил make. Скажи, а как у тебя оно могло собраться, если даже gcc подсказывает то, что я выше написал?

make
gcc -c main.c
gcc -c struct.c
gcc -c struct_cust.c
gcc -o main main.o struct.o struct_cust.o
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: struct_cust.o:(.data.rel.local+0x20): multiple definition of `lst'; struct.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [makefile:5: all] Error 1

Советую ВСЕГДА на стадии debug-сборки добавлять "-Wall -Wextra -Werror", тогда не будет соблазна косяки пропустить.
Вот такой простой makefile поможет тебе писать "make debug" или "make release", цель сохраняется во временном файле, поэтому все следующие make будут использовать ее. Если нужно сменить цель, сначала make clean, а потом уже - нужный.

UPD: пофиксил

[sunjob]

Вот у тебя косяк и выплыл

не знаю, что там у тебя за такое все плохо?!
это сборка моего "шаблона" (стал-бы я выкладывать нерабочий?!)

main$ make clean all
rm -f *.o main
gcc -c main.c
gcc -c struct.c
gcc -c struct_cust.c
gcc -o main main.o struct.o struct_cust.o

./main
### struct ###
struct_list()
lst[0].num = 1; struct_cust_func(0)
lst[1].num = 2;
lst[2].num = 3; struct_cust_func(2)

и это не "рабочий проект" а быстро набитый вслепую "аналог того, что отлаживается", с минимумом того, что нужно :о)

[sunjob]

структуру вообще typedef'ом определил

так сейчас и сделано (сделал то, что нужно было, в конце архив выложил :о)

[sunjob]

Массив лучше сразу же самих структур заводить, а не указателей.

такие требование :о)

[sunjob]

Советую ВСЕГДА на стадии

это не рабочий проект, а шаблон, набранный быстро в ручную :о)
в рабочем проекте мейкфайл наворочен до нЕльзя, и все в нем как надо рулится :о)

[sunjob]

Зачем помещать массив в один файл, а инициализировать - в другом?

обычное разделение на "бибилотеку" и "пользовательские данные"... :о)