Browse Prior Art Database

System for organizing large numbers of distributed, legacy resources Disclosure Number: IPCOM000028797D
Original Publication Date: 2004-Jun-01
Included in the Prior Art Database: 2004-Jun-01
Document File: 2 page(s) / 36K

Publishing Venue



When developing a new embedded system board, it can be extremely difficult to set up an efficient means of accessing all of said board's ports. This problem becomes greater when the board cannot be located near the user. This system not only solves both of these problems, but adds convenient features and user interface.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 2

System for organizing large numbers of distributed, legacy resources

While many new communication technologies, like USB, have attacked the problem of excessively small numbers of simultaneous device connections being permitted, our industry still relies upon older, simpler things such as serial ports and parallel ports for CPU/board/system bringup. While this has many advantages, a problem arises because new items under development are expensive and in short supply, they must often be shared among multiple developers. Recently, we have started to work heavily cross-site as well as with teams across the world--effectively forcing us to find an acceptable method of arbitrating the use of network-connected remote resources.

In one implementation of this system, we consider the early bringup of a Board Under Development (BUD) that will eventually become embedded. This BUD has many interfaces: 4 standard serial ports, 1 EPP parallel printer port, 6 nonstandard serial ports, USB, GPIO, IIC and more. The goal is to efficiently connect all of these ports to development computers (typically desktop PCs running Linux) and manage them in a manner such that the physical location of the bringup hardware is de-emphasized.

From the description above, it is apparent that most desktop PCs (even with expansion cards) can only fully connect one BUD, or partially connect two BUDs. So, the topology tends to be one BUD per desktop PC (that is connected to the corporate net). It is assumed that all/most development stations are intended to be identical. These desktop PCs, running Linux images, are generally unsecured: the users have full root access, which is necessary to remotely correct problems. If we have 10 such BUD/desktop combinations, and 15 users vying for time on development stations, users will have to switch machines frequently. This correlates closely to a real problem seen--arbitration is currently performed via a very general resource scheduler (the resource here is considered to be the desktop PC + BUD). However, said scheduler provides no real authority / control, so users (especially given that they have full root access to all remote PCs) can and do collide with one another regularly. The desktop PCs are used primarily as a means of interacting with the legacy serial/parallel/IIC/USB/GPIO ports over the corporate network, but because of the arrangement we see several problems: The cost of each PC, and thus the total overall cost tends to be greater as each PC will need the full blown standard development environment / toolset. Each PC must be of a certain calibre; have sufficient disk space to support a reasonable number of users who might recompile / update the BUD / provide external mountable resources for the BUD. Each PC may be underutilized; one or two unused ports of each type may be unused on each PC, because the line of demarcation was drawn by 'development station'. Each PC will have to be individually managed, which does no...