读取DS1683 Elapsed Timer ETC寄存器时出现问题

嗨本，
这是DS1682还是DS1683？
我目前在办公桌上没有那个I / C.
看看这个python库：   
GitHub上   
mrmikee /蟒-DS1682
python-ds1682  - 使用Adafruits I2C python库的DS1682 Elapsed Time Counter芯片的Python类        
github.com   
mrmikee /蟒-DS1682 /斑点/主/ DS1682.py＃L77-L85
def readRawETC（self）： 
“从IC读取ETC数据” 
self._etc_low = self.i2c.readU8（self .__ DS1682_ETC_LOW） 
self._etc_low_mid = self.i2c.readU8（self .__ DS1682_ETC_LOW_MID） 
self._etc_high_mid = self.i2c.readU8（self .__ DS1682_ETC_HIGH_MID） 
self._etc_high = self.i2c.readU8（self .__ DS1682_ETC_HIGH） 
if（self.debug）： 
self.showETCData（） 
回来（self._etc_high      
看起来好像需要以8位增量读取ETC。
问候，



以下为原文

        Hi Ben,
Is this the DS1682 or DS1683? I don’t have that I/C at my desk at the moment.
Looking at this python library:
              GitHub        mrmikee/python-ds1682

python-ds1682 - Python Class for DS1682 Elapsed Time Counter chip using Adafruits I2C python library
                        github.com        mrmikee/python-ds1682/blob/master/DS1682.py#L77-L85

• def readRawETC(self):
  
•   "Reads the ETC data from the IC"
  
•   self._etc_low = self.i2c.readU8(self.__DS1682_ETC_LOW)
  
•   self._etc_low_mid = self.i2c.readU8(self.__DS1682_ETC_LOW_MID)
  
•   self._etc_high_mid = self.i2c.readU8(self.__DS1682_ETC_HIGH_MID)
  
•   self._etc_high = self.i2c.readU8(self.__DS1682_ETC_HIGH)
  
•   if (self.debug):
  
•     self.showETCData()
  
•   return (self._etc_high << 24) + (self._etc_high_mid << 16) + (self._etc_low_mid << 8) + self._etc_low
  

                It looks as though ETC needs to be read in 8 bit increments.
Regards,

这是DS1683。
谢谢 - 本



以下为原文

        It is DS1683.  Thanks – Ben

DS1683.pdf
1019.47 KB
ETC寄存器是一个带阴影的EEPROM寄存器，包含累加的寄存器
时间以250ms为增量，EVENT引脚保持高电平。
上电时，
在EVENT引脚的每个上升沿，以及I2C写入ETC寄存器后，
来自阴影EEPROM位置的值被加载到ETC计数器中
存储器（SRAM）。
当EVENT引脚为高电平时，就是这个SRAM存储器
每250ms递增一次。
在EVENT引脚的下降沿，这个
然后将SRAM存储器中的值写入阴影EEPROM存储器
以250毫秒为增量存储累计时间。
0x0C / 0x0C需要很长时间才能显示任何内容（大约250ms * 2 ^ 16）......
使用i2cget，您只能进行注册访问：
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0A b
0x5c
root @ beaglebone：〜＃i2cget -f -y 1 0x6b 0x0B b
为0x00
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0C b
为0x00
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0D b
为0x00
但你可以使用i2cdump：
root @beaglebone：〜＃i2cdump -y -r 0x0A-0x0D 1 0x6b c 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：5c 00 00 00  ...
问候，



以下为原文

        DS1683.pdf

1019.47 KB

The ETC register is a shadowed EEPROM register that contains the accumulatedtime in 250ms increments that the EVENT pin has been held high. On power-up,on every rising edge of the EVENT pin, and after an I2C write to the ETC register,the value from the shadowed EEPROM location is loaded into the ETC countermemory  (SRAM). When the EVENT pin is high, it is this SRAM memory thatis incremented once every 250ms. On the falling edge of the EVENT pin, thisvalue in SRAM memory is then written to the shadowed EEPROM memoryto store the accumulated time in 250ms increments.It’ll take a long time for 0x0C/0x0C to show anything (somewhere around 250ms * 2^16)…
with i2cget you can only do register access:
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0A b0x5croot@beaglebone:~# i2cget -f -y 1 0x6b 0x0B b0x00root@beaglebone:~# i2cget -f -y 1 0x6b 0x0C b0x00root@beaglebone:~# i2cget -f -y 1 0x6b 0x0D b0x00But you can use i2cdump:
root@beaglebone:~# i2cdump -y -r 0x0A-0x0D 1 0x6b c     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               5c 00 00 00                    ...  Regards,

谢谢你的信息。
我非常感谢您的帮助和回应。
但是，我仍然坚持这个问题。
我计算低位两个字节的滴答计数应该每4.5小时翻转一次：
2 ^ 16 = 65536
65536 * 250 = 16384000毫秒
16384000/1000 = 16384秒
16384/3600 =约4.5小时
我可以通过定期读取芯片来看到这种情况。
不幸的是，当发生翻转时，两个高位字节中没有任何内容递增（它们始终保持为零）：
i2cget -f -y 1 0x6b 0x0A b
0x25
i2cget -f -y 1 0x6b 0x0B b
0x6c
i2cget -f -y 1 0x6b 0x0C b
为0x00
i2cget -f -y 1 0x6b 0x0D b
为0x00
此外，我使用了i2c诊断适配器（Aardvark I2C主机适配器）并产生了相同的结果。
该适配器直接连接到i2c总线，充当总线主控器，绕过Linux和Linux i2c驱动程序。
我不知道发生了什么事。
我的配置寄存器可能设置错误吗？
这是我的寄存器的转储：
i2cget -y 1 0x6b 0 b命令
为0x00
i2cget -y 1 0x6b 1 b状态
0×04
i2cget -y 1 0x6b 2 b PWE
为0x00
i2cget -y 1 0x6b 3 b PWE
为0x00
i2cget -y 1 0x6b 4 b PWE
为0x00
i2cget -y 1 0x6b 5 b PWE
为0x00
i2cget -y 1 0x6b 6 b RSVD
为0x00
i2cget -y 1 0x6b 7 b RSVD
为0x00
i2cget -y 1 0x6b 8 b EVENT REG
为0x00
i2cget -y 1 0x6b 9 b EVENT REG
为0x00
i2cget -y 1 0x6b a b ETC REG BYTE 0（注意非零）
为0x1F
i2cget -y 1 0x6b b b ETC REG BYTE 1（注意非零）
×03
i2cget -y 1 0x6b c b ETC REG BYTE 2（始终读为0）
为0x00
i2cget -y 1 0x6b d b ETC REG BYTE 3（始终读为0）
为0x00
i2cget -y 1 0x6b e b RSVD
为0x00
i2cget -y 1 0x6b f b RSVD
为0x00
i2cget -y 1 0x6b 0x10 b EVENT COUNTER ALARM LIMIT BYTE 0
为0x00
i2cget -y 1 0x6b 0x11 b EVENT COUNTER ALARM LIMIT BYTE 1
为0x00
i2cget -y 1 0x6b 0x12 b ETC ALARM LIMIT BYTE 0
为0x00
i2cget -y 1 0x6b 0x13 b ETC ALARM LIMIT BYTE 1
为0x00
i2cget -y 1 0x6b 0x14 b ETC ALARM LIMIT BYTE 2
为0x00
i2cget -y 1 0x6b 0x15 b ETC ALARM LIMIT BYTE 3
为0x00
i2cget -y 1 0x6b 0x16 b CONFIG
为0x00
i2cget -y 1 0x6b 0x17 b PWV BYTE 0
为0x00
i2cget -y 1 0x6b 0x18 b PWV BYTE 1
为0x00
i2cget -y 1 0x6b 0x19 b PWV BYTE 2
为0x00
i2cget -y 1 0x6b 0x1a b PWV BYTE 3
为0x00
谢谢 - 本



以下为原文

        Thanks for the information. I really appreciate your help and responsiveness. However, I’m still stuck on this issue. I calculate that the tick count in the low order two bytes should roll-over around every 4.5 hours:
2^16 = 65536
65536 * 250 = 16384000 ms
16384000/1000 = 16384 seconds
16384/3600 = around 4.5 hours
I can see this happen by periodically reading the chip. Unfortunately, when the rollover occurs, nothing is incremented in the two high-order bytes (they always remain zero):
i2cget -f -y 1 0x6b 0x0A b

0x25
i2cget -f -y 1 0x6b 0x0B b

0x6c
i2cget -f -y 1 0x6b 0x0C b

0x00
i2cget -f -y 1 0x6b 0x0D b

0x00
Also, I used an i2c diagnostic adaptor (Aardvark I2C Host Adapter) and produced identical results. This adapter connects directly to the i2c bus and acts as the bus master, bypassing Linux and the Linux i2c driver.
I don’t know what’s going on. Could my configuration registers be set wrong?
Here is a dump of my registers:
i2cget -y 1 0x6b  0 b  COMMAND

0x00
i2cget -y 1 0x6b  1 b  STATUS

0x04
i2cget -y 1 0x6b  2 b  PWE

0x00
i2cget -y 1 0x6b  3 b  PWE

0x00
i2cget -y 1 0x6b  4 b  PWE

0x00
i2cget -y 1 0x6b  5 b  PWE

0x00
i2cget -y 1 0x6b  6 b  RSVD

0x00
i2cget -y 1 0x6b  7 b  RSVD

0x00
i2cget -y 1 0x6b  8 b  EVENT REG

0x00
i2cget -y 1 0x6b  9 b  EVENT REG

0x00
i2cget -y 1 0x6b  a b  ETC REG BYTE 0 (note non-zero)

0x1f
i2cget -y 1 0x6b  b b  ETC REG BYTE 1 (note non-zero)

0x03
i2cget -y 1 0x6b  c b  ETC REG BYTE 2 (always reads as zero)

0x00
i2cget -y 1 0x6b  d b  ETC REG BYTE 3 (always reads as zero)

0x00
i2cget -y 1 0x6b  e b  RSVD

0x00
i2cget -y 1 0x6b  f b  RSVD

0x00
i2cget -y 1 0x6b  0x10 b EVENT COUNTER ALARM LIMIT BYTE 0

0x00
i2cget -y 1 0x6b  0x11 b EVENT COUNTER ALARM LIMIT BYTE 1

0x00
i2cget -y 1 0x6b  0x12 b ETC ALARM LIMIT BYTE 0

0x00
i2cget -y 1 0x6b  0x13 b ETC ALARM LIMIT BYTE 1

0x00
i2cget -y 1 0x6b  0x14 b ETC ALARM LIMIT BYTE 2

0x00
i2cget -y 1 0x6b  0x15 b ETC ALARM LIMIT BYTE 3

0x00
i2cget -y 1 0x6b  0x16 b CONFIG

0x00
i2cget -y 1 0x6b  0x17 b PWV BYTE 0

0x00
i2cget -y 1 0x6b  0x18 b PWV BYTE 1

0x00
i2cget -y 1 0x6b  0x19 b PWV BYTE 2

0x00
i2cget -y 1 0x6b  0x1a b PWV BYTE 3

0x00
Thanks – Ben

我从你之前的帖子中注意到你似乎遇到了我所看到的相同问题（即你的高阶两个字节为零：
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0A b
0x5c
root @ beaglebone：〜＃i2cget -f -y 1 0x6b 0x0B b
为0x00
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0C b
为0x00
root @beaglebone：〜＃i2cget -f -y 1 0x6b 0x0D b
为0x00
但你可以使用i2cdump：
root @beaglebone：〜＃i2cdump -y -r 0x0A-0x0D 1 0x6b c
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：5c 00 00 00 ...
低位两个字节应该每4.5小时滚动一次（参见我之前的帖子）。
我错过了什么吗？
谢谢 - 本



以下为原文

        I noticed from your previous post that you appear to have the same issue that I’m seeing (i.e., your high order two bytes are zero:
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0A b
0x5c
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0B b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0C b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0D b
0x00
But you can use i2cdump:
root@beaglebone:~# i2cdump -y -r 0x0A-0x0D 1 0x6b c
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               5c 00 00 00                    …
The low-order two bytes should be rolling over every 4.5 hours (see my previous post). Am I missing something?
Thanks – Ben

嘿罗伯特，我仍然有我之前的帖子中描述的问题。
而且看起来你重新制作了它;
在你的帖子中显示时间寄存器的i2cget（0xA-0xD），高位字节（0xC和0XC）为零。
请帮我解决这个问题。
谢谢 - 本



以下为原文

        Hey Robert, I still have the issue described in my previous posts. Further it looks like you re-produced it; in your post showing an i2cget of the time registers (0xA-0xD) the high order bytes (0xC and 0XC) were zero. Please help me resolve this issue.
Thanks – Ben

嗨本，
我在记录时让它运行了一段时间，它包裹得很好：
太阳10月22日14:14:54 UTC 2017 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：e6 ff 00 00？...
太阳10月22日14:14:59 UTC 2017 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：fa ff 00 00？...
太阳10月22日14:15:04 UTC 2017 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：0e 00 01 00？。？。
Sun Oct 22 14:15:09 UTC 2017 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：22 00 01 00“。？。
Sun Oct 22 14:15:14 UTC 2017 
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00：37 00 01 00 7。？。
没有更改DS1683的默认配置。
＃！/斌/庆典
而真实;
做日期;
i2cdump -y -r 0x0A-0x0D 1 0x6b c;
睡5;
DONE
问候，



以下为原文

        Hi Ben,
I left it running for awhile while logging, it wrapped just fine:
Sun Oct 22 14:14:54 UTC 2017     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               e6 ff 00 00                    ?...Sun Oct 22 14:14:59 UTC 2017     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               fa ff 00 00                    ?...Sun Oct 22 14:15:04 UTC 2017     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               0e 00 01 00                    ?.?.Sun Oct 22 14:15:09 UTC 2017     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               22 00 01 00                    ".?.Sun Oct 22 14:15:14 UTC 2017     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef00:                               37 00 01 00                    7.?.No changes to the DS1683’s default configuration.
#!/bin/bashwhile true;do date ; i2cdump -y -r 0x0A-0x0D 1 0x6b c ;sleep 5;doneRegards,