ISO15693 codec and applications updates #274
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since GCC 10, the compiler defaults to -fno-common, thus variables with multiple tentative definitions result in linker errors. We've (me and @MrMoDDoM) extern-ed the shared variables to fix the issue. Also, when I implemented ISR sharing, somehow I forgot about a function which was shared as well, so I fixed that mistake and added a couple of comments on how shared function calls work.
Unvarying interrupt configuration moved from StartISO15693Demod to CodecInit Fixed an old issue (geo-rg#4) properly overwriting the PERBUF register when no data has to be sent Loadmodulation ISR has a new GOTO label which is called when ISO t1 time is elapsed, but data is not yet ready. This way it is possible to avoid checking for state validity on every ISR hit New inline function to clean up interrupts when field noise (garbage) is incorrectly picked up Bitrate configuration in ISO15693_EOC has been simplified Cleaned up header file with useless defines. Moved defines to .c when there was no need to share them with other source files Annotated numer of clock cycles consumed by asm ISR sharing routine As usual, this work was done with @MrMoDDoM
Removed the if-elseif in EM4233 to use a switch case which yields minor speed improvements of ~1,5 microseconds Avoid reading the UID every AppProcess tick in both EM4233 and TiTagIT to save ~11 microseconds.
fptrs
requested changes
Sep 8, 2020
|
Very sorry about that, it was a rogue copy-paste. I'll fix it tomorrow :) |
|
Done |
ISO15693 CRC calculation is slow and it delayed too much transmission of long frames. Some readers marked transmission as unsuccesfull and ignored data. Moving CRC calculation inside the codec allows to start modulating the field while the CRC is not yet ready but, by the time it has to be trasmitted, calculation will be done. This fixes emsec#262 In EM4233, there still are issues with Read Multiple command when block locking status is requested for more than 0x1F blocks Implemented a check in ISO15693 codec to avoid out of bound CRC writes.
|
Fixed the long standing #262 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes and supersedes #272
Me and @MrMoDDoM have been refining ISO15 code due to an issue we faced with the ST CR95HF reader. We thought something was wrong with the codec because the Read Multiple Blocks failed when reading more than 7 blocks at once. It felt like an issue when modulating long frames but, after some investigation it turned out that the ST reader was very precise with SOF timings.
Reading more than 7 blocks into the codec's buffer take too much time, and this means that ISO t1 time elapses before data is ready and the codec is stuck waiting for data before it can modulate anything, so the reader complains as it did not receive a SOF in time. This kind of issues is not present with the phones we've tested the code with
I'd like to discuss about ISO t1 time, since we could not explain how the old value
4192 + 128 + 128 - 1was chosen. This value is greater than both ISO dictated nominal and maximum t1, but yielded better results than t1 nominal, so reading 10 blocks at a time was possible. This is possibly due to the fact that waiting "a bit more" allows the Application to generate needed data before the first interrupt hit occurs and, at that time, data is marked as ready to be processed by CodecTask.How was the old value chosen? Do we want to favor performance over emulation accuracy? Which value should be kept?
Also, applications were updated to improve performance. Reading the UID on every ApplicationTask hit was totally unnecessary and a big performance drag