完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
LIS3DH配置为当3轴中任何一个轴上的加速度值超过MCU设置的阈值时,使用INT1中断MCU。首先,据我所知,即使中断被触发,LID3DH也不会停止采样加速度数据(即使在流到fifo模式下,它也不会停止采样,直到fifo变满为止)。它是否正确?如果它是正确的,是否有一种很好的方法可以使加速度数据与触发中断的确切时间相对应?谢谢。
以上来自于谷歌翻译 以下为原文 The LIS3DH is configured to use INT1 to interrupt the MCU when the acceleration value on any of the 3 axis exceed the threshold that is set by the MCU. Firstly, as my understanding, the LID3DH does not stop sampling acceleration data even if the interrupt is triggered (even in stream-to-fifo mode, it does not stop sampling until the fifo gets full). Is this correct? If it's correct, is there a good way to get the acceleration data corresponds to the exact time when the interrupt is triggered? Thanks. |
|
相关推荐
11个回答
|
|
您的理解是正确的,并且stream-to-fifo模式恰好是用于此目的的正确模式。
FIFO内容将由触发事件之前收集的#30个样本,生成中断事件的样本和触发后的一个样本组成。 请查看应用笔记中的9.3.4章 http://www.st.com/content/ccc/resource/technical/document/application_note/77/ed/e7/e1/28/5a/45/d6/CD00290365.pdf/files/CD00290365.pdf/jcr:内容/翻译/ en.CD00290365.pdf 。 以上来自于谷歌翻译 以下为原文 You understanding is correct and the stream-to-fifo mode is exactly the right mode for the purpose. FIFO content will be composed of #30 samples collected before the trigger event, the sample that has generated the interrupt event and one sample after the trigger. Please check chapter 9.3.4 in the application note http://www.st.com/content/ccc/resource/technical/document/application_note/77/ed/e7/e1/28/5a/45/d6/CD00290365.pdf/files/CD00290365.pdf/jcr:content/translations/en.CD00290365.pdf . |
|
|
|
谢谢回复。我的理解有点不同。在AN3308中,它描述了关于stream-to-fifo模式的以下内容:
因此,据我所知,如果案例2发生,我们仍然无法知道触发器数据在fifo中的位置。对? 那么我是否必须读回fifo中的所有32个数据样本并与我设置的阈值进行比较? fifo中超过阈值的第一个样本是触发数据。 以上来自于谷歌翻译 以下为原文 Thanks for the reply. My understanding is a bit different. In AN3308, it describes following about the stream-to-fifo mode: So as my understanding, if the case 2 happens, we are still not able to know where in the fifo the trigger data is. Right? So do I have to read back all the 32 data sample in the fifo and compare to the Threshold I set? The first sample in the fifo that exceed the threshold is the trigger data. |
|
|
|
您是对的,在第2种情况下,您需要确定哪个样本对应于中断,并且您必须将每个样本与阈值进行比较。但是这种情况只有在你开始测量时才会发生,在32个样本之后FIFO将满,而案例1将会发生。
以上来自于谷歌翻译 以下为原文 You are right, in case 2 you want be sure which sample corresponds to the interrupt and you have to compare each sample with threshold. But this case can happen only when you start your measurement, after 32 samples the FIFO will be full and case 1 will happen. |
|
|
|
谢谢回复。因此案例2只在初始状态下发生一次。大多数情况下都是1。
正如AN3308描述的那样,当fifo已满时,它会在触发后停止收集第一个样本的数据,因此触发中断的数据应为F [30]。但是当我在MCU中断时从lis3de读出32个数据(此时fifo应该已满,因为我等待足够的时间)并将数据与阈值进行比较,结果发现触发数据始终为F [ 26。为什么?我正在使用lis3de作为传感器。 以上来自于谷歌翻译 以下为原文 Thanks for the reply. So case 2 just happens once in the initial state. Most cases it's case 1. As AN3308 describes, when the fifo is full, it stop collecting data at first sample after the trigger, so the data that trigger the interrupt should be at F[30]. But when I read out the 32 data from lis3de when the MCU is interrupted (the fifo should be full at this time because I wait for enough time) and compare the data with the threshold, it turns out the trigger data is always at F[26]. Why? I'm using lis3de as the sensor. |
|
|
|
中断的DURATION设置是什么?
这可以解释为什么在FIFO样本26处已经达到触发,但是在DURATION样本数量超过阈值之后触发了中断。 以上来自于谷歌翻译 以下为原文 What is your DURATION settings for the interrupt? This could explain why the trigger was reached already at FIFO sample 26, but the interrupt was triggered after DURATION number of samples exceed the threshold. |
|
|
|
我的持续时间是5.现在我完全明白了。非常感谢你。
以上来自于谷歌翻译 以下为原文 My duration is 5. Now I completely understand. Thank you very much. |
|
|
|
还有一个问题:如果持续时间设置大于31,该怎么办?我的假设是fifo将包含触发数据的最后31个样本和触发后的1个样本样本。我对吗?
以上来自于谷歌翻译 以下为原文 One more question: What if the duration setting is larger than 31? My assumption is the fifo will contain the last 31 samples of the trigger data and 1 samples of the sample after the trigger. Am I right? |
|
|
|
|
|
|
|
弹出更多问题。 Stream-to-Fifo模式的典型用例是通过将fifo设置为旁路模式并将其设置回Stream-to-Fifo模式来刷新fifo。如果我们不这样做,fifo将保持满,不能再存储数据。在测量期间,此操作将经常发生。如果在刷新fifo后触发器足够快,则会发生情况2。因此案例2并不罕见,我们不应将案例2视为特例。我对吗?
以上来自于谷歌翻译 以下为原文 More question pops up. A typical use case for Stream-to-Fifo mode is to flush the fifo by setting it to bypass mode and set it back to Stream-to-Fifo mode. If we do not do this, the fifo will be kept full and can no longer store data. This operation will happen frequently during the measurements. If the trigger comes quick enough after the fifo is flushed, case 2 will happen. So case 2 is not that rare and we should not treat case 2 as a special case. Am I right? |
|
|
|
这实际上取决于你的应用程序,如果你认为在刷新FIFO后中断很快就会出现,你还要注意案例2。
以上来自于谷歌翻译 以下为原文 It really depends on you application, if you think the interrupt can come quickly after FIFO is flushed you have to take care also the case 2. |
|
|
|
谢谢回复。
它不一定是一个足够快的不同触发器可能导致情况2.如果原始触发持续足够长时间并且中断被锁存到该触发器,则触发器实际上将导致多于1个中断。一旦第一个中断被解锁,第二个中断就会到来。 您的芯片设计团队是否考虑将触发器索引存储在寄存器中的fifo缓冲区中?例如,如果触发中断的数据存储在fifo [11],fifo [12],fifo [13](持续时间设置为3),则该寄存器中的触发索引设置为11。这对应用程序来说更容易确定触发器数据。 以上来自于谷歌翻译 以下为原文 Thanks for the reply. It's not necessarily a different trigger that comes quickly enough can cause case 2. If the original trigger last long enough and the interrupt is latched for that trigger, the trigger will actually cause more than 1 interrupt. Once the first interrupt is unlatched, the second interrupt will come. Have your chip design team consider store the trigger index at the fifo buffer in a register? For example, if the data that trigger the interrupt is stored at fifo[11],fifo[12],fifo[13] (duration set to 3) the trigger index is set to 11 in that register. That would be easier for the application to determine the trigger data. |
|
|
|
只有小组成员才能发言,加入小组>>
请教:在使用UDE STK时,单片机使用SPC560D30L1,在配置文件怎么设置或选择?里面只有SPC560D40的选项
2738 浏览 1 评论
3241 浏览 1 评论
请问是否有通过UART连接的两个微处理器之间实现双向值交换的方法?
1810 浏览 1 评论
3650 浏览 6 评论
6039 浏览 21 评论
1339浏览 4评论
201浏览 3评论
对H747I-DISCO写程序时将CN2的st-link复用为usart1,再次烧录时无法检测到stlink怎么解决?
353浏览 2评论
STM32G474RE芯片只是串口发个数据就发烫严重是怎么回事?
444浏览 2评论
STM32处理增量式编码器Z信号如何判断中断是正转的还是反向转的?
275浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-25 08:44 , Processed in 1.417445 second(s), Total 96, Slave 80 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号