Protect against more function-looking macros (Fixes#502)

Feature/better arrays

.github/FUNDING.yml

@@ -0,0 +1,13 @@
+github: ThrowTheSwitch
+#patreon: # Replace with a single Patreon username
+#open_collective: # Replace with a single Open Collective username
+#ko_fi: # Replace with a single Ko-fi username
+#tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+#community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+#liberapay: # Replace with a single Liberapay username
+#issuehunt: # Replace with a single IssueHunt username
+#lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+#polar: # Replace with a single Polar username
+#buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
+#thanks_dev: # Replace with a single thanks.dev username
+#custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/workflows/main.yml

@@ -0,0 +1,52 @@
+---
+# Continuous Integration Workflow: Test case suite run + validation build check
+name: CI
+
+# Controls when the action will run.
+# Triggers the workflow on push or pull request events but only for the master branch
+on:
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
+
+jobs:
+  # Job: Unit test suite
+  unit-tests:
+    name: "Unit Tests"
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        ruby: ['3.0', '3.1', '3.2', '3.3']
+    steps:
+      # Install Multilib
+      - name: Install Multilib
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install --assume-yes --quiet gcc-multilib
+
+      # Checks out repository under $GITHUB_WORKSPACE
+      - name: Checkout Latest Repo
+        uses: actions/checkout@v2
+        with: 
+          submodules: recursive
+
+      # Setup Ruby Testing Tools to do tests on multiple ruby version
+      - name: Setup Ruby Testing Tools
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: ${{ matrix.ruby }}
+
+      # Install Ruby Testing Tools
+      - name: Setup Ruby Testing Tools
+        run: |
+          sudo gem install rspec
+          sudo gem install rubocop -v 1.57.2
+          sudo gem install bundler
+          bundle update
+          bundle install 
+
+      # Run Tests
+      - name: Run All Unit Tests
+        run: |
+          cd test && rake ci

.gitignore

@@ -1,8 +1,10 @@
 test/system/build
 test/system/generated
 *.sublime-project
+*.sublime-workspace
 Gemfile.lock
 .rake_t_cache
 .DS_Store
 *.swp
 examples/make_example/build
+examples/temp_sensor/build

.gitmodules

@@ -1,8 +1,8 @@
-[submodule "vendor/unity"]
-	path = vendor/unity
-	url = https://github.com/throwtheswitch/unity.git
-	branch = master
 [submodule "vendor/c_exception"]
 	path = vendor/c_exception
 	url = https://github.com/throwtheswitch/cexception.git
 	branch = master
+[submodule "vendor/unity"]
+	path = vendor/unity
+	url = https://github.com/throwtheswitch/unity.git
+	branch = master

.travis.yml

@@ -1,8 +0,0 @@
-language: ruby
-rvm:
-  - "1.9.3"
-  - "2.0.0"
-install:
-  - bundle install
-script:
-  - bundle exec rake ci

Gemfile

@@ -1,9 +1 @@
 source "http://rubygems.org/"
-
-gem "bundler", "~> 1.1.rc.7"
-gem "rake", ">= 0.9.2.2"
-
-gem "minitest"
-gem "require_all"
-gem "constructor"
-gem "diy"

LICENSE.txt

@@ -1,4 +1,6 @@
-Copyright (c) 2007-14 Mike Karlesky, Mark VanderVoord, Greg Williams
+The MIT License (MIT)
+
+Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

README.md

@@ -1,23 +1,54 @@
-CMock - Mock/stub generator for C
-=================================
+CMock ![CI](https://github.com/ThrowTheSwitch/CMock/workflows/CI/badge.svg)
+=====
 
-[![CMock Build Status](https://api.travis-ci.org/ThrowTheSwitch/CMock.png?branch=master)](https://travis-ci.org/ThrowTheSwitch/CMock)
+CMock is a mock and stub generator and runtime for unit testing C. It's been designed
+to work smoothly with Unity Test, another of the embedded-software testing tools 
+developed by ThrowTheSwitch.org. CMock automagically parses your C headers and creates
+useful and usable mock interfaces for unit testing. Give it a try!
+
+If you don't care to manage unit testing builds yourself, consider checking out Ceedling, 
+a test-centered build manager for unit testing C code.
+
+ - [Known Issues](docs/CMockKnownIssues.md)
+ - [Change Log](docs/CMockChangeLog.md)
 
 Getting Started
-================
+===============
+
+Your first step is to get yourself a copy of CMock. There are a number of ways to do this:
+
+1. If you're using Ceedling, there is no need to install CMock. It will handle it for you.
+
+2. The simplest way is to grab it off github. The Github method looks something like this:
 
     > git clone --recursive https://github.com/throwtheswitch/cmock.git
+
+3. You can also grab the `zip` file from github. If you do this, you'll also need to grab yourself a
+copy of Unity and CException, because github unfortunately doesn't bake dependencies into the zip
+files. 
+
+Contributing to this Project
+============================
+
+If you plan to help with the development of CMock (or just want to verify that it can
+perform its self tests on your system) then you can grab its self-testing dependencies, 
+then run its self-tests:
+
     > cd cmock
-    > bundle install # Ensures you have all RubyGems needed
-    > bundle exec rake # Run all CMock library tests
+    > bundle install   # Ensures you have all RubyGems needed
+    > cd test
+    > rake             # Run all CMock self tests
+
+Before working on this project, you're going to want to read our guidelines on 
+[contributing](docs/CONTRIBUTING.md). 
 
 API Documentation
 =================
 
 * Not sure what you're doing?
 	* [View docs/CMock_Summary.md](docs/CMock_Summary.md)
-* Interested in our MIT-style license?
-	* [View docs/license.txt](docs/license.txt)
+* Interested in our MIT license?
+	* [View docs/license.txt](LICENSE.txt)
 * Are there examples?
 	* They are all in [/examples](examples/)
 * Any other resources to check out?

Rakefile

@@ -1,106 +0,0 @@
-# ==============================================================================
-#   CMock Project - Automatic Mock Generation for C
-#   Copyright (c) 2007-2014 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==============================================================================
-
-require './config/test_environment'
-require 'rake'
-require 'rake/clean'
-require 'rake/testtask'
-require './rakefile_helper'
-
-include RakefileHelpers
-
-DEFAULT_CONFIG_FILE = 'gcc.yml'
-CMOCK_ROOT = File.expand_path(File.dirname(__FILE__))
-
-SYSTEM_TEST_SUPPORT_DIRS = [
-  File.join(CMOCK_ROOT, 'test/system/generated'),
-  File.join(CMOCK_ROOT, 'test/system/build')
-]
-
-SYSTEM_TEST_SUPPORT_DIRS.each do |dir|
-  directory(dir)
-  CLOBBER.include(dir)
-end
-
-
-task :prep_system_tests => SYSTEM_TEST_SUPPORT_DIRS
-
-configure_clean
-configure_toolchain(DEFAULT_CONFIG_FILE)
-
-task :default => [:test]
-task :ci      => [:no_color, :default]
-task :cruise  => :ci
-
-desc "Load configuration"
-task :config, :config_file do |t, args|
-  args = {:config_file => DEFAULT_CONFIG_FILE} if args[:config_file].nil?
-  args = {:config_file => args[:config_file] + '.yml'} unless args[:config_file] =~ /\.yml$/i
-  configure_toolchain(args[:config_file])
-end
-
-desc "Run all unit, c, and system tests"
-task :test => [:clobber, :prep_system_tests, 'test:units', 'test:c', 'test:system']
-
-namespace :test do
-  desc "Run Unit Tests"
-  Rake::TestTask.new('units') do |t|
-    t.pattern = 'test/unit/*_test.rb'
-    t.verbose = true
-  end
-
-  #individual unit tests
-  FileList['test/unit/*_test.rb'].each do |test|
-    Rake::TestTask.new(File.basename(test,'.*').sub('_test','')) do |t|
-      t.pattern = test
-      t.verbose = true
-    end
-  end
-
-  desc "Run C Unit Tests"
-  task :c => [:prep_system_tests] do
-    unless ($cfg['unsupported'].include? "C")
-      build_and_test_c_files
-    end
-  end
-
-  desc "Run System Tests"
-  task :system => [:clobber, :prep_system_tests] do
-    #get a list of all system tests, removing unsupported tests for this compiler
-    sys_unsupported  = $cfg['unsupported'].map {|a| 'test/system/test_interactions/'+a+'.yml'}
-    sys_tests_to_run = FileList['test/system/test_interactions/*.yml'] - sys_unsupported
-    compile_unsupported  = $cfg['unsupported'].map {|a| SYSTEST_COMPILE_MOCKABLES_PATH+a+'.h'}
-    compile_tests_to_run = FileList[SYSTEST_COMPILE_MOCKABLES_PATH + '*.h'] - compile_unsupported
-    unless (sys_unsupported.empty? and compile_unsupported.empty?)
-      report "\nIgnoring these system tests..."
-      sys_unsupported.each {|a| report a}
-      compile_unsupported.each {|a| report a}
-    end
-    report "\nRunning system tests..."
-    tests_failed = run_system_test_interactions(sys_tests_to_run)
-    raise "System tests failed." if (tests_failed > 0)
-
-    run_system_test_compilations(compile_tests_to_run)
-  end
-
-  #individual system tests
-  FileList['test/system/test_interactions/*.yml'].each do |test|
-    basename = File.basename(test,'.*')
-    desc "Run system test #{basename}"
-    task basename do
-      run_system_test_interactions([test])
-    end
-  end
-
-  desc "Profile Mock Generation"
-  task :profile => [:clobber, :prep_system_tests] do
-    run_system_test_profiles(FileList[SYSTEST_COMPILE_MOCKABLES_PATH + '*.h'])
-  end
-end
-
-task :no_color do
-  $colour_output = false
-end

cmock.gemspec

@@ -0,0 +1,34 @@
+# -*- encoding: utf-8 -*-
+$LOAD_PATH << File.expand_path(File.join(File.dirname(__FILE__), 'lib'))
+require "lib/cmock_version"
+require 'date'
+
+Gem::Specification.new do |s|
+  s.name        = "cmock"
+  s.version     = CMockVersion::GEM
+  s.platform    = Gem::Platform::RUBY
+  s.authors     = ["Mark VanderVoord", "Michael Karlesky", "Greg Williams"]
+  s.email       = ["mark@vandervoord.net", "michael@karlesky.net", "barney.williams@gmail.com"]
+  s.homepage    = "http://throwtheswitch.org/cmock"
+  s.summary     = "CMock is a mocking framework for C unit testing. It's a member of the ThrowTheSwitch.org family of tools."
+  s.description = <<-DESC
+CMock is a mocking framework for C unit testing. It accepts header files and generates mocks automagically for you.
+  DESC
+  s.licenses    = ['MIT']
+
+  s.metadata = {
+    "homepage_uri"      => s.homepage,
+    "bug_tracker_uri"   => "https://github.com/ThrowTheSwitch/CMock/issues",
+    "documentation_uri" => "https://github.com/ThrowTheSwitch/CMock/blob/master/docs/CMock_Summary.md",
+    "mailing_list_uri"  => "https://groups.google.com/forum/#!categories/throwtheswitch/cmock",
+    "source_code_uri"   => "https://github.com/ThrowTheSwitch/CMock"
+  }
+  
+  s.required_ruby_version = ">= 3.0.0"
+
+  s.files      += Dir['**/*']
+  s.test_files  = Dir['test/**/*']
+  s.executables = ['lib/cmock.rb']
+
+  s.require_paths = ["lib"]
+end

config/production_environment.rb

@@ -1,14 +1,13 @@
-# ==========================================
-#   CMock Project - Automatic Mock Generation for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ========================================== 
- 
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 # Setup our load path:
-[ 
- 'lib',
+[
+  'lib'
 ].each do |dir|
-  $LOAD_PATH.unshift( File.join( File.expand_path(File.dirname(__FILE__)) + '/../', dir) )
+  $:.unshift(File.join("#{__dir__}//..//", dir))
 end
-
-

config/test_environment.rb

@@ -1,16 +1,17 @@
-# ==========================================
-#   CMock Project - Automatic Mock Generation for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ========================================== 
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 # Setup our load path:
-[ 
-  'lib',
-  'vendor/behaviors/lib',
-  'vendor/hardmock/lib',
-  'vendor/unity/auto/',
-  'test/system/'
+[
+  './lib',
+  './vendor/behaviors/lib',
+  './vendor/hardmock/lib',
+  './vendor/unity/auto/',
+  './test/system/'
 ].each do |dir|
-  $LOAD_PATH.unshift( File.join( File.expand_path(File.dirname(__FILE__) + "/../"), dir) )
+  $:.unshift(File.join(File.expand_path("#{File.dirname(__FILE__)}//..//"), dir))
 end

docs/CMockChangeLog.md

@@ -0,0 +1,166 @@
+# CMock - Change Log
+
+## A Note
+
+This document captures significant features and fixes to the CMock project core source files 
+and scripts. More detail can be found in the history on Github. 
+
+This project is now tracking changes in more detail. Previous releases get less detailed as
+we move back in histroy. 
+
+Prior to 2012, the project was hosted on SourceForge.net
+Prior to 2008, the project was an internal project and not released to the public.
+
+## Log
+
+### CMock 2.6.0 (January 2025)
+
+New Features:
+
+  - Reintroduced option to run CMock without setjmp (slightly limited)
+  - Significant speed improvements to parsing
+
+Significant Bugfixes:
+
+  - Make return-thru-pointer calls const
+  - Fix handling of static inlines
+  - Fix some situations where parenthetical statements were misinterpreted as functions
+  - Fix error in skeleton creation
+  - Improvements towards making generated code fully C-compliant and warning free
+
+Other:
+
+  - Improve error message wording where possible
+  - Improve documentation
+  - Updated to Ruby 3.0 - 3.3
+  - Reintroduce matrix testing across multiple Ruby versions
+
+### CMock 2.5.3 (January 2021)
+
+New Features:
+
+  - Support mocks in sub-folders
+  - Improved handling of static and inline functions
+  - Stateless Ignore plugin added
+
+Significant Bugfixes:
+
+  - Allow setting values to empty at command prompt
+  - Improvements towards making generated code fully C-compliant and warning free
+
+Other:
+  
+  - Really basic mocking of cpp files (like C files with extern C)
+
+### CMock 2.5.2 (May 2020)
+
+Significant Bugfixes:
+
+  - Fix whitespace errors
+  - Fix Stop Ignore
+
+### CMock 2.5.1 (April 2020)
+
+New Features:
+
+  - Add StopIgnore function to Ignore Plugin
+  - Add ability to generate skeleton from a header.
+  - Inline functions now have option to remove and mock (with Ceedling's help)
+
+Significant Bugfixes:
+
+  - Convert internal handling of bools to chars from ints for memory savings
+  - Convert CMOCK_MEM_INDEX_TYPE default type to size_t 
+  - Switch to old-school comments for supporting old C compilers
+  - Significant improvements to handling array length expressions
+  - Significant improvements to our "C parser"
+  - Added brace-pair counting to improve parsing
+  - Fixed error when `:unity_helper_path` is relative
+
+Other:
+
+ - Improve documentation
+ - Optimize speed for pass case, particularly in `_verify()` functions
+ - Increased depth of unit and system tests
+
+### CMock 2.5.0 (October 2019)
+
+New Features:
+
+  - New memory bounds checking.
+  - New memory alignment algorithm.
+  - Add `ExpectAnyArgs` plugin
+  - Divided `CVallback` from `Stub` functionality so we can do both.
+  - Improved wording of failure messages.
+  - Added `:treat_as_array` configuration option
+
+Significant Bugfixes:
+
+  - Fixed bug where `CMock_Guts_MemBytesUsed()` didn't always return `0` before usage
+  - Fixed bug which sometimes got `CMOCK_MEM_ALIGN` wrong
+  - Fixed bug where `ExpectAnyArgs` was generated for functions without args.
+  - Better handling of function pointers
+
+Other:
+
+  - `void*` now tested as bytewise array comparison.
+  - Documentation fixes, particularly to examples.
+  - Added `resetTest` to documentation
+  - New handling of messaging to greatly reduce memory footprint
+
+### CMock 2.4.6 (November 2017)
+
+Significant Bugfixes:
+
+  - Fixed critical bug when running dynamic memory.
+
+### CMock 2.4.5 (September 2017)
+
+New Features:
+
+  - Simple threading of mocks introduced.
+
+Significant Bugfixes:
+  
+  - Improvements to handling pointer const arguments.
+  - Treat `char*` separately from an array of bytes.
+  - Fixed handling of string arguments.
+  - Preserve `const` in all arguments.
+  - Fixed race condition when `require`ing plugins
+
+Other:
+
+  - Expand docs on `strict_mock_calling`
+
+### CMock 2.4.4 (April 2017)
+
+New Features:
+
+  - Add `INCLUDE_PATH` option for specifying source
+
+Significant Bugfixes:
+
+  - Parsing improvements related to braces, brackets, and parenthesis
+  - `ReturnThruPtr` checks destination not null before copying data.
+  - Stub overrides Ignore
+  - Improvements to guessing memory alignment based on datatypes
+
+Other:
+
+  - Reorganize testing into subdirectory to not clutter for new users
+  - Docs switching to markdown from pdf
+
+### CMock 2.4.3 (October 2016)
+
+New Features:
+
+  - Support multiple helper header files.
+  - Add ability to use `weak` symbols if compiler supports it
+  - Add mock suffix option in addition to mock prefix.
+
+Significant Bugfixes:
+
+  - Improved UNICODE support
+
+
+

docs/CMockKnownIssues.md

@@ -0,0 +1,13 @@
+# CMock - Known Issues
+
+## A Note
+
+This project will do its best to keep track of significant bugs that might effect your usage of this
+project and its supporting scripts. A more detailed and up-to-date list for cutting edge CMock can
+be found on our Github repository.
+
+## Issues
+
+  - Able to parse most C header files without preprocessor needs, but when handling headers with significant preprocessor usage (#ifdefs, etc), it can get confused
+  - Multi-dimensional arrays currently simplified to single dimensional arrays of the full size
+  - Incomplete support for VarArgs

docs/CMock_ArgumentValidation.md

@@ -0,0 +1,274 @@
+CMock: Argument Validation
+==========================
+
+Much of the power of CMock comes from its ability to automatically 
+validate that the arguments passed to mocked functions are the 
+values that were expected to be passed. CMock puts a lot of effort
+into guessing how the user would most like to see those values 
+compared, and then represented when failures are encountered.
+
+Like Unity, CMock follows a philosophy of making its best guesses,
+and then allowing the user to explicity specify any features that 
+they would like to change or customize.
+
+Option 1: Common Types
+----------------------
+
+First, if you're dealing with C's standard types, there is nothing
+further you need to do. CMock will choose an appropriate assertion
+from Unity's list of assertions and will perform the comparison and
+display using that. For example, if you specify a `short`, then it's 
+very likely CMock will compare using `TEST_ASSERT_EQUAL_INT16`. For
+unsigned values, it assumes you'd like them displayed in hex. Are you
+interested in comparing a `const char*`? That would be Unity's 
+string comparison. 
+
+What if you have some other type of pointer? If you've instructed
+CMock to compare pointers, it'll use `TEST_ASSERT_EQUAL_PTR`. 
+Otherwise it'll use dereference the value being pointed at and 
+compare that for you. (Read more about the Array plugin for more
+details on how this all works). The TYPE being pointed to follows the
+same rules as the those above... so if they're common types, for example 
+`unsigned char*`, then CMock will choose to compare using the 
+logical assertion (in this case `TEST_ASSERT_EQUAL_HEX8`).
+
+A quick note about floating point types: we're calling the assertions
+`TEST_ASSERT_EQUAL_FLOAT` (for example), but don't worry... these 
+assertions are actually checking to make sure that the values are
+"incredibly close" to the desired value instead of identical. This
+is because many numbers can be represented in multiple ways when
+using floating point. These differences are out of the control of 
+the user, for the most part. You can ready more about this in the
+Unity documentation if you're interested in the details.
+
+Option 1b: The Fallback Plan
+----------------------------
+
+So what happens when CMock doesn't recognize the type being used?
+This will happen for any custom types being used. What constitutes
+a custom type?
+
+  - You've used `#define` to create an alias for a standard type
+  - You've used `typedef` to create an alias for a standard type
+  - You've created an `enum` type
+  - You've created a `union` type
+  - You've created a `struct` type
+  - You're working with a function pointer
+
+ When CMock doesn't recognize the type as a standard type, (and 
+ assuming you don't have a better option specified, as any of the
+ options below), it will fall back to performing a memory 
+ comparison using `TEST_ASSERT_EQUAL_MEMORY`. For the most part,
+ this is effective, but the reported failures are not terribly
+ descriptive.
+
+ **WARNING:** There is one important instance where this fallback method
+ doesn't work at all. If the custom type is a `struct` and that 
+ struct isn't packed, then it's possible you can get false failures
+ when the unused bytes between fields differ. For an unpacked struct,
+ it's important that you either use option 3 or 4 below, or ignore that
+ particular argument (and possibly test it manually yourself).
+
+Option 2: Treat-As
+------------------
+
+CMock maintains a list of non-standard types which are basically 
+aliases of standard types. For example, a common shorthand for 
+a single-byte unsigned integer might be `u8` or `U8` or `UNIT8`.
+Any of these can simply be mapped to the standard 
+`TEST_ASSERT_EQUAL_HEX8`.
+
+While CMock has its own list of `:treat_as` mappings, you can 
+add your own pairings to this list. This works especially well for
+the following types:
+
+  - aliases of standard types using `#define` or `typedef`
+  - `enum` types (works well as `INT8` or whatever size your enums are)
+  - function pointers often work well as `PTR` comparisons
+  - `union` types sometimes make sense to treat as the largest type... 
+    but this is a judgement call
+
+Option 3: Custom Assertions for Custom Types
+--------------------------------------------
+
+CMock has the ability to use custom assertions, if you form them 
+according to certain specifications. Creating a custom assertion 
+can be a bit of work, But the reward is that, once you've done so,
+you can use those assertions within your own tests AND CMock will
+magically use them within its own mocks.
+
+To accomplish this, we're going tackle multiple steps:
+
+  1. Write a custom assertion function
+  2. Wrap it in a `UNITY_TEST_` macro
+  3. Wrap it in a `TEST_` macro
+  4. Inform CMock that it exists
+
+Let's look at each of those steps in detail:
+
+### Creating a Custom Assertion
+
+A custom assertion is a function which accepts a standard set of 
+inputs, and then uses Unity's assertion macros to verify any details
+required for the types involved. 
+
+The inputs:
+
+  - the `expected` value (as a `const` version of type being verified)
+  - the `actual` value (also as a `const` version of the desired type)
+  - the `line` this function was called from (as type `UNITY_LINE_TYPE`)
+  - an optional `message` to be appended (as type `const char*`)
+
+Inside the function, we use the *internal* versions of Unity's assertions
+to validate any details that need validating.
+
+Let's look at an example! Let's say we have the following type:
+
+```
+typedef struct MyType_t
+{
+    int a;
+    const char* b;
+} MyType;
+```
+
+In our application, the length of `b` is supposed to be specified by `a`,
+and `b` is therefore allowed to have any value (including `0x00`). 
+
+Our custom assertion might look something like this:
+
+```
+void AssertEqualMyType(const MyType expected, const MyType actual, UNITY_LINE_TYPE line, const char* message)
+{
+    //It's common to override the default message with our own 
+    (void)message; 
+
+    // Verify the lengths are the same, or they're clearly not matched
+    UNITY_TEST_ASSERT_EQUAL_INT(expected.a, actual.a, line, "Data length mismatch");
+
+    // Verify we're dealing with actual pointers
+    UNITY_TEST_ASSERT_NOT_NULL(expected.b, line, "Expected value should not be NULL");
+    UNITY_TEST_ASSERT_NOT_NULL(actual.b, line, "Actual value should not be NULL");
+
+    // Verify the string contents
+    UNITY_TEST_ASSERT_EQUAL_MEMORY(expected.b, actual.b, expected.a, line, "Data not equal");
+}
+```
+
+There are a few things to note about this. First, notice we're using the 
+`UNITY_TEST_ASSERT_` assertions? That's because these allow us to pass 
+on the specific line number. Second, notice we override the message with our
+own more helpful messages? You don't need to do this, but anything you can do
+to help a developer find a bug is a good thing.
+
+What if there isn't an assertion that is right for your needs? You can 
+always do whatever operations are necessary yourself, and use `UNITY_TEST_FAIL()`
+directly.
+
+One final note: It's best to only test the things that are hard rules about
+how a type is supposed to work in your system. Anything else should be left to
+the test code.
+
+For example, let's say that in our example above, there are situations where
+it IS valid for the pointers to be `NULL`. Perhaps the pointers are ignored
+completely when the `a` field is `0`. In that case, we could drop those 
+assertions completely, or add logic to only check when necessary.
+
+Similarly, should our assertion check that the length is positive? In this
+case, it's dangerous if it's negative, because the memory check wouldn't like it.
+
+Updating for these concerns:
+
+
+```
+void AssertEqualMyType(const MyType expected, const MyType actual, UNITY_LINE_TYPE line, const char* message)
+{
+    //It's common to override the default message with our own 
+    (void)message; 
+
+    // Verify the lengths are the same, or they're clearly not matched
+    UNITY_TEST_ASSERT_EQUAL_INT(expected.a, actual.a, line, "Data length mismatch");
+
+    // Verify the lengths are non-negative
+    UNITY_TEST_ASSERT_GREATER_OR_EQUAL_INT(0, expected.a, line, "Data length must be positive");
+
+    if (expected.a > 0)
+    {
+        // Verify we're dealing with actual pointers
+        UNITY_TEST_ASSERT_NOT_NULL(expected.b, line, "Expected value should not be NULL");
+        UNITY_TEST_ASSERT_NOT_NULL(actual.b, line, "Actual value should not be NULL");
+
+        // Verify the string contents
+        UNITY_TEST_ASSERT_EQUAL_MEMORY(expected.b, actual.b, expected.a, line, "Data not equal");
+    }
+}
+```
+
+### Wrapping our Assertion in Macros
+
+Once you have a function which does the main work, we *need* to create
+one macro, and there are a number of other macros which are useful to
+create, in order to treat our assertion just like any other Unity 
+assertion.
+
+`#define UNITY_TEST_ASSERT_EQUAL_MyType(e,a,l,m) AssertEqualMyType(e,a,l,m)`
+
+The macro above is the one that CMock is looking for. Notice that it 
+starts with `UNITY_TEST_ASSERT_EQUAL_` followed by the name of our type, 
+*exactly* the way our type is named. The arguments are, in order:
+
+  - `e` - expected value
+  - `a` - actual value
+  - `l` - line number to report
+  - `m` - message to append at the end
+
+If CMock finds a macro that matches this argument list and naming convention,
+then it can automatically use this assertion where needed... all we need to
+do now is tell CMock where to find our custom assertion.
+
+### Informing CMock about our Assertion
+
+In the CMock configuration file, in the `:cmock` or `:unity` sections, 
+there can be an option for `unity_helper_path`. Add the location of your
+new Unity helper file (file with this assertion) to this list.
+
+Done!
+
+**Bonus:** Once you've created a custom assertion, you can use it
+with `:treat_as`, just like any other standard type! This is 
+particularly useful when there is a custom type which is a pointer
+to a custom type.
+
+For example, let's say you have these types:
+
+```
+typedef struct MY_STRUCT_T_
+{
+    int a;
+    const char* b;
+} MY_STRUCT_T;
+
+typedef MY_STRUCT_T* MY_STRUCT_POINTER_T;
+```
+
+Also, let's assume you've created the following assertion:
+
+```
+UNITY_TEST_ASSERT_EQUAL_MY_STRUCT_T(e,a,l,m)
+```
+
+You can use `:treat_as` like so:
+
+```
+:treat_as:
+  MY_STRUCT_POINTER_T: MY_STRUCT_T*
+```
+
+Option 4: Callback
+------------------
+
+Finally, You can choose to avoid the use of `_Expect` calls altogether
+for challenging types, and use a `Callback` instead. The advantage is that
+you can fill in whichever assertions make sense for that particular test,
+instead of needing to rely on reusable assertions as used elsewhere. 
+Typically, this option is also less work than option 3.

docs/CMock_Summary.md

@@ -1,15 +1,19 @@
-[All code is copyright © 2007-2014 Cmock Project
-by Mike Karlesky, Mark VanderVoord, and Greg Williams.
+CMock: A Summary
+================
 
-This Documentation Is Released Under a Creative Commons 3.0
-Attribution Share-Alike License]
+*[ThrowTheSwitch.org](http://throwtheswitch.org)*
 
+*This documentation is released under a Creative Commons 3.0 Attribution Share-Alike License*
 
-What the What?
-==============
+ - [Known Issues](CMockKnownIssues.md)
+ - [Change Log](CMockChangeLog.md)
+ - [How Does CMock Validate Arguments](CMock_ArgumentValidation.md)
+
+What Exactly Are We Talking About Here?
+---------------------------------------
 
 CMock is a nice little tool which takes your header files and creates
-a Mock interface for it so that you can more easily Unit test modules
+a Mock interface for it so that you can more easily unit test modules
 that touch other modules. For each function prototype in your
 header, like this one:
 
@@ -60,7 +64,29 @@ call DoesSomething enough, or too much, or with the wrong arguments,
 or in the wrong order.
 
 CMock is based on Unity, which it uses for all internal testing.
-It uses Ruby to do all the main work (versions 1.8.6 through 1.9.2).
+It uses Ruby to do all the main work (versions 3.0.0 and above).
+
+
+Installing
+==========
+
+The first thing you need to do to install CMock is to get yourself
+a copy of Ruby. If you're on linux or osx, you probably already
+have it. You can prove it by typing the following:
+
+    ruby --version
+
+
+If it replied in a way that implies ignorance, then you're going to
+need to install it. You can go to [ruby-lang](https://ruby-lang.org)
+to get the latest version. You're also going to need to do that if it
+replied with a version that is older than 3.0.0. Go ahead. We'll wait.
+
+Once you have Ruby, you have three options:
+
+* Clone the latest [CMock repo on github](https://github.com/ThrowTheSwitch/CMock/)
+* Download the latest [CMock zip from github](https://github.com/ThrowTheSwitch/CMock/)
+* Install Ceedling (which has it built in!) through your commandline using `gem install ceedling`.
 
 
 Generated Mock Module Summary
@@ -76,7 +102,11 @@ Expect:
 -------
 
 Your basic staple Expects which will be used for most of your day
-to day CMock work.
+to day CMock work. By calling this, you are telling CMock that you
+expect that function to be called during your test. It also specifies
+which arguments you expect it to be called with, and what return
+value you want returned when that happens. You can call this function
+multiple times back to back in order to queue up multiple calls.
 
 * `void func(void)` => `void func_Expect(void)`
 * `void func(params)` => `void func_Expect(expected_params)`
@@ -84,73 +114,119 @@ to day CMock work.
 * `retval func(params)` => `void func_ExpectAndReturn(expected_params, retval_to_return)`
 
 
+ExpectAnyArgs:
+--------------
+
+This behaves just like the Expects calls, except that it doesn't really
+care what the arguments are that the mock gets called with. It still counts
+the number of times the mock is called and it still handles return values
+if there are some. Note that an ExpectAnyArgs call is not generated for
+functions that have no arguments, because it would act exactly like the existing
+Expect and ExpectAndReturn calls.
+
+* `void func(params)` => `void func_ExpectAnyArgs(void)`
+* `retval func(params)` => `void func_ExpectAnyArgsAndReturn(retval_to_return)`
+
+
 Array:
 ------
 
-An ExpectWithArray will check as many elements as you specify.
-If you specify zero elements, it will check just the pointer if
-`:smart` mode is configured or fail if `:compare_data` is set.
+An ExpectWithArray is another variant of Expect. Like expect, it cares about
+the number of times a mock is called, the arguments it is called with, and the
+values it is to return. This variant has another feature, though. For anything
+that resembles a pointer or array, it breaks the argument into TWO arguments.
+The first is the original pointer. The second specify the number of elements
+it is to verify of that array. If you specify 1, it'll check one object. If 2,
+it'll assume your pointer is pointing at the first of two elements in an array.
+If you specify zero elements and `UNITY_COMPARE_PTRS_ON_ZERO_ARRAY` is defined,
+then this assertion can also be used to directly compare the pointers to verify
+that they are pointing to the same memory address.
 
 * `void func(void)` => (nothing. In fact, an additional function is only generated if the params list contains pointers)
 * `void func(ptr * param, other)` => `void func_ExpectWithArray(ptr* param, int param_depth, other)`
 * `retval func(void)` => (nothing. In fact, an additional function is only generated if the params list contains pointers)
 * `retval func(other, ptr* param)` => `void func_ExpectWithArrayAndReturn(other, ptr* param, int param_depth, retval_to_return)`
 
+When the `:array_size_name` and `:array_size_type` options are configured, CMock
+can recognize that a scalar parameter is the size of an adjacent pointer parameter
+and pair them together. When a size parameter is paired with a pointer, the `_Expect`
+call automatically uses it as the array depth, and `_ExpectWithArray` preserves
+the original argument order without adding a separate depth argument.
 
-Callback:
----------
+When performing this type of automatic identification of arguments, CMock will also
+generate an additional `_ExpectWithArrayExtended`, which accepts an explicit
+depth for every pointer — allowing you to override the inferred depth when the
+pairing heuristic guesses wrong:
 
-As soon as you stub a callback in a test, it will call the callback
-whenever the mock is encountered and return the retval returned
-from the callback (if any) instead of performing the usual expect
-checks. It can be configured to check the arguments first (like
-expects) or just jump directly to the callback.
+* `void func(int size, ptr* buf)` =>
+  * `void func_ExpectWithArray(int size, ptr* buf)` _(depth inferred from `size`)_
+  * `void func_ExpectWithArrayExtended(int size, ptr* buf, int buf_Depth)` _(explicit override)_
 
-* `void func(void)` => `void func_StubWithCallback(CMOCK_func_CALLBACK callback)`
-where `CMOCK_func_CALLBACK` looks like: `void func(int NumCalls)`
-* `void func(params)` => `void func_StubWithCallback(CMOCK_func_CALLBACK callback)`
-where `CMOCK_func_CALLBACK` looks like: `void func(params, int NumCalls)`
-* `retval func(void)` => `void func_StubWithCallback(CMOCK_func_CALLBACK callback)`
-where `CMOCK_func_CALLBACK` looks like: `retval func(int NumCalls)`
-* `retval func(params)` => `void func_StubWithCallback(CMOCK_func_CALLBACK callback)`
-where `CMOCK_func_CALLBACK` looks like: `retval func(params, int NumCalls)`
-
-
-Cexception:
------------
-
-If you are using Cexception for error handling, you can use this
-to throw errors from inside mocks. Like Expects, it remembers
-which call was supposed to throw the error, and it still checks
-parameters.
-
-* `void func(void)` => `void func_ExpectAndThrow(value_to_throw)`
-* `void func(params)` => `void func_ExpectAndThrow(expected_params, value_to_throw)`
-* `retval func(void)` => `void func_ExpectAndThrow(value_to_throw)`
-* `retval func(params)` => `void func_ExpectAndThrow(expected_params, value_to_throw)`
+`_ExpectWithArrayExtended` is only generated for functions where at least one
+size parameter has been automatically identified. For all other functions the short
+`_ExpectWithArray` already gives full depth control. This function can be used to correct
+poor assumptions that CMock has made. It can also be used to separately verify a passed
+length, but compare the actual contents for a DIFFERENT number of elements.
 
 
 Ignore:
 -------
 
-This plugin supports two modes. You can use it to force CMock to
-ignore calls to specific functions or to just ignore the arguments
-passed to those functions. Either way you can specify multiple
-returns or a single value to always return, whichever you prefer.
+Maybe you don't care about the number of times a particular function is called or
+the actual arguments it is called with. In that case, you want to use Ignore. Ignore
+only needs to be called once per test. It will then ignore any further calls to that
+particular mock. The IgnoreAndReturn works similarly, except that it has the added
+benefit of knowing what to return when that call happens. If the mock is called more
+times than IgnoreAndReturn was called, it will keep returning the last value without
+complaint. If it's called fewer times, it will also ignore that. You SAID you didn't
+care how many times it was called, right?
 
 * `void func(void)` => `void func_Ignore(void)`
 * `void func(params)` => `void func_Ignore(void)`
 * `retval func(void)` => `void func_IgnoreAndReturn(retval_to_return)`
 * `retval func(params)` => `void func_IgnoreAndReturn(retval_to_return)`
 
+StopIgnore:
+-------
 
-Ignore Args:
+Maybe you want to ignore a particular function for part of a test but dont want to
+ignore it later on. In that case, you want to use StopIgnore which will cancel the
+previously called Ignore or IgnoreAndReturn requiring you to Expect or otherwise
+handle the call to a function.
+
+* `void func(void)` => `void func_StopIgnore(void)`
+* `void func(params)` => `void func_StopIgnore(void)`
+* `retval func(void)` => `void func_StopIgnore(void)`
+* `retval func(params)` => `void func_StopIgnore(void)`
+
+IgnoreStateless:
+----------------
+
+This plugin is similar to the Ignore plugin, but the IgnoreAndReturn functions are
+stateless. So the Ignored function will always return the last specified return value
+and does not queue the return values as the IgnoreAndReturn of the default plugin will.
+
+To stop ignoring a function you can call StopIgnore or simply overwrite the Ignore
+(resp. IgnoreAndReturn) with an Expect (resp. ExpectAndReturn). Note that calling
+Ignore (resp IgnoreAndReturn) will clear your previous called Expect
+(resp. ExpectAndReturn), so they are not restored after StopIgnore is called.
+
+You can use this plugin by using `:ignore_stateless` instead of `:ignore` in your
+CMock configuration file.
+
+The generated functions are the same as **Ignore** and **StopIgnore** above.
+
+Ignore Arg:
 ------------
 
-This plugin adds the ability to specify specifc arguments to ignore
-for a function, instead of ignoring all the arguments or the entire
-function call, as the Ignore plugin supports. This will create a function
-for each argument and each function.
+Maybe you overall want to use Expect and its similar variations, but you don't care
+what is passed to a particular argument. This is particularly useful when that argument
+is a pointer to a value that is supposed to be filled in by the function. You don't want
+to use ExpectAnyArgs, because you still care about the other arguments. Instead, after
+an Expect call is made, you can call this function. It tells CMock to ignore
+a particular argument for the rest of this test, for this mock function. You may call
+multiple instances of this to ignore multiple arguments after each expectation if
+desired.
 
 * `void func(params)` => `void func_IgnoreArg_paramName(void)`
 
@@ -158,26 +234,97 @@ for each argument and each function.
 ReturnThruPtr:
 --------------
 
-This plugin adds a number of options for returning data through arguments
-that are pointers. This is fled separately from the Expect/Ignore call, so
-you will want to issue one of those calls each time as well. This will only
-create an extra call for arguments that are pointers. It will create one per
-pointer argument.
+Another option which operates on a particular argument of a function is the ReturnThruPtr
+plugin. For every argument that resembles a pointer or reference, CMock generates an
+instance of this function. Just as the AndReturn functions support injecting one or more
+return values into a queue, this function lets you specify one or more return values which
+are queued up and copied into the space being pointed at each time the mock is called.
 
 * `void func(param1)` => `void func_ReturnThruPtr_paramName(val_to_return)`
-* => `void func_ReturnArrayThruPtr_paramName(cal_to_return, len)`
+* => `void func_ReturnArrayThruPtr_paramName(val_to_return, len)`
 * => `void func_ReturnMemThruPtr_paramName(val_to_return, size)`
 
+For example, consider the following function:
+
+`BOOL divide(uint numerator, uint denominator, uint* result){
+    if (denominator == 0){
+        return FALSE;
+    }
+    *result = numerator/denominator;
+    return TRUE;
+}
+`
+
+We might want to mock this function so that regardless of the inputs, it returns TRUE and a result of 23.
+We could do so like this:
+
+`uint result_1 = 23;
+divide_ExpectAnyArgsAndReturn(TRUE);
+divide_ReturnThruPtr_result(&result_1);
+`
+
+If we want to expect a numerator of 5 and a denominator of 2 and return a result of 42:
+`uint result_1 = 42;
+divide_ExpectAndReturn(5,2,NULL,TRUE);
+divide_IgnoreArg_result();
+divide_ReturnThruPtr_result(&result_1);
+`
+
+Callback:
+---------
+
+If all those other options don't work, and you really need to do something custom, you
+still have a choice. As soon as you stub a callback in a test, it will call the callback
+whenever the mock is encountered and return the retval returned from the callback (if any).
+
+* `void func(void)` => `void func_[AddCallback,Stub](CMOCK_func_CALLBACK callback)`
+where `CMOCK_func_CALLBACK` looks like: `void func(int NumCalls)`
+* `void func(params)` => `void func_[AddCallback,Stub](CMOCK_func_CALLBACK callback)`
+where `CMOCK_func_CALLBACK` looks like: `void func(params, int NumCalls)`
+* `retval func(void)` => `void func_[AddCallback,Stub](CMOCK_func_CALLBACK callback)`
+where `CMOCK_func_CALLBACK` looks like: `retval func(int NumCalls)`
+* `retval func(params)` => `void func_[AddCallback,Stub](CMOCK_func_CALLBACK callback)`
+where `CMOCK_func_CALLBACK` looks like: `retval func(params, int NumCalls)`
+
+You can choose from two options:
+
+* `func_AddCallback` tells the mock to check its arguments and calling
+order (based on any Expects you've set up) before calling the callback.
+* `func_Stub` tells the mock to skip all the normal checks and jump directly
+to the callback instead. In this case, you are replacing the normal mock calls
+with your own custom stub function.
+
+There is also an older name, `func_StubWithCallback`, which is just an alias
+for either `func_AddCallback` or `func_Stub` depending on setting of the
+`:callback_after_arg_check` toggle. This is deprecated and we recommend using
+the two options above.
+
+
+Cexception:
+-----------
+
+Finally, if you are using Cexception for error handling, you can use this to throw errors
+from inside mocks. Like Expects, it remembers which call was supposed to throw the error,
+and it still checks parameters first.
+
+* `void func(void)` => `void func_ExpectAndThrow(value_to_throw)`
+* `void func(params)` => `void func_ExpectAndThrow(expected_params, value_to_throw)`
+* `retval func(void)` => `void func_ExpectAndThrow(value_to_throw)`
+* `retval func(params)` => `void func_ExpectAndThrow(expected_params, value_to_throw)`
+
+
+
 Running CMock
 =============
 
 CMock is a Ruby script and class. You can therefore use it directly
 from the command line, or include it in your own scripts or rakefiles.
 
+
 Mocking from the Command Line
 -----------------------------
 
-After unpacking CMock, you will find CMock.rb in the 'lib' directory.
+After unpacking CMock, you will find cmock.rb in the 'lib' directory.
 This is the file that you want to run. It takes a list of header files
 to be mocked, as well as an optional yaml file for a more detailed
 configuration (see config options below).
@@ -191,6 +338,7 @@ And this will create two mocks using the default configuration:
 
     ruby cmock.rb ../mocking/stuff/is/fun.h ../try/it/yourself.h
 
+
 Mocking From Scripts or Rake
 ----------------------------
 
@@ -201,6 +349,7 @@ three ways.
 
 You may specify nothing, allowing it to run with default settings:
 
+    require 'cmock.rb'
     cmock = CMock.new
 
 You may specify a YAML file containing the configuration options
@@ -212,7 +361,42 @@ You may specify the options explicitly:
 
     cmock = Cmock.new(:plugins => [:cexception, :ignore], :mock_path => 'my/mocks/')
 
+Creating Skeletons:
+-------------------
+
+Not only is CMock able to generate mock files from a header file, but it is also able
+to generate (and update) skeleton C files from headers. It does this by creating a
+(mostly) empty implementation for every function that is declared in the header. If you later
+add to that header list, just run this feature again and it will add prototypes for the missing
+functions!
+
+Like the normal usecase for CMock, this feature can be used from the command line
+or from within its ruby API. For example, from the command line, add `--skeleton` to
+generate a skeleton instead:
+
+```
+ruby cmock.rb --skeleton ../create/c/for/this.h
+```
+
+Using CMock Without Ceedling
+----------------------------
+
+CMock depends on the Unity test framework, but it does not *require* Ceedling. You can use the 
+generated mocks directly with the Unity test framework in whatever build system you prefer. One 
+important thing to remember when doing this is that you will need to call the `_Init` function 
+for each of your mocks BEFORE the tests and the `_Verify` function for each mock AFTER each test.
+This allows CMock to perform all of its internal accounting. If you're running into problems where
+some errors aren't getting caught, this is likely what you are missing.
+
+There are many ways to accomplish this. Any is valid:
+
+  - These actions can be performed as part of `setUp` and `tearDown` in each test file
+  - You can hand-write your own RUN_TEST macro. If so, protect `_Verify` calls in `TEST_PROTECT`
+  - You can use Unity's test runner generator and it will automatically take care of this for you.
+  - You can use Ceedling and it will automatically take care of this for you.
+
 Config Options:
+---------------
 
 The following configuration options can be specified in the
 yaml file or directly when instantiating.
@@ -229,16 +413,35 @@ Defined in the yaml file, they look more like this:
             - __intrinsic
           :when_ptr: :compare
 
+In all cases, you can just include the things that you want to override
+from the defaults. We've tried to specify what the defaults are below.
 
 * `:attributes`:
   These are attributes that CMock should ignore for you for testing
   purposes. Custom compiler extensions and externs are handy things to
-  put here.
+  put here. If your compiler is choking on some extended syntax, this
+  is often a good place to look.
+
+  * defaults: ['__ramfunc', '__irq', '__fiq', 'register', 'extern']
+  * **note:** this option will reinsert these attributes onto the mock's calls.
+    If that isn't what you are looking for, check out :strippables.
+
+* `:c_calling_conventions`:
+  Similarly, CMock may need to understand which C calling conventions
+  might show up in your codebase. If it encounters something it doesn't
+  recognize, it's not going to mock it. We have the most common covered,
+  but there are many compilers out there, and therefore many other options.
+
+  * defaults: ['__stdcall', '__cdecl', '__fastcall']
+  * **note:** this option will reinsert these attributes onto the mock's calls.
+    If that isn't what you are looking for, check out :strippables.
 
 * `:callback_after_arg_check`:
-  Tell `:callback` plugin to do the normal argument checking before it
-  calls the callback function. This defaults to false, where the
-  callback function is called instead of the argument verification.
+  Tell `:callback` plugin to do the normal argument checking **before** it
+  calls the callback function by setting this to true. When false, the
+  callback function is called **instead** of the argument verification.
+
+  * default: false
 
 * `:callback_include_count`:
   Tell `:callback` plugin to include an extra parameter to specify the
@@ -246,64 +449,134 @@ Defined in the yaml file, they look more like this:
   callback has the same interface as the mocked function. This can be
   handy when you're wanting to use callback as a stub.
 
+  * default: true
+
 * `:cexception_include`:
-  Tell `:cexception` plugin where to find CException.h... only need to
-  define if it's not in your build path already.
+  Tell `:cexception` plugin where to find CException.h... You only need to
+  define this if it's not in your build path already... which it usually
+  will be for the purpose of your builds.
+
+  * default: *nil*
+
+* `:create_error_stubs`:
+  New users of CMock sometimes struggle with the concept that CMock is
+  generating differently named interface functions for a mock depending
+  on whether a function to be mocked has a return value or not (see
+  description of the plugins `:Expect`, `:ExpectAnyArgs`, `:Array`, `:Ignore`,
+  `:IgnoreStateless` above). They are looking e.g. for a function `func_Expect()`
+  while CMock generated the function `func_ExpectAndReturn()` instead.
+  This has proven to be a significant hurdle, because it is not easy to
+  spot the slightly different named function within the generated mock.
+  Therefore CMock (v2.6.0 and newer) is generating *both* functions
+  per default, although one of them has only a "stub" functionality:
+  on call it will always fail the test emitting a helpful error message
+  pointing towards the correct function.
+
+  Experienced CMock users on the other hand might prefer the original
+  behavior, where no additional error stubs are generated - e.g. to
+  ensure code completion offers only "real" functionality of the mock.
+  In this case, the option `:create_error_stubs` can be set to false.
+
+  * default: true
 
 * `:enforce_strict_ordering`:
   CMock always enforces the order that you call a particular function,
   so if you expect GrabNabber(int size) to be called three times, it
   will verify that the sizes are in the order you specified. You might
-  also want to make sure that all different functions are called in a
+  *also* want to make sure that all different functions are called in a
   particular order. If so, set this to true.
 
+  * default: false
+
 * `:framework`:
   Currently the only option is `:unity.` Eventually if we support other
   unity test frameworks (or if you write one for us), they'll get added
   here.
 
+  : default: :unity
+
 * `:includes`:
   An array of additional include files which should be added to the
   mocks. Useful for global types and definitions used in your project.
   There are more specific versions if you care WHERE in the mock files
-  the includes get placed. You can define any or all of
-  `:includes_h_pre_orig_header,` `:includes_h_post_orig_header, `
-  `:includes_c_pre_header,` `:includes_c_post_header
+  the includes get placed. You can define any or all of these options.
+
+  * `:includes`
+  * `:includes_h_pre_orig_header`
+  * `:includes_h_post_orig_header`
+  * `:includes_c_pre_header`
+  * `:includes_c_post_header`
+  * default: nil #for all 5 options
 
 * `:memcmp_if_unknown`:
-  This is true by default. When true, CMock will just do a memory
-  comparison of types that it doesn't recognize (not standard types, not
-  in `:treat_as,` and not in a unity helper). If you instead want it to
-  throw an error, just set this to false.
+  C developers create a lot of types, either through typedef or preprocessor
+  macros. CMock isn't going to automatically know what you were thinking all
+  the time (though it tries its best). If it comes across a type it doesn't
+  recognize, you have a choice on how you want it to handle it. It can either
+  perform a raw memory comparison and report any differences, or it can fail
+  with a meaningful message. Either way, this feature will only happen after
+  all other mechanisms have failed (The thing encountered isn't a standard
+  type. It isn't in the :treat_as list. It isn't in a custom unity_helper).
+
+  * default: true
 
 * `:mock_path`:
   The directory where you would like the mock files generated to be
   placed.
 
+  * default: mocks
+
 * `:mock_prefix`:
-  The prefix to append to your mock files. Defaults to “Mock”, so a file
-  “USART.h” will get a mock called “MockUSART.c”
+  The prefix to prepend to your mock files. For example, if it's `Mock`, a file
+  “USART.h” will get a mock called “MockUSART.c”. This CAN be used with a suffix
+  at the same time.
+
+  * default: Mock
 
 * `:mock_suffix`:
-  The suffix to append to your mock files. Defaults to “”.
+  The suffix to append to your mock files. For example, it it's `_Mock`, a file
+  "USART.h" will get a mock called "USART_Mock.h". This CAN be used with a prefix
+  at the same time.
 
-* `:weak`:
-  When set to some value, the generated mocks are defined as weak symbols using the configured format. Defaults to ''.
-  Set to '__attribute ((weak))' for weak mocks when using GCC. Set to any non-empty string for weak mocks when using IAR.
-
-* `:subdir`:
-  Relative subdir for your mocks.  Set this to e.g. "sys" in order to
-  create mock for `sys/types.h` in `:mock_path`/sys/
+  * default: ""
 
 * `:plugins`:
-  An array of which plugins to enable. 'expect' is always active. Also
-  available currently are `:ignore,` `:ignore_arg,` `:array,`
-  `:cexception,` `:callback,` and `:return_thru_ptr`
+  An array of which plugins to enable. ':expect' is always active. Also
+  available currently:
+
+  * `:ignore`
+  * `:ignore_stateless`
+  * `:ignore_arg`
+  * `:expect_any_args`
+  * `:array`
+  * `:cexception`
+  * `:callback`
+  * `:return_thru_ptr`
 
 * `:strippables`:
-  An array containing a list of items to remove from the mocked header.
-  For example, use `:strippables: ['(?:functionName\s*\(+.*?\)+)']`
-  to prevent a function from being mocked.
+  An array containing a list of items to remove from the header
+  before deciding what should be mocked. This can be something simple
+  like a compiler extension CMock wouldn't recognize, or could be a
+  regex to reject certain function name patterns. This is a great way to
+  get rid of compiler extensions when your test compiler doesn't support
+  them. For example, use `:strippables: ['(?:functionName\s*\(+.*?\)+)']`
+  to prevent a function `functionName` from being mocked. By default, it
+  is ignoring all gcc attribute extensions.
+
+  * default: `['(?:__attribute__\s*\(+.*?\)+)']`
+
+* `:exclude_setjmp_h`:
+  Some embedded systems don't have <setjmp.h> available. Setting this to true
+  removes references to this header file and the ability to use cexception.
+
+  * default: false
+
+
+* `:subdir`:
+  This is a relative subdirectory for your mocks.  Set this to e.g. "sys" in
+  order to create a mock for `sys/types.h` in `(:mock_path)/sys/`.
+
+  * default: ""
 
 * `:treat_as`:
   The `:treat_as` list is a shortcut for when you have created typedefs
@@ -314,35 +587,159 @@ Defined in the yaml file, they look more like this:
   array of unsigned characters? No problem, just add 'UINT8_T*' =>
   'HEX8*'
 
+  * NOTE: unlike the other options, your specifications MERGE with the
+    default list. Therefore, if you want to override something, you must
+    reassign it to something else (or to *nil* if you don't want it)
+
+  * default:
+    * 'int': 'INT'
+    * 'char': 'INT8'
+    * 'short': 'INT16'
+    * 'long': 'INT'
+    * 'int8': 'INT8'
+    * 'int16': 'INT16'
+    * 'int32': 'INT'
+    * 'int8_t': 'INT8'
+    * 'int16_t': 'INT16'
+    * 'int32_t': 'INT'
+    * 'INT8_T': 'INT8'
+    * 'INT16_T': 'INT16'
+    * 'INT32_T': 'INT'
+    * 'bool': 'INT'
+    * 'bool_t': 'INT'
+    * 'BOOL': 'INT'
+    * 'BOOL_T': 'INT'
+    * 'unsigned int': 'HEX32'
+    * 'unsigned long': 'HEX32'
+    * 'uint32': 'HEX32'
+    * 'uint32_t': 'HEX32'
+    * 'UINT32': 'HEX32'
+    * 'UINT32_T': 'HEX32'
+    * 'void*': 'HEX8_ARRAY'
+    * 'unsigned short': 'HEX16'
+    * 'uint16': 'HEX16'
+    * 'uint16_t': 'HEX16'
+    * 'UINT16': 'HEX16'
+    * 'UINT16_T': 'HEX16'
+    * 'unsigned char': 'HEX8'
+    * 'uint8': 'HEX8'
+    * 'uint8_t': 'HEX8'
+    * 'UINT8': 'HEX8'
+    * 'UINT8_T': 'HEX8'
+    * 'char*': 'STRING'
+    * 'pCHAR': 'STRING'
+    * 'cstring': 'STRING'
+    * 'CSTRING': 'STRING'
+    * 'float': 'FLOAT'
+    * 'double': 'FLOAT'
+
+* `:treat_as_array`:
+  A specialized sort of `:treat_as` to be used when you've created a
+  typedef of an array type, such as `typedef int TenIntegers[10];`.  This
+  is a hash of typedef name to element type.  For example:
+
+        { "TenIntegers" => "int",
+          "ArrayOfFloat" => "float" }
+
+  Telling CMock about these typedefs allows it to be more intelligent
+  about parameters of such types, so that you can use features like
+  ExpectWithArray and ReturnArrayThruPtr with them.
+
 * `:treat_as_void`:
   We've seen "fun" legacy systems typedef 'void' with a custom type,
   like MY_VOID. Add any instances of those to this list to help CMock
   understand how to deal with your code.
 
+  * default: []
+
 * `:treat_externs`:
-  Set to `:include` to mock externed functions or `:exclude` to ignore
-  them (the default).
+  This specifies how you want CMock to handle functions that have been
+  marked as extern in the header file. Should it mock them?
+
+  * `:include` will mock externed functions
+  * `:exclude` will ignore externed functions (default).
+
+* `:treat_inlines`:
+  This specifies how you want CMock to handle functions that have been
+  marked as inline in the header file. Should it mock them?
+
+  * `:include` will mock inlined functions
+  * `:exclude` will ignore inlined functions (default).
+
+  CMock will look for the following default patterns (simplified from the actual regex):
+  - "static inline"
+  - "inline static"
+  - "inline"
+
+  You can override these patterns, check out :inline_function_patterns.
+
+  Enabling this feature does require a change in the build system that
+  is using CMock.  To understand why, we need to give some more info
+  on how we are handling inline functions internally.
+
+  Let's say we want to mock a header called example.h.  example.h
+  contains inline functions, we cannot include this header in the
+  mocks or test code if we want to mock the inline functions simply
+  because the inline functions contain an implementation that we want
+  to override in our mocks!
+
+  So, to circumvent this, we generate a new header, also named
+  example.h, in the same directory as mock_example.h/c .  This newly
+  generated header should/is exactly the same as the original header,
+  only difference is the inline functions are transformed to 'normal'
+  functions declarations.  Placing the new header in the same
+  directory as mock_example.h/c ensures that they will include the new
+  header and not the old one.
+
+  However, CMock has no control in how the build system is configured
+  and which include paths the test code is compiled with.  In order
+  for the test code to also see the newly generated header ,and not
+  the old header with inline functions, the build system has to add
+  the mock folder to the include paths.
+
+  Furthermore, we need to keep the order of include paths in mind. We
+  have to set the mock folder before the other includes to avoid the
+  test code including the original header instead of the newly
+  generated header (without inline functions).
 
 * `:unity_helper_path`:
   If you have created a header with your own extensions to unity to
   handle your own types, you can set this argument to that path. CMock
   will then automagically pull in your helpers and use them. The only
   trick is that you make sure you follow the naming convention:
-  UNITY_TEST_ASSERT_EQUAL_YourType
+  `UNITY_TEST_ASSERT_EQUAL_YourType`. If it finds macros of the right
+  shape that match that pattern, it'll use them.
+
+  * default: []
 
 * `:verbosity`:
-  0 for errors only. 1 for errors and warnings. 2 for normal. 3 for
-  verbose
+  How loud should CMock be?
+
+  * 0 for errors only
+  * 1 for errors and warnings
+  * 2 for normal (default)
+  * 3 for verbose
+
+* `:weak`:
+  When set this to some value, the generated mocks are defined as weak
+  symbols using the configured format. This allows them to be overridden
+  in particular tests.
+
+  * Set to '__attribute ((weak))' for weak mocks when using GCC.
+  * Set to any non-empty string for weak mocks when using IAR.
+  * default: ""
 
 * `:when_no_prototypes`:
   When you give CMock a header file and ask it to create a mock out of
   it, it usually contains function prototypes (otherwise what was the
   point?). You can control what happens when this isn't true. You can
-  set this to `:warn,` `:ignore,` or `:error
+  set this to `:warn,` `:ignore,` or `:error`
+
+  * default: :warn
 
 * `:when_ptr`:
   You can customize how CMock deals with pointers (c strings result in
-  string comparisons... we're talking about other pointers here). Your
+  string comparisons... we're talking about **other** pointers here). Your
   options are `:compare_ptr` to just verify the pointers are the same,
   `:compare_data` or `:smart` to verify that the data is the same.
   `:compare_data` and `:smart` behaviors will change slightly based on
@@ -351,41 +748,196 @@ Defined in the yaml file, they look more like this:
   to a struct called ORGAN_T, it will compare one ORGAN_T (whatever that
   is).
 
+  * default: :smart
+
+* `:array_size_type`:
+* `:array_size_name`:
+  When the `:array` plugin is disabled, these options do nothing.
+
+  When the `:array` plugin is enabled, these options allow CMock to recognize
+  functions with parameters that might refer to an array, like the following,
+  and treat them more intelligently:
+
+  * `void GoBananas(Banana * bananas, int num_bananas)`
+  * `int write_data(int fd, const uint8_t * data, uint32_t size)`
+  * `void store_data(int buf_size, uint8_t * buf)`
+
+  `:array_size_type` is a list of additional types (besides `int` and `size_t`)
+  that could be used for an array size parameter.  For example, to get CMock to
+  recognize that `uint32_t size` is an array size, you'd need to say:
+
+        cfg[:array_size_type] = ['uint32_t']
+
+  `:array_size_name` is a regular expression used to match an array size
+  parameter by name.  By default, it's 'size|len'.  To get CMock to recognize a
+  name like `num_bananas`, you could tell it to also accept names containing
+  'num_' like this:
+
+        cfg[:array_size_name] = 'size|len|num_'
+
+  A parameter must match *both* `:array_size_type` and `:array_size_name` to be
+  treated as an array size.
+
+  **Pairing heuristic:** CMock scores each candidate size parameter against each
+  pointer parameter using name similarity. It strips size-words (e.g. "size",
+  "len") from the size parameter's name to derive a root, then checks whether
+  that root matches the pointer's name exactly (score 10), as a prefix or suffix
+  (score 7), or as a substring (score 5). Adjacency in the argument list adds a
+  small bonus (score +2). The highest-scoring pairing wins. This means CMock
+  correctly pairs `buff_size` with `buffer` even when another pointer appears
+  adjacent to `buff_size`.
+
+  Size parameters may appear either **before or after** the pointer they describe.
+  CMock recognizes both orderings:
+
+  * Size after pointer: `void func(uint8_t* buf, int buf_size)` — the `_Expect`
+    call uses `buf_size` as the depth automatically. `_ExpectWithArray` adds an
+    explicit `buf_Depth` argument after `buf` for manual override.
+
+  * Size before pointer: `void func(int buf_size, uint8_t* buf)` — the `_Expect`
+    call again uses `buf_size` as the depth automatically, and `_ExpectWithArray`
+    keeps arguments in their original order with no extra depth argument added.
+    An additional `_ExpectWithArrayExtended` variant is generated that does accept
+    an explicit depth, allowing you to override the inferred value when needed.
+
+  Once you've told it how to recognize your arrays, CMock will give you `_Expect`
+  calls that work more like `_ExpectWithArray`, and compare an array of objects
+  rather than just a single object.
+
+  For example, if you write the following, CMock will check that GoBananas is
+  called and passed an array containing a green banana followed by a yellow
+  banana:
+
+        Banana b[2] = {GreenBanana, YellowBanana};
+        GoBananas_Expect(b, 2);
+
+  In other words, `GoBananas_Expect(b, 2)` now works just the same as:
+
+        GoBananas_ExpectWithArray(b, 2, 2);
+
+* `:fail_on_unexpected_calls`:
+  By default, CMock will fail a test if a mock is called without `_Expect` and `_Ignore`
+  called first. While this forces test writers to be more explicit in their expectations,
+  it can clutter tests with `_Expect` or `_Ignore` calls for functions which are not the focus
+  of the test. While this is a good indicator that this module should be refactored, some
+  users are not fans of the additional noise.
+
+  Therefore, :fail_on_unexpected_calls can be set to false to force all mocks to start with
+  the assumption that they are operating as `_Ignore` unless otherwise specified.
+
+  * default: true
+  * **note:**
+    If this option is disabled, the mocked functions will return
+    a default value (0) when called (and only if they have to return something of course).
+
+* `:inline_function_patterns`:
+  An array containing a list of strings to detect inline functions.
+  This option is only taken into account if you enable :treat_inlines.
+  These strings are interpreted as regex patterns so be sure to escape
+  certain characters. For example, use `:inline_function_patterns: ['static inline __attribute__ \(\(always_inline\)\)']`
+  to recognize `static inline __attribute__ ((always_inline)) int my_func(void)`
+  as an inline function.
+  The default patterns are are:
+
+  * default: ['(static\s+inline|inline\s+static)\s*', '(\bstatic\b|\binline\b)\s*']
+  * **note:**
+    The order of patterns is important here!
+    We go from specific patterns ('static inline') to general patterns ('inline'),
+    otherwise we would miss functions that use 'static inline' iso 'inline'.
+
 
 Compiled Options:
 -----------------
 
 A number of #defines also exist for customizing the cmock experience.
+Feel free to pass these into your compiler or whatever is most
+convenient. CMock will otherwise do its best to guess what you want
+based on other settings, particularly Unity's settings.
 
-CMOCK_MEM_STATIC or CMOCK_MEM_DYNAMIC
+* `CMOCK_MEM_STATIC` or `CMOCK_MEM_DYNAMIC`
+  Define one of these to determine if you want to dynamically add
+  memory during tests as required from the heap. If static, you
+  can control the total footprint of Cmock. If dynamic, you will
+  need to make sure you make some heap space available for Cmock.
 
-Define one of these to determine if you want to dynamically add
-memory during tests as required from the heap. If static, you
-can control the total footprint of Cmock. If dynamic, you will
-need to make sure you make some heap space available for Cmock.
+* `CMOCK_MEM_SIZE`
+  In static mode this is the total amount of memory you are allocating
+  to Cmock. In Dynamic mode this is the size of each chunk allocated
+  at once (larger numbers grab more memory but require fewer mallocs).
 
-CMOCK_MEM_SIZE
+* `CMOCK_MEM_ALIGN`
+  The way to align your data to. Not everything is as flexible as
+  a PC, as most embedded designers know. This defaults to 2, meaning
+  align to the closest 2^2 -> 4 bytes (32 bits). You can turn off alignment
+  by setting 0, force alignment to the closest uint16 with 1 or even
+  to the closest uint64 with 3.
 
-In static mode this is the total amount of memory you are allocating
-to Cmock. In Dynamic mode this is the size of each chunk allocated
-at once (larger numbers grab more memory but require less mallocs).
+* `CMOCK_MEM_PTR_AS_INT`
+  This is used internally to hold pointers... it needs to be big
+  enough. On most processors a pointer is the same as an unsigned
+  long... but maybe that's not true for yours?
 
-CMOCK_MEM_ALIGN
+* `CMOCK_MEM_INDEX_TYPE`
+  This needs to be something big enough to point anywhere in Cmock's
+  memory space... usually it's a size_t.
 
-The way to align your data to. Not everything is as flexible as
-a PC, as most embedded designers know. This defaults to 2, meaning
-align to the closest 2^2 -> 4 bytes (32 bits). You can turn off alignment
-by setting 0, force alignment to the closest uint16 with 1 or even
-to the closest uint64 with 3.
+Other Tips
+==========
 
-CMOCK_MEM_PTR_AS_INT
+resetTest
+---------
 
-This is used internally to hold pointers... it needs to be big
-enough. On most processors a pointer is the same as an unsigned
-long... but maybe that's not true for yours?
+While this isn't strictly a CMock feature, often users of CMock are using
+either the test runner generator scripts in Unity or using Ceedling. In
+either case, there is a handy function called `resetTest` which gets
+generated with your runner. You can then use this handy function in your tests
+themselves. Call it during a test to have CMock validate everything to this point
+and start over clean. This is really useful when wanting to test a function in
+an iterative manner with different arguments.
 
-CMOCK_MEM_INDEX_TYPE
+C++ Support
+-----------
 
-This needs to be something big enough to point anywhere in Cmock's
-memory space... usually it's an unsigned int.
+C++ unit test/mocking frameworks often use a completely different approach (vs.
+CMock) that relies on overloading virtual class members and does not support
+directly mocking static class member methods or free functions (i.e., functions
+in plain C). One workaround is to wrap the non-virtual functions in an object
+that exposes them as virtual methods and modify your code to inject mocks at
+run-time... but there is another way!
 
+Simply use CMock to mock the static member methods and a C++ mocking framework
+to handle the virtual methods. (Yes, you can mix mocks from CMock and a C++
+mocking framework together in the same test!)
+
+Keep in mind that since C++ mocking frameworks often link the real object to the
+unit test too, we need to resolve multiple definition errors with something like
+the following in the source of the real implementation for any functions that
+CMock mocks:
+
+    #if defined(TEST)
+        __attribute__((weak))
+    #endif
+
+To address potential issues with re-using the same function name in different
+namespaces/classes, the generated function names include the namespace(s) and
+class. For example:
+
+    namespace MyNamespace {
+        class MyClass {
+            static int DoesSomething(int a, int b);
+        };
+    }
+
+Will generate functions like
+
+    void MyNamespace_MyClass_DoesSomething_ExpectAndReturn(int a, int b, int toReturn);
+
+
+Examples
+========
+
+You can look in the [examples directory](/examples/) for a couple of examples on how
+you might tool CMock into your build process. You may also want to consider
+using [Ceedling](https://throwtheswitch.org/ceedling). Please note that
+these examples are meant to show how the build process works. They have
+failing tests ON PURPOSE to show what that would look like. Don't be alarmed. ;)

docs/CODE_OF_CONDUCT.md

@@ -0,0 +1,138 @@
+
+# ThrowTheSwitch.org Code of Conduct
+
+Thank you for participating in a ThrowTheSwitch.org community project! We want
+this to continue to be a warm and inviting place for everyone to share ideas
+and get help. To accomplish this goal, we've developed this Code of Conduct.
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+hello@thingamabyte.com.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

docs/CONTRIBUTING.md

@@ -0,0 +1,238 @@
+# Contributing to a ThrowTheSwitch.org Project
+
+👍🎉 _First off, thanks for taking the time to contribute!_ 🎉👍
+
+The following is a set of guidelines for contributing to any of ThrowTheSwitch.org's projects or the website itself, hosted at throwtheswitch.org or ThrowTheSwitch's organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+
+### Table Of Contents
+
+- [Code of Conduct](#book-code-of-conduct)
+- [Asking Questions](#bulb-asking-questions)
+- [Opening an Issue](#inbox_tray-opening-an-issue)
+- [Feature Requests](#love_letter-feature-requests)
+- [Triaging Issues](#mag-triaging-issues)
+- [Submitting Pull Requests](#repeat-submitting-pull-requests)
+- [Writing Commit Messages](#memo-writing-commit-messages)
+- [Code Review](#white_check_mark-code-review)
+- [Coding Style](#nail_care-coding-style)
+- [Certificate of Origin](#medal_sports-certificate-of-origin)
+- [Credits](#pray-credits)
+
+## :book: Code of Conduct
+
+Please review our [Code of Conduct](CODE_OF_CONDUCT.md). It is in effect at all times. We expect it to be honored by everyone who contributes to this project. Be a Good Human!
+
+## :bulb: Asking Questions
+
+> **Note:** Please don't file an issue to ask a question. We have an official forum where the community chimes in with helpful advice if you have questions.
+
+* [ThrowTheSwitch Forums](https://throwtheswitch.org/forums)
+
+### What should I know before I get started?
+
+ThrowTheSwitch hosts a number of open source projects — Ceedling is the entrypoint for many users. Ceedling is actually built upon the foundation of Unity Test (a flexible C testing framework) and CMock (a mocking tool for C) and it coordinates many other open source and proprietary tools. Please do your best to focus your ideas and questions at the correct tool. We'll do our best to help you find your way, but there will be times where we'll have to direct your attention to another subtool.
+
+Here are some of the main projects hosted by ThrowTheSwitch.org:
+
+ - [Ceedling](https://www.github.com/throwtheswitch/ceedling) -- Build coordinator for testing C applications, especially embedded C (and optionally your release build too!)
+ - [CMock](https://www.github.com/throwtheswitch/cmock) -- Mocking tool for automatically creating stubs, mocks, and skeletons in C
+ - [Unity](https://www.github.com/throwtheswitch/unity) -- Unit Testing framework for C, specially embedded C.
+ - [MadScienceLabDocker](https://www.github.com/throwtheswitch/madsciencelabdocker) -- Docker image giving you a shortcut to getting running with Ceedling
+ - [CException](https://www.github.com/throwtheswitch/cexception) -- An exception framework for using simple exceptions in C.
+
+There are many more, but this list should be a good starting point.
+
+## :inbox_tray: Opening an Issue
+
+Before [creating an issue](https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue), check if you are using the latest version of the project. If you are not up-to-date, see if updating fixes your issue first.
+
+### :beetle: Bug Reports and Other Issues
+
+A great way to contribute to the project is to send a detailed issue when you encounter a problem. We always appreciate a well-written, thorough bug report. :v:
+
+In short, since you are most likely a developer, **provide a ticket that you would like to receive**.
+
+- **Review the documentation** before opening a new issue.
+
+- **Do not open a duplicate issue!** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
+
+- **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue.
+
+- **Fully complete the provided issue template.** The bug report template requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable).
+
+- **Use [GitHub-flavored Markdown](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).** Especially put code blocks and console outputs in backticks (```). This improves readability.
+
+## :seedling: Feature Requests
+
+Feature requests are welcome! We don't have all the answers and we truly love the collaborative experience of building software together! That being said, we cannot guarantee your request will be accepted. We want to avoid [feature creep](https://en.wikipedia.org/wiki/Feature_creep). Your idea may be great, but also out-of-scope for the project. If accepted, we'll do our best to tackle it in a timely manner, but cannot make any commitments regarding the timeline for implementation and release. However, you are welcome to submit a pull request to help!
+
+- **Please don't open a duplicate feature request.** Search for existing feature requests first. If you find your feature (or one very similar) previously requested, comment on that issue.
+
+- **Fully complete the provided issue template.** The feature request template asks for all necessary information for us to begin a productive conversation. 
+
+- Be precise about the proposed outcome of the feature and how it relates to existing features. Include implementation details if possible.
+
+## :mag: Triaging Issues
+
+You can triage issues which may include reproducing bug reports or asking for additional information, such as version numbers or reproduction instructions. Any help you can provide to quickly resolve an issue is very much appreciated!
+
+## :repeat: Submitting Pull Requests
+
+We **love** pull requests! Before [forking the repo](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [creating a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.
+
+For most contributions, after your first pull request is accepted and merged, you will be [invited to the project](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) and given **push access**. :tada:
+
+*Note: All contributions will be licensed under the project's license.*
+
+- **Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether. 
+
+- **Coordinate bigger changes.** For large and non-trivial changes, open an issue to discuss a strategy with the maintainers. Otherwise, you risk doing a lot of work for nothing!
+
+- **Prioritize understanding over cleverness.** Write code clearly and concisely. Remember that source code usually gets written once and read often. Ensure the code is clear to the reader. The purpose and logic should be obvious to a reasonably skilled developer, otherwise you should add a comment that explains it.
+
+- **Follow existing coding style and conventions.** Keep your code consistent with the style, formatting, and conventions in the rest of the code base. When possible, these will be enforced with a linter. Consistency makes it easier to review and modify in the future.
+
+- **Include test coverage.** Add unit tests when possible. Follow existing patterns for implementing tests.
+
+- **Update the example project** if one exists to exercise any new functionality you have added.
+
+- **Add documentation.** Document your changes with code doc comments or in existing guides.
+
+- **Update the CHANGELOG** for all enhancements and bug fixes. Include the corresponding issue number if one exists, and your GitHub username. (example: "- Fixed crash in profile view. #123 @jessesquires")
+
+- **Use the repo's default branch.** Branch from and [submit your pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) to the repo's default branch. Usually this is `main`, but it could be `dev`, `develop`, or `master`.
+
+- **[Resolve any merge conflicts](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)** that occur.
+
+- **Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it. 
+
+- When writing comments, use properly constructed sentences, including punctuation.
+
+- Use spaces, not tabs.
+
+## :memo: Writing Commit Messages
+
+Please [write a great commit message](https://chris.beams.io/posts/git-commit/).
+
+1. Separate subject from body with a blank line
+1. Limit the subject line to 50 characters
+1. Capitalize the subject line
+1. Do not end the subject line with a period
+1. Wrap the body at _about_ 72 characters
+1. Use the body to explain **why**, *not what and how* (the code shows that!)
+1. If applicable, prefix the title with the relevant component name or emoji (see below. examples: "[Docs] Fix typo", "[Profile] Fix missing avatar")
+
+```
+:palm_tree: Summary of Amazing Feature Here
+
+Add a more detailed explanation here, if necessary. Possibly give 
+some background about the issue being fixed, etc. The body of the 
+commit message can be several paragraphs. Further paragraphs come 
+after blank lines and please do proper word-wrap.
+
+Wrap it to about 72 characters or so. In some contexts, 
+the first line is treated as the subject of the commit and the 
+rest of the text as the body. The blank line separating the summary 
+from the body is critical (unless you omit the body entirely); 
+various tools like `log`, `shortlog` and `rebase` can get confused 
+if you run the two together.
+
+Explain the problem that this commit is solving. Focus on why you
+are making this change as opposed to how or what. The code explains 
+how or what. Reviewers and your future self can read the patch, 
+but might not understand why a particular solution was implemented.
+Are there side effects or other unintuitive consequences of this
+change? Here's the place to explain them.
+
+ - Bullet points are awesome, too
+
+ - A hyphen should be used for the bullet, preceded
+   by a single space, with blank lines in between
+
+Note the fixed or relevant GitHub issues at the end:
+
+Resolves: #123
+See also: #456, #789
+```
+
+## :heart: Who Loves Emoji?
+
+Commit comments, Issues, Feature Requests... they can all use a little sprucing up, right? Consider using the following emoji for a mix of function and :sparkles: dazzle!
+
+  - actions
+    - :seedling: `:seedling:` (or other plants) when growing new features. Choose your fav! :cactus: :herb: :evergreen_tree: :palm_tree: :deciduous_tree: :blossom: 
+    - :art: `:art:` when improving the format/structure of the code
+    - :racehorse: `:racehorse:` when improving performance
+    - :non-potable_water: `:non-potable_water:` when plugging memory leaks
+    - :memo: `:memo:` when writing docs
+    - :bug: `:bug:` (or other insects) when fixing a bug. Maybe :beetle: :ant: or :honeybee: ?
+    - :fire: `:fire:` when removing code or files
+    - :green_heart: `:green_heart:` when fixing the CI build
+    - :white_check_mark: `:white_check_mark:` when adding tests
+    - :lock: `:lock:` when dealing with security
+    - :arrow_up: `:arrow_up:` when upgrading dependencies
+    - :arrow_down: `:arrow_down:` when downgrading dependencies
+    - :shirt: `:shirt:` when removing linter warnings
+
+  - platforms
+    - :penguin: `:penguin:` when fixing something on Linux
+    - :apple: `:apple:` when fixing something on macOS
+    - :checkered_flag: `:checkered_flag:` when fixing something on Windows
+
+## :white_check_mark: Code Review
+
+- **Review the code, not the author.** Look for and suggest improvements without disparaging or insulting the author. Provide actionable feedback and explain your reasoning.
+
+- **You are not your code.** When your code is critiqued, questioned, or constructively criticized, remember that you are not your code. Do not take code review personally.
+
+- **Always do your best.** No one writes bugs on purpose. Do your best, and learn from your mistakes.
+
+- Kindly note any violations to the guidelines specified in this document. 
+
+## :violin: Coding Style
+
+Consistency is the most important. Following the existing style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.
+
+For example, if all private properties are prefixed with an underscore `_`, then new ones you add should be prefixed in the same way. Or, if methods are named using camelcase, like `thisIsMyNewMethod`, then do not diverge from that by writing `this_is_my_new_method`. You get the idea. If in doubt, please ask or search the codebase for something similar.
+
+When possible, style and format will be enforced with a linter.
+
+### C Styleguide
+
+C code is linted with [AStyle](https://astyle.sourceforge.net/).
+
+### Ruby Styleguide
+
+Ruby code is linted with [Rubocop](https://github.com/rubocop/rubocop)
+
+## :medal_sports: Certificate of Origin
+
+*Developer's Certificate of Origin 1.1*
+
+By making a contribution to this project, I certify that:
+
+> 1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
+> 1. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
+> 1. The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
+> 1. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
+
+## [No Brown M&M's](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
+
+If you are reading this, bravo dear user and (hopefully) contributor for making it this far! You are awesome. :100: 
+
+To confirm that you have read this guide and are following it as best as possible, **include this emoji at the top** of your issue or pull request: :pineapple: `:pineapple:`
+
+## :pray: Credits
+
+Written by [@jessesquires](https://github.com/jessesquires). Lovingly adapted to ThrowTheSwitch.org by [@mvandervoord](https://github.com/mvandervoord).
+
+**Please feel free to adopt this guide in your own projects. Fork it wholesale or remix it for your needs.**
+
+*Many of the ideas and prose for the statements in this document were based on or inspired by work from the following communities:*
+
+- [Alamofire](https://github.com/Alamofire/Alamofire/blob/master/CONTRIBUTING.md)
+- [CocoaPods](https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md)
+- [Docker](https://github.com/moby/moby/blob/master/CONTRIBUTING.md)
+- [Linux](https://elinux.org/Developer_Certificate_Of_Origin)
+
+*We commend them for their efforts to facilitate collaboration in their projects.*

docs/ThrowTheSwitchCodingStandard.md

@@ -0,0 +1,207 @@
+# ThrowTheSwitch.org Coding Standard
+
+Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
+we try to follow these standards to unify our contributors' code into a cohesive
+unit (puns intended). You might find places where these standards aren't
+followed. We're not perfect. Please be polite where you notice these discrepancies
+and we'll try to be polite when we notice yours.
+
+;)
+
+
+## Why Have A Coding Standard?
+
+Being consistent makes code easier to understand. We've made an attempt to keep
+our standard simple because we also believe that we can only expect someone to
+follow something that is understandable. Please do your best.
+
+
+## Our Philosophy
+
+Before we get into details on syntax, let's take a moment to talk about our
+vision for these tools. We're C developers and embedded software developers.
+These tools are great to test any C code, but catering to embedded software has
+made us more tolerant of compiler quirks. There are a LOT of quirky compilers
+out there. By quirky I mean "doesn't follow standards because they feel like
+they have a license to do as they wish."
+
+Our philosophy is "support every compiler we can". Most often, this means that
+we aim for writing C code that is standards compliant (often C89... that seems
+to be a sweet spot that is almost always compatible). But it also means these
+tools are tolerant of things that aren't common. Some that aren't even
+compliant. There are configuration options to override the size of standard
+types. There are configuration options to force Unity to not use certain
+standard library functions. A lot of Unity is configurable and we have worked
+hard to make it not TOO ugly in the process.
+
+Similarly, our tools that parse C do their best. They aren't full C parsers
+(yet) and, even if they were, they would still have to accept non-standard
+additions like gcc extensions or specifying `@0x1000` to force a variable to
+compile to a particular location. It's just what we do, because we like
+everything to Just Work™.
+
+Speaking of having things Just Work™, that's our second philosophy. By that, we
+mean that we do our best to have EVERY configuration option have a logical
+default. We believe that if you're working with a simple compiler and target,
+you shouldn't need to configure very much... we try to make the tools guess as
+much as they can, but give the user the power to override it when it's wrong.
+
+
+## Naming Things
+
+Let's talk about naming things. Programming is all about naming things. We name
+files, functions, variables, and so much more. While we're not always going to
+find the best name for something, we actually put quite a bit of effort into
+finding *What Something WANTS to be Called*™.
+
+When naming things, we more or less follow this hierarchy, the first being the
+most important to us (but we do all four whenever possible):
+1. Readable
+2. Descriptive
+3. Consistent
+4. Memorable
+
+
+#### Readable
+
+We want to read our code. This means we like names and flow that are more
+naturally read. We try to avoid double negatives. We try to avoid cryptic
+abbreviations (sticking to ones we feel are common).
+
+
+#### Descriptive
+
+We like descriptive names for things, especially functions and variables.
+Finding the right name for something is an important endeavor. You might notice
+from poking around our code that this often results in names that are a little
+longer than the average. Guilty. We're okay with a tiny bit more typing if it
+means our code is easier to understand.
+
+There are two exceptions to this rule that we also stick to as religiously as
+possible:
+
+First, while we realize hungarian notation (and similar systems for encoding
+type information into variable names) is providing a more descriptive name, we
+feel that (for the average developer) it takes away from readability and
+therefore is to be avoided.
+
+Second, loop counters and other local throw-away variables often have a purpose
+which is obvious. There's no need, therefore, to get carried away with complex
+naming. We find i, j, and k are better loop counters than loopCounterVar or
+whatnot. We only break this rule when we see that more description could improve
+understanding of an algorithm.
+
+
+#### Consistent
+
+We like consistency, but we're not really obsessed with it. We try to name our
+configuration macros in a consistent fashion... you'll notice a repeated use of
+UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
+remember each macro's details.
+
+
+#### Memorable
+
+Where ever it doesn't violate the above principles, we try to apply memorable
+names. Sometimes this means using something that is simply descriptive, but
+often we strive for descriptive AND unique... we like quirky names that stand
+out in our memory and are easier to search for. Take a look through the file
+names in Ceedling and you'll get a good idea of what we are talking about here.
+Why use preprocess when you can use preprocessinator? Or what better describes a
+module in charge of invoking tasks during releases than release_invoker? Don't
+get carried away. The names are still descriptive and fulfill the above
+requirements, but they don't feel stale.
+
+
+## C and C++ Details
+
+We don't really want to add to the style battles out there. Tabs or spaces?
+How many spaces? Where do the braces go? These are age-old questions that will
+never be answered... or at least not answered in a way that will make everyone
+happy.
+
+We've decided on our own style preferences. If you'd like to contribute to these
+projects (and we hope that you do), then we ask if you do your best to follow
+the same. It will only hurt a little. We promise.
+
+
+#### Whitespace
+
+Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
+power-of-2 number that looks decent on a wide screen. We have no more reason
+than that. We break that rule when we have lines that wrap (macros or function
+arguments or whatnot). When that happens, we like to indent further to line
+things up in nice tidy columns.
+
+```C
+    if (stuff_happened)
+    {
+        do_something();
+    }
+```
+
+
+#### Case
+
+- Files - all lower case with underscores.
+- Variables - all lower case with underscores
+- Macros - all caps with underscores.
+- Typedefs - all caps with underscores. (also ends with _T).
+- Functions - camel cased. Usually named ModuleName_FuncName
+- Constants and Globals - camel cased.
+
+
+#### Braces
+
+The left brace is on the next line after the declaration. The right brace is
+directly below that. Everything in between in indented one level. If you're
+catching an error and you have a one-line, go ahead and to it on the same line.
+
+```C
+    while (blah)
+    {
+        //Like so. Even if only one line, we use braces.
+    }
+```
+
+
+#### Comments
+
+Do you know what we hate? Old-school C block comments. BUT, we're using them
+anyway. As we mentioned, our goal is to support every compiler we can,
+especially embedded compilers. There are STILL C compilers out there that only
+support old-school block comments. So that is what we're using. We apologize. We
+think they are ugly too.
+
+
+## Ruby Details
+
+Is there really such thing as a Ruby coding standard? Ruby is such a free form
+language, it seems almost sacrilegious to suggest that people should comply to
+one method! We'll keep it really brief!
+
+
+#### Whitespace
+
+Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
+nice power-of-2 number that really grooves with Ruby's compact style. We have no
+more reason than that. We break that rule when we have lines that wrap. When
+that happens, we like to indent further to line things up in nice tidy columns.
+
+
+#### Case
+
+- Files - all lower case with underscores.
+- Variables - all lower case with underscores
+- Classes, Modules, etc - Camel cased.
+- Functions - all lower case with underscores
+- Constants - all upper case with underscores
+
+
+## Documentation
+
+Egad. Really? We use markdown and we like pdf files because they can be made to
+look nice while still being portable. Good enough?
+
+
+*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

examples/make_example/Makefile

@@ -1,8 +1,8 @@
 CC ?= gcc
-BUILD_DIR ?= ./build
-SRC_DIR ?= ./src
-TEST_DIR ?= ./test
-TEST_BUILD_DIR ?= ${BUILD_DIR}/test
+export BUILD_DIR ?= ./build
+export SRC_DIR ?= ./src
+export TEST_DIR ?= ./test
+export TEST_BUILD_DIR ?= ${BUILD_DIR}/test
 TEST_MAKEFILE = ${TEST_BUILD_DIR}/MakefileTestSupport
 OBJ ?= ${BUILD_DIR}/obj
 OBJ_DIR = ${OBJ}

examples/make_example/src/foo.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "foo.h"
 
 void foo_init(void)

examples/make_example/src/foo.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _foo_h
 
 void foo_init(void);

examples/make_example/src/main.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include <stdio.h>
 #include "foo.h"
 

examples/make_example/test/test_foo.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "foo.h"
 
@@ -13,5 +20,5 @@ void test_foo_init_should_initialize_multiplier()
 {
     foo_init();
 
-    TEST_ASSERT_FALSE(1);
+    TEST_ASSERT_FALSE(0);
 }

examples/make_example/test/test_main.c

@@ -1,5 +1,12 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
-#include "mock_foo.h"
+#include "Mockfoo.h"
 
 void setUp(void)
 {

examples/temp_sensor/gcc.yml

@@ -1,43 +0,0 @@
-compiler:
-  path: gcc
-  source_path:     'src/'
-  unit_tests_path: &unit_tests_path 'test/'
-  build_path:      &build_path 'build/'
-  options:
-    - -c
-  includes:
-    prefix: '-I'
-    items:
-      - 'src/'
-      - '../src/'
-      - '../vendor/unity/src/'
-      - '../vendor/unity/examples/example_3/helper/'
-      - 'mocks/'
-      - *unit_tests_path
-  defines:
-    prefix: '-D'
-    items:
-      - __monitor
-  object_files:
-    prefix: '-o'
-    extension: '.o'
-    destination: *build_path
-linker:
-  path: gcc
-  options:
-    - -lm
-  includes:
-    prefix: '-I'
-  object_files:
-    path: *build_path
-    extension: '.o'
-  bin_files:
-    prefix: '-o'
-    extension: '.exe'
-    destination: *build_path
-:cmock:
-  :plugins: []
-  :includes:
-    - Types.h
-
-colour: true

examples/temp_sensor/iar_v4.yml

@@ -1,91 +0,0 @@
-tools_root: &tools_root 'C:\Program Files\IAR Systems\Embedded Workbench 4.0 Kickstart\'
-compiler:
-  path:             [*tools_root, 'arm\bin\iccarm.exe']
-  source_path:      'src\'
-  unit_tests_path:  &unit_tests_path 'test\'
-  build_path:       &build_path 'build\'
-  options:
-    - --dlib_config
-    - [*tools_root, 'arm\lib\dl4tptinl8n.h']
-    - -z3
-    - --no_cse
-    - --no_unroll
-    - --no_inline
-    - --no_code_motion
-    - --no_tbaa
-    - --no_clustering
-    - --no_scheduling
-    - --debug
-    - --cpu_mode thumb
-    - --endian little
-    - --cpu ARM7TDMI
-    - --stack_align 4
-    - --interwork
-    - -e
-    - --silent
-    - --warnings_are_errors
-    - --fpu None
-    - --diag_suppress Pa050
-  includes:
-    prefix: '-I'
-    items:
-      - 'src/'
-      - '../src/'
-      - '../vendor/unity/src/'
-      - '../vendor/unity/examples/example_3/helper/'
-      - 'mocks/'
-      - [*tools_root, 'arm\inc\']
-      - *unit_tests_path
-  defines:
-    prefix: '-D'
-    items:
-  object_files:
-    prefix: '-o'
-    extension: '.r79'
-    destination: *build_path
-linker:
-  path: [*tools_root, 'common\bin\xlink.exe']
-  options:
-    - -rt
-    - [*tools_root, 'arm\lib\dl4tptinl8n.r79']
-    - -D_L_EXTMEM_START=0
-    - -D_L_EXTMEM_SIZE=0
-    - -D_L_HEAP_SIZE=120
-    - -D_L_STACK_SIZE=32
-    - -e_small_write=_formatted_write
-    - -s
-    - __program_start
-    - -f
-    - [*tools_root, '\arm\config\lnkarm.xcl']
-  includes:
-    prefix: '-I'
-    items:
-      - [*tools_root, 'arm\config\']
-      - [*tools_root, 'arm\lib\']
-  object_files:
-    path: *build_path
-    extension: '.r79'
-  bin_files:
-    prefix: '-o'
-    extension: '.d79'
-    destination: *build_path
-simulator:
-  path: [*tools_root, 'common\bin\CSpyBat.exe']
-  pre_support:
-    - --silent
-    - [*tools_root, 'arm\bin\armproc.dll']
-    - [*tools_root, 'arm\bin\armsim.dll']
-  post_support:
-    - --plugin
-    - [*tools_root, 'arm\bin\armbat.dll']
-    - --backend
-    - -B
-    - -p
-    - [*tools_root, 'arm\config\ioat91sam7X256.ddf']
-    - -d
-    - sim
-:cmock:
-  :plugins: []
-  :includes:
-    - Types.h
-

examples/temp_sensor/iar_v5.yml

@@ -1,80 +0,0 @@
-tools_root: &tools_root 'C:\Program Files\IAR Systems\Embedded Workbench 5.3\'
-compiler:
-  path:             [*tools_root, 'arm\bin\iccarm.exe']
-  source_path:      'src\'
-  unit_tests_path:  &unit_tests_path 'test\'
-  build_path:       &build_path 'build\'
-  options:
-    - --dlib_config
-    - [*tools_root, 'arm\inc\DLib_Config_Normal.h']
-    - --no_cse
-    - --no_unroll
-    - --no_inline
-    - --no_code_motion
-    - --no_tbaa
-    - --no_clustering
-    - --no_scheduling
-    - --debug
-    - --cpu_mode thumb
-    - --endian=little
-    - --cpu=ARM7TDMI
-    - --interwork
-    - --warnings_are_errors
-    - --fpu=None
-    - --diag_suppress=Pa050
-    - --diag_suppress=Pe111
-    - -e
-    - -On
-  includes:
-    prefix: '-I'
-    items:
-      - 'src/'
-      - '../src/'
-      - '../vendor/unity/src/'
-      - '../vendor/unity/examples/example_3/helper/'
-      - 'mocks/'
-      - [*tools_root, 'arm\inc\']
-      - *unit_tests_path
-  defines:
-    prefix: '-D'
-    items:
-  object_files:
-    prefix: '-o'
-    extension: '.r79'
-    destination: *build_path
-linker:
-  path: [*tools_root, 'arm\bin\ilinkarm.exe']
-  options:
-    - --redirect _Printf=_PrintfLarge
-    - --redirect _Scanf=_ScanfSmall
-    - --semihosting
-    - --entry __iar_program_start
-    - --config
-    - [*tools_root, 'arm\config\generic.icf']
-  object_files:
-    path: *build_path
-    extension: '.o'
-  bin_files:
-    prefix: '-o'
-    extension: '.out'
-    destination: *build_path
-simulator:
-  path: [*tools_root, 'common\bin\CSpyBat.exe']
-  pre_support:
-    - --silent
-    - [*tools_root, 'arm\bin\armproc.dll']
-    - [*tools_root, 'arm\bin\armsim.dll']
-  post_support:
-    - --plugin
-    - [*tools_root, 'arm\bin\armbat.dll']
-    - --backend
-    - -B
-    - -p
-    - [*tools_root, 'arm\config\debugger\atmel\ioat91sam7X256.ddf']
-    - -d
-    - sim
-:cmock:
-  :plugins: []
-  :includes:
-    - Types.h
-

examples/temp_sensor/project.yml

@@ -0,0 +1,75 @@
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+:project:
+  :build_root: 'build/'
+  :colour: true
+
+:paths:
+  :source:
+    - 'src/'
+  :include:
+    - 'src/'
+    - '../../src/'
+    - '../../vendor/unity/src/'
+    - '../../vendor/unity/examples/example_3/helper/'
+    - 'build/mocks/'
+    - 'test/'
+  :test: 'test/'
+  :build: 'build/'
+  :mocks: 'build/mocks/'
+
+:extension:
+  :object: '.o'
+  :executable: '.exe'
+
+:defines:
+  :test:
+    - __monitor
+    - UNITY_SUPPORT_64
+
+:cmock:
+  # Core configuration
+  :plugins: []
+  :verbosity: 2
+  :when_no_prototypes: :warn
+
+  # File configuration
+  :mock_path: 'build/mocks'
+  :skeleton_path: ''
+  :mock_prefix: 'Mock'
+  :mock_suffix: ''
+
+  # Parser configuration
+  :strippables:
+    - '(?:__attribute__\s*\([ (]*.*?[ )]*\)+)'
+  :attributes:
+    - __ramfunc
+    - __irq
+    - __fiq
+    - register
+    - extern
+  :c_calling_conventions:
+    - __stdcall
+    - __cdecl
+    - __fastcall
+  :treat_externs: :exclude
+  :treat_inlines: :exclude
+
+  # Type handling configuration
+  :memcmp_if_unknown: true
+  :when_ptr: :compare_data
+
+  # Mock generation configuration
+  :weak: ''
+  :enforce_strict_ordering: false
+  :fail_on_unexpected_calls: true
+  :callback_include_count: true
+  :callback_after_arg_check: false
+  :includes:
+    - Types.h
+  :exclude_setjmp_h: false

examples/temp_sensor/rakefile.rb

@@ -1,4 +1,11 @@
-HERE = File.expand_path(File.dirname(__FILE__)) + '/'
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+HERE = "#{__dir__}//".freeze
 
 require 'rake'
 require 'rake/clean'
@@ -7,26 +14,36 @@ require './rakefile_helper'
 
 include RakefileHelpers
 
+REQUIRED_DIRS = ['./build', './build/mocks'].freeze
+REQUIRED_DIRS.each do |v|
+  directory v
+end
+
 # Load default configuration, for now
-DEFAULT_CONFIG_FILE = 'gcc.yml'
+DEFAULT_CONFIG_FILE = 'gcc_64.yml'.freeze
 configure_toolchain(DEFAULT_CONFIG_FILE)
 
 task :unit do
-  run_tests(get_unit_test_files)
+  run_tests(unit_test_files)
 end
 
-desc "Generate test summary"
+desc 'Generate test summary'
 task :summary do
   report_summary
 end
 
-desc "Build and test Unity"
-task :all => [:clean, :unit, :summary]
-task :default => [:clobber, :all]
+desc 'Build and test Unity'
+task :all => %i[clean unit summary]
+task :default => REQUIRED_DIRS + %i[clobber all]
 task :ci => [:default]
 task :cruise => [:default]
 
-desc "Load configuration"
-task :config, :config_file do |t, args|
-  configure_toolchain(args[:config_file])
+desc 'Load configuration'
+task :config, [:config_file, :cmock_overlay] do |_t, args|
+  configure_toolchain(args[:config_file], args[:cmock_overlay])
+end
+
+desc 'Return error on Failures'
+task :strict do
+  $return_error_on_failures = true
 end

examples/temp_sensor/rakefile_helper.rb

@@ -1,270 +1,324 @@
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 require 'yaml'
 require 'fileutils'
-require '../vendor/unity/auto/unity_test_summary'
-require '../vendor/unity/auto/generate_test_runner'
-require '../vendor/unity/auto/colour_reporter'
+require '../../vendor/unity/auto/unity_test_summary'
+require '../../vendor/unity/auto/generate_test_runner'
+require '../../vendor/unity/auto/colour_reporter'
 
 module RakefileHelpers
+  $return_error_on_failures = false
 
-  C_EXTENSION = '.c'
+  C_EXTENSION = '.c'.freeze
 
-  def load_configuration(config_file)
+  def load_yaml(yaml_string)
+    YAML.load(yaml_string, aliases: true)
+  rescue ArgumentError
+    YAML.load(yaml_string)
+  end
+
+  def find_cmock_target(targets_dir, config_file)
+    return config_file if File.exist?("#{targets_dir}/#{config_file}")
+
+    basename = File.basename(config_file, '.yml')
+    while basename.include?('_')
+      basename = basename.rpartition('_').first
+      candidate = "#{basename}.yml"
+      return candidate if File.exist?("#{targets_dir}/#{candidate}")
+    end
+
+    nil
+  end
+
+  def load_configuration(config_file, cmock_overlay = nil)
     $cfg_file = config_file
-    $cfg = YAML.load(File.read($cfg_file))
-    $colour_output = false unless $cfg['colour']
+    $proj = load_yaml(File.read('./project.yml'))
+
+    unity_targets_dir = '../../vendor/unity/test/targets'
+    cmock_targets_dir = '../../test/targets'
+    config_basename   = File.basename(config_file)
+    path_specified    = File.dirname(config_file) != '.'
+
+    # Resolve the target file location:
+    #   - path specified → use only that location
+    #   - no path → check current directory first, then vendor unity targets
+    unity_target = if path_specified
+                     config_file
+                   elsif File.exist?("./#{config_file}")
+                     "./#{config_file}"
+                   else
+                     "#{unity_targets_dir}/#{config_file}"
+                   end
+
+    if File.exist?(unity_target)
+      puts "Loading Unity target:  #{unity_target}"
+      $unity_cfg = load_yaml(File.read(unity_target))
+
+      cmock_file = cmock_overlay || find_cmock_target(cmock_targets_dir, config_basename)
+      if cmock_file
+        puts "Loading CMock overlay: #{cmock_targets_dir}/#{cmock_file}"
+        $cmock_cfg = load_yaml(File.read("#{cmock_targets_dir}/#{cmock_file}"))
+      else
+        puts "No CMock overlay found for #{config_file}"
+        $cmock_cfg = {}
+      end
+    else
+      # CMock-only target (no Unity equivalent); it uses Unity format directly
+      puts "Loading CMock-only target: #{cmock_targets_dir}/#{config_basename}"
+      $unity_cfg = load_yaml(File.read("#{cmock_targets_dir}/#{config_basename}"))
+      $cmock_cfg = {}
+    end
+
+    $colour_output = $proj[:project][:colour]
   end
 
   def configure_clean
-    CLEAN.include($cfg['compiler']['build_path'] + '*.*') unless $cfg['compiler']['build_path'].nil?
+    CLEAN.include("#{$proj[:project][:build_root]}*.*")
   end
 
-  def configure_toolchain(config_file=DEFAULT_CONFIG_FILE)
-    config_file += '.yml' unless config_file =~ /\.yml$/
-    load_configuration(config_file)
+  def configure_toolchain(config_file = DEFAULT_CONFIG_FILE, cmock_overlay = nil)
+    config_file ||= DEFAULT_CONFIG_FILE
+    config_file += '.yml' unless config_file =~ /\.yml$/i
+    cmock_overlay += '.yml' if cmock_overlay && cmock_overlay !~ /\.yml$/i
+    load_configuration(config_file, cmock_overlay)
     configure_clean
   end
 
-  def get_unit_test_files
-    path = $cfg['compiler']['unit_tests_path'] + 'Test*' + C_EXTENSION
-    path.gsub!(/\\/, '/')
+  def unit_test_files
+    path = $proj[:paths][:test] + "Test*#{C_EXTENSION}"
+    path.tr!('\\', '/')
     FileList.new(path)
   end
 
-  def get_local_include_dirs
-    include_dirs = $cfg['compiler']['includes']['items'].dup
-    include_dirs.delete_if {|dir| dir.is_a?(Array)}
-    return include_dirs
+  def local_include_dirs
+    $proj[:paths][:include].reject { |dir| dir.is_a?(Array) }
   end
 
   def extract_headers(filename)
     includes = []
     lines = File.readlines(filename)
     lines.each do |line|
-      m = line.match(/^\s*#include\s+\"\s*(.+\.[hH])\s*\"/)
-      if not m.nil?
-        includes << m[1]
-      end
+      m = line.match(/^\s*#include\s+"\s*(.+\.[hH])\s*"/)
+      includes << m[1] unless m.nil?
     end
-    return includes
+    includes
   end
 
   def find_source_file(header, paths)
     paths.each do |dir|
       src_file = dir + header.ext(C_EXTENSION)
-      if (File.exists?(src_file))
-        return src_file
-      end
+      return src_file if File.exist?(src_file)
     end
-    return nil
+    nil
   end
 
   def tackit(strings)
-    case(strings)
-      when Array
-        "\"#{strings.join}\""
-      when /^-/
-        strings
-      when /\s/
-        "\"#{strings}\""
+    case strings
+    when Array
+      "\"#{strings.join}\""
+    when /^-/
+      strings
+    when /\s/
+      "\"#{strings}\""
+    else
+      strings
+    end
+  end
+
+  # All defines: project common + Unity target + CMock overlay + any extras
+  def all_defines(extra = [])
+    (($proj[:defines][:test] || []) +
+     ($unity_cfg[:defines][:test] || []) +
+     (($cmock_cfg[:defines] || {})[:test] || []) +
+     extra).uniq
+  end
+
+  # Toolchain-specific include paths: Array items in Unity's :paths: :test:
+  def toolchain_include_paths
+    if $unity_cfg[:paths] && $unity_cfg[:paths][:test]
+      $unity_cfg[:paths][:test]
+    else
+      []
+    end
+  end
+
+  # Resolve argument template tokens into a flat argument string.
+  # Supports Ceedling-style positional tokens and legacy Unity COLLECTION_* tokens.
+  #   ${5}  → expands to one arg per include path (toolchain paths + project paths combined)
+  #   ${6}  → expands to one arg per define
+  #   ${1}  → input file(s)
+  #   ${2}  → output file
+  def build_argument_list(raw_args, toolchain_paths, project_paths, defines, input, output)
+    result = []
+    raw_args.each do |arg|
+      if arg.is_a?(Array)
+        result << arg.join
+      elsif arg.include?('${5}')
+        (toolchain_paths + project_paths).each do |p|
+          result << arg.gsub('${5}', p.is_a?(Array) ? p.join : p.to_s)
+        end
+      elsif arg.include?('${6}')
+        defines.each { |d| result << arg.gsub('${6}', d) }
+      elsif arg.include?('COLLECTION_PATHS_TEST_TOOLCHAIN_INCLUDE')
+        toolchain_paths.each { |p| result << "-I\"#{p.is_a?(Array) ? p.join : p}\"" }
+      elsif arg.include?('COLLECTION_PATHS_TEST_SUPPORT_SOURCE_INCLUDE_VENDOR')
+        project_paths.each { |p| result << "-I\"#{p}\"" }
+      elsif arg.include?('COLLECTION_DEFINES_TEST_AND_VENDOR')
+        defines.each { |d| result << "-D#{d}" }
       else
-        strings
+        result << arg.gsub('${1}', input.to_s).gsub('${2}', output.to_s)
+      end
     end
+    result.join(' ')
   end
 
-  def squash(prefix, items)
-    result = ''
-    items.each { |item| result += " #{prefix}#{tackit(item)}" }
-    return result
-  end
+  def compile(file, extra_defines = [])
+    tool       = $unity_cfg[:tools][:test_compiler]
+    ext        = $unity_cfg[:extension][:object] || '.o'
+    build_root = $proj[:project][:build_root] || 'build/'
+    obj_file   = build_root + File.basename(file, C_EXTENSION) + ext
 
-  def build_compiler_fields
-    command  = tackit($cfg['compiler']['path'])
-    if $cfg['compiler']['defines']['items'].nil?
-      defines  = ''
-    else
-      defines  = squash($cfg['compiler']['defines']['prefix'], $cfg['compiler']['defines']['items'])
-    end
-    options  = squash('', $cfg['compiler']['options'])
-    includes = squash($cfg['compiler']['includes']['prefix'], $cfg['compiler']['includes']['items'])
-    includes = includes.gsub(/\\ /, ' ').gsub(/\\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
-    return {:command => command, :defines => defines, :options => options, :includes => includes}
-  end
-
-  def compile(file, defines=[])
-    compiler = build_compiler_fields
-    cmd_str  = "#{compiler[:command]}#{compiler[:defines]}#{compiler[:options]}#{compiler[:includes]} #{file} " +
-               "#{$cfg['compiler']['object_files']['prefix']}#{$cfg['compiler']['object_files']['destination']}"
-    obj_file = "#{File.basename(file, C_EXTENSION)}#{$cfg['compiler']['object_files']['extension']}"
-    execute(cmd_str + obj_file)
-    return obj_file
-  end
-
-  def build_linker_fields
-    command  = tackit($cfg['linker']['path'])
-    if $cfg['linker']['options'].nil?
-      options  = ''
-    else
-      options  = squash('', $cfg['linker']['options'])
-    end
-    if ($cfg['linker']['includes'].nil? || $cfg['linker']['includes']['items'].nil?)
-      includes = ''
-    else
-      includes = squash($cfg['linker']['includes']['prefix'], $cfg['linker']['includes']['items'])
-    end
-    includes = includes.gsub(/\\ /, ' ').gsub(/\\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
-    return {:command => command, :options => options, :includes => includes}
+    cmd_str = "#{tackit(tool[:executable])} #{
+              build_argument_list(tool[:arguments],
+                                  toolchain_include_paths,
+                                  $proj[:paths][:include],
+                                  all_defines(extra_defines),
+                                  file, obj_file)}"
+    execute(cmd_str)
+    File.basename(obj_file)
   end
 
   def link_it(exe_name, obj_list)
-    linker = build_linker_fields
-    cmd_str = "#{linker[:command]}#{linker[:includes]} " +
-      (obj_list.map{|obj|"#{$cfg['linker']['object_files']['path']}#{obj} "}).join +
-      $cfg['linker']['bin_files']['prefix'] + ' ' +
-      $cfg['linker']['bin_files']['destination'] +
-      exe_name + $cfg['linker']['bin_files']['extension'] + " #{linker[:options]}"
+    tool       = $unity_cfg[:tools][:test_linker]
+    ext        = $unity_cfg[:extension][:executable] || ''
+    build_root = $proj[:project][:build_root] || 'build/'
+
+    input_files = obj_list.uniq.map { |obj| build_root + obj }.join(' ')
+    output_file = build_root + exe_name + ext
+
+    cmd_str = "#{tackit(tool[:executable])} #{build_argument_list(tool[:arguments], [], [], [], input_files, output_file)}"
     execute(cmd_str)
   end
 
   def build_simulator_fields
-    return nil if $cfg['simulator'].nil?
-    if $cfg['simulator']['path'].nil?
-      command = ''
+    return nil unless $unity_cfg[:tools][:test_fixture]
+
+    tool       = $unity_cfg[:tools][:test_fixture]
+    executable = tackit(tool[:executable])
+    raw_args   = tool[:arguments] || []
+    idx        = raw_args.index('${1}')
+    if idx
+      pre  = raw_args[0...idx].map { |a| a.is_a?(Array) ? a.join : a }.join(' ')
+      post = raw_args[(idx + 1)..].map { |a| a.is_a?(Array) ? a.join : a }.join(' ')
     else
-      command = (tackit($cfg['simulator']['path']) + ' ')
+      pre  = ''
+      post = raw_args.map { |a| a.is_a?(Array) ? a.join : a }.join(' ')
     end
-    if $cfg['simulator']['pre_support'].nil?
-      pre_support = ''
-    else
-      pre_support = squash('', $cfg['simulator']['pre_support'])
-    end
-    if $cfg['simulator']['post_support'].nil?
-      post_support = ''
-    else
-      post_support = squash('', $cfg['simulator']['post_support'])
-    end
-    return {:command => command, :pre_support => pre_support, :post_support => post_support}
+    { command: "#{executable} ", pre_support: pre, post_support: post }
   end
 
-  def execute(command_string, verbose=true)
+  def execute(command_string, verbose = true, ok_to_fail = false)
     report command_string
     output = `#{command_string}`.chomp
-    report(output) if (verbose && !output.nil? && (output.length > 0))
-    if $?.exitstatus != 0
+    report(output) if verbose && !output.nil? && !output.empty?
+    unless (!$?.nil? && $?.exitstatus.zero?) || ok_to_fail
       raise "Command failed. (Returned #{$?.exitstatus})"
     end
-    return output
+
+    output
   end
 
   def report_summary
     summary = UnityTestSummary.new
-    summary.set_root_path(HERE)
-    results_glob = "#{$cfg['compiler']['build_path']}*.test*"
-    results_glob.gsub!(/\\/, '/')
+    summary.root = HERE
+    results_glob = "#{$proj[:project][:build_root]}*.test*"
+    results_glob.tr!('\\', '/')
     results = Dir[results_glob]
-    summary.set_targets(results)
+    summary.targets = results
     report summary.run
-    raise "There were failures" if (summary.failures > 0)
+    raise 'There were failures' if (summary.failures > 0) && $return_error_on_failures
   end
 
   def run_tests(test_files)
-
     report 'Running system tests...'
 
-    # Tack on TEST define for compiling unit tests
     load_configuration($cfg_file)
-    test_defines = ['TEST']
-    $cfg['compiler']['defines']['items'] = [] if $cfg['compiler']['defines']['items'].nil?
-    $cfg['compiler']['defines']['items'] << 'TEST'
 
-    include_dirs = get_local_include_dirs
+    include_dirs = local_include_dirs
 
     # Build and execute each unit test
     test_files.each do |test|
+      # Detect dependencies and build required modules
+      header_list = (extract_headers(test) + ['cmock.h'] + [($proj[:cmock] || {})[:unity_helper_path]]).compact.uniq
+      header_list.each do |header|
+        # create mocks if needed
+        next unless header =~ /Mock/
+
+        require '../../lib/cmock'
+        @cmock ||= CMock.new($proj[:cmock])
+        @cmock.setup_mocks([$proj[:paths][:source].first + header.gsub('Mock', '')])
+      end
+
+      # compile all mocks and dependencies
       obj_list = []
-
-      # Detect dependencies and build required required modules
-      header_list = extract_headers(test) + ['cmock.h']
       header_list.each do |header|
-
-        #create mocks if needed
-        if (header =~ /Mock/)
-          require "../lib/cmock.rb"
-          @cmock ||= CMock.new($cfg_file)
-          @cmock.setup_mocks([$cfg['compiler']['source_path']+header.gsub('Mock','')])
-        end
-
-      end
-
-      #compile all mocks
-      header_list.each do |header|
-        #compile source file header if it exists
         src_file = find_source_file(header, include_dirs)
-        if !src_file.nil?
-          obj_list << compile(src_file, test_defines)
-        end
+        obj_list << compile(src_file, ['TEST']) unless src_file.nil?
       end
 
-      # Build the test runner (generate if configured to do so)
-      test_base = File.basename(test, C_EXTENSION)
-      runner_name = test_base + '_Runner.c'
-      if $cfg['compiler']['runner_path'].nil?
-        runner_path = $cfg['compiler']['build_path'] + runner_name
-        test_gen = UnityTestRunnerGenerator.new($cfg_file)
-        test_gen.run(test, runner_path)
-      else
-        runner_path = $cfg['compiler']['runner_path'] + runner_name
-      end
+      # Build the test runner
+      test_base   = File.basename(test, C_EXTENSION)
+      runner_name = "#{test_base}_Runner.c"
+      runner_path = "#{$proj[:project][:build_root]}#{runner_name}"
+      UnityTestRunnerGenerator.new({}).run(test, runner_path)
 
-      obj_list << compile(runner_path, test_defines)
+      obj_list << compile(runner_path, ['TEST'])
 
       # Build the test module
-      obj_list << compile(test, test_defines)
+      obj_list << compile(test, ['TEST'])
 
       # Link the test executable
       link_it(test_base, obj_list)
 
       # Execute unit test and generate results file
-      simulator = build_simulator_fields
-      executable = $cfg['linker']['bin_files']['destination'] + test_base + $cfg['linker']['bin_files']['extension']
-      if simulator.nil?
-        cmd_str = executable
-      else
-        cmd_str = "#{simulator[:command]} #{simulator[:pre_support]} #{executable} #{simulator[:post_support]}"
-      end
-      output = execute(cmd_str)
-      test_results = $cfg['compiler']['build_path'] + test_base
-      if output.match(/OK$/m).nil?
-        test_results += '.testfail'
-      else
-        test_results += '.testpass'
-      end
+      simulator  = build_simulator_fields
+      build_root = $proj[:project][:build_root]
+      executable = build_root + test_base + ($unity_cfg[:extension][:executable] || '')
+      cmd_str = if simulator.nil?
+                  executable
+                else
+                  "#{simulator[:command]} #{simulator[:pre_support]} #{executable} #{simulator[:post_support]}"
+                end
+      output = execute(cmd_str, true)
+      test_results = build_root + test_base
+      test_results += output.match(/OK$/m).nil? ? '.testfail' : '.testpass'
       File.open(test_results, 'w') { |f| f.print output }
     end
   end
 
   def build_application(main)
-
-    report "Building application..."
+    report 'Building application...'
 
     obj_list = []
     load_configuration($cfg_file)
-    main_path = $cfg['compiler']['source_path'] + main + C_EXTENSION
+    main_path = $proj[:paths][:source].first + main + C_EXTENSION
 
-    # Detect dependencies and build required required modules
-    include_dirs = get_local_include_dirs
+    # Detect dependencies and build required modules
+    include_dirs = local_include_dirs
     extract_headers(main_path).each do |header|
       src_file = find_source_file(header, include_dirs)
-      if !src_file.nil?
-        obj_list << compile(src_file)
-      end
+      obj_list << compile(src_file) unless src_file.nil?
     end
 
     # Build the main source file
-    main_base = File.basename(main_path, C_EXTENSION)
     obj_list << compile(main_path)
 
     # Create the executable
-    link_it(main_base, obj_list)
+    link_it(File.basename(main_path, C_EXTENSION), obj_list)
   end
-
 end

examples/temp_sensor/src/AT91SAM7X256.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 //  ----------------------------------------------------------------------------
 //          ATMEL Microcontroller Software Support  -  ROUSSET  -
 //  ----------------------------------------------------------------------------
@@ -45,15 +52,16 @@
 #define AT91SAM7X256_H
 
 typedef volatile unsigned int AT91_REG;// Hardware register definition
+typedef volatile void*        AT91_PTR;// Hardware register pointer
 
 // *****************************************************************************
 //              SOFTWARE API DEFINITION  FOR System Peripherals
 // *****************************************************************************
 typedef struct _AT91S_SYS {
     AT91_REG     AIC_SMR[32];     // Source Mode Register
-    AT91_REG     AIC_SVR[32];     // Source Vector Register
-    AT91_REG     AIC_IVR;     // IRQ Vector Register
-    AT91_REG     AIC_FVR;     // FIQ Vector Register
+    AT91_PTR     AIC_SVR[32];     // Source Vector Register
+    AT91_PTR     AIC_IVR;     // IRQ Vector Register
+    AT91_PTR     AIC_FVR;     // FIQ Vector Register
     AT91_REG     AIC_ISR;     // Interrupt Status Register
     AT91_REG     AIC_IPR;     // Interrupt Pending Register
     AT91_REG     AIC_IMR;     // Interrupt Mask Register
@@ -64,7 +72,7 @@ typedef struct _AT91S_SYS {
     AT91_REG     AIC_ICCR;     // Interrupt Clear Command Register
     AT91_REG     AIC_ISCR;     // Interrupt Set Command Register
     AT91_REG     AIC_EOICR;     // End of Interrupt Command Register
-    AT91_REG     AIC_SPU;     // Spurious Vector Register
+    AT91_PTR     AIC_SPU;     // Spurious Vector Register
     AT91_REG     AIC_DCR;     // Debug Control Register (Protect)
     AT91_REG     Reserved1[1];     // 
     AT91_REG     AIC_FFER;     // Fast Forcing Enable Register
@@ -214,9 +222,9 @@ typedef struct _AT91S_SYS {
 // *****************************************************************************
 typedef struct _AT91S_AIC {
     AT91_REG     AIC_SMR[32];     // Source Mode Register
-    AT91_REG     AIC_SVR[32];     // Source Vector Register
-    AT91_REG     AIC_IVR;     // IRQ Vector Register
-    AT91_REG     AIC_FVR;     // FIQ Vector Register
+    AT91_PTR     AIC_SVR[32];     // Source Vector Register
+    AT91_PTR     AIC_IVR;     // IRQ Vector Register
+    AT91_PTR     AIC_FVR;     // FIQ Vector Register
     AT91_REG     AIC_ISR;     // Interrupt Status Register
     AT91_REG     AIC_IPR;     // Interrupt Pending Register
     AT91_REG     AIC_IMR;     // Interrupt Mask Register
@@ -227,7 +235,7 @@ typedef struct _AT91S_AIC {
     AT91_REG     AIC_ICCR;     // Interrupt Clear Command Register
     AT91_REG     AIC_ISCR;     // Interrupt Set Command Register
     AT91_REG     AIC_EOICR;     // End of Interrupt Command Register
-    AT91_REG     AIC_SPU;     // Spurious Vector Register
+    AT91_PTR     AIC_SPU;     // Spurious Vector Register
     AT91_REG     AIC_DCR;     // Debug Control Register (Protect)
     AT91_REG     Reserved1[1];     // 
     AT91_REG     AIC_FFER;     // Fast Forcing Enable Register
@@ -1727,14 +1735,14 @@ typedef struct _AT91S_ADC {
 #define AT91C_AIC_EOICR ((AT91_REG *)     0xFFFFF130) // (AIC) End of Interrupt Command Register
 #define AT91C_AIC_DCR   ((AT91_REG *)     0xFFFFF138) // (AIC) Debug Control Register (Protect)
 #define AT91C_AIC_FFER  ((AT91_REG *)     0xFFFFF140) // (AIC) Fast Forcing Enable Register
-#define AT91C_AIC_SVR   ((AT91_REG *)     0xFFFFF080) // (AIC) Source Vector Register
-#define AT91C_AIC_SPU   ((AT91_REG *)     0xFFFFF134) // (AIC) Spurious Vector Register
+#define AT91C_AIC_SVR   ((AT91_PTR *)     0xFFFFF080) // (AIC) Source Vector Register
+#define AT91C_AIC_SPU   ((AT91_PTR *)     0xFFFFF134) // (AIC) Spurious Vector Register
 #define AT91C_AIC_FFDR  ((AT91_REG *)     0xFFFFF144) // (AIC) Fast Forcing Disable Register
-#define AT91C_AIC_FVR   ((AT91_REG *)     0xFFFFF104) // (AIC) FIQ Vector Register
+#define AT91C_AIC_FVR   ((AT91_PTR *)     0xFFFFF104) // (AIC) FIQ Vector Register
 #define AT91C_AIC_FFSR  ((AT91_REG *)     0xFFFFF148) // (AIC) Fast Forcing Status Register
 #define AT91C_AIC_IMR   ((AT91_REG *)     0xFFFFF110) // (AIC) Interrupt Mask Register
 #define AT91C_AIC_ISR   ((AT91_REG *)     0xFFFFF108) // (AIC) Interrupt Status Register
-#define AT91C_AIC_IVR   ((AT91_REG *)     0xFFFFF100) // (AIC) IRQ Vector Register
+#define AT91C_AIC_IVR   ((AT91_PTR *)     0xFFFFF100) // (AIC) IRQ Vector Register
 #define AT91C_AIC_IDCR  ((AT91_REG *)     0xFFFFF124) // (AIC) Interrupt Disable Command Register
 #define AT91C_AIC_CISR  ((AT91_REG *)     0xFFFFF114) // (AIC) Core Interrupt Status Register
 #define AT91C_AIC_IPR   ((AT91_REG *)     0xFFFFF10C) // (AIC) Interrupt Pending Register

examples/temp_sensor/src/AdcConductor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "AdcConductor.h"
 #include "AdcModel.h"

examples/temp_sensor/src/AdcConductor.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _ADCCONDUCTOR_H
 #define _ADCCONDUCTOR_H
 

examples/temp_sensor/src/AdcHardware.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "AdcHardware.h"
 #include "AdcHardwareConfigurator.h"

examples/temp_sensor/src/AdcHardware.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _ADCHARDWARE_H
 #define _ADCHARDWARE_H
 

examples/temp_sensor/src/AdcHardwareConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "AdcHardwareConfigurator.h"
 #include "ModelConfig.h"

examples/temp_sensor/src/AdcHardwareConfigurator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _ADCHARDWARECONFIGURATOR_H
 #define _ADCHARDWARECONFIGURATOR_H
 

examples/temp_sensor/src/AdcModel.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "AdcModel.h"
 #include "TaskScheduler.h"
 #include "TemperatureCalculator.h"

examples/temp_sensor/src/AdcModel.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _ADCMODEL_H
 #define _ADCMODEL_H
 

examples/temp_sensor/src/AdcTemperatureSensor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "AdcTemperatureSensor.h"
 

examples/temp_sensor/src/AdcTemperatureSensor.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _ADCTEMPERATURESENSOR_H
 #define _ADCTEMPERATURESENSOR_H
 

examples/temp_sensor/src/Executor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "Executor.h"
 #include "Model.h"

examples/temp_sensor/src/Executor.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _EXECUTOR_H
 #define _EXECUTOR_H
 

examples/temp_sensor/src/IntrinsicsWrapper.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "IntrinsicsWrapper.h"
 #ifdef __ICCARM__
 #include <intrinsics.h>

examples/temp_sensor/src/IntrinsicsWrapper.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _INTRINSICS_WRAPPER_H
 #define _INTRINSICS_WRAPPER_H
 

examples/temp_sensor/src/Main.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 
 #include "IntrinsicsWrapper.h"

examples/temp_sensor/src/Main.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _MAIN_H_
 #define _MAIN_H_
 

examples/temp_sensor/src/Model.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Model.h"
 #include "TaskScheduler.h"
 #include "TemperatureFilter.h"

examples/temp_sensor/src/Model.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _MODEL_H
 #define _MODEL_H
 

examples/temp_sensor/src/ModelConfig.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _MODELCONFIG_H
 #define _MODELCONFIG_H
 

examples/temp_sensor/src/TaskScheduler.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TaskScheduler.h"
 

examples/temp_sensor/src/TaskScheduler.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TASKSCHEDULER_H
 #define _TASKSCHEDULER_H
 

examples/temp_sensor/src/TemperatureCalculator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TemperatureCalculator.h"
 #include <math.h>

examples/temp_sensor/src/TemperatureCalculator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TEMPERATURECALCULATOR_H
 #define _TEMPERATURECALCULATOR_H
 

examples/temp_sensor/src/TemperatureFilter.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TemperatureFilter.h"
 #include <math.h>
@@ -27,13 +34,16 @@ void TemperatureFilter_ProcessInput(float temperature)
   {
     if (temperature == +INFINITY ||
         temperature == -INFINITY ||
-        temperature == +NAN ||
-        temperature == -NAN)
+        temperature != temperature)
     {
+      /* Check if +/- Infinity or NaN... reset to -Inf in this instance. */
       initialized = FALSE;
-      temperature = -INFINITY;
+      temperatureInCelcius = -INFINITY;
+    }
+    else
+    {
+      /* Otherwise apply our low-pass filter to smooth the values */
+      temperatureInCelcius = (temperatureInCelcius * 0.75f) + (temperature * 0.25);
     }
-    
-    temperatureInCelcius = (temperatureInCelcius * 0.75f) + (temperature * 0.25);
   }
 }

examples/temp_sensor/src/TemperatureFilter.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TEMPERATUREFILTER_H
 #define _TEMPERATUREFILTER_H
 

examples/temp_sensor/src/TimerConductor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerConductor.h"
 #include "TimerModel.h"

examples/temp_sensor/src/TimerConductor.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERCONDUCTOR_H
 #define _TIMERCONDUCTOR_H
 

examples/temp_sensor/src/TimerConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerConfigurator.h"
 #include "TimerInterruptConfigurator.h"

examples/temp_sensor/src/TimerConfigurator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERCONFIGURATOR_H
 #define _TIMERCONFIGURATOR_H
 

examples/temp_sensor/src/TimerHardware.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerHardware.h"
 #include "TimerConfigurator.h"

examples/temp_sensor/src/TimerHardware.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERHARDWARE_H
 #define _TIMERHARDWARE_H
 

examples/temp_sensor/src/TimerInterruptConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerInterruptConfigurator.h"
 #include "TimerInterruptHandler.h"
@@ -36,7 +43,7 @@ void Timer_EnableInterrupt(void)
 
 static inline void SetInterruptHandler(void)
 {
-  AT91C_BASE_AIC->AIC_SVR[AT91C_ID_TC0] = (uint32)Timer_InterruptHandler;
+  AT91C_BASE_AIC->AIC_SVR[AT91C_ID_TC0] = Timer_InterruptHandler;
 }
 
 static inline void ConfigureInterruptSourceModeRegister(void)

examples/temp_sensor/src/TimerInterruptConfigurator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERINTERRUPTCONFIGURATOR_H
 #define _TIMERINTERRUPTCONFIGURATOR_H
 

examples/temp_sensor/src/TimerInterruptHandler.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerInterruptHandler.h"
 #include "TimerInterruptConfigurator.h"

examples/temp_sensor/src/TimerInterruptHandler.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERINTERRUPTHANDLER_H
 #define _TIMERINTERRUPTHANDLER_H
 

examples/temp_sensor/src/TimerModel.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "TimerModel.h"
 #include "TaskScheduler.h"

examples/temp_sensor/src/TimerModel.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TIMERMODEL_H
 #define _TIMERMODEL_H
 

examples/temp_sensor/src/Types.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _MYTYPES_H_
 #define _MYTYPES_H_
 

examples/temp_sensor/src/UsartBaudRateRegisterCalculator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartBaudRateRegisterCalculator.h"
 

examples/temp_sensor/src/UsartBaudRateRegisterCalculator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTBAUDRATEREGISTERCALCULATOR_H
 #define _USARTBAUDRATEREGISTERCALCULATOR_H
 

examples/temp_sensor/src/UsartConductor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartConductor.h"
 #include "UsartHardware.h"

examples/temp_sensor/src/UsartConductor.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTCONDUCTOR_H
 #define _USARTCONDUCTOR_H
 

examples/temp_sensor/src/UsartConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartConfigurator.h"
 

examples/temp_sensor/src/UsartConfigurator.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTCONFIGURATOR_H
 #define _USARTCONFIGURATOR_H
 

examples/temp_sensor/src/UsartHardware.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartHardware.h"
 #include "UsartConfigurator.h"

examples/temp_sensor/src/UsartHardware.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTHARDWARE_H
 #define _USARTHARDWARE_H
 

examples/temp_sensor/src/UsartModel.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartModel.h"
 #include "ModelConfig.h"

examples/temp_sensor/src/UsartModel.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTMODEL_H
 #define _USARTMODEL_H
 

examples/temp_sensor/src/UsartPutChar.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartPutChar.h"
 #include "UsartTransmitBufferStatus.h"

examples/temp_sensor/src/UsartPutChar.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTPUT_HAR_H
 #define _USARTPUT_HAR_H
 

examples/temp_sensor/src/UsartTransmitBufferStatus.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "Types.h"
 #include "UsartTransmitBufferStatus.h"
 

examples/temp_sensor/src/UsartTransmitBufferStatus.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _USARTTRANSMITBUFFERSTATUS_H
 #define _USARTTRANSMITBUFFERSTATUS_H
 

examples/temp_sensor/test/TestAdcConductor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "UnityHelper.h"
 #include "Types.h"

examples/temp_sensor/test/TestAdcHardware.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "AdcHardware.h"

examples/temp_sensor/test/TestAdcHardwareConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "AdcHardwareConfigurator.h"

examples/temp_sensor/test/TestAdcModel.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "AdcModel.h"

examples/temp_sensor/test/TestAdcTemperatureSensor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "AdcTemperatureSensor.h"

examples/temp_sensor/test/TestExecutor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "Executor.h"

examples/temp_sensor/test/TestMain.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "MockExecutor.h"

examples/temp_sensor/test/TestModel.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "Model.h"

examples/temp_sensor/test/TestTaskScheduler.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TaskScheduler.h"

examples/temp_sensor/test/TestTemperatureCalculator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TemperatureCalculator.h"

examples/temp_sensor/test/TestTemperatureFilter.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TemperatureFilter.h"

examples/temp_sensor/test/TestTimerConductor.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TimerConductor.h"

examples/temp_sensor/test/TestTimerConfigurator.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TimerConfigurator.h"

examples/temp_sensor/test/TestTimerHardware.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    CMock - Automatic Mock Generation for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "Types.h"
 #include "TimerHardware.h"