armsrc/felica: add polling response time slot support to felica_sim_lite

Make sure we respond in a valid time slot.
We were responding too early, the first time slot (which is always allowed) starts after 512 * 64 / fc.

Also, respond in incremental time slots. We could have used a fixed time slot (#0 is always allowed), but by using incremental time slots we have a better chance the reader will get our response in the expected time frame.
(when our timing is wrong, we have a risk of responding too early when using the first slot, and too late when using the last slot. Slots in the middle of the allowed range have the best chance)
This commit is contained in:
pieterg 2021-11-19 14:59:45 +01:00 committed by GitHub
commit 1ec2e95437
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -735,6 +735,7 @@ void felica_sim_lite(uint8_t *uid) {
if (FelicaFrame.crc_ok) {
if (FelicaFrame.framebytes[2] == 6 && FelicaFrame.framebytes[3] == 0) {
static uint8_t timeslot = 0;
// polling... there are two types of polling we answer to
if (FelicaFrame.framebytes[6] == 0) {
@ -747,6 +748,13 @@ void felica_sim_lite(uint8_t *uid) {
curlen = R_POLL1_LEN;
listenmode = false;
}
if (timeslot > FelicaFrame.framebytes[7]) {
// framebytes[7] contains the maximum time slot in which we are allowed to respond (#0..#15)
timeslot = 0;
}
// first time slot (#0) starts after 512 * 64 / fc, slot length equals 256 * 64 / fc
felica_nexttransfertime = GetCountSspClk() - (DELAY_AIR2ARM_AS_READER + DELAY_ARM2AIR_AS_READER) / 16 + (512 + timeslot * 256) * 64 / 16 + 1;
timeslot++; // we should use a random time slot, but responding in incremental slots should do just fine for now
}
if (FelicaFrame.framebytes[2] > 5 && FelicaFrame.framebytes[3] == 0x06) {