CSE 466 – Fall 2000 - Introduction - 1 AB 2 4 3 1 Chat Application 1 2 3 4 (no event) || (getchar(&c) && !call(c) ) / if (c) echo c, print failure message.

Slides:



Advertisements
Similar presentations
I/O Systems & Mass-Storage Systems
Advertisements

Introduction to Sockets Jan Why do we need sockets? Provides an abstraction for interprocess communication.
Categories of I/O Devices
Taekyung Kim 0x410 ~ 0x International Standards Organization (ISO) is a multinational body dedicated to worldwide agreement on international.
H. 323 Chapter 4.
Intermediate TCP/IP TCP Operation.
CSE 466 – Fall Introduction - 1 COMMANDS RESPONSES Master/Slave Software Architecture Master void master() _task_ MAST{ Button(mode); // enq(cmd)
UDP & TCP Where would we be without them!. UDP User Datagram Protocol.
Transmission Control Protocol (TCP) Basics
BZUPAGES.COM 1 User Datagram Protocol - UDP RFC 768, Protocol 17 Provides unreliable, connectionless on top of IP Minimal overhead, high performance –No.
Network Layer and Transport Layer.
Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.
I/O Hardware n Incredible variety of I/O devices n Common concepts: – Port – connection point to the computer – Bus (daisy chain or shared direct access)
CSE 466 – Fall Introduction - 1 AB Chat Application (no event) || (getchar(&c) && !call(c) ) / if (c) echo c, print failure message.
CSE Fall Introduction - 1 What is an Embedded Systems  Its not a desktop system  Fixed or semi-fixed functionality (not user programmable)
OSI Model.
Introduction To Networking
Understanding Networks. Objectives Compare client and network operating systems Learn about local area network technologies, including Ethernet, Token.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
TCP/IP Protocol Suite 1 Chapter 11 Upon completion you will be able to: User Datagram Protocol Be able to explain process-to-process communication Know.
CSE 466 – Fall Introduction - 1 Implementation of Shared Memory  Considerations  Network traffic due to create/read/write  Latency of create/read/write.
1 CCNA 2 v3.1 Module Intermediate TCP/IP CCNA 2 Module 10.
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
CSE 466 – Fall Introduction - 1 Remainder of Syllabus  Lecture  RTOS  Maestro In Linux  Distributed Control Architecture – distributed state.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Gursharan Singh Tatla Transport Layer 16-May
SERIAL BUS COMMUNICATION PROTOCOLS
2011 Embedded Systems Software Training Center BluRapport SDK.
OSI Model Routing Connection-oriented/Connectionless Network Services.
Chapter 17 Networking Dave Bremer Otago Polytechnic, N.Z. ©2008, Prentice Hall Operating Systems: Internals and Design Principles, 6/E William Stallings.
Networking Basics TCP/IP TRANSPORT and APPLICATION LAYER Version 3.0 Cisco Regional Networking Academy.
Real-time Systems Lab, Computer Science and Engineering, ASU Linux Input Systems (ESP – Fall 2014) Computer Science & Engineering Department Arizona State.
LWIP TCP/IP Stack 김백규.
I/O Systems I/O Hardware Application I/O Interface
High Performance Computing & Communication Research Laboratory 12/11/1997 [1] Hyok Kim Performance Analysis of TCP/IP Data.
Internet Addresses. Universal Identifiers Universal Communication Service - Communication system which allows any host to communicate with any other host.
LWIP TCP/IP Stack 김백규.
User Datagram Protocol (UDP) Chapter 11. Know TCP/IP transfers datagrams around Forwarded based on destination’s IP address Forwarded based on destination’s.
Distributed Systems Concepts and Design Chapter 4.
Application Block Diagram III. SOFTWARE PLATFORM Figure above shows a network protocol stack for a computer that connects to an Ethernet network and.
Transport Layer3-1 Chapter 4: Network Layer r 4. 1 Introduction r 4.2 Virtual circuit and datagram networks r 4.3 What’s inside a router r 4.4 IP: Internet.
Bluetooth on CE. Mid - Presentation Roman Zoltsman & Oren Haggai Group /2001 Instructor: Nir Borenshtein HSDSL Lab. Technion.
Networking Basics CCNA 1 Chapter 11.
Institute of Technology Sligo - Dept of Computing Chapter 12 The Transport Layer.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 13: I/O Systems I/O Hardware Application I/O Interface Kernel I/O Subsystem.
The Client-Server Model And the Socket API. Client-Server (1) The datagram service does not require cooperation between the peer applications but such.
Silberschatz, Galvin and Gagne  Operating System Concepts Six Step Process to Perform DMA Transfer.
1 Chapter 4. Protocols and the TCP/IP Suite Wen-Shyang Hwang KUAS EE.
Networks, Part 2 March 7, Networks End to End Layer  Build upon unreliable Network Layer  As needed, compensate for latency, ordering, data.
4343 X2 – The Transport Layer Tanenbaum Ch.6.
Silberschatz, Galvin, and Gagne  Applied Operating System Concepts Module 12: I/O Systems I/O hardwared Application I/O Interface Kernel I/O.
© 2002, Cisco Systems, Inc. All rights reserved..
Agenda Socket Programming The OSI reference Model The OSI protocol stack Sockets Ports Java classes for sockets Input stream and.
The OSI Model. Understanding the OSI Model In early 1980s, manufacturers began to standardize networking so that networks from different manufacturers.
Chapter 9: Transport Layer
Module 12: I/O Systems I/O hardware Application I/O Interface
Introduction to Networking
I2C Synchronous Serial Two wire communications (plus ground)
CSE 466 – Fall Introduction - 1
I/O Systems I/O Hardware Application I/O Interface
Operating System Concepts
13: I/O Systems I/O hardwared Application I/O Interface
CS703 - Advanced Operating Systems
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
CS4470 Computer Networking Protocols
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Network Architecture Models: Layered Communications
Module 12: I/O Systems I/O hardwared Application I/O Interface
TCP Connection Management
Presentation transcript:

CSE 466 – Fall Introduction - 1 AB Chat Application (no event) || (getchar(&c) && !call(c) ) / if (c) echo c, print failure message (getchar(&c) && call(c)) || recv(&c) / echo c, print success message, call accept() if from network (no event) || (getchar(&c) && c!=ESC) || (recv(&c) && (c!= ESC)) / if (c) putchar(c), if from term, send(c). (getchar(&c) && c==ESC) || (recv(&c) && (c== ESC)) / call close(), print message Transport Layer Services: call(); accept(); send(); recv(); close();

CSE 466 – Fall Introduction - 2 Complete the Stack User the weather? Transport Physical I2C Transport message semantics / telephone model dial tone ? I2C frames ? Describe the API that the physical layer has to provide to the transport layer. Try writing call(), accept(), send(), recv(), close() functions using that API. Find out what functions you want the physical layer to provide. Application dial tone call() accept() send()… call() accept() send()… connection management / security

CSE 466 – Fall Introduction - 3 New Versions of the App void stateB() _task_ B { while(1) { if (!busy) wait(K_SIG); busy = 1; if (g=getchar(&c) || (recv(CHAT,&c)) { if (c != ESC) { putchar(c); if (g) send(CHAT,c); } else { close(CHAT); busy = 0; os_signal_task(A); } void stateA() _task_ A{ while(1) { if (!avail) wait(K_SIG); avail = 1; if ((getchar(&c) && call(CHAT, c)) || accept(CHAT,&c)) { sprint(“connected to: ”); putchar(c); avail = 0; os_signal_task(B); } AVAIL BUSY generic transport layer interface: > call(port, address)// blocking > accept(port, *address)// non-blocking > send(port, data)// blocking > recv(port, data)// non-blocking > close(port, data)// non-blocking can close if undesired caller

CSE 466 – Fall Introduction - 4 My Attempt Physical Data Queues Allocated by transport layer as needed for application requests. Has Port and Dst attributes Physical Layer Stuffs incoming data into matching queue Stuffs control info into control queue Makes and sends control and data frames data frame [s, dst, src, port, data, …, data, p] control frame [s, dst, 0, src, port, cmd, p] Control queue (transport to transport communication) dst Port Transport control adr port cmd adr port cmd … data … call(), accept(), close(), send(), recv()

CSE 466 – Fall Introduction - 5 The Transport Layer Protocol User Transport Physical I2C Transport dial tone ?? Application dial tone call() accept() send()… call() accept() send()… call() accept()

CSE 466 – Fall Introduction - 6 A look at Call() int call(int port, int dst) { // establish a connection to specified port on dst system queue *inq, *outq; int count ; if (status[port] == BUSY) return 0; else (status[port] == BUSY); outq = outQueues[port] ; inq = inQueues[port];// static allocation of queues…could be dynamic inq->addr = outq->addr = c; inq->port = outq->port = port; enq(outCtlQ,c); enq(outCtlQ,port);// put call into control queue enq(outCtlQ,CALL); while (ack = scan(inCtlQ,c,port,ACK) && count++<=MAX); if (ack) return port; status[port] = AVAIL; return 0; }

CSE 466 – Fall Introduction - 7 A look at Accept() int accept(int port, char c) { queue *inq, *outq; if (status[port] == BUSY) return 0; if (scan(inCtlQ, &c, port, CALL)) { status[port] == BUSY; outq = outQueues[port] inq = inQueues[port];// static allocation inq->src = outq->dst = c; inq->port = outq->port = port; enq(outCtlQ, c); enq(outCtlQ, port); enq(outCtlQ, ACK);// send an acknowledgement } return port; }

CSE 466 – Fall Introduction - 8 The rest of the Functions int send(char port, char c) { queue *outq; if (status[port] == AVAIL) return 0; outq = outQueues[port]; enq(outq,c); //blocking } int recv(char port, char *c) { queue *inq; if (status[port] == AVAIL) { return 0; } inq = inQueues[port]; return(deq(inq, c)); //non blocking } int close(char port) { queue *outq; if (status[port] == AVAIL) return 0; outq = outQueues[port]; while(!empty(outq)); enq(outCtlQ, outQueues[port]->dst); enq(port); enq(outCtlQ, CLOSE) ; status[port] = AVAIL; return 1; } physical/datalink layer has to provide flow control guarantees security/validation I2C does not enforce indentification of the sender!

CSE 466 – Fall Introduction - 9 Physical Layer API (same as Lab)  enq(), deq(), scan()  Periodically  if not currently master and there is a non-empty outgoing queue  select non-empty outgoing queue and attempt to become bus master by sending start condition  On Interrupt  if bus master and not end of frame (data queue empty, control queue new command) send next byte, otherwise send stop condition  if currently bus slave  get byte and place into appropriate queue based on frame header info  Deal w/ flow control somehow (control frames for acknowledgement)  Deal w/ Security dst port Timer Interrupt and External Interrupt Routines Function Calls

CSE 466 – Fall Introduction - 10 Phew…is it just TCP?  Probably. I tried to find a TCP/I2C stack but no hits on the web. Its probably been done  What’s the embedded way?  Get an OS w/ a built in stack…you can get these  Give up on layers… write a non-layered special purpose protocol  Most companies with a product line will  develop a hardware platform  develop kernel and networking infrastructure  churn out products by writing primarily at the application layer

CSE 466 – Fall Introduction - 11 A simple monolithic solution  Keep same frame specification, except all data packets are one byte  On I2C Interrupt  if master send next byte frame or stop  if slave, get next byte of frame.  If complete frame received  if NACK frame from dst set avail  if call and busy, queue up NACK frame  if data and avail ignore  if call and avail set busy, set dst, queue up ACK frame  if data and busy and wrong dst ignore  if data and busy and right dst display  On keypress  if not busy queue up CALL frame, signal initMaster  if busy, queue up data frame, signal initMaster  No flow control or error handling

CSE 466 – Fall Introduction - 12 Finishing out the Term  Option 1: A final lab assignment … to be negotiated.  Some improvement on music player (I think we can do 20K music at 11 MHz anyway). Maybe Streaming from NT through one player to another player over I2C. No upload needed.  Chat  A PCB for the Music Player w/I2C and Serial ports  Option 2: A report/presentation  design approaches for some existing system  fuzzy logic controller for people movers  automotive apps and networking (ECU, Airbag, CAN)  Embedded TCP (IP?/I2C?)  Embedded web-servers  Robots  Convergence devices  hw that we didn’t cover  motors  watchdog circuits  DAC, ADC  display…vga/lcd  radios  flash  audio codec

CSE 466 – Fall Introduction - 13