使共享总线充当OR


10

如果您不耐烦,可以跳过背景。

背景

我正在编程一组与SPI通信的微控制器。有一个主n从共享总线。没有芯片选择。(这不是一个不好的设计,但是n很大,没有足够的空间容纳n多余的行)。

因此,从站有责任保持其MISO处于高阻抗状态,并且最多只有其中一个发言。通过仅在轮询其ID时进行响应才能完成此操作。

现在,我们希望有一个初始发现阶段,在此阶段,主节点会发现附加了ID的从节点。为了使生活更轻松(在某些方面),我们希望具有唯一的ID(因此,例如32位)。这样,主机就不可能简单地逐个轮询id并查看谁做出响应(存在太多可能性)。

为了解决这个问题,我设计了一种二进制搜索的变体,其中从站集体响应,而主站能够快速找到最小id。告知具有该ID的从站不再参与,算法重复执行。(细节不重要)。

不过有一个问题。集体响应必须是所有响应的逻辑或(或逻辑与)。有人告诉我,可以以MISO总线可以用作逻辑OR的方式配置线路。有人告诉我:

  • 将主机上的MISO设置为上拉和
  • 将每个从机上的MISO设置为漏极开路。

我已经尝试过了,但是即使只有一个从机,此配置也无法工作(示波器在行上显示恒定的零)。如果我在主设备上将MISO配置为高阻抗输入,则在示波器上可以看到电压下降到一半,这是两个从设备的输出位不同的地方(我认为基本上是短路)。

注意:在主机上将MISO配置为高阻抗,在从机上将其配置为推挽,即使同一总线上有许多MISO,我也可以分别与它们交谈。我的意思是,我怀疑这是生产线本身的问题。

我的问题是,是否完全可能,如果可以,如何配置主机和从机的输入和输出引脚,以使共享的MISO线充当逻辑或(或逻辑与)?


编辑

  1. 原来,它变成了具有负真逻辑(基本上是AND)的OR。

  2. 通过将1写入主机上的上拉引脚,可以解决单个从机的问题。以前它的初始状态为0。

编辑2

事实证明,ST从机将我的MISO GPIO配置改写为漏极开路,并在写入时强制将其拉高。我决定在这种特殊情况下手动使SPI静默并输出MISO。


我不想问,因为我确定您已经想到了,但是您是否考虑过使用I2C或CAN?它们是为n个设备设计的,而SPI实际上是为与每个设备的芯片选择一起使用而设计的。
Bob

@bob,是的。他们太慢了。无论如何,如果我的问题的答案是“不可能”,那么我们只需要做一些手工工作,但最终产品在SPI上仍然要好得多。
Shahbaz 2013年

1
遗憾的是您使用32位作为地址,因为如果您使用24位(16,772,216个变体),则可以发送“ discover”命令并等待16,772,216个时钟,并且可以获得所有从属信息。以10Mbps的速度将花费不到2秒的时间,而且不会产生冲突。嘿,你-我让我为此加+1。
安迪(aka Andy)2013年

@ Andyaka,24位也可能不错(但是32位肯定更好)。如果我对您的理解正确,那意味着每个从机在其id时钟响应为1,而主机查看哪个时钟生成一个时钟?不错,除了从站以字节为单位响应。因此,每个从站都以8位响应,除非我可以使总线充当OR,否则,一个从站的响应仍会在另一个从站的响应内“丢失”(一个从站的1会从所有从站中被下拉0)。其余的部分)。
Shahbaz 2013年

@Shahbaz如果您可以控制从站的代码,则可以将其设置为“特殊”,其中从站在其分配的时间仅响应1位。是的,你明白了我的主意。
安迪(aka Andy)

Answers:


5

Microchip的MCP23017芯片(和其他芯片)使用的是SPI-on-selected。这种方法没有错。

是的,您想要的是可能的,但是您必须使奴隶开漏。如果您不能让它们表现为漏极开路,则可以通过在每个输出端串联一个(肖特基)二极管来作弊。

您的枚举方法与Dallas单线总线用于枚举的方式以及CAN总线用于仲裁的方式相同。

但是这种方法的一个严重缺点是,速度现在受上拉电阻驱动的上升时间的限制。这将比由推挽输出驱动时要慢,并且可能会限制总线的运行速度。

如果每个从站上都有两个备用引脚,则可以将它们菊花链连接,并根据它们在菊花链中的位置制定枚举方案。


是的,我忘了提一提,我还被告知我需要降低速度(我的速度降低了20倍(从4Mpbs降至128Kbps))。虽然这是一个初始阶段,但是我的算法可以处理较慢的速度(仍然相当快)。不幸的是,我怀疑我们现在是否应该重新设计硬件。付出的代价不仅仅是简单地忽略此阶段,并告诉主机期望什么ID。
Shahbaz 2013年

回到问题,我已经将奴隶配置为漏极开路。我应该如何配置主机?
Shahbaz 2013年

1
除上拉电阻外,主机的MISO引脚上没有任何其他特殊要求。我怀疑采用上拉设计时您将达到128Kbps,但是YMMV。阅读一些深入的I2C文档可能会有所帮助,这是线或上拉总线,因此那里应用的所有技巧都可能对您有所帮助。
Wouter van Ooijen 2013年

非常感谢。我将尝试进一步降低总线速度,以了解发生了什么。我想我必须最终研究并了解这些上拉,开漏和其他实际含义。(这里是软件工程师!)
Shahbaz 2013年

1
将示波器放在总线上,然后检查会发生什么情况。上升时间可能太慢,但也可能会响起。
Wouter van Ooijen

4
  • 将主机上的MISO设置为上拉和
  • 将每个从机上的MISO设置为漏极开路。

我已经尝试过了,但是即使只有一个从机,此配置也无法工作(示波器在行上显示恒定的零)。

您需要检查上拉模式下主I / O引脚的等效电阻是多少。

通常,上拉模式具有很高的电阻,可能为50 kOhms或更高。这样做的目的是为了防止引脚因emi或其他噪声而出现毛刺,或者为非常慢的控制信号设置默认值,同时不要为此浪费太多功率。

正如Wouter所指出的,在漏极开路的总线中,速度受上拉电阻的限制。较高的电阻值会使总线变慢。I2C(获得100或400 kHz)的典型值为1-5 kOhms。您将需要类似的上拉电阻才能达到类似的速度。

我认为您需要使用一个外部上拉电阻(1至5 kOhms左右),而不是使用主机的I / O引脚上拉电阻才能使该方案正常工作。


感谢您的提示。我不是电子产品专家,但我必须请我的同事看看您的建议。我只需要有线或仅用于程序的初始阶段,而在正常阶段,该引脚未配置为上拉。因此,可能无法使用外部电阻。
Shahbaz 2013年

如果您在主微控制器上有一个空闲的I / O引脚,则可以通过5 kOhms将其连接到总线。然后在总线枚举期间将其调高,在正常通信期间将其调高至Z。
Photon 2013年

1

为了使有线和总线正常工作,总线上的节点需要开漏,即它们必须进行传输

  • 通过强烈下拉来降低逻辑电平,以及
  • 通过断开总线将逻辑高电平。

此外,必须弱上拉总线。

您在单个非发送主机和单个发送从机上看到的特殊行为可以通过主机强上拉或从机弱下拉来解释。

您需要确定上述情况正在发生。

使从机进入高阻模式,并通过10k电阻将总线接地。如果线路电压变化不大,则说明主电源正在上拉,您需要对其进行修复。否则,对从机执行相同的步骤(这次将电阻器连接至Vcc);如果线路电压显着上升,则从站将弱下拉(修复该问题)。否则,请在您周围的区域中寻找时空变形。


请原谅我对电子产品的无知,但是如果从属设备强烈下拉,这是否会使总线充当AND?我的意思是说,由于需要高电平的从机正在断开连接,而希望低电平的从机在下拉,因此总体结果是下降,不是吗?
Shahbaz 2013年

@Shahbaz,我不好,当然,这辆巴士会有线连接,而我确定了答案。如果要接线或,只需反转极性(主机弱拉,从机强拉)。
avakar 2013年

通过阅读维基百科,我意识到他们将其称为“有线和”或“有线或”或“否定-真”逻辑。
Shahbaz 2013年

1

我建议在总线上进行被动上拉或下拉(我假设为上拉),并让从属在有话要说时主动驱动总线(驱动高电平和驱动低电平),否则浮动它。具有带有地址和掩码的query-address命令,并根据其是否喜欢该地址和掩码,指示每个从站输出00或不执行任何操作(保持其输出浮空)。如果可能的话,在从机开始驱动总线之前,让主机主动将总线驱动为高电平。根据上拉强度以及主机是否将总线驱动为高电平,在允许从机将其拉低之前,可能有必要在设置阶段限制总线速度。另一方面,设置完成后,


如果两个从机主动驱动高电平和低电平,我期望从总线读取什么?
Shahbaz 2013年

一个人应该避免一个奴隶试图驱动高电平,而另一个奴隶则驱动低电平。从站仅应在以下情况下驱动总线:(1)知道这样做是唯一的,或者(2)知道从站并且其他所有正在驱动总线的人都将其驱动到被动空闲的对面州。
2013年

那是什么意思呢?...让每个选定的从机都主动驱动高电平和低电平,这将允许总线...
Shahbaz 2013年

@Shahbaz:当从站有话要说时,它应主动将总线驱动为高电平以发送“ 1”位,而为低电平则发送“ 0”位。当从机无话可说时,它根本不应该驱动总线。请注意,当从机要发送“ 1”位时主动将总线驱动为高电平将比依赖于被动上拉将总线驱动为高电平的速度快得多。
2013年

@Shahbaz:超级猫想说的是,在枚举状态下,电阻器应拉高线路,而从机仅应发送“ 0”或不发送任何信号(漏极开路输出),但是在正常通信之后,仅发送单个从站应同时处于活动状态,活动的从站应发送“ 0”或“ 1”(正常输出)。因此,上拉电阻和线路电容仅在枚举期间限制了比特率。此后,在正常通信中,如主动驱动所允许的,比特率可以更高。
Laszlo Valko 2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.