(main)
1.  Introduction
2.  Architecture
	Serial Line Sub-Architecture
	Internet Sub-Architecture
3.  Assembly Bootstrap Program
	Overview
	Message Handling
	SMCP Protocol
4.  C Proxy Server
	Overview
	TCP Library
	Serial Library
5.  The Java Client
	Overview
	Command Execution
	Threaded Query System
	Mutual Exclusion
6.  Conclusion
	The Future
7.  Acknowledgments
8.  APPENDIX A: Assembly Bootstrap Code
9.  APPENDIX B: C Proxy Server Code
10. APPENDIX C: vNet Class
11. APPENDIX D: Java Client

Copyright 1997 

Our main project is a web-based development environment for the Intel 80C196KB micro-controller, designed using a multi-protocol package for communication between Java clients, a C proxy server, and a serial "bootstrap" engine written in Assembly. As a side-effect, we decided to release the client-server protocol between the Java clients and the C proxy server so that independent developers can easily create Java applets, that make use of our protocol, to communicate with the micro-controller over the internet.

We chose to do this project because we feel that it may have viable commercial application. We envision that soon communicating with micro-controllers over the net will become commonplace, and we wish to provide one of the interfaces to make this happen.

This document describes the implementation level details of our multi-level client/server architecture. The first portion of the discussion will describe the actual architecture with high to medium level details. The remainder of this document will concentrate further on each of the separate pieces making up the architecture, namely the Assembly, C, and Java portions. For user level details on the development environment, please refer to the Visual Asm Environment for 80C196KB Developer’s Guide and for user level details on the vNet protocol please refer to vNet Protocol Developer’s Guide.

The communication link that holds together the entire architecture is the C proxy server. The proxy server acts as a go between for the Java client applets and the "bootstrap" program running on the micro-controller. It acts as a tie between the internet-based vNet protocol and the serial-line based SMCP (Serial Micro-controller Communications Protocol) protocol. Basically, Java applets use vNet to send requests to the proxy server, which translates them into one or many SMCP requests to the "bootstrap" running on the micro-controller. The "bootstrap" services these requests and sends messages through the serial line using SMCP, which are collected by the proxy server. The proxy server then binds these into a single vNet message that is returned to the client. The proxy also handles a few "special case" messages that do not go to the micro-controller, such as assembling of code and connection requests. Due to the limitation that only one micro-controller is available, only a single client can be connected at one time. The vNet and SMCP protocols are modular in their implementation such that they can be easily extended or modified transparently to the applications that use them.

Serial Line Sub-Architecture: The host machine, on which the proxy runs, is connected to an 80C196KB Evaluation Board via a serial line from COM2. Communications run at 9600 baud with an "8 bits, No parity, 1 stop bit" setting. The communication is controlled by the SMCP protocol and is completely transparent to Java client. The communication is entirely handled by the "bootstrap" program and the C proxy server. It is a strict protocol in that there must be a response to every request, and it does not allow multiple requests to be issued at once. This aids in making this sub-architecture more stable and provides quick and immediate error detection. For a detailed description of the SMCP protocol, see the section titled Assembly Bootstrap Program.

Internet Sub-Architecture: The proxy server and the Java clients communicate using the vNet protocol over TCP/IP. The communication is entirely handled by the vNet class and the proxy server, and is mostly transparent to the client, and completely transparent to the micro-controller. Like the SMCP, this is also a strict protocol in that there must be a response to a request before further requests can be issued. Again this assists in transaction stability and quicker error detection (and possible recovery). For a detailed description of the vNet protocol, see the vNet Protocol Developer’s Guide.

Overview: The assembly "bootstrap" program must always remain resident. It processes many commands, such as downloading object code from the proxy server, etc. The "bootstrap" program uses the serial interrupts (int08 and int09) in order to communicate with the proxy server, and as such will always be able to interrupt an executing program and deal with server requests. The "bootstrap" code has an additional rseg at 40H where it defines the vRegisters(0..15) as a table. The user code is loaded at 3000H, and the user’s rseg starts at 60H. Through a file called vSetup.inc, the user gains easy access to the vRegisters which are referred to as vR0..vR15.

Message Handling: All the incoming message handling is performed in the receive interrupt. There is an elaborate scheme using flags and case statements which processes each message. Since messages can have more than one byte, and one byte is received at a time, the assembly program often behaves like a state machine while processing messages. All of the outgoing messages are of size two bytes. Therefore, the transmitting serial interrupt code is a very basic state machine which transmits two bytes every time. There is a synch state in the code which is a simple loop. This is used when no user code is running and keeps the "bootstrap" program active and ready to receive interrupts.

SMCP Protocol: The following is a detailed description of the SMCP protocol, and how the assembly program handles each message. In essence, this is a description of the entire assembly program.

Message Type			Description and Handling Details
SMCP_READY 			A generic ready message. This is sent in response to all requests.
 
SMCP_ERROR 			A generic error message. This is sent when the incoming request is not recognized.
 
 
SMCP_INIT			Simply results in the generation of a ready message. It is used as a keep-alive from the proxy.
 
SMCP_CODEDOWNLOAD		The proxy sends this message to signal the beginning of an object code download. 
				-The assembly program answers with a ready and enters the receive code state.
				-The proxy then begins sending the code, and ends it with a ‘.’ character.
				-The assembly program running a modified version of Ken’s code starts loading incoming bytes into memory from 
				3000H. Upon seeing the ‘.’, it sends a ready reply and prepares to jump to 3000H on the proxy’s command.
 
SMCP_CODEEXECUTE 		The proxy sends this message to signal code execution.
				-The assembly program sends back a ready message and jumps out of the synch state and into 3000H
				beginning execution of the user program.
 
SMCP_CODEHALT                              The proxy sends this message to signal execution halt.
				-The assembly program replies with a ready and saves the current PC in case the user may want 
				to resume code execution. It loads the address of the synch loop onto SP+4, so that the return from interrupt 
				causes a jump to the synch loop allowing the bootstrap to wait for the next command.
	
SMCP_REGREQUEST 		The proxy sends this message to query the contents of a vRegister (0..15). 
				-The assembly program replies with a ready and enters a state in which it waits for the register’s id number. 
				-The proxy sends the register’s id number
				-The assembly program indexes into the vRegister Table using the id. It then sends back the word at
				that location in two successive bytes.
 
SMCP_CODERESUME 		The proxy sends this message to resume halted execution.
				-The assembly program answers with a ready and it drops out of synch state and jumps to the previously 
				saved PC (at which user code execution was halted).
 
SMCP_REGMODIFY                           The proxy sends this message to modify a vRegister.
				-The assembly program replies with a ready and entersa series of states which receive the vRegister id and then 
				in two successive bytes the values of the low and high bytes to be stored at the location referenced by a table 
				lookup using the id provided.

Overview: The proxy server is a simple main loop which waits for an incoming vNet message and processes it accordingly. The processing is done after the message is parsed and the appropriate subroutine is called to handle it (possibly using SMCP to communicate with the micro-controller). Besides the main program, the C proxy server contains two major libraries which assist in communications: the TCP library and the Serial library. The server uses the TCP library to implement the vNet protocol on its end, and it uses the Serial library to implement the SMCP protocol. The server was designed to be fault-tolerant on the TCP end, in that it recovers gracefully when clients abruptly or maliciously drop connections.

TCP Library: The TCP library uses Windows Sockets 2.0 to perform TCP communication. It contains initialization routines which start up a Windows Sockets .dll and do version checking to ensure that communications are possible. It also contains a shutdown routine which cleanly closes the TCP/IP stack and shuts down Winsock .dll. This library also contains routines to listen for connections and accept ncoming connections. Furthermore, routines exist to send and receive byte messages across the net. Some utility functions are also available which allow the main program to construct and decrypt vNet headers.

Serial Library: The serial library uses the standard Win32 API to communicate through the serial connection. It also contains initialization routines which attempt to open the serial port and set the communications properties. All the routines return proper error conditions in case the resources requested could not be initialized. This library also contains basic routines for sending and receiving byte messages across the serial line.

Overview: The Java client is a full-fledged Intel 80C196KB assembly development environment. It uses Java AWT to provide a graphical user interface. For user level details, refer to the Visual Asm Environment for 80C196KB Developer’s Guide. We will now discuss the actual implementation level details of the client.

Command Execution: The client is an action based model. It simply responds to user input. Therefore, most of the explanation of the inner working of the client has already been covered in the Developer’s Guide. There, however, are some hidden details to the user which are significant to the workings of the Client application.

Threaded Query System: When the user chooses the debug option, in order to still allow interaction with the user interface, a thread is spawned to handle register content querying. This thread simply goes through a boolean array looking for register id’s to query and performs queries on them (at the user provided refresh rate) updating the GUI as the results are obtained. When the debug option is toggled off, the query thread is suspended until further debugging is needed. Introducing a threaded query system creates several subtle Critical Section problems in the application. First of all, when the client is talking to the proxy, the main thread should not communicate with the proxy. This would undermine the strict vNet protocol in that multiple requests could be issued before appropriate replies. A further problem is that if a user turns debugging off while the query thread is in the middle of a transaction the vNet protocol will be violated. In order to curb these bad behaviors, we enforced mutual exclusion in the system.

Mutual Exclusion: Mutual exclusion is enforced in the client by using the Java language’s "synchronized" construct. In essence we created a mutex (mutual exclusion semaphore) object which prevented multiple threads of the client from entering the critical sections at the same time. The mutex is used in any situation where it is possible that more than one vNet request could be made concurrently or a pending transaction could be terminated prematurely. This makes the client safe.

In conclusion, we created this project because we felt that it would be a useful venture. We wanted to create an almost professional tool with real-world applicability. In fact, our own development environment uses the vNet protocol for its communications with the micro-controller. Since we have declared this protocol as public domain, anyone could, if they so wished, using our vNet class, build another version of the development environment supporting a different set of features. Furthermore, it would be easy to port SMCP and the assembly code to different micro-controllers since SMCP is mostly architecture independent. The C proxy would require minor changes, if any, since it executes the assembler through a batch file which could easily be changed. However, in order to port the C proxy from WinNT to another environment, we would only have to change the TCP and Serial libraries. The Java client is inherently architecture independent, and can run on any machine that supports Java. Therefore, we envision students with Macintoshes, PC’s, Solaris Workstations, etc. taking EE476 and working on their projects from home (using our environment). In fact, the demonstration assembly code was created and debugged in our own environment, simply because we much prefer it.

The Future: Finally, we envision a number of ways that this project can be extended. One example would be to have one proxy server support multiple micro-controllers and multiple clients. Each client, as they log on, would be assigned to a micro-controller. The vNet class would undergo changes transparent to the client: with every packet it would simply transport a micro-controller id also (i.e. the micro-controller which is assigned to the client). This would assist the proxy in directing the resulting SMCP messages to the correct micro-controller. In addition, the micro-controllers may be completely distinct from each other, but by supporting the standard SMCP protocol the proxy server could deal with them in a like fashion. In this manner, we could have developers from different parts of the world, working on entirely different platforms and writing and debugging code in real-time for entirely different micro-controllers over the web.

The development team would like to thank Professor Land for helping us to come up with this project idea and for teaching this course. We would also like to thank Ken Andrews for allowing us to use and modify both his lst2hex.c and rax.asm code for use in our project and encouraging us to do so. Finally, we would like to thank our TA Marc Lai for helping us through all of the labs, and his overall assistance throughout.