Microcomputer Engineering 2 Assignment Manual 2018/2019 Part 1: Introduction Part 2: The Assignments Basic IO with C++ and mbed Mini-Project Part 3: Circuit Diagrams Microcontroller Board I/O Board Dr. Peter Green School and Electrical and Electronic Engineering University of Manchester EEEN20019 Microcontroller Engineering II 1. Organisation of Assignments and Assessment This section contains important information. Please read it! 1.1. Introduction TO FINISH This unit aims to help you develop the knowledge and skills to program simple embedded systems in the C programming language. This is a practical objective, so the module is supported by two laboratory-based assignments. These assignments make up the coursework for this unit. Each assignment requires a range of activities: (i) Independent study of lecture notes, exercise sheet questions and answers, and technical documentation (ii) The completion of assessed preparatory work before the start of the ????? (iii) Laboratory work involving the development of C++/C programs based on the specifications contained in the Assignment Scripts included in this document. 1.2 Laboratory Organisation (i) You will attend four laboratory sessions. The first 2 are concerned with Assignment 1, the second two with Assignment 2. Lab sessions last for 1 hour 50 minutes and take place in the Barnes Wallis building. (ii) You will be allocated to one of four groups (1, 2, 3 or 4). The allocation of students to groups will be posted on Blackboard at the end of week 1. (iii) Each group attends laboratory sessions every two weeks. The first lab sessions are in week 3. (iv) There are 2 Assessment Sessions (week 7 and week 12), where your programs will be marked. 1.3 Equipment The equipment to be used in the laboratory assignments is: • A laboratory PC You will be allocated a PC in the Barnes Wallis cluster and you will use this machine in all your Micro 2 sessions. • An ST Nucleo Board (NB) - Nucleo F401RE. • An mbed Application Shield (AS) • A USB cable to connect the NB to a PC 6You will each be given a NB/AS/USB cable when you return your PIC microcontroller board1. Details of when NSs etc will be distributed will be posted on Blackboard. This is likely to be at the start of week 2. The NB/AS/USB cable must be returned along with all your Embedded Systems equipment at the end of semester 2 YOU MUST bring your NB/AS/USB cable to all Micro 2 sessions in the Barnes Wallis cluster. Spares cannot be provided. You are also advised to bring a calculator, a copy of the lecture notes, a copy of the laboratory script, paper and a pen/pencil. Personal laptops and tablets can be used and tablets can be used in lab sessions BUT NOT IN ASSESSMENT SESSIONS. 1.4 Marks The coursework is worth 20% of the total unit mark. The mark allocation for the individual coursework components is detailed in the table below: Coursework component Mark as a fraction of the total unit mark Takes place Assessed in Assignment 1 9% Weeks 3, 4, 5 and 6 Week 7 Assignment 2 11% Weeks 8, 9, 10 and 11 Week 9 1.5 Missed Laboratories and Deadlines If you think you have a legitimate reason for missing a laboratory session, contact your personal tutor to explain the situation. If your tutor agrees that your reason is legitimate, then he/she should send me an email detailing why you need to reschedule your lab session. However, on-line preparatory work must be completed by the original deadline. 1.6 Laboratory Rules Pen drives/other removable media may NOT be used during lab sessions. Programs written before the start of the session should be stored on your P drive, and downloaded at the start of the session. Alternatively, you may arrive early and copy your own pre-written code from a pen-drive before the session begins. All other rules regarding conduct in laboratories in general, and the Barnes Wallis cluster in particular, must be observed. 1.7 Assessment of Programs The programs that you develop for Assignment 1 will be assessed in Week 7. Those developed for Assignment 2 will be graded in Week 12. 1 The return of a PIC board does NOT apply to direct entry students. 7• You must upload ALL your Assignment 1 programs to Blackboard by midnight on the Friday of Week 62. If you do not, you will receive a mark of 0 for Assignment 1. • You must upload ALL your Assignment 2 programs to Blackboard by midnight on the Friday of Week 112. If you do not, you will receive a mark of 0 for Assignment 2. • All uploaded programs should include the following information in comments at the start of the program: student name, student id, lab group, program title, and date. • Any additional information required for assessment will be specified via Blackboard at least 1 week before the Assessment Sessions. • Details of the upload procedure will be posted on Blackboard before Week 6. During each of the Assessment Sessions, you will be interviewed by a demonstrator or member of staff for up to 10 minutes. During this time you will be expected to demonstrate your most complex working program (see Section ??? for further details). You will also be required to explain how your programs work and to answer questions about them. Note: • Programs that do not work will be awarded a mark of 0. • The quality of your explanations and answers will have a significant effect on the marks that you will be awarded 1.7.1 The Last Week of the Semester Attendance at both Assessment Sessions is mandatory. Note carefully that if you leave Manchester before the Assessment Session in Week 12 you will be awarded a mark of 0 for Assignment 2. 1.7.2 Plagiarism Plagiarism in programming assignments is very easy to detect, even if function and variable names have been changed. Do not be tempted to cheat and copy someone else’s work – you will not gain any understanding or expertise, and you will be caught. The School’s disciplinary procedures will be invoked against ANYONE involved in acts of plagiarism. See your course documentation for further details. 2 In the event of DOCUMENTED problems with Blackboard, programs may be emailed to: . These will be accepted so long as the email transmission time is before midnight. 8EEEN20019 Microcontroller Engineering II 2. General Advice Most inexperienced programmers find programming a difficult3 and frustrating experience, but one which is ultimately very rewarding. In recognition of this difficulty, you should expect to spend between 12 and 16 hours on each of the two assignments. This includes the scheduled laboratory session. The time that you spend working on the assignment before the laboratory session should include the following: • Thoroughly reading the assignment scripts. • Thoroughly reading the relevant lecture notes, specified in the assignment script. • Attempting problems on the exercise sheets, as specified in the assignment script. • Reading any technical documentation indicated by the assignment script. This will include the microcontroller’s data sheet [1], reference manual [2], the HAL/LLL document. All are available on the unit’s Blackboard pages. • Completing the preparatory work. • Developing and testing prototype versions of the programs described in the laboratory script. You should try to ensure that you have completed at least the first part of an assignment before the start of the corresponding laboratory session. • Asking questions after lectures or by email, if appropriate. These activities will significantly enhance your ability to complete the assignments successfully, and will help with your preparation for the written examination in January. 1.6 Contacting Me I am happy to be contacted via email about any aspect of the unit. It is usual for me to receive very high volumes of email from the class, given the nature of the unit, but I try to respond within 24 hours. To help me be responsive, I would ask you to do the following: (i) Always start the subject of the email with MCE2, for example: Subject: MCE2 Query about assignment 1 3 In fact, most programmers find programming difficult, full stop. It is simply that the more experienced you become, the more you become accustomed to the pain. 9This is necessary as I use an email filter to separate out emails related to this unit from the rest of my mail. If you don’t do this, I may miss your message and you may not get a response to your question. (ii) ALWAYS include your group number in your emails. If you don’t, I’ll simply reply by asking for this information. 10Unit Plan 2018/2019 Date Week Labs Type of session Groups Lectures 24/9/18 1 No Lab 1. Intro 2. ARM Review 3. Intro to OOP 1/10/18 2 Intro and basic C++ 1 hour per group 4. OOP C and O 1 5. Mbed 6. Digital IO 8/10/18 3 Digital and analogue IO with mbed Lab 1 2 7. ADC 1 8. ADC 2 15/10/18 4 Digital and analogue IO with mbed Lab 3 4 9. Interrupts 1 10. Interrupts 2 22/10/18 5 Timers and callbacks with mbed Lab 1 2 11. Timers 1 12. Timers 2 29/10/18 6 Timers and callbacks with mbed Lab 3 4 Revision Revision 5/11/18 7 Timers and callbacks with mbed Assessment 1, 2, 3 4 13. OOP C and O 2 14. Inheritance 12/11/18 8 Mini-project Lab 1 2 15. Serial Comms 1 16. Serial Comms 2 19/11/18 9 Mini-project Lab 3 4 17. LLL Programming 1 18. LLL Programming 2 26/11/18 10 Mini-project Lab 1 2 19. Buffers 20. FSMs 1 3/12/18 11 Mini-project Lab 3 4 21. FSMs 2 Revision 10/12/18 12 Mini-project Assessment 1, 2, 3 4 Revision Revision 113. Software Development Environments Two software development environments will be used in this unit: • Mbed • Keil µVision Both of these are ARM products and will be discussed briefly below. 3.1 Mbed Mbed is a ‘platform’ – essentially, it is a set of C++ class libraries (APIs4) that enable programmers to control embedded systems peripheral devices in a large variety of Cortex-based microcontrollers. Other key parts of the platform. are: • A real-time operating system (RTOS) • An on-line compiler The RTOS is beyond the scope of this unit (but such matters are discussed in the 3rd year unit Concurrent Systems). However, extensive use of the on-line compiler will be made. This is extremely easy to use, and the best way to start is to watch the following video: https://www.youtube.com/watch?v=L5TcmFFD0iw This shows how to register with Mbed and then how to use the compiler. Once you have access to the on-line compiler you will be asked to specify the board you are working with. For this unit, the NUCLEO-F401RE board should be specified, and an icon representing it will appear near the top-right corner of the page. Go to the Mbed pages for the Nucleo-F401RE board: https://os.mbed.com/platforms/ST-Nucleo-F401RE/ This contains a short video introduction to the board (worth watching), information about pin-out and headers, and links to technical documentation from ST. It also has a Nucleo-based video introduction to using Mbed and the on-line compiler which is also worth watching. 4 The class libraries are APIs (Application Programming Interfaces), as are the LLL and the HAL. APIs consist of pre-written code (classes or functions) that enables applications programmers to access necessary resources e.g. hardware devices, operating system functions, communications protocols etc. 12This page also has links to a variety of simple Mbed programs that can be downloaded and run on your board: You are STRONGLY advised to download programs and experiment with them. However, you should be careful not to use this code directly in your assessed programs, as this would be an act of academic malpractice. Additional programs are available via the Application Shield’s Mbed page: https://os.mbed.com/cookbook/mbed-application-shield These may also be imported into the on-line compiler. However, they may require a small amount of customisation with respect to, for example, the pins that are specified in object constructors. 3.2 Keil µvision This is a sophisticated IDE (Integrated Development Environment) enabling C or C++ programs to be developed for an enormous range of ARM-based platforms. It can be used to develop programs that use the Lower Layer Libraries (LLL), the Hardware Abstraction Layer (HAL) and Mbed. Keil is more difficult to use than Mbed, but its support for program development, particularly in terms of debug, is very much better than the Mbed on-line compiler. A free version of Keil is available for download at: https://www.keil.com/download/product/ 13This limits the size of compiled programs to 50 Kbytes i.e. it does not allow very large programs to be compiled. However, this will not cause problems for the programs that will be developed in this unit. Moreover, the full version of Keil is available on the Barnes Wallis cluster (100 licences) which is not subject to this limitation. A video that describes setting up mVision can be found on the MCE2 Blackboard pages at: ??? Note that Keil only runs under Windows. However, if you have an Apple machine, you may be able to install Windows as a separate process and run µVision of top of that. Keil will be used during the second half of the unit. 142. Program Development In order to develop a program that meets its requirements, it is necessary to have a clear understanding of the program’s specification, and to design a solution. This involves deciding upon what components are needed in the program and how they work together. Components in a C program are functions and data structures, whereas in a C++ program, they are classes and objects. The standard method for organising large C programs in terms of .h and .c files5, which is discussed in Example Program 5, has similarities with the Object Oriented approach, so the remarks below are made in terms of OO concepts. Which components are needed in a program? The full answer to this question requires a course in Systems Analysis, and more will be said on this topic in the Embedded Systems Project. However, for this unit, hardware devices that must be controlled by a program are good candidates for components, as are objects that control the behaviour/sequencing of other objects, for example, the Sequencer class in Example Program 3. Objects that temporarily store data such as buffers and stacks are also common. Note that the selection of components is an ITERATIVE process – you are unlikely to select exactly the right set at the start of development6. Once a plausible set of components has been selected, it is necessary to determine how they work together e.g. which functions call which other functions, the parameters that are needed and the results that are returned. Related flow-of-control issues involving interrupts/callbacks must also be considered. Next the operation of each function must be specified. In other words the algorithm used in the function designed or chosen7. To summarise, a design for a C++ program would involve at least the following: • A list of classes and a class diagram. • A list of function prototypes for each class • Declarations of any complex private data structures (e.g. list, stacks, buffers etc). • A description of the operation of each function in terms of pseudo-code, state machines etc. 5 Programs are divided into several source files (.c). Each .c file has a .h file with the same name (e.g. my_code.c and mycode.h). The .h file defines the prototypes of functions implemented in the corresponding .c file. It may also contain constants and typedefs. In OO terms the .h file defines the public interface of an object, whose implementation (in terms of function code and shared variables) is private - hidden inside the .c file. 6 You need to get used to the idea that you need to rework a solution to a design problem until it is satisfactory. This is a fact of life in ALL engineering design. 7 If an efficient algorithm exists to implement a particular function, it is often wise to use it. Numerical solution of differential equations, numerical integration, sorting and searching are 4 examples where algorithms would be chosen and not designed from scratch. 15After the design has been completed, the program must be implemented i.e. the actual code must be written. Note carefully how much thinking needs to be done before the coding stage is reached. Experience shows that starting to code without adequate preparation almost always leads to programs that do not work. You should take steps to back-up your programs, in particular those that actually work! As you will see, some of the later tasks make use of code developed in earlier tasks. Do not simply edit the earlier program, make a copy and edit that. Much of the code that you develop in this module will be useful to you in other contexts (e.g. the Embedded Systems Project, your third year project etc etc.), so be careful to preserve your investment of time and effort. 163. Programming Style. Embedded systems programming is an important activity in many engineering enterprises. These organisations always require code to be understandable, reusable and extendable. Hence, you are expected to adopt a mature, professional style. of C/C++ programming. This was introduced by example in your first year course and this will be continued in the example programs presented in this unit. However, the basic guidelines are as follows: (i) Use meaningful names for classes, functions, variables and types. (ii) Use indentation with control constructs i.e. the statements ‘belonging’ to functions, if, while, for etc. Statements within such a construct should be indented by 3 or 4 spaces with respect to the if, while, for etc statement. (iii) Make good use of comments, but avoid comments that state the obvious e.g. x = 0; // x is set to 0 (iv) Don’t use ‘magic numbers’ in your code. ‘Magic numbers’ are constant values used in expressions, as function parameters etc appearing without any explanation. For example: g_force = 9.8*mass; circumference = 6.28*radius; include the ‘magic numbers’ 9.8 and 6.28. Instead you should define these constants at the start of the program via #define G 9.8 #define PI 3.142 or const float g = 9.8, pi = 3.142; and then use the appropriate name in the statements to calculate acceleration and circumference. Basically, application constants and system constants (e.g. fixed addresses) should be defined as constants at the start of the program (or in a header file). (v) Use appropriate control constructs e.g. if you need a loop to execute a fixed number of times, use a for loop, NOT a while loop with a counter that you create. (vi) Use functions liberally, including 1 line functions, where it makes sense to do so. See the example programs. (vii) In C programs, do not use extern variables in place of auto or static variables8. Many of you will consider doing this. Don’t. (viii) White space (blank lines, tabs, spaces etc) are all good within reason, but don’t over-use them.转自：http://ass.3daixie.com/2018110120083428.html