Logo

» About

» Downloads

» GitHub

» GitLab

Mottek Blog

» Mottek

» Archive

2024 2023 2022 2020 2019 2018 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004 2003

RSS

Communication Protocols 101

Communication Protocols 101

One of the challenges in the Bluetooth driver project and any other project involving the NewtonOS communications framework are the communication primitives which are exposed to the NewtonScript layer.

These primitives (Bind, Connect, Input, Output etc) have to be implemented by any lower layer protocol such as RCOMM or SSL. It is of course possible to bypass them and offer a separate API via a native module (I can already talk to my Bluetooth card on that level), but then, no existing application could take advantage of the new protocol.

The RFCOMM layer has to fit under the generic TCommTool interface which in turn is called using the outer communications primitives. In addition to that, there is a tradeoff in reusing the existing code for interacting with the serial chip (implementing in TSerTool and TAsyncSerTool) and being able to implement whatever buffering scheme and packet handler is necessary for the HCI/L2CAP layer.

I figure that reusing the TAsyncSerTool is the best way to go. It implements a significant amount of logic and I don’t think I could reimplement a comm tool from scratch. This means that I have to reverse engineer it to that extent that I know how to fit the HCI/L2CAP layers into the existing code.

From the experiences with Nitro I have already figured out which functions are called in which order when a NewtonScript client uses an endpoint. The situation regarding the RFCOMM tool is quite similar: The TSerTool handles the upper layer input buffers which are visible to the NewtonScript layer. The TAsyncSerTool uses its own ring buffers to talk to the hardware and fill the TSerTool buffers. This is point where the RFCOMM tool will come into play. Instead of simply copying the data between the buffers, it will have to implement the HCI/L2CAP logic. This requires changes to the IRQ handler, the DoInput and DoOutput functions and a number of internal functions (which are thankfully all declared as virtual so they can be overloaded).

The biggest difficulty is to implement the logic which the NewtonScript glue layer expects from the comm tool layer…

2003-08-08