Ceedling how to pass defines to CMock - c

I am somewhat new to TDD, although I have been using C for some time. As a result, I am using ceedling to test my embedded project.
I can rake test:all in gcc, but I am now trying to move that to an embedded target simulator. I am specifying my cross-compiler, linker, etc. through the 'project.yml' file.
When I rake test:all, I get an error when "compiling cmock.c" (several other files compile without problems):
< path_to_cmock >/cmock.c:17:31: error: size of array 'CMock_Guts_Buffer' is too large
There are other errors after this, but this is the one that kicks them off.
When I go to cmock.c, I see this at the top of the file:
#ifdef CMOCK_MEM_DYNAMIC
static unsigned char* CMock_Guts_Buffer = NULL;
static CMOCK_MEM_INDEX_TYPE CMock_Guts_BufferSize = CMOCK_MEM_ALIGN_SIZE;
static CMOCK_MEM_INDEX_TYPE CMock_Guts_FreePtr;
#else
static unsigned char CMock_Guts_Buffer[CMOCK_MEM_SIZE + CMOCK_MEM_ALIGN_SIZE];
static CMOCK_MEM_INDEX_TYPE CMock_Guts_BufferSize = CMOCK_MEM_SIZE + CMOCK_MEM_ALIGN_SIZE;
static CMOCK_MEM_INDEX_TYPE CMock_Guts_FreePtr;
#endif
Perfect, so I just need to find where these are declared. I do a text search only to find that they aren't declared anywhere... so I suspect that they are coming from the defaults within ceedling.
I found the documentation for CMOCK and, under "Compiled Options",
A number of #defines also exist for customizing the cmock experience...
It goes on to list the #defines that I have found in the source code, but it does not state where to find them. I have tried to make an include file with the appropriate defines and pass the include file through the 'project.yml' with no luck.
I suspect that the answer is unbelievably simple, it just isn't outlined anywhere that I have searched. Thank you for your time,

Of course, the answer was staring me in the face.
In the 'project.yml' file, there is a section called 'defines'. The default defines are:
:defines:
# in order to add common defines:
# 1) remove the trailing [] from the :common: section
# 2) add entries to the :common: section (e.g. :test: has TEST defined)
:commmon: &common_defines []
:test:
- *common_defines
- TEST
:test_preprocess:
- *common_defines
- TEST
I simply added the defines for my target:
:defines:
# in order to add common defines:
# 1) remove the trailing [] from the :common: section
# 2) add entries to the :common: section (e.g. :test: has TEST defined)
:commmon: &common_defines
- __dsPIC33EP32MC204__
- UNITY_INT_WIDTH=16
- CMOCK_MEM_INDEX_TYPE=uint16_t
- CMOCK_MEM_PTR_AS_INT=uint16_t
- CMOCK_MEM_ALIGN=1
- CMOCK_MEM_SIZE=1024
- CMOCK_MEM_STATIC
:test:
- *common_defines
- TEST
:test_preprocess:
- *common_defines
- TEST

The proper way to setup the cmock for your prohect is as slightlynybbled pointed in previous answer, bu you could also provide a hidden setup for your cmocks into your project.yml file as follow:
:cmock:
:mock_prefix: mock_
:when_no_prototypes:
:warn
:enforce_strict_ordering: TRUE
:includes_h_pre_orig_header:
- ../<cmock_headers_includes>.h
:plugins:
- :ignore
- :ignore_arg
- :callback
- :expect
- :expect_any_args
:treat_as:
uint8: HEX8
uint16: HEX16
uint32: UINT32
int8: INT8
bool: UINT8
This setup have been tested with Ceedling 0.27, 0.28 and 0.28.1

Related

Are the added dependencies really been compiled by shadow-cljs? If so, why do the values stay the same?

I am following shadow-cljs Quick Start documentation on a minimal example of a project. Here is the link.
Initially, I had this shadow-cljs.edn file:
;; shadow-cljs configuration
{:source-paths
["src/dev"
"src/main"
"src/test"]
:dev-http {8080 "public"}
:dependencies
[]
:builds
{:frontend
{:target :browser
:modules {:main {:init-fn acme.frontend.app/init}}
}}}
In /Users/pedro/projects/acme-app/src/main/acme/frontend/app.cljs, I also have:
(ns acme.frontend.app)
(defn init []
(println "Hello World"))
I can build and watch it with the command:
$ npx shadow-cljs compile frontend
shadow-cljs - config: /Users/pedro/projects/acme-app/shadow-cljs.edn
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
[:frontend] Compiling ...
[:frontend] Build completed. (79 files, 0 compiled, 0 warnings, 4.88s)
I have been adding dependencies such as:
:dependencies [[day8.re-frame/re-frame-10x "1.2.1"]
[proto-repl "0.3.1"]
[re-frame "1.2.0"]
[com.degel/re-frame-firebase "0.9.6-SNAPSHOT"]
[bidi "2.1.5"]
[re-com "2.13.2-106-180ea1f-SNAPSHOT-TALLYFOR"]
[com.andrewmcveigh/cljs-time "0.5.2"]
[com.pupeno/free-form "0.6.0"]
[binaryage/dirac "RELEASE"]
[hickory "0.7.1"]
[cljs-hash "0.0.2"]
[medley "1.2.0"]]
But, the build does not change in terms of files, compiled, and warnings. Just the time changes a bit - time is probably somewhat random/stochastic (79 files, 0 compiled, 0 warnings, 5.59s).
Are the dependencies really been compiled? How do I know if the dependencies were compiled too?
If they are being compiled, why does the number of files stay the same?
Obs.: note that I am not invoking the function being used inside the dependencies - and I do not want to invoke them for debugging reasons.
Adding the :dependencies does very little, they'll not be compiled on their own. They are only made available on the classpath.
They will only be compiled and loaded once you add them the :require in the ns forms of your files, or dynamically require at the REPL. Without an explicit request (ie. :require) to load them, they are just passive resources that are unused.

Custom u-boot environment variables using buildroot

How do you add a new set of custom environment variables to u-boot using buildroot as the os build system?
I attempted to patch the include/configs/rpi.h using an external tree patch to add a new variable but kconfig got grumpy (patch shown after complaining):
The following new ad-hoc CONFIG options were detected:
CONFIG_XXXXXX_ENV_SETTINGS
Please add these via Kconfig instead. Find a suitable Kconfig
file and add a 'config' or 'menuconfig' option.
Makefile:871: recipe for target 'all' failed
--- a/include/configs/rpi.h 2018-03-13 12:02:19.000000000 +0000
+++ b/include/configs/rpi.h 2018-11-19 12:32:15.728000000 +0000
## -140,0 +141,7 ##
+#define CONFIG_XXXXXX_ENV_SETTINGS \
+ "newboard=true" \
+ "hasFailedBoot=false" \
+ "hasFailedBootCount=0" \
+ "maximumFailedBootCount=3"
+
+
## -145 +152,2 ##
- BOOTENV
+ BOOTENV \
+ CONFIG_XXXXXX_ENV_SETTINGS
I can use uboot-menuconfig to set up u-boot specific stuff but am not sure how to create environment variables
You can set CONFIG_USE_DEFAULT_ENV_FILE in uboot-menuconfig and point that to a file that contains the complete default environment.
Since you use Buildroot, don't forget to save the modified U-Boot configuration by changing its location (Buildroot option BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE) and running make uboot-update-defconfig.

Ceedling CMock settings for ARM STM32

I've been setting up Ceedling for STM32. The howto is very scarce, so far I've managed to google next to nothing. Fortunately, the framework is relatively transparent for its size. This is a PIC configuration. I set up something similar (project.yml):
...
:defines:
# in order to add common defines:
# 1) remove the trailing [] from the :common: section
# 2) add entries to the :common: section (e.g. :test: has TEST defined)
:commmon: &common_defines #[]
- STM32F103xB
- UNITY_INT_WIDTH=32
- CMOCK_MEM_INDEX_TYPE=uint32_t
- UNITY_LINE_TYPE=uint16_t
:test:
- *common_defines
- TEST
:test_preprocess:
- *common_defines
- TEST
So far so good (no real work is yet attempted). Having added this definition
- CMOCK_MEM_PTR_AS_INT=uint32_t
I'm having a warning:
/vendor/ceedling/vendor/cmock/src/cmock.c:105:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
index = *(CMOCK_MEM_INDEX_TYPE*)((CMOCK_MEM_PTR_AS_INT)next - CMOCK_MEM_INDEX_SIZE);
No wonder, as next is a PC platform 64-bit pointer. Still I am not at all sure whether I have to control CMOCK_MEM_PTR_AS_INT or not. It depends on whether CMOCK_MEM_PTR_AS_INT is a critical target (ARM) platform definition.
So far I haven't found an STM32 example.
Here is the hard won sequence, complete with the Eclipse integration:
Install Ceedling:
$ gem install ceedling
Create Ceedling project (troubleshooting #215):
myproject $ cd ..
$ ceedling new myproject
$ cd myproject/vendor/
$ rm -rf ceedling/
$ git clone --recursive https://github.com/throwtheswitch/ceedling.git
Modify vendor/ceedling/plugins/module_generator/config/module_generator.yml:
:module_generator:
:project_root: ./
:source_root: Src/
:inc_root: Inc/
:test_root: test/
Modify project.yml:
...
:paths:
:test:
- +:test/**
- -:test/support
:source:
- Src/**
:include:
- Drivers/**
- Inc/**
:support:
- test/support
...
:defines:
:commmon: &common_defines # A nice typo, next to invisible :)
- STM32F103xB
...
:cmock:
:strippables:
- volatile
...
:plugins:
:load_paths:
- vendor/ceedling/plugins
:enabled:
# - stdout_pretty_tests_report
- stdout_gtestlike_tests_report
- module_generator
Eclipse C/C++ Unit plugin configuration:
Main/Project: myproject
Main/Application: /home/user/.gem/ruby/2.5.0/bin/ceedling
Main/Disable auto build
Arguments/Program arguments: clobber\ntest:all
Testing/Test Runner: Google Test Runner
Environment: Variable TERM Value xterm

Ceedling project file does not recognize paths and libraries

I wanted to use ceedling for unit testing C Code for STM32 family.
I installed it as shown on their page on GitHub Ceedling and run successfully the example tests.
The project.yml file I have modified the paths because I have a different path for header files (path: include) as the source files (path: src):
:paths:
:test:
- +:test/**
- -:test/support
:source:
- build/STM32F2xx_StdPeriph_Driver/include/**
- build/STM32F2xx_StdPeriph_Driver/src/**
- include/**
- src/**
:support:
- test/support
:defines:
:commmon: &common_defines
#Define for header files
- STM32F2XX
:libraries:
:placement: :end
:flag: "${1}" # or "-L ${1}" for example
:common: &common_libraries []
:test:
- *common_libraries
#toolchain of STM32F2
- build/STM32F2xx_StdPeriph_Driver/include/**
- build/STM32F2xx_StdPeriph_Driver/src/**
- build/STM32F2xx/include/
But somehow the path and libraries does not get recognized and I get error for unknown variables.
Is my .yml file wrong?
for future readers, I switched to cppUTest. Its easy to use, and you have the power of cpp and the mocking is fantastic.

PAM standard macros and logging on CentOS7

According to the D(x) macro defined in pam_macros.h (source code) and used as follows:
D(("Hello PAM World"));
Where is this log located on CentOS7?
Note that I am using as flag debug in my pam.d conf file.
I tried also the following command:
grep -rnw '/var/log/' -e "Hello Pam World"
But with no success.
In the file you link, there are these lines at the top:
/*
* This is for debugging purposes ONLY. DO NOT use on live systems !!!
* You have been warned :-) - CG
*
* to get automated debugging to the log file, it must be created manually.
* _PAM_LOGFILE must exist, mode 666
*/
#ifndef _PAM_LOGFILE
#define _PAM_LOGFILE "/tmp/pam-debug.log"
#endif
So it looks like the output will be directed to /tmp/pam-debug.log, but you have to create it before, and give it full read-write permissions:
$ touch /tmp/pam-debug.log
$ chmod 666 /tmp/pam-debug.log
Looking to the Linux version of this file, it looks like it is written to /var/run/pam-debug.log, but only if it is compiled with PAM_DEBUG.
There a nice comment in configure.ac:
if test x"$enable_debug" = x"yes" ; then
AC_DEFINE([PAM_DEBUG],,
[lots of stuff gets written to /var/run/pam-debug.log])

Resources