Embedded Hardware Complexity

This section aims to identify the hardware requirements imposed by a chosen communication protocol. We will discuss the resulting embedded designs considering: 1) physical integration ease; 2) power consumption; 3) extensibility; 4) flexibility; and 5) computational resources.

• HaldunKomsuoglu (26 Aug 2003) - Those MCUs that offer USB interface are of large form factor (large number of pins and big package) with high power consumption. Such solutions are good where the task is complex and require many peripheral interfaces. However, it is quite plausible that there will be things that are physically displaced at far corners of the robot with very simple requirements. One solution is to utilize an existing unit for the job but the added cabling can be a problem. Adding a new module is even more problematic where the physical integration of the large chip and required USB cabling will surely borther somebody for sometime. On the other hand, I2C? based solution allows one to utilize very simple small chips as well as very powerful large ones making it a very flexibile solution for any task.

• • ShaiRevzen (26 Aug 2003) - as you have previously noted, I2C? is the "lowest common denominator" implemented by almost all MCUs. In those cases where a really dumb MCU is required to handle some remote sensor, you can always wire it by I2C? to the nearest remote node, and from there multiplex it as a pipe over USB.

• • • HaldunKomsuoglu (27 Aug 2003) - You must agree that this kind of an approach would immensely complicate the hardware structure where I2C? and USB and their respective controllers are all mixed together. In this setting with every new addition you will not only need to do some redesign of your remote nodes to support I2C? which would increase the complexity of bith circuit as well as firmware. I would much rather like to see a uniform solution across the robot where no two remote node development is dependent on each other.

• • • ShaiRevzen (27 Aug 2003) - There is no mixup. Remote nodes are connected to the main board via USB. There is one remote node design, which allows devices to be added onto its local IO interfaces, be they I2C? , serial, PIO, DAC-s or ADC-s. Regardless of which interface you use, you never (well, almost never) modify the node - you just hook up something on it. Usually each such device gets mapped via the node's software onto a USB pipe, meaning that it becomes visible as a peripheral device of some sort if you connect the USB cable to your PC (please see RccGlossary)

• • • HaldunKomsuoglu (27 Aug 2003) - In this scheme in each remote node we would need to design code for two bus interfaces: USB; and I2C? . I don't think establishing a robust standard to hook I2C? nodes into USB pipes will be a day's work. Certainly, this would introduce firmware and hardware complexity. Wouldn't it be simpler to commit to a single bus structure instead?

• • HaldunKomsuoglu (04 Sep 2003) - Just as a data point I have come across an MCU (Cygnal C8051F320? and C8051F321? ) that has a very small form factor (5x5mm) and has built-in USB 2.0 support as well as other peripheral interfaces like ADCs.

• ShaiRevzen (26 Aug 2003) - The tradeoff between a "high-end" protocol like USB and a "basic" protocol like I2C? is really a tradeoff in module complexity. Big and smart modules offload most of the computation from the CPU, and justify the extra complexity of the "high-end" bus for those cases where they require high-bandwidth "attention" from the CPU. As the modules become simpler, they justify less computation locally and therefore less bus complexity.

• • HaldunKomsuoglu (26 Aug 2003) - Above comment seems to imply a "proportional" relationship between module complexity and bandwidth requirements. In my opinion, a smart module implementing local controllers and signal conditioning for sensory data would require much more compact command/data structures exchanged at lower update rates, hence, the bandwidth requirements for a system made out of smart modules would be much less than that of a system with dumb sensors. In other words, module complexity and bandwidth requirement are "inversely proportional" (for a given task).

• • ShaiRevzen (26 Aug 2003) - You misunderstood me; obviously a smarter remote node can convert lots of data into a small number of bits of valuable information (i.e. bandwidth is inversely proportional to computational power in the nodes). My point was that the smarter the remote node, and the more valuable the information, the more it makes sense to use a sophisticated protocol, i.e. bus protocol sophistication is proportional to the to computational power in the nodes.

• • HaldunKomsuoglu (27 Aug 2003) - I am still confused why a valuable information requires a spohisticated protocol. The same packet of bits can be exchanged over a simple protocol just the same. Although having a powerful chip at a remote node makes it possible to implement a sophisticated protocol, it does not make it necessary.

• • ShaiRevzen (27 Aug 2003) - not necessary, just reasonable. The more valuable the information is, and the less regularly it is produced (because of more code complexity, or because it is only produced as needed) the more it makes sense to use a reliable communication protocol. My point is that "important" data, e.g. missile launch codes, gets encapsulated in multiple complex protocols; "unimprotant" data, e.g. current number octets that went through an ethernet card, just gets read and overwritten periodically and nobody really cares if a sample gets garbled or lost.

• • HaldunKomsuoglu (29 Aug 2003) - One can very easily implement functionalities over a simple protocol that would provide "gurranttees" for delivery. Its advantage is that it also allows you to have simple transactions with in the same architecture.

• ShaiRevzen (26 Aug 2003) - For RiSE, complexity is bounded both in physical cabling and in computation. The cabling advantages of I2C? are significant, but using the I2C? pre-disposes towards "simple modules and smart CPU".

• • HaldunKomsuoglu (26 Aug 2003) - I disagree that I2C? pre-disposes towards simple modules. One can find a very wide spectrum of processors that support I2C? all the way from a simple 8-bit microcontroller to a DSP chip. This is a serious advantage and the basis of the flexibility of the I2C? based design.

• • ShaiRevzen (26 Aug 2003) - One could hardly consider DSP-s as the epitome of CPU sophistication; they are just chips that are good at fast number crunching.

• • HaldunKomsuoglu (27 Aug 2003) - Ordering the chip families according to their computational resources was not my goal in this comment. I was trying to point out that a simple protocol, such as I2C? , supported by a wide spectrum of chips provides a great flexibility to us in the design of remote modules which is a very crucial factor in a system as restricted in size as RiSE.

• • ShaiRevzen (27 Aug 2003) - My apologies for being so terse... I was interrupted while writing that and forgot to continue it. I2C? is very broadly supported; but most HW gurus I asked tell me that it is used for boot-time configuration and low sample rate periodic sampling. Its probably the right bus if you want to hook up the keypad decoder or lcd matrix of a TV remote control to some MCU, but nobody I could find uses it to carry data, e.g. audio samples in a digital speaker system. In part, I guess this is because it is both simple, and low bit rate. Our remote nodes should be "smarter" than a DSP, and their communication with the CPU should be supported by a more robust bus (plese see RccGlossary regarding my terminology).

• • HaldunKomsuoglu (29 Aug 2003) - I disagree. First of all, there are many ICs that provide I2C? interfaces to exchange data (e.g. MCP3221 - a 12-bit ADC) and they are very broadly utilized. Though, granted that I don't think not many people utilized I2C? as a basis for an extensible data bus, instead, it is mostly used as a hardwired comm-link between hardware units. However, just because we cannot find a design similar to our idea is not a good reason to disqualify an option. If you look from that perspective I have not seen any design (though there might be somewhere) that uses USB anything more than plugging a PC to a couple of devices. Even though its standard allows it, not many people use it as the data bus in a distributed computation system.

• • HaldunKomsuoglu (29 Aug 2003) - If we have to use something broadly utilized then why not use Ethernet. There are many MCUs with ethernets MAC layer and it is a high speed architecture with bus topology. Most of these ICs are serious pieces of devices with lots of power under the hood. From that point of view I would still thing this is not the best approach if there will be node with simple tasks. Here are a some solutions that I found:
  1. DS80C400? is a 75MHz 8051 microcontroller with 10/100 MAC and plenty other cool stuff. They also indicate that it has a fully accessable OS and IPv4/6 accessable in its ROM. Its form factor is a 68-pin PLCC package.
  2. ez80F92/3 is a 50MHz Z80 microprocessor with 10/100 MAC. It comes in a 100-pin PLCC package.
  3. C8900A? is a 10M ethernet MAC chip that comes in a 100-TQFP package. It is highly integrated. There are 100 Mbit/sec version of the same family: CS8952; and CS8952T? .

• Add your comments here