Let's go through an example, using the following macro:
If the first timer read is 0xe4 and the second one is 0x32, the timer wrapped.
If the timer would have had more bits, it's new value would have been 0x132,
and the correct difference in time is 0x132 - 0xe4 = 0x4e
old code TIMER_DIFF_8(0x32, 0xe4) = 0xff - 0xe4 + 0x32 = 0x4d, which is wrong.
new code TIMER_DIFF_8(0x32, 0xe4) = 0xff + 1 - 0xe4 + 0x32 = 0x4e, which is correct.
This also gives a chance for a smart compiler to optimize the code using normal
integer overflow.
For example on AVR, the following C code:
uint8_t __attribute__ ((noinline)) test(uint8_t current_timer, uint8_t start_timer)
{
return TIMER_DIFF_8(current_timer, start_timer);
}
With the original code, it gets translated to the following list of instructions:
00004c6e <test>:
4c6e: 98 2f mov r25, r24
4c70: 86 1b sub r24, r22
4c72: 96 17 cp r25, r22
4c74: 08 f4 brcc .+2 ; 0x4c78 <test+0xa>
4c76: 81 50 subi r24, 0x01 ; 1
4c78: 08 95 ret
But with this commit, it gets translated to a single instruction:
00004c40 <test>:
4c40: 86 1b sub r24, r22
4c42: 08 95 ret
This unfortunately doesn't always work so nicely, for example the following C code:
int __attribute__ ((noinline)) test(uint8_t current_timer, uint8_t start_timer)
{
return TIMER_DIFF_8(current_timer, start_timer);
}
(Note: return type changed to int)
With the original code it gets translated to:
00004c6e <test>:
4c6e: 28 2f mov r18, r24
4c70: 30 e0 ldi r19, 0x00 ; 0
4c72: 46 2f mov r20, r22
4c74: 50 e0 ldi r21, 0x00 ; 0
4c76: 86 17 cp r24, r22
4c78: 20 f0 brcs .+8 ; 0x4c82 <test+0x14>
4c7a: c9 01 movw r24, r18
4c7c: 84 1b sub r24, r20
4c7e: 95 0b sbc r25, r21
4c80: 08 95 ret
4c82: c9 01 movw r24, r18
4c84: 84 1b sub r24, r20
4c86: 95 0b sbc r25, r21
4c88: 81 50 subi r24, 0x01 ; 1
4c8a: 9f 4f sbci r25, 0xFF ; 255
4c8c: 08 95 ret
Wth this commit it gets translated to:
00004c40 <test>:
4c40: 28 2f mov r18, r24
4c42: 30 e0 ldi r19, 0x00 ; 0
4c44: 46 2f mov r20, r22
4c46: 50 e0 ldi r21, 0x00 ; 0
4c48: 86 17 cp r24, r22
4c4a: 20 f0 brcs .+8 ; 0x4c54 <test+0x14>
4c4c: c9 01 movw r24, r18
4c4e: 84 1b sub r24, r20
4c50: 95 0b sbc r25, r21
4c52: 08 95 ret
4c54: c9 01 movw r24, r18
4c56: 84 1b sub r24, r20
4c58: 95 0b sbc r25, r21
4c5a: 93 95 inc r25
4c5c: 08 95 ret
There is not much performance improvement in this case, however at least with this
commit it functions correctly.
Note: The following commit will improve compiler output for the latter example.
The bootkey set in bootloader_jump() works with Pro Micro and Leonardo.
This fix doesn't seem to prevent other bootloaders, however, it can be
disabled by defining NO_BOOTLOADER_CATERINA_BOOTKEY.
Startup wait loop is originally intended to start keyboard task loop and
after console output endpoint becomes available. But now that console
output is buffered when it is not available and you don't have to wait
for it to be ready. You can disable the startup wait loop by defining
NO_WAIT_FOR_USB_CONFIGURED in config.h
Suspend loop is used for power saving by making tasks stop while
USB bus is under suspend status. But this may cause problem on some
devices like converter that must keep doing its task to retain
communication with keyboard. The suspend loop can block its task for
around 15-17ms. You can disable the suspend loop by defining
NO_USB_SUSPEND_LOOP in config.h.
Calling led_set() in ISR can cause the problem. With converter
especially, led_set() can take long time and USB can be stuck in the end.
USB-USB converter freezes occasionally when computer power up or reboot.
https://geekhack.org/index.php?topic=69169.msg2740179#msg2740179
This is also related to suspend/wakeup issue #386.
- Change keyboard_init() timing and matrix_scan() is called in USB
startup wait loop for FC660C
- FC660C startup seems to be faster and it doesn't work without this fix
when plugin the keyboard and converter at same time
console_putc:
Linux: works very well in general
Windows: also works very well and connection seems to be faster than Linux
Mac: to be: confirmed
NOTE: long session of matrix_print still blocks keyboard_task in main loop
and prevents it from sending keyboard report.
XT protocol buffer overflow occurs when slamng on keys
TODO: check when print functions are called in ISR
Purdea Andrei
tmk
You Xiaojie / 尤晓杰
rxy0424
Konstantin Đorđević
Øystein Bech Gadmar
alex-ong
alex-ong
yangdigi
Mark Furland
X64051