With a lot of digging, I found that the acquire bus and release bus are supposed to control the SPI CS. (very helpful post from one of your experts).
I've done two projects. One linked everything in, and attempted to compile each routine along with the rest of them. This required some considerable changing of paths to allow compilation. (Yes, I know now that wasn't the preferred way). In clearing the screen (I used one of my own drivers for the ILI9341), your fill routine takes the background color (in this case, blue, your definition of blue), then converts it to the native display format. That macro returned a zero, which was used to clear the screen. I wanted blue as a test. Perhaps a bit more documentation on *when* a particular macro is chosen might help. However, putting that aside to try to do the "right" version of including the software: the following happens:
This is CubeMXIDE, with which I have had some issues. However, it works for my projects. I have a common library for all of my projects where possible, and link to the sources. An options file uses #ifdef to include and #define to customize features, dropping out, for instance an LED control chip and defining how it can be accessed. That works. I followed some directions about setting up Eclipse (on this forum), imported the whole directory of uGFX, moved the config file up to the core/inc directory, put the makefile.c into the core/src directory, made the entire uGFX addition excluded from compilation. Added the gfxinit file to the main bridge program. (I have the main.c as provided by the CUBEMXIDE, which is modified to add QSPI memory. That program then calls a C++ program (CPP_LINK) which sets up my wrappers around the low level HAL drivers and can (did) initialize displays. The call to GFXinit is there. FreeRTOS is already started, and CPP_LINK then creates the main application as a loop, which goes on to initialize all the system interfaces (C++, packet capable).
I haven't modified the build system from what CubeMXIDE provides. The system seems to work, however, it fails compilation when gfx.h/c is trying to find the configuration file. Since it's apparently been configured by the makefile, it doesn't read compiler paths.
So at this point, no compilation on the second try, but it does seem to be more of what you intend.
What I did was to rewrite (in this case) the SPI drivers so that they were C routines (I kept the original C++ drivers intact). If I use the same semaphore on my code, the drivers interlock. Interfaces are protected at the system driver level, and the entire device (display, memory chip, etc) is protected at the system device level. I think I'll have to use my semaphores, though. (semaphores are not owned by the SPI driver class, so they're accessible to C code).
The low level code in the board file is C, not C++, so that's not a problem. My original C++ routines do more heavy lifting. ex: controlling the A0 line and CS so that the entire transaction is done as: CS down, A0 down, send x bytes of command, A0 up, send y bytes of data, CS up, A0 down (just so it's in a known state). I also reset the SPI timing on the interface as needed, in case the interface is shared by two different chips (hardware SPI enables NOT used).
What I was looking for was a "this is what the project tree needs to look like, so your sources go here". since you never have the IDE compile the program, it matters a bit less, but I was looking more for a "do this and here's what we expect" kind of approach.
I'm getting that idea now, which is ok. I see the idea of the boardfile and why you did it like that.
Every program (and language, computer or otherwise) is created with the inborn assumption that "things will be done this way". The larger the program, the more subtle, at times, the assumptions. Now I'm beginning to understand the assumptions you made in this program. Since I'm still setting things up, well, still figuring things out.
I think I have the board file reasonably understood, but some of the configuration options are going to be interesting. Since I don't (obviously!) write code the way you do, I'm still figuring out what I need to know.
Thanks for the help, I need to figure out how some of those paths are resolved.
I prefer to know why, so if it doesn't work, I can figure out how to fix it.
Harvey
