+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
bormand 09.07.2014 22:56 # +1
Зато эта жесть сжирает почти всю флешку? :)
FlySnake 09.07.2014 23:09 # 0
bormand 09.07.2014 23:48 # +1
inkanus-gray 09.07.2014 23:15 # 0
bormand 09.07.2014 23:17 # 0
А разве есть дешевые цифровые индикаторы с чернилами?
inkanus-gray 09.07.2014 23:21 # 0
bormand 09.07.2014 23:42 # +1
Да и, емнип, в таких железках со спецом ставят медленные индикаторы с охеренной инерцией, чтобы частоту развертки большую не делать. Это ж не моник.
inkanus-gray 09.07.2014 23:13 # +2
Тут уже́ есть проверка на наличие старшего разряда, которая в микроконтроллере сводится к вычитанию 99 из числа. Это даёт возможность укоротить массив вдвое, если не терять результат вычитания:
Qwertiy 10.07.2014 10:02 # +1
bormand 09.07.2014 23:14 # +2
bormand 09.07.2014 23:24 # +1
Хотя не факт. Такта 4 на переходах то сэкономили, зато получили битовые операции против тупых ldi (или как их зовут там на этой платформе). Короче тестить надо.
inkanus-gray 09.07.2014 23:29 # 0
Для уверенности остаётся только сравнить скорость выполнения сдвига и конъюнкции с двумя джампами.
bormand 09.07.2014 23:34 # 0
FlySnake 10.07.2014 13:45 # 0
bormand 10.07.2014 14:03 # 0
Но на тех же avr был swap, который полубайты меняет местами. Если и здесь такое есть, а компилер додумается 4 сдвига заменить на swap + and - получится норм.
Это уберет всю логику и сдвиги, но добавит лишнее обращение к массивКак вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта.у (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
bormand 10.07.2014 14:09 # 0
Читаем так: Как вариант - можно попробовать сделать массив из uint16_t и загружать оттуда джва подряд идущих байта. Это уберет всю логику и сдвиги, но добавит лишнее обращение к массиву (на avr загрузка-с-флешки-с-инкрементом 3 такта, как на pic - х.з.).
bormand 10.07.2014 14:08 # 0
FlySnake 10.07.2014 15:07 # +1
vadik 25.08.2021 21:15 # 0