您推荐使用 SunSPOT 的 TTL、SPI 或 I2C
我开始尝试与一些支持以下协议 TTL、SPI 或 I2C 的外部组件（Skyetek M1 Mini 或 M1 RFID 扫描仪）连接。 我想知道您会推荐其中哪一条路线。 现场运行的应用程序需要大量处理时间（连续运行的手势匹配算法）并且资源相当昂贵。
有关该主题的任何链接或来源将不胜感激。
我发现的有用链接：
TTL：
谢谢您帮助。
编辑：
如果它对我尝试连接的设备有帮助，则为 Skyetek M1 和 M1 迷你 。 平台/CPU 是 Sun SunSPOT。
I am starting to try to interface with some external components (Skyetek M1 Mini or M1 RFID scanner) than supports the following protocols TTL, SPI or I2C. I am wondering which one of these routes you would recommend. The app that is running on the spot needs alot of processing time (a continuously running gesture matching algorithm) and is fairly resource expensive.
Any links or sources on the topic would be greatly appreciated.
Helpful links I found:
TTL:
- Function Listing including those for
UART control. - Does not seem to have good buffer control according to this
Thanks for your help.
Edit:
If it helps the device I am trying to interface with is the Skyetek M1 and M1 mini. The platform/CPU is the Sun SunSPOT.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
TTL 是指 UART（外围设备自动接收/发送串行流）还是 bitbanging（手动设置/重置/切换位）？
我可能会推荐 SPI。 这是一个相对简单的协议，在主控端，如果有必要，您可以对其进行位操作。 （但使用内置 SPI 外设要容易得多。）SPI 主机发出一条时钟线 (SCLK) 和一条数据线（MOSI = 主出从入），其中数据位在指定的时钟沿有效线; 它从从机接收数据线（MISO = 主输入从输出），其中数据位在时钟线的指定边沿有效。 如果您有多个从机，该技术通常是为每个从机配备一条片选 (CS) 线； 如果 CS 为低电平，则相关从机处于活动状态，否则它应该忽略时钟/数据信号并且不会干扰 MISO 线。 SPI 很简单，如果您的微控制器输出端口引脚短缺并且您需要一些额外的引脚，那么 SPI 甚至可以与 HC594 或 HC595 输出寄存器配合使用（将 MOSI 连接到 SER，将 SCLK 连接到 SCK，将 CS 连接到 RCK）。 如果您有超过 3 个 SPI 设备，请考虑使用 HC138 作为解码器，从一组地址位生成各个设备 CS 线，并从微处理器生成主芯片选择线。 （因为一次只有一条 CS 线应该为低电平）
I2C 是一种痛苦。 它的主要优点是，您可以通过在一堆外围设备之间共享的 2 条线（+ 电源和地线）来完成所有操作。 但你必须处理地址争用和许多其他问题。 它也比 SPI 慢，并且具有开路集电极线，因此其功耗 + 抗噪性与您使用的上拉电阻（或电流源）有关。
UART 可能是最快的解决方案。 SPI 具有与往返传播时间相关的速度限制，因为双方使用相同的时钟信号。 （信号路径 = 主设备更改 SCLK 引脚，从设备看到它并通过更改 MISO 引脚进行响应，然后主设备在下一个 SCLK 边沿使用 MISO 信号，因此来自从设备的信号此时应该已到达）在 UART 中，传入和传出的比特流是独立的，延迟并不意味着吞吐量会降低，除非高级协议是 UART 端点 A 向 UART 端点 B 发送命令，等待 B 响应，然后发送下一个命令。 真正快速的串行流应考虑使用 LVDS 来保持信号完整性。 但与 SPI 相比，解析 UART 字节有点痛苦； 在 SPI 中，有明显分隔的数据包，而在 UART 中，您处理的是无分隔的串行流，任何分包都必须通过解析数据本身来完成。
编辑：UART 的另一个优点是，有时处理器可以自动处理大型发送/接收缓冲区，以便您的程序可以对要发送的一大堆字节进行排队，然后在您认为需要时解析一堆接收到的字节喜欢它。 硬件可以处理发送/接收每个单独字节的即时性，并使您的程序不必担心程序在执行其他操作时丢失到达的单个字节。
By TTL do you mean UART (where a peripheral receives/ sends out a serial stream automatically) or bitbanging (where you manually set/reset/toggle bits)?
I would probably recommend SPI. It's a relatively easy protocol, and on the master side, if you have to, you can bit-bang it. (But much easier to use built-in SPI peripherals.) The SPI master sends out a clock line (SCLK) and a data line (MOSI = master out slave in), where the data bits are valid on a designated edge of the clock line; it receives a data line (MISO = master in slave out) from the slave where the data bits are valid on a designated edge of the clock line. If you have multiple slaves, the technique is usually to have one chip select (CS) line for each slave; if CS is low then the slave in question is active, otherwise it's supposed to ignore the clock/data signals and not disturb the MISO line. SPI is simple and will even work with an HC594 or HC595 output register (tie MOSI to SER, SCLK to SCK, CS to RCK) if your microcontroller is short on output port pins and you need a few extra ones. If you have more than 3 SPI devices, consider using an HC138 as a decoder to produce the individual device CS lines from a set of address bits and a master chip select line from the microprocessor. (since only one CS line is supposed to be low at a time)
I2C is a pain. Its main advantage is that you can do everything in 2 wires (+ power and ground) shared among a bunch of peripherals. But you have to handle address contention and a bunch of other things. It's also slower than SPI and has open-collector lines so its power consumption + noise immunity are related to what you use where for pullup resistors (or current sources).
A UART can be the fastest solution. SPI has a speed limitation related to the round-trip propagation time, since both sides use the same clock signal. (signal path = master changes SCLK pin, slave sees it and responds by changing MISO pin, then master uses MISO signal on the next SCLK edge so the signal from the slave should have arrived by then) In a UART, the incoming and outgoing bitstreams are independent, and latency doesn't mean your throughput is reduced unless the high-level protocol is for UART endpoint A to send a command to UART endpoint B, wait for B to respond, and then send the next command. Really fast serial streams should consider using LVDS to maintain signal integrity. But parsing UART bytes is kind of a pain compared to SPI; in SPI there are distinctly delimited packets, whereas in UARTs you are dealing with an undelimited serial stream and any packetizing has to be done from parsing the data itself.
edit: one other plus with a UART, is that sometimes the processor can automatically handle large send/receive buffers, so that your program can queue up a big glob of bytes to be sent, and then parse a bunch of received bytes when you feel like it. The hardware can handle the immediacy of sending/receiving each individual byte, and frees your program from worrying about missing individual bytes that arrive when your program is doing something else.
杰森的回答更详细，但我想我应该补充一下我的简短经验。
我使用了 SkyTek M1 Micro RFID 读/写模块，通过 TTL 连接到 BASIC Stamp。 我从来没有遇到过任何问题，而且设置比我选择 I2C 时要简单得多。
它只需要微控制器按照 SkyeTek 协议发送简单的串行 TTL 命令。 我在面包板上安装并运行了大约 5 分钟。
Jason's answer is a lot more detailed, but I thought that I'd add my brief experience.
I used a SkyTek M1 Micro RFID read/write module connected to a BASIC Stamp over TTL. I never had any problems, and the set up was a lot more simple than it would have been had I chosen I2C.
It just requires the microcontroller to send simple serial-TTL commands, following the SkyeTek protocol. I had it set up and working in about 5 minutes on my breadboard.