Development Infrastructure

This section aims to identify the properties of the development infrastructure for implementation of embedded systems. The some important parameters for comparison are: availability; level of custom design and implementation; ease of distribution; similarity to the setting in the physical robot.

• HaldunKomsuoglu (12 Aug 2003) - A USB enabled device can be directly connected to a PC and accessed using existing USB device drivers. Furthermore, the program that runs on the PC may be identical to the one that would run on the robot provided that we choose a PC-like central computational unit running the same operating system as the development PC. This would be an important enabler in getting people involved with the hardware design.

• HaldunKomsuoglu (12 Aug 2003) - The I2C? approach is not too far from the USB's state. Obviously, no PC comes with a I2C? port, hence, there is a little work to be done to provide some interface, let's call it PC-bus adapter, that would sit in between the module under development and the PC. This PC-bus adapter would be essentially a bus arbitrar with some interface to the PC, may be a simple RS-232. However, the required development time for such a device is a negative for the I2C? approach.

• • ShaiRevzen (26 Aug 2003) - There are several people who have already solved this problem, e.g. Linux I2C? developers. The primier example being http://www.voxel.at/prj/i2c/ .

• • • HaldunKomsuoglu (26 Aug 2003) - Such an I2C? card would be helpful in development time. However, note that in this approach the PC would be adopting the "bus arbitrar" role. In my opinion, one would still like to have the same hardware that would arbitrate the bus in a development setup so that the differences between the run-time and development are minimized. Hence, I would be more inclined towards a solution where a PC-bus adapter with standard RiSE specific bus interface is hooked up to the development PC thru some secondary channel. This may be RS232 or yet another I2C? or even USB.

• • • ShaiRevzen (26 Aug 2003) - There is a problem with this: it means that we cannot have a developer work on a module (a.k.a. Al's "remote node") without the "bus arbiter" board. I would prefer to fix this by making sure that the remote node's dependencies on the choice of physical layer be restricted to a well defined software module; then we can implement the same API over a regular serial interface. A PC based I2C? interface board that takes the bus arbiter role should only be required by the people developing the main board (as a debugging aid).

• • • HaldunKomsuoglu (27 Aug 2003) - I don't see the need for a bus arbitrar card as a serious problem. It is certainly an additional work to be done but it is nothing more that a standardized piece of electronic circuitry (which needs to be designed for the robot anyways) that has two interfaces: one for the RiSE compliant serial bus; and another one to connect to the PC which can even be a simple RS232. In the I2C? based design I am against the idea of using the PC to emulate the bus arbitrar in a development setting. In my opinion, we should keep the differences between the development and robot settings to a minimum. Of course, if we choose to go with USB, than the setup of a standard PC would be identical (or very similar) to that of the robot's central control computer, and therefore, this similarity issue would not appeare at all. On the other hand, an approach like I2C? would certainly require some device to be installed to the development PC. Here we would better utilize the same bus arbitrar to eliminate any unforeseen compliancy issues. [I have added this discussion into the tabel of comparision]

• • • HaldunKomsuoglu (27 Aug 2003) - There is one little thing I am confused, though. I do agree that the communication API must hide the details of the communication system and I can also imagine implementing the same API using different physical layers as well. However, I am not clear if you are suggesting to have two different physical layer implementations in each node, a simple serial and whatever high speed thing we shall choose, where the former is used for debugging and development while the later is used in run-time. Could you clarify this? If your answer is yes, then I think the requirement for two physical serial interfaces for each node would be drag which would unnecessarily complicate both hardware and software. Furthermore, differences in these two different serial interface might cause hard to trace bugs during run-time.

• • • AlRizzi (27 Aug 2003) Just a few comments.
      1. Hal, given the tight space requirements we will have for the computational system on RiSE, I doubt that we will be able to afford something like a serial interface between the main CPU and the "bus arbitration system". It is much more likely that we will have the bus modules (8051ish controllers) tightly integrated with the main CPU. How to best reproduce this sort of operating environment for benchtop development is not clear to me immediatly. The obvious options include building/buying a serial/USB bridge device that we can use, or making our "nodes" support serial as well as I2C? . I really do not like either of these.
      2. Lots of my confusion has come from thinking we were talking about bus level things, when much of the discussion has been up at the software model. I'll just chime in to say that I agree that we must abstract the details of this bus (messages, subscriptions, etc) away as much as possible.

• • • • HaldunKomsuoglu (27 Aug 2003) - I would like to clarify my previous comment. The "serial interface" between the main CPU and the bus arbitrer was not meant to be utilizied in the physical robot but merely an aproach for benchtop development effort for the module design. I completely agree that the integration on the physical robot needs to be as tight as possible.

• • • • HaldunKomsuoglu (27 aug 2003) - When it comes to reproduce a development environment similar to that of the physical robot I believe we are stuck with some sort of intermediate circuitry no matter what we use at the physical bus. I believe the majority of this circuitry will be identical to the bus arbitrar, and therefore, it will introduce a very small design/implementation overhead. As I stated earlier I have strong dislike against designing remote modules with two seperate hardware interfaces which would complicate both hw and sw.

• Add your comments here