Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
8-битный микроконтроллер, 32768Гц тактовая частота, батарейное питание, CPU по-максимуму в спячке для экономии энергии.
Функции display3d(), display2d(), display1() отображают цифру в соответствующем знакоместе на 2.5 разрядном LCD от 0 до 199.
Преобразование числа в BCD формат.
Эта жесть даёт выигрыш порядка 10 мкА перед "обычным" преобразования с делениями на 10 за счёт меньшего времени работы CPU для расчёта. Вроде говнокод, но в данном случае оправдан, потому не воняет :)
Ну деление на тех же авр это пиздец тот еще. На тиньке с ее 2кб флехи оно зажирало не то четверть, не то вообще половину... давно это было, точных цифр не помню.
Тут уже́ есть проверка на наличие старшего разряда, которая в микроконтроллере сводится к вычитанию 99 из числа. Это даёт возможность укоротить массив вдвое, если не терять результат вычитания:
> да и работать должно пошустрее switch'а
Хотя не факт. Такта 4 на переходах то сэкономили, зато получили битовые операции против тупых ldi (или как их зовут там на этой платформе). Короче тестить надо.
Учитывая, что сишка переводит свитчи в таблицы переходов, оба кода сводятся к массиву. Однако, в этом варианте не будет джампов, так что, вероятно, он лучше.
Для уверенности остаётся только сравнить скорость выполнения сдвига и конъюнкции с двумя джампами.
Да, тупанул я, на контроллеры barrel shifter то не завезли...
Но на тех же avr был swap, который полубайты меняет местами. Если и здесь такое есть, а компилер додумается 4 сдвига заменить на swap + and - получится норм.
Это уберет всю логику и сдвиги, но добавит лишнее обращение к массивКак вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта.у (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
Читаем так: Как вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта. Это уберет всю логику и сдвиги, но добавит лишнее обращение к массиву (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
Я не помню, как мы оказались в постели, но такого секса у нас ещё не было. Мы будто заново изучали друг друга и не могли насытиться теми ощущениями, которые дарили друг другу. Пусть это прозвучит банально, но мы занимались не сексом, мы занимались любовью!
Зато эта жесть сжирает почти всю флешку? 🙂
А разве есть дешевые цифровые индикаторы с чернилами?
Да и, емнип, в таких железках со спецом ставят медленные индикаторы с охеренной инерцией, чтобы частоту развертки большую не делать. Это ж не моник.
Тут уже́ есть проверка на наличие старшего разряда, которая в микроконтроллере сводится к вычитанию 99 из числа. Это даёт возможность укоротить массив вдвое, если не терять результат вычитания:
Хотя не факт. Такта 4 на переходах то сэкономили, зато получили битовые операции против тупых ldi (или как их зовут там на этой платформе). Короче тестить надо.
Для уверенности остаётся только сравнить скорость выполнения сдвига и конъюнкции с двумя джампами.
Но на тех же avr был swap, который полубайты меняет местами. Если и здесь такое есть, а компилер додумается 4 сдвига заменить на swap + and - получится норм.
Это уберет всю логику и сдвиги, но добавит лишнее обращение к массивКак вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта.у (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
Читаем так: Как вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта. Это уберет всю логику и сдвиги, но добавит лишнее обращение к массиву (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).