C Programming. A quick introduction for embedded systems. Dr. Alun Moon UNN/CEIS. September 2008

Transcription

1 C Programming A quick introduction for embedded systems Dr. Alun Moon UNN/CEIS September 2008 Dr. Alun Moon (UNN/CEIS) C Programming September / 13

2 Programming is both an art and a science. It is an art in the sense of a master craftsman. In this guide I hope to introduce the thinking behind programming. It is aimed at those needing to program in C, but the skills of a programmer are independent of the language used. Remember, programming cannot be learnt by simply reading a book. It has to be learnt through practice writing programs! Take the time to practice, write your own solutions to the problems here and the exercises given. Look at my solutions, but they will be different to yours, after all I ve been doing this a lot longer. Take the time to read through and learn from my solutions. But don t forget to write your own. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

3 Program Design I a few simple steps Identifying features in the program. Is the first step taking the problem into the design. It is the process of identifying what the essential functions of the program are to be. Just as important is identifying what is not needed. Breaking the problem down into smaller pieces. Most problems can be broken down into smaller pieces. Either as distinct sub-programs or as a series of tasks within a program, or even function. This functional decomposition allows a complex task to be reduced to smaller simpler pieces that fit together to perform the task. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

4 Program Design II a few simple steps Identifying functions and writing the prototype. Once the tasks have been found, often they can be written down as the names of functions to use. With the name goes the information that the function needs and the values it returns. Writing the program logic. Once the functions are known, what they do can be transfered into the program logic. The logic for a function can be very simple or complex depending on the task. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

5 File contents C programming Good practice Program source files are simply text files. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

6 File contents C programming Good practice Program source files are simply text files. They can be worked on by any editor Dr. Alun Moon (UNN/CEIS) C Programming September / 13

7 File contents C programming Good practice Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

8 File contents C programming Good practice Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Dr. Alun Moon (UNN/CEIS) C Programming September / 13

9 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

10 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Corollary (Treat programs as documents) Dr. Alun Moon (UNN/CEIS) C Programming September / 13

11 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Corollary (Treat programs as documents) express concepts with clarity Dr. Alun Moon (UNN/CEIS) C Programming September / 13

12 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Corollary (Treat programs as documents) express concepts with clarity readability Dr. Alun Moon (UNN/CEIS) C Programming September / 13

13 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Corollary (Treat programs as documents) express concepts with clarity readability comment when code is not clear Dr. Alun Moon (UNN/CEIS) C Programming September / 13

14 C programming Good practice File contents Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. the linker control file is another text file Corollary Since source files are text, they can be created and edited by other programs. Corollary (Treat programs as documents) express concepts with clarity readability comment when code is not clear reference them Dr. Alun Moon (UNN/CEIS) C Programming September / 13

15 Rob Pike rules[7] C programming Good practice 1 You can t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don t try to second guess and put in a speed hack until you ve proven where the bottleneck is. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

16 Rob Pike rules[7] C programming Good practice 1 You can t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don t try to second guess and put in a speed hack until you ve proven where the bottleneck is. 2 Measure. Don t tune for speed until you ve measured, and even then don t unless one part of the code overwhelms the rest. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

17 Rob Pike rules[7] C programming Good practice 1 You can t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don t try to second guess and put in a speed hack until you ve proven where the bottleneck is. 2 Measure. Don t tune for speed until you ve measured, and even then don t unless one part of the code overwhelms the rest. 3 Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know then n is frequently going to be big, don t get fancy. (Even if n does get big, use Rule 2 first.) Dr. Alun Moon (UNN/CEIS) C Programming September / 13

18 Rob Pike rules[7] C programming Good practice 1 You can t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don t try to second guess and put in a speed hack until you ve proven where the bottleneck is. 2 Measure. Don t tune for speed until you ve measured, and even then don t unless one part of the code overwhelms the rest. 3 Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know then n is frequently going to be big, don t get fancy. (Even if n does get big, use Rule 2 first.) 4 Fancy algorithms are buggier than simple ones, and they re much harder to implement. Use simple algorithms as well as simple data structures. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

19 Rob Pike rules[7] C programming Good practice 1 You can t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don t try to second guess and put in a speed hack until you ve proven where the bottleneck is. 2 Measure. Don t tune for speed until you ve measured, and even then don t unless one part of the code overwhelms the rest. 3 Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know then n is frequently going to be big, don t get fancy. (Even if n does get big, use Rule 2 first.) 4 Fancy algorithms are buggier than simple ones, and they re much harder to implement. Use simple algorithms as well as simple data structures. 5 Data dominates. If you ve chosen the right data structures and organised things well, the algroithms will always be self-evident. Data structures, not algorithms, are central to programming. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

20 C programming Good practice Philosopy of good programs I The Art of Unix Programming[8] 1 Rule of Modularity: Write simple parts connected by clean interfaces. 2 Rule of Clarity: Clarity is better than cleverness. 3 Rule of Composition: Design programs to be connected to other programs. 4 Rule Rule of Separation: Separate policy from mechanism; separate interfaces from engines. 5 Rule of Simplicity: Design for simplicity; add complexity only where you must. 6 Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. 7 Rule of Transparency: Design for visibility to make inspection and debugging easier. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

21 C programming Good practice Philosopy of good programs II The Art of Unix Programming[8] 8 Rule of Robustness: Robustness is the child of transparency and simplicity. 9 Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. 10 Rule of Least Surprise: In interface design, always do the least surprising thing. 11 Rule of Silence: When a program has nothing surprising to say, it should say nothing. 12 Rule of Repair: When you must fail, fail noisily and as soon as possible. 13 Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

22 C programming Good practice Philosopy of good programs III The Art of Unix Programming[8] 14 Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. 15 Rule of Optimization: Prototype before polishing. Get it working before you optimize it. 16 Rule of Diversity: Distrust all claims for one true way. 17 Rule of Extensibility: Design for the future, because it will be here sooner than you think. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

23 Reading I C programming Good practice S. P. Harbison and G. L. Steel, C: A Reference Manual, Prentice Hall, 5 ed., March Good reference, covers the C99 standard. S. Holmes, C programming. Internet tutorial, University of Strathclyde Computer Centre. An excellent online tutorial for C programming, (recommended). A. Hunt and D. Thomas, The Pragmatic Programmer, Addison-Wesley, Oct A good book on the practice of writing programs. Not tied to a particular language, and has examples in C, Java etc. Has some very useful ideas about orgainising the process of programming. B. W. Kernighan and D. Ritchie, C Programming Language (2nd Edition), Prentice Hall PTR, March Dr. Alun Moon (UNN/CEIS) C Programming September / 13

24 Reading II C programming Good practice S. Kochan, Programming in C, Sams, 3 ed., July A good book for students who are serious about C. M. McGrath, C in easy steps, ineasy steps, Computer Step, 2 ed., June A good conversion text that covers the basics. R. Pike, Notes on programming in c. E. S. Raymond, The Art of Unix Programming, Professional Computing Series, Addison-Wesley, Dr. Alun Moon (UNN/CEIS) C Programming September / 13

25 Program structure Program structure There are a number of repeated patterns that occur in programs. These are both how the program interacts with the outside world and the internal structure of the program. Understanding how these patterns work and applying them to the implemetation of probles is the key to effective programming. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

26 Program structure External External structure Cooperating programs Programs can be designed to act together, the output from one becomes the input to the next. The actual mechanism is handled by the outside environment. input Program a Program b output Dr. Alun Moon (UNN/CEIS) C Programming September / 13

27 Program structure External Corollary The upshot of this is that the formats of the input and output data are important in designing a program. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

28 Program structure External Corollary The upshot of this is that the formats of the input and output data are important in designing a program. Corollary Design programs to cooperate. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

29 Program structure External Corollary The upshot of this is that the formats of the input and output data are important in designing a program. Corollary Design programs to cooperate. Corollary Sometimes a problem can be split into separate cooperating programs. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

30 Program structure Internal structure There are two basic patterns that are useful at this stage for thinking about the internal structure of a program. These can apply at any level Most programs have the same basic internal structure. 1 initialise the program. Set up data structures, parameters and constants. initialise 2 process perform the operations of the program. process finish 3 finish clean up after the program. This pattern applies at any scale, the program as a whole, a function, a loop within a block of code. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

31 Program structure Internal structure The processing performed by the program follows a similar pattern read 1 read some data 2 process the data process 3 write the results. write Usually there is some loop wrapped around this pattern. Depending on the problem the processing can occur for each item read, or all the data needs to be read before the processing can occur. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

32 Unix C programs are written to run under Unix. any text editor, vi, emacs, gedit, scite, etc. will do. gcc is a command line tool that combines the functions of compiler assembler linker the files likely to be encountered are C source C header object executable Dr. Alun Moon (UNN/CEIS) C Programming September / 13

33 Unix framework assembler converts assembly code into object files compiler converts c-code into object filrs linker combines object files together debugger controls running of the program to allow execution of single instructions and examine contents of variables There are a number of commonly used file extensions used in C and assembly programming. Most of these are common to all systems. The various tools assume these extensions are used. input Program output Dr. Alun Moon (UNN/CEIS) C Programming September / 13

34 Unix framework Program source files are simply text files. They can be worked on by any editor All an IDE does is wrap up an editor and the invocation of the tools in a single front-end. Corollary the linker control file is another text file Since source files are text, they can be created and edited by other programs. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

35 Tools Object files An object file contains the output generated by assemblers and compilers. The bulk of the content is the image for blocks of memory, describing the address-range and the contents. some blocks are given absolute (fixed) addresses some blocks are relocatable in that the block as a whole can be put at any valid location in memory Object files contain unresolved references to labels. i.e.memory addresses and subroutine calls using address labels that do not yet have a known address. Example mov a, data jsr double jsr sin mov b, scale data dc.w 1024 double mov a,b add b,a Dr. Alun Moon rts (UNN/CEIS) C Programming September / 13

36 Tools Assembler The assembler is a simple program that takes an assembly language program and generates an object file..o.s Assembler Dr. Alun Moon (UNN/CEIS) C Programming September / 13

37 Tools Compiler The compiler is a complex program that grenerate an object file from a C source file. (Strictly it generates an assemly language source that is then assembled.). However there is a problem in that the compiler complains about unresolved function and variable names. Which is why we have header files. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

38 Tools Compiler C does not like forward references Definition (Forward reference) A forward reference is where we can use a function or variable in the program, before we have declared it to exist It is a similar problem to that of unresolved references in assembly language programs. Corollary We have to tell the compiler about functions and variables before we need them. Dr. Alun Moon (UNN/CEIS) C Programming September / 13

39 Tools Compiler Example (dblib.h) e x t e r n double p o w e r f a c t o r ; double d e c i B e l l ( doubl Example (dblib.c) #i n c l u d e <math. h> double p o w e r f a c t o r ; double d e c r a t i o ) { r e t u r n 10.0 l o g 1 0 ( r a t i o ) ; } Example (prog.c) #i n c l u d e d B l i b. h v o i d main ( v o i d ) { p o w e r f a c t o d e c i B e l l ( ) ; } Dr. Alun Moon (UNN/CEIS) C Programming September / 13

40 Tools Compiler The preprocessor handles the include! and define! lines in the c source file. the include! reads in the given file at that point in the program, where the preprocessor looks for the file depends on the quoting, angle brackets <>: look in the standard system locations quotes "": look in the working directory Dr. Alun Moon (UNN/CEIS) C Programming September / 13

41 Tools Linker Dr. Alun Moon (UNN/CEIS) C Programming September / 13