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:09] – 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 13: Line 19:
 Also ''ceedling'' cannot automatically pick ''.c'' files when included .h file depends on another ''.h'' file. Also ''ceedling'' cannot automatically pick ''.c'' files when included .h file depends on another ''.h'' file.
 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> 
 + 
 +===== 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> </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;''