We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi there,
This may be a compiler/driver issue or it may be a hardware issue but I am wondering if anyone else has seen a similar problem to this.
We have code to read an ADC channel and this works fine. We have code to generate timer interrupts and handle CAN communications and this works fine.
However, when we call the ADC channel read from inside a timer interrupt (timer1, specially used just for this) it appears to completely screw up the CAN transmission. We get transmission on odd channels, bad data, all sorts.
Before I post lots of code as each system is quite complex, has anyone ever heard of this or a similar problem ? I have checked all the 89C51 errata sheets and gone through the assembly code produced by the Kiel and nowhere does there seem to be any connection between the two. Even with the ADC read in the interrupt it only occupies 2% of the processor time so I don't think it's to do with load or latency. I have made sure the ADC interrupt is off so it doesn't create an interrupt within an interrupt.
Thanks for any help,
Dirk
It is unwise to make function calls from an interrupt to code that is used outside the interrupt. They are likely to use separate stack space last I checked. These are CO Routines you need to consider the PC term "thread safe" you should call only functions in the interrupt that are used only by the interrupt. Data is the only thing to consider outside them. Even then the data should only be accessed when a semaphore is set.
Stephen
Thanks Stephen,
However I don't think this applies here. We only call the ADC read function once, and this is from inside the timer interrupt. I have called it from other places to test if it works in those situations and also in other products it is called outside of the timer.
As the Kiel and the 89C51 are not the best at multi threaded operation we avoid it completely and don't allow multiple calls as you pointed out.
As it is at the moment I am not even bothering with the data read form the ADC as I want to crack as to why even accessing the ADC screws the CAN up.
Anyway, thanks for the interest. Any help is appreciated.