Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

More documents

Recommendations

Info

Chapter 2 AUTOSAR 1 TASK(Task1) { Rte RECount Task1 divby2 0−−; if ( Rte RECount Task1 divby2 0 == 0 ) { run11(); } { run12(); 10 } if ( Rte RECount Task1 divby2 0 == 0 ) { Rte RECount Task1 divby2 0 = 2; } TerminateTask(); } Listing 2.6: Example code for Task1 The RTE generator also creates the source code for the tasks. The extract for Task1 is shown in listing 2.6. Here it can be seen that the runnable run11 is triggered every 100ms and runnable run12 every 50ms. This is done by activating the task every 50ms and executing the runnable run11 just any second call. The activation of the task every 50ms is done in the configuration of the operating system, which is also created from the generator. 2.8.3 Implementing the Runnables At the end listing, 2.7 shows how the runnable run12 can be implemented. The created API can be used to access the ports. Here it is just necessary to write the correct API to the source code. This code can then be compiled with the generated header file. Instead of the global variables for the sender–receiver communication shown in this example, also a function call can be used. The runnable would not get noticed about it. 1 FUNC(void, RTE APPL CODE) run12(void) { String8 val1; Int16 val2; ... 6 Rte Call rport1 parse(val1, &val2); ... 8 Rte Write pport1 intValue1(val2); ... 10 } Listing 2.7: Example code for run12 This also shows the first problem for sharing object code. If a component is compiled against such a header file with global variables, it is expected that a generator, which creates the whole API, does not create the same global variable. So the object code 22
2.9 Summary cannot be used. Therefore function calls have to be created for sharing object code. But this causes an overhead for the function invocation when accessing a port. 2.8.4 Conclusion of the Example This simple example shows some basic mechanisms defined in AUTOSAR. It presents the complexity of the XML configuration which is already reached by such a simple case. But it should help to understand, how the mechanisms described in this chapter are implemented in the source code. 2.9 Summary In summary AUTOSAR allows a strict distinction between functional parts (SWCs) of software and infrastructural parts (BSW), which just provides the necessary basis to run the SWCs. The functional components are developed independent with respect to AUTOSAR compliant interfaces and descriptions, which specify in a formal and detailed way, what resources are necessary to run a component. Additionally, it has to be specified, which conditions are provided by the hardware and the topology of the system. Then, the RTE generator creates automatically the RTE, which brings the two parts (SWCs and BSW) together. With the standardization of the BSW and the interfaces between each part of the BSW, the replaceability of parts increases and even with the MCAL it is possible to exchange microcontrollers with others, if there are AUTOSAR compliant MCALs available for the new controllers. 23
Page 1: Evaluation Environment for AUTOSAR-
Page 5: Danksagung An dieser Stelle möchte
Page 8 and 9: Contents 4 Goals 29 4.1 Background
Page 10 and 11: Contents Abbreviations 105 Bibliogr
Page 12 and 13: Chapter 1 Introduction not allow to
Page 14 and 15: Chapter 2 AUTOSAR 2.1 Architecture
Page 16 and 17: Chapter 2 AUTOSAR the hardware depe
Page 18 and 19: Chapter 2 AUTOSAR Basic task Basic
Page 20 and 21: Chapter 2 AUTOSAR communications. T
Page 22 and 23: Chapter 2 AUTOSAR DataReceivePoint
Page 24 and 25: Chapter 2 AUTOSAR mode A mode depen
Page 26 and 27: Chapter 2 AUTOSAR not absolutely tr
Page 28 and 29: Chapter 2 AUTOSAR 1 types Int
Page 30 and 31: Chapter 2 AUTOSAR 1 swc root
Page 34 and 35: Chapter 2 AUTOSAR 24
Page 36 and 37: Chapter 3 MEDC17 3.2 Basic Software
Page 38 and 39: Chapter 3 MEDC17 28
Page 40 and 41: Chapter 4 Goals Communication The c
Page 42 and 43: Chapter 4 Goals 4.1.3 Development o
Page 44 and 45: Chapter 4 Goals files for special p
Page 46 and 47: Chapter 5 Analysis and Design test
Page 48 and 49: Chapter 5 Analysis and Design 38 na
Page 50 and 51: Chapter 5 Analysis and Design confi
Page 52 and 53: Chapter 5 Analysis and Design group
Page 54 and 55: Chapter 5 Analysis and Design direc
Page 56 and 57: Chapter 5 Analysis and Design The s
Page 58 and 59: Chapter 5 Analysis and Design 48
Page 60 and 61: Chapter 6 Implementation of the Tes
Page 82 and 83:
Chapter 6 Implementation of the Tes
Page 84 and 85:
Chapter 6 Implementation of the Tes
Page 86 and 87:
Chapter 7 Test Cases These examples
Page 88 and 89:
Chapter 7 Test Cases • The AUTOSA
Page 90 and 91:
Chapter 7 Test Cases SWC1 run11 SWC
Page 92 and 93:
Chapter 7 Test Cases 1 #include #i
Page 94 and 95:
Chapter 7 Test Cases 1 #ifndef TEST
Page 96 and 97:
Chapter 7 Test Cases 7.3.2 Implemen
Page 98 and 99:
Chapter 7 Test Cases 1 FUNC(void, R
Page 100 and 101:
Chapter 7 Test Cases 7.9. The sourc
Page 102 and 103:
Chapter 8 Conclusion Since a templa
Page 104 and 105:
Appendix A Example /interfaces/CS
Page 106 and 107:
Appendix A Example /interfaces/SR
Page 108 and 109:
Appendix A Example 98
Page 110 and 111:
Appendix B Requirements of the Func
Page 112 and 113:
Page 114 and 115:
Page 117 and 118:
Bibliography [1] FlexRay Protocol S
show all

Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?