Здравствуйте уважаемые пользователи форума!
Столкунлся с проблемой и прошу помощи.
Конроллер ATmega16? среда CVAVR

обявляю прерменную 32 бита
unsigned long int REG_0=0b0...........................................01 (32 бита)
вывожу через printf
printf("REG0= %u ",REG_0);

но явно пропадают первые два старших байта, не могу разобраться как быть.

и насколько правильно выделять из unsigned long int 4 байта типа unsigned char

bait_1=REG_0 & 0xFF;
bait_2=(REG_0>>=8) & 0xFF;
bait_3=(REG_0>>=8) & 0xFF;
bait_4=(REG_0>>=8) & 0xFF;

Спасибо

%u - это просто "int", который архитектурно-зависимую длину имеет, в Вашем случае 16 бит.
чтобы корректно вывести long int - нужна последовательность %lu

Байты так выделять некорректно - у Вас сдвиг везде на 8. Корректно - на 8, потом на 16, потом на 24. И то лишь в случае, если требуемый порядок следования байт "little endian", то есть первым по порядку следует младший байт.

UPD:
Упс. Извините, не заметил, что там ">>=". Корректно байты выделять так. Но с учетом "little endian", и не факт, что оптимизатор правильно поймет и скомпилирует в оптимальную конструкцию.

SM большое спасибо за "lu" не известно сколько бы я еще происидел, не нашел этого момента в хелпе на CVAVR.
по поводу второго тоже спасибо)

Видимо, не там искали. Это не относится к конкретной реализации C компилятора, это относится к языку С вообще.

Лучше не приучайтесь использовать printf. Это плохой стиль для встраиваемых систем.

qu'est-ce que c'est?

Всякие стандарты типа MISRA запрещают использование функций, в прототипах которых есть многоточие (elipsis).

Ой, да неужели непонятно, что слова «это плохой стиль для встраиваемых систем» означают «это сделано не так, как привык тот, кто сказал, что это плохой стиль».
Если не всегда, то почти всегда. Сказанные «вообще», без учета конкретных ограничений конкретной системы — всегда. Но с учётом ограничений это не «плохой стиль», а «неучёт ограничений».

Для на всякий случай хочу сразу сказать, что компы, на которых появился и сам С, и его printf в библиотеке, находятся где-то на уровне от atmega162+внешнее ОЗУ до atmega64 — по ресурсам. По быстродействию на порядок-полтора медленнее. Те компы медленнее, чем AVR-ки, а не наоборот.

Так тоже не надо делать. Транслитерация для любых платформ является плохим стилем


ReAl, нет, это значит "Это сделано не так, как рекомендует промышленный стандарт". Не нужно отвечать за меня- это тоже плохой стиль. Я сам могу.

Тогда «плохой стиль с точки зрения мисры», а не «плохой стиль для embedded вообще».
Причина в том, что код с функцями с эллипсисом несколько труднее формально верифицировать, чем десять строк тупых itoa()/strlen()/put_spaces()/putstr(). Но в результате то, что можно написать одним вызовом printf, придётся писать несколькими строками вызовов разных функций и ещё неизвестно, где легче ошибку сделать как при начальном написании, так и при модификации.

А GCC, например, умеет сам ругаться на несоответствие количества и типов аргументов форматной строке printf (в духе «третий спецификатор для long, а туда сунули char*»). И даже про свою функцию lcd_printf(int x, int y, const char *fmt, ...) ему можно объяснить, каким аргументом идёт форматная строка и он проверит всё.

Не только мисры. Вот ссылки на пункты стандартов, не рекомендующие использование функций с неограниченным колличеством аргументов.
Related standards model rules
CAST : 5.1.7
CERT-C : DCL10-C, DCL11-C
CERT-J : DCL02-J
CMSE : 1.1.8
CWE : 628
DERA : 69
EADS-C++ : 40
FSB582-C : 3.6.5
GJB : 4.1.1.8
HIC++ : 11.6
HIS : 69
JPL : 8
JSF++ AV : 108
LMTCP : 203
MISRA-AC : 16.1
MISRA-C++:2008 : 8-4-1
MISRA-C:1998 : 69
MISRA-C:2004 : 16.1
SEC-C : R2.8.2