EECI08: Embedded Systems Programming - Revision history

Murray: EECI: Embedded Systems Programming moved to EECI08: Embedded Systems Programming

2009-03-01T20:13:31Z

EECI: Embedded Systems Programming moved to EECI08: Embedded Systems Programming

← Older revision		Revision as of 20:13, 1 March 2009
(No difference)

Murray at 00:58, 29 March 2008

2008-03-29T00:58:01Z

← Older revision		Revision as of 00:58, 29 March 2008
Line 1:		Line 1:
	{{eeci-sp08 header\|prev=[[~~NCS~~: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[~~NCS~~: Trajectory Generation and Differential Flatness\|Trajectory Generation]]}}		{{eeci-sp08 header\|prev=[[EECI: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[EECI: Trajectory Generation and Differential Flatness\|Trajectory Generation]]}}

	{{righttoc}}		{{righttoc}}

Murray: NCS: Embedded Systems Programming moved to EECI: Embedded Systems Programming

2008-03-28T15:18:54Z

NCS: Embedded Systems Programming moved to EECI: Embedded Systems Programming

← Older revision	Revision as of 15:18, 28 March 2008
(No difference)

Murray at 20:11, 16 March 2008

2008-03-16T20:11:16Z

← Older revision		Revision as of 20:11, 16 March 2008
Line 1:		Line 1:
	{{eeci-sp08 header\|prev=[[NCS: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[NCS: ~~Real-Time~~ Trajectory Generation\|Trajectory Generation]]}}		{{eeci-sp08 header\|prev=[[NCS: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[NCS: Trajectory Generation and Differential Flatness\|Trajectory Generation]]}}

	{{righttoc}}		{{righttoc}}

Murray at 20:10, 16 March 2008

2008-03-16T20:10:08Z

← Older revision		Revision as of 20:10, 16 March 2008
Line 1:		Line 1:
	{{eeci-sp08 header\|prev=[[NCS: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[NCS: Real-Time Trajectory Generation\|Trajectory Generation]]}}		{{eeci-sp08 header\|prev=[[NCS: Case Study - Autonomous Driving\|Autonomous Driving]]\|next=[[NCS: Real-Time Trajectory Generation\|Trajectory Generation]]}}

			{{righttoc}}
	Early control systems used carefully synchronized control loops running on a single computer to insure that control processes ran at a fixed clock cycle and with predictable timing. Modern multi-threaded control environments use much looser timing models and provide non-deterministic execution, but provide advantages in terms of programming flexibility and processor utilization. In addition, networked communication allows multiple computers to run asynchronously, allowing a much richer set of behaviors but complicating the problem of debugging and verifying code.		Early control systems used carefully synchronized control loops running on a single computer to insure that control processes ran at a fixed clock cycle and with predictable timing. Modern multi-threaded control environments use much looser timing models and provide non-deterministic execution, but provide advantages in terms of programming flexibility and processor utilization. In addition, networked communication allows multiple computers to run asynchronously, allowing a much richer set of behaviors but complicating the problem of debugging and verifying code.
	This lecture describes some of the software infractructure used to implement moder networked control systems. We first discuss "message transfer systems", which is responsible for managing network communications between computers and software modules with the control system. We focus on the use of [[spread]] as a specific example of a low-level message transfer subsystem and describe how it can be used in a NCS context. We then describe the [[Pthreads]] programming environment, which provides a standardized API for managing process threads and mutexes (to resolve data access conflicts).		This lecture describes some of the software infractructure used to implement moder networked control systems. We first discuss "message transfer systems", which is responsible for managing network communications between computers and software modules with the control system. We focus on the use of [[spread]] as a specific example of a low-level message transfer subsystem and describe how it can be used in a NCS context. We then describe the [[Pthreads]] programming environment, which provides a standardized API for managing process threads and mutexes (to resolve data access conflicts).

Murray at 20:09, 16 March 2008

2008-03-16T20:09:47Z

New page

{{eeci-sp08 header|prev=[[NCS: Case Study - Autonomous Driving|Autonomous Driving]]|next=[[NCS: Real-Time Trajectory Generation|Trajectory Generation]]}}

Early control systems used carefully synchronized control loops running on a single computer to insure that control processes ran at a fixed clock cycle and with predictable timing. Modern multi-threaded control environments use much looser timing models and provide non-deterministic execution, but provide advantages in terms of programming flexibility and processor utilization. In addition, networked communication allows multiple computers to run asynchronously, allowing a much richer set of behaviors but complicating the problem of debugging and verifying code.
This lecture describes some of the software infractructure used to implement moder networked control systems. We first discuss "message transfer systems", which is responsible for managing network communications between computers and software modules with the control system. We focus on the use of [[spread]] as a specific example of a low-level message transfer subsystem and describe how it can be used in a NCS context. We then describe the [[Pthreads]] programming environment, which provides a standardized API for managing process threads and mutexes (to resolve data access conflicts).

== Lecture Materials ==
* Lecture slides: {{eeci-sp08 pdf|L3_embedded.pdf|Embedded Systems Programming}}

== Reading ==
=== Messaging Systems ===
* [http://portal.acm.org/citation.cfm?id=359563 Time, clocks, and the ordering of events in a distributed system], L. Lamport. ''Communications of the ACM'', 21(7):558-565, 1978. This is a classic paper on ordering of messages in distributed systems. A must read for distributed systems. 
* [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=37515 Exploiting virtual synchrony in distributed systems], K. Birman and T. Joseph. ACM Symposium on Operating Systems Principles, 1987. This paper gives a nice overview of some of the problems in group messaging systems and is one of the sets of papers that motivated the work that lead to [[Spread]].

*[http://www.spread.org/docs/guide/users_guide.pdf A Users Guide to Spread], J. Stanton. 2002. This is the documentation for the [http://www.spread.org Spread Toolkit]. The first and second chapters provide most of the information you need to understand the basic ideas, although the way in which [[Spread]] servers are configured, described in Chapter 3, is also useful.

* [http://www.cnds.jhu.edu/pub/papers/spread.pdf The Spread Wide Area Group Communication System], Y. Amir and J. Stanton. Technical Report CNDS-98-4, The Center for Networking and Distributed Systems, The Johns Hopkins University, 1998. The paper provides a detailed technical description of how [[Spread]] works. It is mainly useful if you want to know more about what [[spread]] does. Requires some background in network protocols if you want to understand the details. 

* [http://www.cnds.jhu.edu/pub/papers/hop_ftcs2000.pdf A Low Latency, Loss Tolerant Architecture and Protocol for Wide Area Group Communication], Yair Amir, Claudiu Danilov, and Jonathan Stanton. International Conference on Dependable Systems and Networks (DSN00), New York, New York, June 25-28, 2000. The paper is similar to the one above but with more technical details. 

=== Threads ===
* [http://www.llnl.gov/computing/tutorials/pthreads/ POSIX Threads Programming], Lawrence Livermore National Laboratory. 2006. This tutorial provides an introduction to Pthreads, the standard implementation of threads under linux. It's a pretty quick read, with examples of the code and pretty good descriptions of the basic pthreads functionality.

* [http://www.acm.org/classics/feb96/ Monitors: An Operating System Structuring Concept], C. A. R. Hoare. ''Communciations of the ACM'', 17(10):549--557, 1974. This paper describes the concept of a "monitor", which is basically a function that uses mutexes to access a shared resourse. This is one of the early papers on concurrent computing and is cited as one of the design patterns for using threads and mutexes.

* Cooperating Sequential Processes, E. W. Dijkstra. In ''Structured Programming'', Academic Press, 1972. This is one of the most widely cited papers in concurrent programming and is often labelled as the paper that started the field. I haven't been able to locate an online copy yet (and haven't read it either).

== Additional Resources ==
* [http://www.spread.org Spread Toolbox] - The Spread Wide Area Group Communication System
* [http://www.isd.mel.nist.gov/projects/rcslib/NMLcpp.html Neutral Message Language (NML) Programmers Guide] - part of the NIST [http://www.isd.mel.nist.gov/projects/rcslib/ Realtime Control System] library
* [http://roboflag.mae.cornell.edu/Documentation.html RoboFlag documentation] - includes discussion of how RoboFlag network communications are implemented