RTOS SDK Where is app_main defined as startup function? - sdk

Using rtos SDK i was able to develop and run successfully some simple examples, but I need to understand.
Normally a c / c++ program starts with main(...) (I don't remember the exact signature)
RTOS projects seem to start almost all with app_main() and some examples online with user_init()
A text search throughout all sources did not help me. It seems that there is a startup.c that in turn calls app_main but this does not explain why some other examples (https://github.com/espressif/esp8266-rtos-sample-code/blob/master/03Wifi/Soft_AP_DEMO/user/user_main.c that I did not try) have another entrypoint.
Can somebody explain how it is structured? "Who" is
calling app_main?

The ESP32 ESP-IDF SDK startup procedure is fairly thoroughly described in Application Startup Flow - Application startup. ESP8266 RTOS SDK startup is similar.
ESP-IDF application entry point is call_start_cpu0 function found in
components/esp_system/port/cpu_start.c. This function is executed by
the second stage bootloader, and never returns.
. . . <skip> . . .
Once call_start_cpu0 completes running, it calls the “system layer”
initialization function start_cpu0 found in
components/esp_system/startup.c. Other cores will also complete
port-layer initialization and call start_other_cores found in the same
file.
. . . <skip> . . .
The main system initialization function is
start_cpu0. By default, this function is weak-linked to the function
start_cpu0_default. This means that it’s possible to override this
function to add some additional initialization steps.
. . . <skip> . . .
After all other components are initialized, the main task is created and the FreeRTOS scheduler starts running.
After doing some more initialization tasks (that require the scheduler
to have started), the main task runs the application-provided function
app_main in the firmware.
The last part has been refactored recently. Here's a link to the app_main call in an older IDF-SDK v4.2.

Related

XPSDrv Sample Entry Point / Filters Squence

Finally, I managed to build XPSDrv Sample project successfully . But still there is a problem .
I need to execute a function ( to start an exe file ) after the xps file has been sent to the printer (in my case to local port). So , where and how can I add the function ?
And regarding the filters , how would I know the sequence in which the filters executed .
I really need a help in this matter because I am a beginner in Windows Driver Development , specially in Printer Drivers ...
Any Idea is highly appreciated.
Thanks in Advance
Which filters are included, and the order in which they execute, is controlled by the PipelineConfig.xml.
I'm not sure that launching an external executable after the document has cleared the pipeline is a particularly good idea, but if you must do so, you will need to add that functionality to the last filter in the pipeline.

Difference in manual execution of running app in background and runAppInBackground() using appium

While executing runAppInBackground() for Android application through Appium the app gets restarted but when executed the same manually couldn't be able to reproduce the same. I Would like to deep dive into implementation of a runAppInBackground() method to reproduce the same issue in a manual way.
You need to look behind the code of runAppInBackground
From java client side (your test code) perspective, it is a single call to Appium server:
POST "/session/:sessionId/appium/app/background"
If you continue looking into where its implemented on server side, you finish with appium-android-driver function.
In short what it does:
Get current activity and package
Press physical Home button
Wait for time you provided as argument (seconds)
Bring up back in focus based on different conditions; from the code you can understand what activity is being started
Basically its a sequence of adb shell commands, that you can run from terminal.
My guess is that step 4 you did manually may differ from what Appium is doing: different activities/arguments for activity been called

Events for loaded modules in erlang

How can I get an event when a module has been loaded in erlang?
The "event" can be in the form of execution of a fun/MFA, message to arbitrary process etc. If there is no support in the standard lib what is the best work around?
The workarounds I can think of are:
run a trace on the code module
scan loaded module times in a loop
An additional restriction is that there shouldn't have to be special hooks in the module being loaded because this is for a debugging app. Standard library modules are not expected to be reloaded and it is assumed the tools application is running.
There is -on_load() module directive. You can set some function to run when module is loaded using this directive. See more information in documentation.

How to launch another program from within erlang code

I downloaded the program ImageMagik (www.imagemagick.org/). It can be executed from command line and takes command-line arguments which is perfect for me. How do I execute the program from within a module in Erlang?
You can use either os:cmd call
http://www.erlang.org/doc/man/os.html#cmd-1
or use port
open port http://www.erlang.org/doc/tutorial/c_port.html
Use emagick, https://github.com/kivra/emagick
which already has the necessary bindings ready.

How to tell if process is run by the Service Control Manager

I have a few Windows Services written in C# that I have setup to support being run from the command line as a console app if a specific parameter is passed. Works great but I would love to be able to detect whether the app is being run by the service control mananger or from a command line.
Is there any way to tell at runtime if my app was started by the SCM?
Environment.UserInteractive will return false if the process is running under the SCM.
The SCM will call your OnStart method, so you could mark that event and make sure when you run from the command line, you don't call OnStart. Or, you could check the startup parameters to see how the application was started.
In C the function StartServiceCtrlDispatcher() will fail with ERROR_FAILED_SERVICE_CONTROLLER_CONNECT. This is the best way in C, wonder if C# exposes any of this?
ERROR_FAILED_SERVICE_CONTROLLER_CONNECT
This error is returned if the program is being run as a console application rather than as a service. If the program will be run as a console application for debugging purposes, structure it such that service-specific code is not called when this error is returned.

Resources