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:07] – 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 10: Line 16:
  
 ===== cross includes = deep linking ===== ===== cross includes = deep linking =====
-Also ceedling cannot automatically pick ''.c'' files when included .h file depends on another ''.h'' file. 
-All dependant includes needs to be added manually in test ''.c'' 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.
 +
 +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>
 +:cmock:
 +  :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>
 +
 +[[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;''