meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
programming:c:ceedling [2021/04/22 11:10] – niziakprogramming:c:ceedling [2021/04/22 16:55] (current) – niziak
Line 1: Line 1:
 ====== Ceedling ====== ====== Ceedling ======
   * **support files ** - additional C files needed for tests but not for project (not added to project src).   * **support files ** - additional C files needed for tests but not for project (not added to project src).
-  * + 
 +====== Hints ====== 
 +  * Orgranize code into very small functional modules. 
 +  * Make separate ''.h'' for each ''.c'' module. 
 +  * Try to create separate ''.h'' for types and separate for function prototypes (it helps later with mocking) 
 +  * Always wrap HAL or other lower parts using some thin wrappers 
 ===== add .c file  ===== ===== add .c file  =====
  
-When ceedling fails to pickup automatically .c file it can be added to given test by+When ''ceedling'' fails to pickup automatically .c file it can be added to given test by
 <code c> <code c>
 TEST_FILE("source_file_to_compile.c") TEST_FILE("source_file_to_compile.c")
Line 14: Line 20:
 All dependent includes needs to be added manually in test ''.c'' file. All dependent includes needs to be added manually in test ''.c'' file.
  
-To automatically add linked resources there is a project option:+This is desired behavior because ''ceedling'' gives you control how to treat additional dependeny headers.  
 +Perhaps you should break dependency chain by including mocked header. 
 + 
 +<code c> 
 +# This will include 20 another headers :) 
 + 
 +#include "cpu_hal.h" 
 + 
 +# To prevent this: 
 +#include "mock_cpu_hal.h 
 +</code> 
 + 
 +===== common includes =====
 <code yaml> <code yaml>
-:project: +:cmock: 
- :auto_link_deep_dependencies: TRUE+  :includes: 
 +    - <stdbool.h> 
 +    - <stdint.h>
 </code> </code>
  
-But it has impact on performance.+===== extern keyword ===== 
 +<code> 
 +WARNING: No function prototypes found! 
 +</code> 
 +By default ''cmock'' will ignore ''extern'' function (is not mocking them). To enable mocking of ''extern'' functions: 
 +<code yaml> 
 +:cmock: 
 +  :treat_externs: :include 
 +</code> 
 + 
 + 
 +===== volatile function parameters ===== 
 +<code c> 
 +void myfn(custom_t *m, volatile uint32_t *var); 
 + 
 +error: conflicting types for ... 
 +</code>
  
 +[[https://github.com/ThrowTheSwitch/CMock/issues/135|CMock chokes on volatile function parameters #135]]
  
 +  The C99 standard recommends against using volatile as function call parameters and as return values, 
 +  stating that it is undefined behavior (because it is implementation-  specific) and therefore should 
 +  not be depended upon.
  
 +  * **Workaround1:** is to use macro for volatile and redefine it to nothing when ''TEST''.
 +  * **Workaround2:** is to use ''typedef volatile uint32_t my_volatile_type;''