After ordering the break out board from Embedded Adventures in the UK, I got a nice email indicating that they would ship to me via stock held in the USA. The email also included some sample code for a PIC.
I started to look at the code today. Even though the interface is fairly simple, the sample code had precious few comments. So I went through and commented the code as I followed along with the data sheet. I find this process to be soothing as well as educational. And that is when I found a real nasty ‘feature’ of the chip. One must wait an excruciating long 2 milliseconds AFTER the hardware interrupt pin toggles before you can read the interrupt service register telling you why the interrupt occurred!
What sort idiocy is this? When an interrupt occurs, the interrupt service routine should be able to read the register to indicate why the interrupt occurred, not have to wait 2 milliseconds to find out the reason. It TOTALLY defeats the reason for having an interrupt in the first place. Why not just poll at a 2 ms rate? The firmware engineer that dreamed this up should be shot drawn and quartered.
The best workaround I can think of is to set a flag and get the current time in the ISR, add two milliseconds to it and store that as a target time. Now in the mail loop if the flag is set and the current time has exceeded the target time, then read the reason for the interrupt and process appropriately. What a idiotic piece of stinking garbage. I sure hope the rest of the chip is better designed.
Just to be clear, I have no issues with the break out board made by Embedded Adventures. I do have serious issues with the nut cases at Austria Micro Systems that designed the chip. If you have ever seen the rant Dave Jones of EEVBlog did on the PicKit3, then you have some idea how I feel about the AS3935.
Edit 2/5/2013: The more I think about this, the more the datasheet must be in error. There are numerous translation errors (not as bad as some) from this Austrian company. So I have sent a question to the application engineer looking for a comment. We will see.
Edit 2/6/2013: Sadly the 2 millisecond limitation was confirmed by the vendor. The reply I got did not seem to grasp the significance of this limitation. They indicate that the lightning signal is slow and they need the 2ms to classify it as noise or as a strike. They did not seem to consider that they should just hold off notification till they had finished the classification. Oh well. This will just force unnecessary complication to the software design and increased power consumption.