Remainder of Syllabus

1. Remainder of Syllabus • Lecture • RTOS • Maestro In Linux • Distributed Control Architecture – distributed state management • Quiz • Embedded Networking • Safety and Society • Real Time UML • Quiz/Final • Lab • This week: streaming demo required…no report • Next week: Two-way pilot-player interface, full “player” UI w/ pause, etc. no resetting of processor for next song! Time to clean up. • I2C network • I2C network • upgrade? CSE 466 – Fall 2000 - Introduction - 1

2. Linux Interprocess Communication • Semaphore process 1: semid = getsem(semid); semop(semid, -1); // wait process 2: semid = getsem(semid); semop(semid,1); // signal • Pipes (queue) void main() { int pfds[2]; pipe(pfds); if (fork()) producer(); else consumer(); } void producer() { // serial? int q = pfds[0]; while (1) write(q, data, n); } void consumer() { // music? int q = pfds[1]; while (1) read(q, data, n); } CSE 466 – Fall 2000 - Introduction - 2

3. FIFO’s, which are named pipes • Process 1 void main() { mknod(“myfifo”, S_IFIFO, ); // create a FIFO file node f = open(“/usr/larrya/myfifo”, O_WRONLY); write(f, data, n); } • Process 2 void main() { f = open(“/usr/larrya/myfifo”, O_RDONLY); read(f, data, n); } CSE 466 – Fall 2000 - Introduction - 3

4. A Player? void main() { int pfds[2]; pipe(pfds); if (fork()) serial(); else consumer(); } void serialTask() { // serial? int q = pfds[0]; s = open(“/dev/com1”, O_RDWR); while (1) {read(s, data, 1); write(s,ack, 1); write(q, data, 1); } void musicTask() { // music? int q = pfds[1]; while (1) { semop(semid, -1); processNextPacket(read(q, data, n)); } now all we need as an ISR, right? CSE 466 – Fall 2000 - Introduction - 4

5. Not Quite • Not yet • User programs are not allowed to access the physical devices (physical memory space) – including hardware interrupts. Only the OS can do that. • User programs can’t control when things happen • OS slice is about 10ms, maybe 1ms on some machines • If there are many tasks, our musicTask might not meet its deadline.. • Need a device driver • Its part of the operating system • It can include an interrupt service routine • What is a device driver? • The interface is the same as a file on the disc • supports standard file I/O interface • open() • read() • write() • close() • Driver writer defines these system calls to provide a useful general device to the public CSE 466 – Fall 2000 - Introduction - 5

6. Partition between the User App and The Driver • Device Driver should be general…what would a player look like? • open() – makes sure that hardware resources are available…not being used by another device for example. Registers the interrupt service routine • read() – nothing? can be defined to return current packet? • write() – adds packets to the queue? so, maybe our SERIAL is the user app, and our MUSIC/ISR is the OS/Device Driver. write should fail if it isn’t a proper music packet: three tones and duration. • close() – release the hardware resources • Now…how do we get a good trade-off between interrupt latency and timeliness+ • Need an ISR for the tone generation and tone duration counting • Where can we put the housekeeping? • ISR? • device driver? • User App? CSE 466 – Fall 2000 - Introduction - 6

7. Answer: In the ISR…sort of • Linux Nomenclature for Interrupt handling • Top Half – the actual ISR. Time critical stuff • Bottom Half – the Time dependent, less critical stuff. Signaled by the ISR Top Half: Tone Generation user space int task queue User App ie. stream cse466 format music from serial port to player Bottom Half: Housekeeping kernel space system call Device Driver Interface (open, read, etc.) CSE 466 – Fall 2000 - Introduction - 7

8. Schedule of task queues…bottom halves in Linux blah() blah() blah() other app interrupt TOP HALF add to task queue, and mark execution BOT. HALF blah() blah() blah() rti no critical section here BOT HALF and Device Driver are mutually exclusive. Not true for Top Half, so this is a good way to share data between driver and ISR sys callor tick OS: Schedule or sys call Device Driver EXECUTE TASK QUEU myapp blah() blah() blah() write() CSE 466 – Fall 2000 - Introduction - 8

9. As a Task Diagram ISR TOP ISR BOT OS/driver OS/other myapp process 2 process 1 myapp: blocked by driver on full queue myapp: write(player…) ISR BOT and Driver are mutually exclusive, so no problem with shared data structure. CSE 466 – Fall 2000 - Introduction - 9

10. The Application void main() { if (serial = open("/dev/com3", O_RDWR) == -1) exit(); // open serial port if (player = open("/dev/player", O_RDWR) == -1) exit(); // open player device while (1) { read(serial, &byte, 1); // blocking read write(serial, &ack, 1); // send acknowledgement switch(state) case STREAMING: read(serial,packet,1); // maybe better if non-blocking ? n = getNumTones(*packet); read(serial, packet+1, n); // read the tone bytes TNE = getTNE(packet); // set new TNE if (isStop(packet)) { close(serial); // close the I/O close(player); // close the player, release the HW resources exit(); } getTones(packet, writeBuf); // convert packet to tones writeBuf[3] = duration; // add duration write(player, writeBuf, 4); // write to the player break; case IDLE: if (byte == 'S') { state = STREAMING; read(serial,&duration,1); // time slice duration...this is a blocking read } } } CSE 466 – Fall 2000 - Introduction - 10