embedded
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| embedded [2020/04/05 17:54] – created jrseti | embedded [2020/04/05 18:57] (current) – [Tips] jrseti | ||
|---|---|---|---|
| Line 9: | Line 9: | ||
| - Power | - Power | ||
| - Processing power | - Processing power | ||
| + | |||
| + | =====Tips===== | ||
| + | |||
| + | On ARM Processors: | ||
| + | |||
| + | * Unordered List ItemGenerally local variables are allocated in registers. However if we take the address of a local variable, compiler will not allocate the variable to register. | ||
| + | * The compiler will never put the global variable into register. | ||
| + | * Try to ensure that small functions take four or fewer arguments. These will not use the stack for argument passing. It will copied into registers. | ||
| + | * If a function needs more than four arguments, try to ensure that it does a significant amount of work, so that the cost of passing the stacked arguments is outweighed. | ||
| + | * Pass pointers to structures instead of passing the structure itself. | ||
| + | * Put related arguments in a structure, and pass a pointer to the structure to functions. This will reduce the number of parameters and increase readability. | ||
| + | * Minimize the number of long long parameters, as these take two argument words. This also applies to doubles if software floating-point is enabled. | ||
| + | * Avoid functions with a parameter that is passed partially in a register and partially on the stack (split-argument). This is not handled efficiently by the current compilers: all register arguments are pushed on the stack. | ||
| + | * Avoid functions with a variable number of parameters. Varargs functions | ||
| + | |||
| + | On Arm there is the " | ||
| + | |||
| + | Example: | ||
| + | < | ||
| + | __pure int square(int x) | ||
| + | { return x * x; | ||
| + | } | ||
| + | </ | ||
| =====Integral Types====== | =====Integral Types====== | ||
| Line 37: | Line 60: | ||
| RW Data - read/write data | RW Data - read/write data | ||
| - | But mani | + | =====Bit manipulation===== |
| + | |||
| + | Binary can be like: 0c000100 | ||
| + | Remember XOR! | ||
| + | Great Macro: | ||
| + | #define MASK(0) ((uint8_t(1<< | ||
| + | |||
| + | ====Bit Fields==== | ||
| + | Better use of memory. | ||
| + | < | ||
| + | typedef union { | ||
| + | struct{ | ||
| + | unsigned monday : 1; | ||
| + | unsigned tuesday : 1; | ||
| + | unsigned wednesday : 1; | ||
| + | unsigned thursday : 1; | ||
| + | unsigned friday : 1; | ||
| + | unsigned saturday : 1; | ||
| + | unsigned sunday : 1; | ||
| + | } days; | ||
| + | uint8_t byte_sized; | ||
| + | } weekdays; | ||
| + | |||
| + | weekdays active_days; | ||
| + | active_days.days.monday = 0; | ||
| + | |||
| + | </ | ||
| + | |||
| + | =====Qualifiers===== | ||
| + | |||
| + | ====Volatile==== | ||
| + | Being specific about variables | ||
| + | |||
| + | **Volatile** – tells the compiler that the variable may change at any time by some source other than the code it’s compiling. This may avoid the compiler optimizing out a section of code that appears to never get execute due to a conditional. | ||
| + | |||
| + | * Blocking delays | ||
| + | * Loops that loop to delay | ||
| + | * Use volatile to avoid optimizing loop out | ||
| + | |||
| + | ====const==== | ||
| + | |||
| + | * Stored in ROM, use less space. | ||
| + | * #defines are simply replaces in-line by the compiler, canbloat. | ||
| + | * #defines are not visible to the debugger | ||
| + | * Try to use const if you can | ||
| + | |||
| + | =====Function Alternatives===== | ||
| + | |||
| + | * Functions use a lot of memory for the stack | ||
| + | * Lookup tables and inline functions use ROM | ||
| + | * Lookup tables are easy on the CPU | ||
| + | * | ||
| + | * Lookup tables are const arrays. Use const | ||
| + | * Limitations: | ||
| + | |||
| + | ====Macro Functions==== | ||
| + | |||
| + | #define square_macro(x) x*x | ||
| + | * part of the pre-processor | ||
| + | Error! | ||
| + | Square_macro(2+3) == 11, wrong answer! | ||
| + | |||
| + | * Macros should be one line | ||
| + | * Always in-line function. Bloat may occur, function would be better | ||
| + | |||
| + | ====Inline Functions==== | ||
| + | |||
| + | * Almost identical to regular functions | ||
| + | * Add the " | ||
| + | * The compiler may decide not to inline | ||
| + | * You can force the compiler to always inline | ||
| + | |||
| + | To force inlining: | ||
| + | < | ||
| + | Int square_AI(unsigned char x)__attribute__((always_inline)); | ||
| + | Int square_AI(unsigned char x) { | ||
| + | Return x*x; | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | To suggest inlining: | ||
| + | < | ||
| + | Int inline square_SI(unsigned char x){ | ||
| + | Return x*x; | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | Inline advantages over macros: | ||
| + | |||
| + | * Compiler checks parameter types | ||
| + | * Debugging is easier | ||
| + | |||
| + | =====Floating Point Alternatives===== | ||
| + | |||
| + | * Note that for a float 100, | ||
| + | * Use fixed point when you can anticipate the range | ||
| + | * Fixed point can be faster than float on processors without an FPU | ||
| + | |||
| + | =====System Design = Elevator===== | ||
| + | |||
| + | Design an elevator. Think about it, there are some user controls and indicators that need to be implements, some sensors and auto controls, some for safety. | ||
| + | |||
| + | Process car calls | ||
| + | Process hall calls | ||
| + | Indicate direction | ||
| + | indicate current floor | ||
| + | |||
| + | Move and stop the car | ||
| + | Emergency brake | ||
| + | Open/close the door | ||
embedded.1586109277.txt.gz · Last modified: 2020/04/05 17:54 by jrseti