Strictly speaking, nearly all of that is available for the application to use. However, once you add various PSoC Components into the project schematic so that the IDE generates relevant API code for you, and particularly once you start using those APIs in your code, some flash and RAM will be used by the APIs and (in the case of BLE) pre-compiled object code that provides core BLE stack functionality.
The specific memory footprint depends on which APIs you end up using. For example, if you design a project with peripheral-only BLE capability, you will have more space available for the application than if you design peripheral and central together in the same project.
For a very rough ballpark, I would refer to the simple "BLE_Find_Me" example project that comes with PSoC Creator. This is a peripheral-only project with basic BLE functionality. Here's the compiler output:
Flash used: 83099 of 131072 bytes (63.4 %).
SRAM used: 11568 of 16384 bytes (70.6 %). Stack: 2048 bytes. Heap: 1024 bytes.
Great. If I can look at he compiler output and see the available flash /heap available for application code to use - that's exactly what I was looking for
The largest footprint by far is the BLE component with it taking around 2/3s of the system space/resources as @Jrow said above.
The other components all take much less :)
Follow up question
My compiler output states
Flash used: 114033 of 131072 bytes (87.0 %).
SRAM used: 14144 of 16384 bytes (86.3 %). Stack: 2048 bytes. Heap: 1024 bytes.
If I'm reading this right my application has 16384 -14144=2240 bytes for stack and heap
Where do the values for stack (2048 ) and heap (1024) come from? Their sum is greater than the available SRAM (2048 + 1024 = 3072 )
1 of 1 people found this helpful
The stack and heap settings can be configured in the Design Wide Resources section of the project definition. Those are the values that are set by default for most projects, but they are often overkill. You can reduce the stack somewhat and often cut out the heap entirely if you don't use runtime memory allocation functions (e.g. malloc).
The figure shown as "SRAM used" (14144 in your example) actually includes and stack and heap values, so the remaining amount is truly unallocated.