- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have a question around the timing of an internal interrupt to do an i2c read to return a 16bit value from a sensor.
My sensor has an interrupt which should fire every 1ms but due to a couple of variables it is not reliable so i have been told to poll the data.
The manufactures of my sensor recommend polling the data at 1.811Khz which means taking a reading every .552ms. I know my I2C read only takes up to max 100us so there should be no problem reading.
Is it possible to set up an internal interrupt to fire every 552us and to take an I2C? I need to only do this for 1 second so will end up having 1811 samples.
To make things easier i will not be connected to a BLE device when sampling the data.
I have been told this should be no bother as the MCU is cortex-m3.
Regards,
Luke.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
What is your sensor?
If your sensor has interrupt lines, you can have the sensor fire up interrupts whenever new data is available.
That way you only need to set up I2C interrupt on your BCM.
Or if your sensor has FIFO feature, then you can use FIFO to store the data and poll every second.
I think you asked a similar question before:
Increment timer on the BCM20737s
As for as I know, the minimum resolution of the timer that you can set up using the SDK is only 1.25ms. So I don't think you can set it up for 552us.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is a pressure sensor returning a 16 bit value over I2C.
My sensor does have an interrupt line but as I said earlier its not reliable (+-15%) and the output is not fixed. And the exact time of each sample is vital so this is not an option.
I need a way of polling the data in fixed intervals. I have set it up in a for loop with a delay to space out my reads to give me 1.811khz and it works but i feel this is not the best way to do. I know from my experience with stm32 mcu you can internal interrupt to call a function at fixed intervals.
I would like to try do it this way?
Luke.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As ehoffman previously suggested, the only feasible way to do this is to run an infinite loop, kicking the watchdog on every loop and breaking the loop on the appropriate end condition (some number of samples).
This is possible since you'll be out of connection at the time, but it's tough to say how the system will react to this afterward. If you store your data in NVRAM and do a soft reset, you'll probably be good to go. It shouldn't take long to write some code that does this--just sit in a loop for a couple seconds, break it and check the functionality of the BLE, SW timers, callbacks, etc.
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the watch dog disabled and not connected via bluetooth while i will be reading.
Id prefer not read my data by a for loop and a delay between each read to try set my sampling frequency.
Id like to do it by an internal interrupt so i know no matter what happens in the code my function will be called at the correct time and no matter what happenes on the i2c bus the time between each read will be fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Luke,
1. Nothing in the system can give you a 552uSec timer or periodic interrupt
2. We have a hw_timer.a patch that you could include in your make file, but I don't think you will be able to achieve the 552uS.
3. Also include the hw_timer.h located here:
4. The hw_timer_register_timer_expired_callback function will be called in the interrupt context but you must be careful where this callback is called.
5. It is a watchdog timer, so you will need to restart it everytime in the callback and if there are other interrupts pending, there may be a bit of jitter.
6. You have to disable tracing, no logging, nothing that will interfere with the interrupts.
7. You just use I2C, place it in some global variable and that's it.
8. But there is no guarantee that this will work.
Thanks
JT