Of course, simulator is simulator, it does not include anything hardware related, it would not make any sense, the simulator is simulating the UI only, not the entire device. It simulates the UI on Windows, not ARM environment.
To avoid such issues while using simulator builds - use conditional compilation. In your UI never include hardware related code, unless it's contained in conditional macros starting from `#if` or `#ifdef`. The way to detect simulator builds is `SIMULATOR` macro present. So using `#ifndef SIMULATOR` as the start of the block - you will ensure it won't be compiled for a simulator build.
To make things even cleaner and more readable to myself, in my device build I defined a macro `DEVICE` that is set to `1`. So for all my hardware related code in presenters I write `#if DEVICE`. If it's not defined, the macro will evaluate to false, so, the simulator builds will build correctly, not seeing the code that is not meant for them.
Another useful thing to remember is to never mix views with the backend. ST invented Model-Presenter-View architecture to make views more cleaner without backend code mixed. So perfectly you should call your hardware related code from the Model only, but I usually use presenters for it. The model in my app is used only as a model of the UI itself, it's like the database for the UI state, not the hardware state. When the virtual button needs to pass actual signal - it calls the presenter, and the presenter has the optional include that includes my backend code that first synchronizes the threads (passes the request from the UI thread to the main application thread), then do the hardware related work.
You can make UI thread your actually "main application thread" - unless you want to things work in the background primarily and the UI updates on top of it. It's entirely up to the user to decide, both approaches have their pros and cons.
