i need help. We would like to implement the ADS1000 in our new design which will be controlled by an embedded linux controller.
Therefore i would like to know if for ADAS1000 a newer driver exists? The old one is not usable with the kernel 4.9.52. A lot of error messages are created when the build process is started (unknown functions and data structures).
I appreciate any help.
We have this driver in an old branch:
You could try to use it.
I am not sure how it works with newer kernels, it would require some testing.
I remember I tried to patch it onto a newer kernel and it applied.
But I did not find any time to test it.
We've implemented with success the driver for adas1000, but its generate a heavy system load. We look now for the reason for this.
It's a bit hard to say just from looking at the driver.
Heavy system load is also relative to the performance of the device.
If the CPU is not powerful, it looks heavy.
But maybe, what you need to do is to check if the interrupts are being used.
If they are being used, check if there are interrupt storms.
The driver seems to be able to operate with and without interrupts.
Without interrupts, it's a polling mechanism somewhere in IIO; and on lower performance systems this can cause heavy loads.
You are right, in our application we use interrupts. And indeed there where we expect 1 interrupt we receive 3. We try to understand why this occur.
One question, do you've used ADAS1000 with Linux? The problems we have persist and we have no idea at the moment how to continue with this issue.
Unfortunately, we don't use the ADAS1000 Linux driver that much.
It was written many years back on top of a Blackfin processor board.
Maybe try to ask about the interrupts on the product subforum.
Maybe this one?
[ I am not sure about all the subforums yet].
But in general, interrupts storms can happen if the interrupt is not quickly/properly acknowledged.
Basic theory of operation for interrupts, is:
1. a device will issue an interrupt
2. the host system will quickly acknowledge it (usually just set a bit in some register)
3. optionally, interrupts will be disabled [for this device] to do some processing, and since this processing can take a while, interrupts shouldn't fire until processing is finished
4. do processing while there is data to process; in cases where the data is still coming in (even though interrupts aren't firing anymore), the processing can continue longer on a system-thread routine
5. when no more processing, re-enable interrupts