Status: This is a project in planning state. Currently, these are just thoughts and ideas noted for future usage -- once I have time and/or materials needed for this. If you want to help me with the materials issues, you can check the WishList for an overview what I am missing. Usually, though, the missing resource is just time.
Sometimes, one wishes to see what exactly happened on a serial console of a computer. This is usually the case on "real" computers, that is, non-PCs - like, for example, Sun workstations or servers. While many larger server machines feature a kind of system controller, a dedicated embedded computer just for managing the whole system, the smaller systems (those that a personal user can afford) do not have such devices, and loose their console text buffer on reboot or power-off.
Therefore, I am going to design and build a device that can be attached between the computer's console port and the terminal device attached to it. This device will in normal operations sniff the serial communication that is passing by, and, upon e.g. pressing of a button, will replay it in direction of the terminal device. A relatively small buffer (say, 100 kByte) will be sufficient, as error messages and diagnostic output of interest is usually printed right before the Bad Things happen.
The design question left before starting actual work on this is how the sniffed data will be stored: Either in a RAM that would require internal power to keep the memory cells refreshed, or a flash storage device which would not need internal power, but degrades with write accesses. Another alternative would be a combination of both, where in normal operations data is written to RAM, and, for example when for some time no activity happens, or a serial data line is no longer asserted, does the write to flash memory as stable backing store. This would also require some power (possibly from a "Gold Cap" that can be charged from the serial line), and much more "intelligence" than a solution using only one storage device.
Also, I am not quite sure yet if it will operate in a pass-through way where the processor inside the device acts as sender/receiver in both directions and actively forwards the data, or if it just will sit on the serial bus in parallel to the computer and terminal devices. Also, it is yet to be determined whether a single transmission mode will be supported (either fixed by design, or configurable by jumpers or switches) or if an autosensing mechanism for transmission parameters (line speed, word size, stop bits, flow control) can be built.
THIS DATA IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
All product and brand names mentioned on there pages and in the source code are registered names and/or trademarks of the respective owner and are mentioned for identification purposes only.
For a full copyright notice, please see this link. For imprint and contact information, please see http://www.thiemo.net/.