Recent Changes

If you change this page, please update the placement of your change anchors

Central Processing Unit HW/SW Interface

This section concerns the details of the hardware and software interface to the sensor/actuator bus for the central computational unit. The primary point of interest is the question "How does the information gets from the bus into the memory of the PC on the robot?"

• HaldunKomsuoglu (12 Aug 2003) - The bridge between the I2C? bus and the central computational unit can be implemented by a dual-port RAM (similar the way it is done in RhIO) where the RAM becomes an intermediate blackboard for the information. On the bus side bus arbitrar updates the fields in this RAM that correspond to sensory modules and reads commands from actuator fields to be sent to the associated actuator modules. Independently on the other side of the RAM, the central processing unit can access to only those sensory data that it needs and update the command fields. This scheme has two important advantages: 1) the interrupt service routine for the I2C? bus would be very simple (merely a data copy from bus to RAM), and therefore, very fast; and 2) the asynchronous layer implemented by the dual-port RAM would significantly decrease the load on central processing unit and simplify the interfacing software.

• ShaiRevzen (26 Aug 2003) - I don't really see the point of this "bus arbiter" and the DPR if there is enough processing power in the remote nodes.

• • HaldunKomsuoglu (27 Aug 2003) - I believe there is a misunderstanding caused by my rather vauge description above. Let me try to clairfy. Here I am trying to describe a means to transfer information from the bus into the PC on the robot for the I2C? based proposal. I am certain the need for such a mechanism is obvious. No matter what bus you use the data must somehow get into the PC. In the USB case this is done by the USB controller. In the I2C? case I propose to use a DPRAM to facilitate the intermediate medium which would take the form of a blackboard. This approach simplifies the software components associated with the bus-to-PC transfer job, and therefore, makes them faster and more efficient as briefly explained above. Please, let me know if you like me to make a more detailed description of what I have in mind.

• • HaldunKomsuoglu (27 Aug 2003) - I don't think I quite understood your comment, either. I am not sure how the computational power of the remote nodes remove the need for a "bus arbitrar." The DPRAM is "an" approach to solve the data transfer problem in I2C? case providing advantageous simplification in software design. Therefore, it is also not related to the computational power of the remote modules.

• HaldunKomsuoglu (27 Aug 2003) - I believe one can compare these two approaches in terms of the computational power requirements of their respective bus interface software running on the PC. Shai: could you explain the processes that would be required to organize the raw data stream coming into the USB controller into meaningful chunks grouped according to their respective sources? [I am adding this as another item into the comparision table with empty comments.]

• • ShaiRevzen (27 Aug 2003) - there is no "raw data stream" in USB. A typical USB interface chip supports 2-16 "pipes". The pipe abstraction is part of the USB standard, and there are several different pipe types (e.g. synchronous and asynchronous). Usually data for each pipe gets DMA-ed into a separate buffer. When USB devices boot they connect a "default control pipe" that is used to negotiate all the other pipes. In typical a USB device the pipe descriptors are burned into nonvolatile memory in the USB controller (or obtained from serial memory via I2C? ). By mapping (device,pipe) pairs into our own "port numbering" for the communication API, we can actually get the USB hardware to do most of the work for us.

• • • HaldunKomsuoglu (27 Aug 2003) - Is there a limit on the max number of hardware supported pipes or can it be increased upon need? Your comment above kind of implies that 16 is an upper bound. If so, wouldn't this cause an extensibility issue as the number of single sources and sinks increase with added remote nodes?

• Add your comments