ENH - Cleanup and reorganize RFID station firmware

[BobGlicksman]

The RFID station firmware and been patched and added to several times now and it is getting very hard to follow. There are also lots of comments about EZ Facility and other legacy stuff that would further confuse someone who is trying to read and follow the code. Furthermore, the code contains lots of comments about how pieces of code should really be consolidated with other parts of the code and other extraneous comments that we added as we patched things expediently. It would be nice to take time to reorganize and rewrite the code so that it is clean and understandable.

[jschrempp]

Ideas:

1. Move each of the state machines to its own module.
2. Rename variables and functions away from "ezf" and over to "crm" to make the code more generic
3. Move access control decision making out of the firmware and to the FDB.

[BobGlicksman]

Re. #1: I think that it is OK to have all of the state machines in one file, but we might want to move the functions out into separate files. We have a complex set of functions, some that call other functions, and many of the functions are only needed by one state of one state machine but it is hard to sort through them all when trying to review the code logic. Perhaps there is a way to reorganize the functions so that they can be moved into several files where each file contains only those functions that apply to a specific operation in a specific state machine, making the functions easy to find and the workflow easier to follow.

[jschrempp]

Yes, moving code to other files will help us isolate the variables that really need to be global. I still hold hope to have each state machine in its own file - I think that would make the dependencies very clear.

[BobGlicksman]

I was thinking about not having to scroll down through thousands of lines of code to review the to level logic (state machine) and then have to walk through nested function calls to find the algorithm that does something specific.  Smaller and well partitioned code files would be a big help.  On Thursday, October 5, 2023 at 05:13:03 PM PDT, Jim Schrempp ***@***.***> wrote: Yes, moving code to other files will help us isolate the variables that really need to be global. I still hold hope to have each state machine in its own file - I think that would make the dependencies very clear. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>