Преобразовать 0xffffff в три восьмибитных
- Войдите на сайт для отправки комментариев
Пт, 16/12/2016 - 12:31
Всем привет, возник вопрос преобразования 3-х битного шестнадцатиричного числа в три восьмибитных шестнадцатиричных, т.е. например из 0xffffff нужно разложить на 0xff 0xff 0xff. Посоветуйте кто делал?
3-х битного шестнадцатиричного числа
Это что? Описка, глупость или что-то имелось в виду?
да, описка, извините, 24-х битного
Ладно... из жалости сделаю вид, что догадался о том, что число не "3-х битовое", а, все-таки, трех БАЙТОВОЕ.
1. нет такого типа, есть uint16_t и uint32_t в 2 и 4 байта, соответственно.
2. Значит преобразовывать нужно uint32_t.
Проще всего использовать "расово верное" преобразование через union, оно работает на всех платформах, следовательно переносимо и является гуд-стайлом программирования. Можно сдвигами и масками, только дольше.
Как я понял, тебе нужны только первые три байта.
Сдвиги и маски:
Еще раз сдвиги и маски - суть говнокод. так можно, но не стоит программировать.
Как говорил мой старый учитель:
Старайся делать хорошо, ибо плохо - оно само получится.
Ок парни, спасибо за быстрые ответы, попробую оба варианта, нужна именно скорость преобразования
А сдвиги, кончно же, говнокод, то-то под него говноинженеры предусмотрели аппаратные говноинструкции shr и shl, ror и rol и прочие :)
Да! Добавлю:
Если ты работаешь с цветом и постоянно нужны либо разложение по цветам либо полный код, то сразу держи все в юнионе, он для того и придуман авторами С. Компилятор сам все, что нужно сделает. Не нужно пытаться быть умнее компилятора.
Код будет короче (и быстрее) для контроллера и читаемее в исходнике.
А сдвиги, кончно же, говнокод, то-то под него говноинженеры предусмотрели аппаратные говноинструкции shr и shl, ror и rol и прочие :)
Дурака из себя строешь? Получается....
=================
Штоп не думал, что обзываюсь, поясню:
сдвиг на 8 в 8-ми битном контроллере, это взятие байта по другому адресу. Просто смысла не имеет.
Еще раз, для тех, кто в танке - СДВИГ НА 8. Ничего не ёрзает? Не на 3 и не на 5, а на 8
Единственная надежда, что компилятор оптимизирует - иначе код будет просто пи..ец какой кривой.
--- В ARM-e хоть какой-то смысл есть, там важно выравнивание лонга по адресу, делящемуся на 4, но в AVR Mega - вообще никакого смысла не имеет.
Парни, код будет применяться на Maple mini - STM32F103CBT6 под Arduino Ide 1.6.5
Можно переделать под себя такой пример:
1. нет такого типа, есть uint16_t и uint32_t в 2 и 4 байта, соответственно.
Нет, то оно нет, но если сильно хочется. то сделать можно :)
https://gist.github.com/mntone/25d591ff5db04de26e95
1. нет такого типа, есть uint16_t и uint32_t в 2 и 4 байта, соответственно.
Нет, то оно нет, но если сильно хочется. то сделать можно :)
https://gist.github.com/mntone/25d591ff5db04de26e95
Супер!!! Очень забавно. Поправили мне поганое, с утра, настроение. Спасибо!
1. нет такого типа, есть uint16_t и uint32_t в 2 и 4 байта, соответственно.
Нет, то оно нет, но если сильно хочется. то сделать можно :)
https://gist.github.com/mntone/25d591ff5db04de26e95
Скажу больше, делать ничего не надо, есть __uint24 и __int24.
https://gcc.gnu.org/wiki/avr-gcc
Хоть и описано в Extensions, но есть. Товарищь с ником ptr сделал для меня открытие недавно.
Скажу больше, делать ничего не надо, есть __uint24 и __int24.
Про то, что в GNU это есть я знал, но думал, что с теми опциями компилятора, что стоят в IDE по умолчанию, этого типа нет. А я уж давно зарёкся кому-либо здесь говорить про фичи, которых нет в умолчательных опциях.
Но, сейчас проверил в своём IDE - есть! Так что, спасибо, что напомнили.
Правда, я не уверен, что у меня в IDE опции "по умолчанию". У меня и auto есть, и типизированные enum, но что-то мне кажется, что раньше их не было. Может я таки поменял опции, не помню. Не мог бы кто-нибудь, у кого точно опции стоят "из коробки" проверить?
Дык, я из коробки и иммел ввиду. Сам очень долго удивлялся.
Спасибо, xDriver.