messenger 0 9 января, 2013 Опубликовано 9 января, 2013 · Жалоба Здравствуйте уважаемые пользователи форума! Столкунлся с проблемой и прошу помощи. Конроллер 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; Спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 9 января, 2013 Опубликовано 9 января, 2013 · Жалоба %u - это просто "int", который архитектурно-зависимую длину имеет, в Вашем случае 16 бит. чтобы корректно вывести long int - нужна последовательность %lu Байты так выделять некорректно - у Вас сдвиг везде на 8. Корректно - на 8, потом на 16, потом на 24. И то лишь в случае, если требуемый порядок следования байт "little endian", то есть первым по порядку следует младший байт. UPD: Упс. Извините, не заметил, что там ">>=". Корректно байты выделять так. Но с учетом "little endian", и не факт, что оптимизатор правильно поймет и скомпилирует в оптимальную конструкцию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
messenger 0 9 января, 2013 Опубликовано 9 января, 2013 · Жалоба SM большое спасибо за "lu" не известно сколько бы я еще происидел, не нашел этого момента в хелпе на CVAVR. по поводу второго тоже спасибо) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 9 января, 2013 Опубликовано 9 января, 2013 · Жалоба не нашел этого момента в хелпе на CVAVR. Видимо, не там искали. Это не относится к конкретной реализации C компилятора, это относится к языку С вообще. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Misile_Inc 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 · Жалоба Лучше не приучайтесь использовать printf. Это плохой стиль для встраиваемых систем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 · Жалоба Лучше не приучайтесь использовать printf. Это плохой стиль для встраиваемых систем. qu'est-ce que c'est? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Misile_Inc 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 · Жалоба Всякие стандарты типа MISRA запрещают использование функций, в прототипах которых есть многоточие (elipsis). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 · Жалоба Ой, да неужели непонятно, что слова «это плохой стиль для встраиваемых систем» означают «это сделано не так, как привык тот, кто сказал, что это плохой стиль». Если не всегда, то почти всегда. Сказанные «вообще», без учета конкретных ограничений конкретной системы — всегда. Но с учётом ограничений это не «плохой стиль», а «неучёт ограничений». Для на всякий случай хочу сразу сказать, что компы, на которых появился и сам С, и его printf в библиотеке, находятся где-то на уровне от atmega162+внешнее ОЗУ до atmega64 — по ресурсам. По быстродействию на порядок-полтора медленнее. Те компы медленнее, чем AVR-ки, а не наоборот. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Misile_Inc 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 (изменено) · Жалоба bait_1 Так тоже не надо делать. Транслитерация для любых платформ является плохим стилем ReAl, нет, это значит "Это сделано не так, как рекомендует промышленный стандарт". Не нужно отвечать за меня- это тоже плохой стиль. Я сам могу. Изменено 20 февраля, 2013 пользователем Misile_Inc Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 · Жалоба Всякие стандарты типа MISRA запрещают использование функций, в прототипах которых есть многоточие (elipsis).Тогда «плохой стиль с точки зрения мисры», а не «плохой стиль для embedded вообще». Причина в том, что код с функцями с эллипсисом несколько труднее формально верифицировать, чем десять строк тупых itoa()/strlen()/put_spaces()/putstr(). Но в результате то, что можно написать одним вызовом printf, придётся писать несколькими строками вызовов разных функций и ещё неизвестно, где легче ошибку сделать как при начальном написании, так и при модификации. А GCC, например, умеет сам ругаться на несоответствие количества и типов аргументов форматной строке printf (в духе «третий спецификатор для long, а туда сунули char*»). И даже про свою функцию lcd_printf(int x, int y, const char *fmt, ...) ему можно объяснить, каким аргументом идёт форматная строка и он проверит всё. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Misile_Inc 0 20 февраля, 2013 Опубликовано 20 февраля, 2013 (изменено) · Жалоба Не только мисры. Вот ссылки на пункты стандартов, не рекомендующие использование функций с неограниченным колличеством аргументов. 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 Изменено 20 февраля, 2013 пользователем Misile_Inc Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться