Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Since the at91sam7s does support interupts, how come we never use it on device side?
Offline
The whole LF part is full of timers, or to be exact the need to do things on a precise moment.
Which would a candidate for interrupts, instead of having the code loop-wait at all places.
Simpler code? no?
WDT_Hit() were suggested by another user, or usb_poll.. which makes sense aswell.
The WDT_HIT is called or thrown in places where the time might take too long but still ok. This would make the device about more saver from resets but it also might get the device to loop indefinite. Pros and cons.
usb_poll as interrupt would open up the device to simpler control from clientside.
Offline
I did some experiments with interrupts some time ago. I didn't find it very usefull though. Usually there is nothing else to do when we are waiting e.g for a tag answer or a new command from client.
If you want to prevent resets from WDT, it would be easier to disable it. Using a timer interrupt would make it useless.
Offline
The WDT has it advantages when it comes to endless loops.
Offline
"Usually there is nothing else to do when we are waiting"
That's quite it and nothing more here. And when we are not waiting, we are often doing work where timing is critical enough not to have any interrupt of sort being something we want to deal with.
And still, if interrupts are somehow wanted to be used, it would even be better to rewrite the logic with a simple RTOS in mind, with still the same constraint of timings criticity which has since ever made the no-os option making everything easier.
For dealing with functions which actually needs physical "click" to the proxmark or which needs to wait for their own return before permitting communication, then you could just put a usb_polling at a point where an equivalent state machine would be best candidate as to be the _IDLE state, and may respond to such client need only when possible, like next iteration _IDLE state, and maybe by splitting answers every _IDLE iteration in order to avoid having influence on timings.
I tried but couln't think of such need where the interrupt or RTOS solution would have been positive result considering the benefits/costs balance.
Specialized builds can totally benefit from real RTOS and so on implementation, but still they would be just because of such specialization, and eventual needs to do something which should have been of client business but now standalone.
About the WDT_hit, you can go for the "ESP8266's Arduino's way" which is strange but works : Modify SpinDelay(); or equivalent to add a WDT_hit call from it, and make habit of a Spindelay(1); at end of loops or long tasks. You may use SpinDelayUs() as target for WDT_hit where 1ms is too much of a wait but still at end of the task.
This is the quick-n-dirty but very working way of dealing with WDT I first find out years ago and I'm still happy about it. When I suspect a loop candidate to a race-condition, then I just don't add the SpinDelay(1) or SpinDelayUs(1);
All I can see from an eventuel WDT disabling are Darkness and Misery.
Offline
@piwi do you still have any of your interrupts experiment code? I'm trying to get interrupts working, but not having much luck, if you could share an example or point to another interrupt example code for the at91sam7s?
thanks
Offline
After looking at the armcode, I belive LED- and button- control would be benifit from interrupt handling.
For newer revisions of proxmark3 with a different user-device interface than we have now.
Offline