CSE 466 – Fall Introduction - 1 Reentrant Driver open() { if (count++) return(0); else return(grab_resources()); } release() { if (--count) return(0); else return(release_resources()); } read() { if (read_count++) sleep_on_interruptible(&wq); else { start = getTime(); INIT = 1; sleep_on_interruptible(wq); INIT = 0; } compute_distance(); copy_to_user(); if (--read_count) INIT == ; return(length); } isr() { stop = getTime(); wake_on_interruptible(wq); } read() { if (INIT) sleep_on(&wq); else { start = getTime(); INIT = 1; sleep_on(wq); } compute_distance(); copy_to_user(); return; } isr() { stop = getTime(); INIT = 0; compute_distance() wake_on(wq); } still: a new read that occurs before the queue is emptied will overwrite “start” wake  INIT=0  read  blocked reader computes wrong distance problem: processes added to wq after wake_on may never get awakened! They have to wait until a read is attempted after the queue is emptied and INIT is turned off. read after wake problem

CSE 466 – Fall Introduction - 2 Use a Bottom Half! read() { if (INIT) sleep_on(wq); else { start = getTime(); INIT = 1; sleep_on(wq); } copy_to_user(); if (empty(wq)) INIT = 0; return; } isr() { // reads will still pile up on the wait queue until the bh executes. stop = getTime(); add_to_bh_queue(isr_bh); } isr_bh() { // make a new queue for all future reads, compute distance with correct start-stop data. sonar_result = Compute_distance(); // do this once per interrupt INIT = 0; tmp = wq; // re-initialize queue to catch for read calls wq = (wait_queue*) kmalloc(sizeof(wait_queue)); wake_on(tmp); // wake old queue } will each reader get the “correct” reading?

CSE 466 – Fall Introduction - 3 FIFO’s, which are named pipes  Process 1 void main() { mknod(“/tmp/myfifo”, S_IFIFO ); // create a FIFO file node f = open(“/tmp/myfifo”, O_WRONLY); while (1) {generate_data(buf); write(q, buf, n);} }  Process 2 void main() { f = open(“/tmp/myfifo”, O_RDONLY); while (1) {read(q, buf, n); process_data(buf);} }  Works for “unrelated” processes  Multiple writers, Multiple readers  Kernel ensures mutual exclusion  Kernel does not control interleaving of writers, readers

CSE 466 – Fall Introduction - 4 Multi-Processor Systems A Control Dominated Example H2H2 Air H20H20 Heat controller sense: Temperature H 2 Output Current Output Voltage Fan Speed control H2 valves Output MOSFET Fan Speed Stack MOSFETS not showing power supply circuitry for the controller…runs off fuel cell w/ backup battery.

CSE 466 – Fall Introduction - 5 System level Modes (Logical Structure) startup warmuponline offline shtdwn Self Check Fail Warm On Overload+ Off Self Check Pass Error off

CSE 466 – Fall Introduction - 6 State Table (*error conditions are mode dependent) ModeOutputs Tasks Signals New Mode OffLoad Disabled Power Supply Off Gas Valves Closed Power Button Enabled nonePower Button PushStartup Load Disabled Power Supply On Gas Valves Closed Initialize Temp Control H2 Detection Load Monitor UI Running Initialize Complete Warm Up Error Condition Detected* or shutdown request Shutdown WarmupLoad Disabled Power Supply On Gas Valves Open Temp Control H2 Detection Load Monitor UI Running Operating Temp ReachedOff Line Error Condition Detected* or shutdown request Shutdown Off LineLoad Disabled Power Supply On Gas Valves Open Temp Control H2 Detection Load Monitor UI Running On-Line Command Received (UI) On Line Error Condition or Shutdown request Shutdown On LineLoad Enabled Power Supply On Gas Valves Open Temp Control H2 Detection Load Monitor UI Running Off Line CommandOff Line OverloadOff Line Error Condition* or Shutdown Request Shutdown Load Disabled Power Supply On Gas Valves Closed Fan On Temp Control Schedule transition to Off state TimeoutOff

CSE 466 – Fall Introduction - 7 Examples of Mode Dependencies  Fan Speed Control:  In startup or shutdown mode always run minimum speed  otherwise attempt to maintain temperature set point  If fan doesn’t turn, issue badfan signal  Hydrogen Detection: always close hydrogen valves and issue h2dectected signal if hydrogen detected, except in startup mode.  Load Monitoring  If not online and output current > 0 or output voltage < min, then issue mosfet failure signal  If online and load current is > max allowed, or if output voltage is < min then turn on another stack. If all stacks are on, then issue overload signal.  UI Process  If “line” button pushed and online issue offline event, If offline issue online signal.  If “power” button pushed and not in off mode, then issue shutdown signal.

CSE 466 – Fall Introduction - 8 Logical Decomposition UI Next State Logic signals Temp Load H2 Task Output Logic inputs

CSE 466 – Fall Introduction - 9 Logical Implementation task stateMgr _task_ 0 { while (1) { recv_signal(&s); // blocking switch(state) startUp: switch(s) TOOHOT: state = SHTDWN; … break; … } synchronized volatile state; task tempControl _task_ 1 { while(1) { t = readTemp(); if (t > MAXT) send_signal(TOOHOT); //blocking if (t < MINT) send_signal(TOOCOLD); if (t < setpoint) increase_fan_speed(); if (t > setpoint) decrease_fan_speed(); wait(ThermalTime); }} task loadMonitor _task_ 2 { while(1){ if (state != ONLINE) if (getLoad() > 0) send_signal(BADFET); else if (getLoad() > MAXLOAD) send_signal(OVRLOAD); wait(LoadTime); }} task H2Monitor _task_ 3 { while (1) { if (state() != startUp) if ((getH2() MAXH)) send_signal(H2FAILURE); }} // let this process fill in all unused cycles! Issues: what are send_signal() and recv_signal()? How can synchronized state be implemented?

CSE 466 – Fall Introduction - 10 Physical Decomposition -- Layers State Mgr + UI load temp H2 Socket could be implemented in shared memory, internet, or anything in between. High level architecture can be independent of implementation choices. Synthesis Problem: Map processes and sockets to processors and networks. Optimize performance, latency, shared mem. Warning: usually not done this way for embedded systems…usually designer performs the physical decomposition and app is written to the hardware…not a good idea! state signals physical layer network layer application layer

CSE 466 – Fall Introduction - 11 Example of Physical Layer: SPI Bus Master Slave SCK SDO SDI SCK SDI SDO void isr() interrupt TIMER { SDR = S; while(!SPF); R = SDR; } void isr() interrupt SPF{ R = SDR; SDR = S signal(RECV); } shift reg shift reg

CSE 466 – Fall Introduction - 12 Multiple Slave Configuration Master Slave SCK SDO SDI SCK SDI SDO Slave SCK SDI SDO

CSE 466 – Fall Introduction - 13 ISO Layers Continued  Transport Layer: responsible for end-to-end protocol of user data buffer transmissions. Source and destination addresses are private – host to host.  Maps application space channel (socket) name to network address.  makes network packets w/ transport header and communicates w/ network layer.  Each layer has a peer-to-peer and an intra-stack protocol Transport -- TCP Network -- IP Datalink -- Ether Physical -- Etherethernet fiber Datalink -- Ether Network -- IP fiber ethernet Datalink -- Ether Network -- IP Transport -- TCP Network -- IP Datalink -- Ether Physical -- Ether write(s, buf,n);read(s, buf,n ); Application

CSE 466 – Fall Introduction - 14 Transport Network -- IP Transport Network -- IP Embedded Networking: Simplest Case  Simple case: socket name is the same as physical address. No mapping, we just need to break our message into frames…maybe  Physical Layer – typically low bandwidth, serial, byte oriented  Data link layer – read/write interface to the application  frames: destination address, data, checksum.  No mapping from sockets to network address  No mapping from network address to physical address (no routing) Datalink Physicalethernet fiber Datalink -- Ether fiber ethernet Datalink -- EtherDatalink Physical write(s, buf,n);read(s, buf,n ); Application

CSE 466 – Fall Introduction - 15 Master Slave Data Link Protocol  As an example frame is [destination address, command, data]  An acknowledgement frame is [address, data, checksum] Master Slave SCK SDO SDI SCK SDI SDO Slave SCK SDI SDO mux dstcmddatadsttypedata addrdatasumtypedatasum mux x x x

CSE 466 – Fall Introduction - 16 Multi-master Systems: I2C  Multi-mastered  Send and receive  Two wire (plus ground)  Packet oriented (block send)

CSE 466 – Fall Introduction - 17 Major Features of I2C

CSE 466 – Fall Introduction - 18 Physical Layer

CSE 466 – Fall Introduction - 19 Bit Transfer Transmitter Master

CSE 466 – Fall Introduction - 20 Who gets to be master The one who initiates a frame: A frame is: … OR … …

CSE 466 – Fall Introduction - 21 An I2C Byte Transfer Tx Device Rx Device master slave Rx MSB First MSB……………….LSB

CSE 466 – Fall Introduction - 22 A Complete Frame MSB……..LSB

CSE 466 – Fall Introduction - 23 Beauty of Layers  App doesn’t care if lower layer is SPI or I2C  How much can we isolate the physical differences?