Letme
commented
3 years ago The first part seemed logical, but then the second part where you changed the compiler to the embedded one I kinda lost you. Are you trying to run binaries on target? Then I would assume .elf instead of .out and some more commands in project.yml to actually run (:simulator: fields). So that second route seems totally wrong. This also explains the problems you have with asm directive, as that is probably something tuned to arm (based on your includes).
Now for the first part. I haven't been doing much with FreeRTOS in the last 5 years, but I remember it was a bunch of quite standard C files. Glanced through the website quickly and I noticed you generate it per target - so my question: is your freetros generated for x86_64 or did you leave it for arm? The error in the other issue simply tells you you probably need mock_task.h before mock_freertos.h, and I would assume also FreeRTOSConfig.h somewhere on top.
second-string
GlebPlekhotko
lorenz10
luisGallet
oyeBilly
raulperez
EDIT: I think there are some better approaches that have been posted more recently - make sure you check out all of the alternative approaches to see what suits you best
Hi, I've searched pretty extensively on how to get this working, but I can't seem to find too many (if any) mentions of people running into this issue. I can't be the only person using CMock or Ceedling to mock unit tests within an embedded codebase including FreeRTOS, so I fear I'm missing something obvious.
Initially, I could get everything working with minimal hassle by including
along with my normal source file paths in the
:paths:source:section of my project.yml.Then when I wanted to start testing more of my files than a few fully decoupled algorithms, I ran into the issue where either those modules' header files, or headers that they included, in turn included files from the Middlewares directory of the FreeRTOS source files (which is the third and final dir that sits at the same level as Core and Drivers listed above).
No problem, I though, and dropped the Middlewares path below those two.
This then exploded into a ton of errors trying to compile FreeRTOS, most notably the one mentioned here: https://github.com/ThrowTheSwitch/Ceedling/issues/548 We previously had been using a support file for stubbing FreeRTOS files with 5 or 6 macros and functions definitions to avoid including the Middlewares folder in the tests, so I replaced that with an empty C file besides the line
#include "freertos.c"to gte around the casing issues.We also have been using multiple "stubbed" headers in lieu of our real source headers which were basically copies of the originals with functionality delicately carved out of them and no FreeRTOS dependencies. This was because even when using
#include "mock_[filename].h"the generated mock files still include the original header file. We would include the stubbed headers with#ifdef UNIT_TESTthroughout source header files, where UNIT_TEST was a define declared in our Ceedling project.yml.The problem with this solution is that it doesn't scale, and at some point I'll run into something that I can't
typedef void *or remove from a header.I finally removed almost all of the errors by stubbing things out or partitioning header includes with
#ifdef UNIT_TESTonly to get down to a ton of errors about invalid__asm(...)calls from within FreeRTOS files. Obviously this is because Ceedling is using gcc to compile, but for our embedded project we're usingarm-none-eabi-gcc.So now I've gone down the route of adding in a custom compiler and linker into our project.yml file:
and I switched
:flags:test:compile:and:flags:test:compile:from what we had defined in there for 32-bit compilation with gcc to the same compilation/linking flags used when compiling with out STM32 makefile. I've fought through a dozen compilation and linking errors to finally get to one single linker issue:It can't find that symbol because it's defined in a startup assembly file. It's located on the source paths, so I'm not sure why it's not included in compilation and linking. Regardless, I'm not really sure this approach will work / is worth it.
Finally to my actual question: am I going about this 100% wrong? Is there an easy way to stub/mock out layers way up before I did any of this that I'm just somehow missing? If I could use the standard compiler and not include this architecture-specific Middlewares directory I'd love that, but I'm lost as to how to do that without completely sullying all of my source header and implementation files with a ton of
#ifdefs, writing a header stub for tons of files, and hand stubbing out every single FreeRTOS function signature that's called.