What you say on his needs definitly makes sense, and so it makes my message absolutely out of the subject.
but still, it was quite a "concise" one, so I will left it here.
LEDS are usefull only for debuging what is not at anyhow being able to be seen by the client (before usb is enabled and working, for exemple) and as "Langage" to show the status if used in standalone mode. With 4 leds, it makes quite a lot of possibility for monitoring a standalone mode, but as said, when it comes in optimization and it gets too far, then leds are of no use.
This is your fault in part, by making piwi's implementation so easy to get working, matt indecence to have prepared needed standalone infrastructure, and last but not least, usb_disabled which is in long run an impressive changer, just as MFG_DBG_LEVEL_NONE. If you set tracelen and trace buffers to 0, destroy tracing infrastructure, because not needed at all in standalone if not to be saved on flash for further use, then you got something working too fast for even beeing real.
Try it Iceman, it's really that. I won't talk again about bigbuf, but if you get rid of these contraint and do a little work on DMA, It's something of Hollywoodian dream. Just get your local countries keys, which are always the same between 13.56Mhz supplyers in order to be less work for them to have central management and voila.
You have in hand a device which can emulate 95% of the Tag you will see in the street in near 2.5s from booting.
Edit : also get every function used to ram. Every one. Destroy any line which doesn't do a real useful thing in the process you want to be afraid of. Make it a 50kb rom. Fear of your own thing.
]]>I think that @OP meant with timing pins was to be used with a logical analyser, to trigger when it should start recording.
]]>If timing is to be done by proxmark for any reason, I think one of the known fork has leftovers with Tickers being reported with above or alike hooks, just a matter of choix for what is to be reported by adding the hook-report to relevant part of code.
Still it should be something simple to make for quick needs, or could be thought as a long-term improvement by providing an architecture reflecting such needs, which is a matter of choice.
Still I' can't really see what at this state could need anything more than a printed report for such timing needs.
Edit : Iceman1001, LEDs are not consistant trigger, as very same condition tends to have quite heavy difference for a same led into "shortest time to turn on&off" by itself, from 1 to more than 30ms, and more strange than that, more than 50ms of diffence in same conditon from led X to led Y, making the A/B/C/D leds being indicator in short loops very led-dependant.
As very good example I got just here is :
- if Matt's build of hf standalone is to be used
- with usb_disable
- AND your piwi's implementation for getting ChkKeys "faster" (euphemism)
Then it not only makes an incredible demonstration for education , but also that (in my device) B and D led impossible to use to report acurate report of next-sector found keys, as the leds get's to be OFF _before_ having time to get ON physically. Using A and C makes them 'slighltly being making a short red pixel" during the whole process, getting Neither really on or off with such fast loop.