ceedling 0.0.3 → 0.0.4

data/new_project_template/vendor/ceedling/rakefile.rb

@@ -1,59 +0,0 @@
-require File.expand_path(File.dirname(__FILE__)) + '/config/test_environment'
-require 'rake'
-require 'rake/clean'
-require 'rake/testtask'
-require 'rakefile_helper'
-
-TEST_FILE_SUFFIX  = '_test.rb'
-TEST_FILE_PATTERN = "*#{TEST_FILE_SUFFIX}"
-
-include RakefileHelpers
-
-
-
-task :default => ['test:all']
-task :cruise  => [:default]
-
-
-unit_test_pattern           = "test/unit/#{TEST_FILE_PATTERN}"
-integrations_test_pattern   = "test/integration/#{TEST_FILE_PATTERN}"
-system_test_pattern         = "test/system/#{TEST_FILE_PATTERN}"
-
-ALL_UNIT_TESTS          = FileList[unit_test_pattern]
-ALL_INTEGRATION_TESTS   = FileList[integrations_test_pattern]
-ALL_SYSTEM_TESTS        = FileList[system_test_pattern]
-
-
-namespace :test do
-  desc "Run all unit, integration, and system tests"
-  task :all => ['test:unit:all']
-
-  Rake::TestTask.new('unit:all') do |t|
-    t.pattern = unit_test_pattern
-    t.verbose = true
-  end
-
-  namespace :unit do
-    create_test_tasks(ALL_UNIT_TESTS)
-  end
-
-  Rake::TestTask.new('integration:all') do |t|
-    t.pattern = integrations_test_pattern
-    t.verbose = true
-  end
-
-  namespace :integration do
-    create_test_tasks(ALL_INTEGRATION_TESTS)
-  end
-
-  Rake::TestTask.new('system:all') do |t|
-    t.pattern = system_test_pattern
-    t.verbose = true
-  end
-
-  namespace :system do
-    create_test_tasks(ALL_SYSTEM_TESTS)
-  end
-
-end
-

data/new_project_template/vendor/ceedling/rakefile_helper.rb

@@ -1,23 +0,0 @@
-require 'yaml'
-require 'fileutils'
-
-module RakefileHelpers
-  
-  def report(message)
-    puts message
-    $stdout.flush
-    $stderr.flush
-  end
-
-  def create_test_tasks(test_list)
-    test_list.each do |test|
-      base_file = File.basename(test).gsub(/#{Regexp.escape(TEST_FILE_SUFFIX)}/, '')
-      desc base_file
-      Rake::TestTask.new(base_file) do |t|
-        t.test_files = [test]
-      end
-    end
-  end
-  
-end
-

data/new_project_template/vendor/ceedling/vendor/c_exception/docs/license.txt

@@ -1,30 +0,0 @@
- Copyright (c) 2007 Mark VanderVoord
-
- Permission is hereby granted, free of charge, to any person
- obtaining a copy of this software and associated documentation
- files (the "Software"), to deal in the Software without
- restriction, including without limitation the rights to use,
- copy, modify, merge, publish, distribute, sublicense, and/or sell
- copies of the Software, and to permit persons to whom the
- Software is furnished to do so, subject to the following
- conditions:
-
- The above copyright notice and this permission notice shall be
- included in all copies or substantial portions of the Software.
-
- The end-user documentation included with the redistribution, if 
- any, must include the following acknowledgment: "This product 
- includes software developed for the CEXCeption Project, by Mark 
- VanderVoord and other contributors", in the same place and form 
- as other third-party acknowledgments.  Alternately, this 
- acknowledgment may appear in the software itself, in the same 
- form and location as other such third-party acknowledgments.
- 
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- OTHER DEALINGS IN THE SOFTWARE.

data/new_project_template/vendor/ceedling/vendor/c_exception/docs/readme.txt

@@ -1,236 +0,0 @@
-====================================================================
-CException
-====================================================================
-
-CException is a basic exception framework for C, suitable for use in
-embedded applications.  It provides an exception framework similar in
-use to C++, but with much less overhead.
-
-CException uses C standard library functions setjmp and longjmp to 
-operate.  As long as the target system has these two functions defined,
-this library should be useable with very little configuration.  It 
-even supports environments where multiple program flows are in use, 
-such as real-time operating systems.
-
-There are about a gabillion exception frameworks using a similar 
-setjmp/longjmp method out there... and there will probably be more 
-in the future. Unfortunately, when we started our last embedded 
-project, all those that existed either (a) did not support multiple 
-tasks (therefore multiple stacks) or (b) were way more complex than 
-we really wanted.  CException was born.
-
-Why use CException?
-
-0. It's ANSI C, and it beats passing error codes around.
-
-1. You want something simple... CException throws a single id. You can 
-   define those ID's to be whatever you like. You might even choose which 
-   type that number is for your project. But that's as far as it goes. 
-   We weren't interested in passing objects or structs or strings... 
-   just simple error codes.
-
-2. Performance... CException can be configured for single tasking or 
-   multitasking. In single tasking, there is very little overhead past 
-   the setjmp/longjmp calls (which are already fast). In multitasking, 
-   your only additional overhead is the time it takes you to determine 
-   a unique task id 0 - num_tasks. 
-
-For the latest version, go to http://cexception.sourceforge.net
-
---------------------------------------------------------------------
-CONTENTS OF THIS DOCUMENT
---------------------------------------------------------------------
-
-Usage
-Limitations
-API
-Configuration
-Testing
-License
-
---------------------------------------------------------------------
-Usage
---------------------------------------------------------------------
-
-Code that is to be protected are wrapped in Try { } Catch { } blocks.
-The code directly following the Try call is "protected", meaning that
-if any Throws occur, program control is directly transferred to the
-start of the Catch block.
-
-A numerical exception ID is included with Throw, and is made accessible
-from the Catch block.
-
-Throws can occur from within function calls (nested as deeply as you 
-like) or directly from within the function itself.
-
---------------------------------------------------------------------
-Limitations
---------------------------------------------------------------------
-
-This library was made to be as fast as possible, and provide basic
-exception handling.  It is not a full-blown exception library.  Because 
-of this, there are a few limitations that should be observed in order 
-to successfully utilize this library:
-
-1. Do not directly "return" from within a Try block, nor "goto" 
-   into or out of a Try block.  
-   
-   Why? 
-   
-   The "Try" macro allocates some local memory and alters a global 
-   pointer.  These are cleaned up at the top of the "Catch" macro. 
-   Gotos and returns would bypass some of these steps, resulting in
-   memory leaks or unpredictable behavior.
-   
-2. If (a) you change local (stack) variables within your Try block, 
-   AND (b) wish to make use of the updated values after an exception 
-   is thrown, those variables should be made volatile. Note that this 
-   is ONLY for locals and ONLY when you need access to them after a 
-   throw.
-   
-   Why?
-   
-   Compilers optimize.  There is no way to guarantee that the actual 
-   memory location was updated and not just a register unless the 
-   variable is marked volatile.
-
-3. Memory which is malloc'd or new'd is not automatically released
-   when an error is thrown.  This will sometimes be desirable, and
-   othertimes may not.  It will be the responsibility of the Catch
-   block to perform this kind of cleanup.
-   
-   Why?
-   
-   There's just no easy way to track malloc'd memory, etc., without
-   replacing or wrapping malloc calls or something like that.  This 
-   is a light framework, so these options were not desirable.
-   
---------------------------------------------------------------------
-API
---------------------------------------------------------------------
-
-Try
----
-
-Try is a macro which starts a protected block.  It MUST be followed by 
-a pair of braces or a single protected line (similar to an 'if'), 
-enclosing the data that is to be protected.  It MUST be followed by a 
-Catch block (don't worry, you'll get compiler errors to let you know if 
-you mess any of that up).
-
-Catch(e)
---------
-
-Catch is a macro which ends the Try block and starts the error handling 
-block. The catch block is called if and only if an exception was thrown 
-while within the Try block.  This error was thrown by a Throw call 
-somewhere within Try (or within a function called within Try, or a function
-called by a function called within Try, etc).
-
-The single parameter 'e' is filled with the error code which was thrown.
-This can be used for reporting, conditional cleanup, etc. (or you can just
-ignore it if you really want... people ignore return codes all the time, 
-right?).  'e' should be of type EXCEPTION_T;
-
-Throw(e)
---------
-
-The method of throwing an error.  Throws should only occur from within a
-protected (Try...Catch) block, though it may easily be nested many function
-calls deep without an impact on performance or functionality.  Throw takes 
-a single argument, which is an exception id which will be passed to Catch 
-as the reason for the error.
-
-If you wish to Rethrow an error, this can be done by calling Throw(e) with
-the error code you just caught.  It IS valid to throw from a catch block.
-
---------------------------------------------------------------------
-CONFIGURATION
---------------------------------------------------------------------
-
-CException is a mostly portable library.  It has one universal 
-dependency, and some macros which are required if working in a 
-multi-tasking environment.
-
-1. The standard C library setjmp must be available.  Since this is part
-   of the standard library, chances are good that you'll be fine.
-
-2. If working in a multitasking environment, methods for obtaining an 
-   index into an array of frames and to get the overall number of 
-   id's are required.  If the OS supports a method to retrieve Task 
-   ID's, and those Tasks are number 0, 1, 2... you are in an ideal 
-   situation.  Otherwise, a more creative mapping function may be 
-   required.  Note that this function is likely to be called twice 
-   for each protected block and once during a throw.  This is the 
-   only overhead in the system.
-   
-Exception.h
------------------
-By convention, most projects include Exception.h which defines any 
-further requirements, then calls CException.h to do the gruntwork.  All
-of these are optional.  You could directly include CException.h if
-you wanted and just use the defaults provided.
-
-EXCEPTION_T      - Set this to the type you want your exception id's 
-                   to be.  Defaults to 'unsigned int'.
-
-EXCEPTION_NONE   - Set this to a number which will never be an 
-                   exception id in your system.  Defaults to 0x5a5a5a5a.
-
-EXCEPTION_GET_ID - If in a multi-tasking environment, this should be 
-                   set to be a call to the function described in #2 above.
-                   Defaults to just return 0 all the time (good for 
-                   single tasking environments)
-                     
-EXCEPTION_NUM_ID - If in a multi-tasking environment, this should be set
-                   to the number of ID's required (usually the number of
-                   tasks in the system).  Defaults to 1 (for single
-                   tasking environments).
-
-You may also want to include any header files which will commonly be
-needed by the rest of your application where it uses exception handling 
-here.  For example, OS header files or exception codes would be useful.
-
---------------------------------------------------------------------
-TESTING
---------------------------------------------------------------------
-
-If you want to validate that CException works with your tools or that
-it works with your custom configuration, you may want to run the test
-suite.
-
-The test suite included makes use of the Unity Test Framework.  It will
-require a native C compiler. The example makefile uses MinGW's gcc.  
-Modify the makefile to include the proper paths to tools, then run 'make'
-to compile and run the test application.  
-
-C_COMPILER - The C compiler to use to perform the tests
-C_LIBS - The path to the C libraries (including setjmp) 
-UNITY_DIR - The path to the Unity framework (required to run tests)
-            (get it at http://embunity.sourceforge.net)
-
---------------------------------------------------------------------
-LICENSE
---------------------------------------------------------------------
-
-This software is licensed under the MIT License
-
-Copyright (c) 2007 Mark VanderVoord
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.

data/new_project_template/vendor/ceedling/vendor/c_exception/vendor/unity/docs/Unity Summary.txt

@@ -1,217 +0,0 @@
-==============
-Unity Test API
-==============
-
-[Copyright (c) 2007 - Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams]
-
--------------
-Running Tests 
-------------- 
-
-RUN_TEST(func, linenum)
-
-Each Test is run within the macro RUN_TEST.  This macro performs necessary setup before the test is called and handles cleanup and result tabulation afterwards.
-
---------------
-Ignoring Tests
---------------
-
-There are times when a test is incomplete or not valid for some reason.  At these times, TEST_IGNORE can be called.  Control will immediately be returned to the caller of the test, and no failures will be returned.
-
-TEST_IGNORE()
-
-Ignore this test and return immediately
-
-TEST_IGNORE_MESSAGE (message)
-
-Ignore this test and return immediately.  Output a message stating why the test was ignored.
-
---------------
-Aborting Tests
---------------
-
-There are times when a test will contain an infinite loop on error conditions, or there may be reason to escape from the test early without executing the rest of the test.  A pair of macros support this functionality in Unity.  The first (TEST_PROTECT) sets up the feature, and handles emergency abort cases.  TEST_ABORT can then be used at any time within the tests to return to the last TEST_PROTECT call.
-
-TEST_PROTECT()
-
-Setup and Catch macro
-
-TEST_ABORT()
-
-Abort Test macro
-
-Example:
-
-main()
-{
-    if (TEST_PROTECT() == 0)
-    {
-        MyTest();
-    }
-}
-
-If MyTest calls TEST_ABORT, program control will immediately return to TEST_PROTECT with a non-zero return value.
-
-
-=======================
-Unity Assertion Summary
-=======================
-
---------------------
-Basic Validity Tests
---------------------
-
-TEST_ASSERT_TRUE(condition)
-
-Evaluates whatever code is in condition and fails if it evaluates to false
-
-TEST_ASSERT_FALSE(condition)
-
-Evaluates whatever code is in condition and fails if it evaluates to true
-
-TEST_ASSERT(condition)
-
-Another way of calling TEST_ASSERT_TRUE
-
-TEST_ASSERT_UNLESS(condition)
-
-Another way of calling TEST_ASSERT_FALSE
-
-TEST_FAIL()
-TEST_FAIL_MESSAGE(message)
-
-This test is automatically marked as a failure.  The message is output stating why.
-
-------------------------------
-Numerical Assertions: Integers
-------------------------------
-
-TEST_ASSERT_EQUAL_INT(expected, actual)
-TEST_ASSERT_EQUAL_INT8(expected, actual)
-TEST_ASSERT_EQUAL_INT16(expected, actual)
-TEST_ASSERT_EQUAL_INT32(expected, actual)
-TEST_ASSERT_EQUAL_INT64(expected, actual)
-
-Compare two integers for equality and display errors as signed integers. A cast will be performed
-to your natural integer size so often this can just be used.  When you need to specify the exact size,
-like when comparing arrays, you can use a specific version:
-
-
-
-TEST_ASSERT_EQUAL_UINT(expected, actual)	
-
-Compare two integers for equality and display errors as unsigned integers.  Like INT, there are 
-variants for different sizes also.
-
-
-
-TEST_ASSERT_EQUAL_HEX(expected, actual)
-
-Compares two integers for equality and display errors as hexadecimal.  Like the other integer comparisons,
-you can specify the size... here the size will also effect how many nibbles are shown (for example, HEX16 
-will show 4 nibbles).
-
-_ARRAY
-
-You can append _ARRAY to any of these macros to make an array comparison of that type.  Here you will
-need to care a bit more about the actual size of the value being checked.  You will also specify an
-additional argument which is the number of elements to compare.  For example:
-
-TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, elements)
-
-
-TEST_ASSERT_EQUAL(expected, actual)
-
-Another way of calling TEST_ASSERT_EQUAL_INT
-
-
-
-TEST_ASSERT_INT_WITHIN(delta, expected, actual)
-
-Asserts that the actual value is within plus or minus delta of the expected value.  This also comes in 
-size specific variants.
-
-
------------------------------
-Numerical Assertions: Bitwise
------------------------------
-
-TEST_ASSERT_BITS(mask, expected, actual)
-
-Use an integer mask to specify which bits should be compared between two other integers.  High bits in the mask are compared, low bits ignored.
-
-TEST_ASSERT_BITS_HIGH(mask, actual)
-
-Use an integer mask to specify which bits should be inspected to determine if they are all set high.  High bits in the mask are compared, low bits ignored.
-
-TEST_ASSERT_BITS_LOW(mask, actual)
-
-Use an integer mask to specify which bits should be inspected to determine if they are all set low.  High bits in the mask are compared, low bits ignored.
-
-TEST_ASSERT_BIT_HIGH(bit, actual)
-
-Test a single bit and verify that it is high.  The bit is specified 0-31 for a 32-bit integer.
-
-TEST_ASSERT_BIT_LOW(bit, actual)
-
-Test a single bit and verify that it is low.  The bit is specified 0-31 for a 32-bit integer.
-
-----------------------------
-Numerical Assertions: Floats
-----------------------------
-
-TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
-
-Asserts that the actual value is within plus or minus delta of the expected value.
-
-TEST_ASSERT_EQUAL_FLOAT(expected, actual)
-
-Asserts that two floating point values are "equal" within a small % delta of the expected value.
-
------------------
-String Assertions
------------------
-
-TEST_ASSERT_EQUAL_STRING(expected, actual)
-
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different.
-
-TEST_ASSERT_EQUAL_STRING_MESSAGE(expected, actual, message)
-
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different. Output a custom message on failure.
-
-------------------
-Pointer Assertions
-------------------
-
-Most pointer operations can be performed by simply using the integer comparisons above.  However, a couple of special cases are added for clarity.
-
-TEST_ASSERT_NULL(pointer)
-
-Fails if the pointer is not equal to NULL
-
-TEST_ASSERT_NOT_NULL(pointer)
-
-Fails if the pointer is equal to NULL
-
-
------------------
-Memory Assertions
------------------
-
-TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)
-
-Compare two blocks of memory.  This is a good generic assertion for types that can't be coerced into acting like
-standard types... but since it's a memory compare, you have to be careful that your data types are packed.
-
---------
-_MESSAGE
---------
-
-you can append _MESSAGE to any of the macros to make them take an additional argument.  This argument
-is a string that will be printed at the end of the failure strings.  This is useful for specifying more
-information about the problem.
-
-
-
-