+136
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
void lcd_show(uint8_t number)
{
uint8_t digit3 = 0;
uint8_t digit2 = 0;
uint8_t digit1 = number > 99u ? 1u : 0;
switch(number)
{
case 0u:
digit3 = 0u;
digit2 = 0u;
break;
case 1u:
digit3 = 1u;
digit2 = 0u;
break;
.....
.....
case 199u:
digit3 = 9u;
digit2 = 9u;
break;
default:
digit3 = '-';
digit2 = '-';
digit1 = 0;
break;
}
display3d(digit3);
display2d(digit2);
display1d(digit1);
}
8-битный микроконтроллер, 32768Гц тактовая частота, батарейное питание, CPU по-максимуму в спячке для экономии энергии.
Функции display3d(), display2d(), display1() отображают цифру в соответствующем знакоместе на 2.5 разрядном LCD от 0 до 199.
Преобразование числа в BCD формат.
Эта жесть даёт выигрыш порядка 10 мкА перед "обычным" преобразования с делениями на 10 за счёт меньшего времени работы CPU для расчёта. Вроде говнокод, но в данном случае оправдан, потому не воняет :)
Запостил:
FlySnake,
09 Июля 2014
Зато эта жесть сжирает почти всю флешку? :)
А разве есть дешевые цифровые индикаторы с чернилами?
Да и, емнип, в таких железках со спецом ставят медленные индикаторы с охеренной инерцией, чтобы частоту развертки большую не делать. Это ж не моник.
Тут уже́ есть проверка на наличие старшего разряда, которая в микроконтроллере сводится к вычитанию 99 из числа. Это даёт возможность укоротить массив вдвое, если не терять результат вычитания:
Хотя не факт. Такта 4 на переходах то сэкономили, зато получили битовые операции против тупых ldi (или как их зовут там на этой платформе). Короче тестить надо.
Для уверенности остаётся только сравнить скорость выполнения сдвига и конъюнкции с двумя джампами.
Но на тех же avr был swap, который полубайты меняет местами. Если и здесь такое есть, а компилер додумается 4 сдвига заменить на swap + and - получится норм.
Это уберет всю логику и сдвиги, но добавит лишнее обращение к массивКак вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта.у (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
Читаем так: Как вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта. Это уберет всю логику и сдвиги, но добавит лишнее обращение к массиву (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).