platform: esp-idf: uPortPlatformStart return fix

[alonbl]

currently the uPortPlatformStart returns error in all cases, it should return error only if there was a failure.

[alonbl]

@RobMeades this is a fix for freerots for sure, I do not understand the Arduino code, how come delete self task has a benefit? it should block until the task finished, if this is true it should be fix in different patch. This patch is about the return value (when it is returned).

[RobMeades]

Hi: you are correct, though uPortPlatformStart() is only ever meant to return if there has been an error because execution is expected to end up at pEntryPoint and never come back. We'd not anticipated that a user would call uPortPlatformStart() (or any of the port functions for that matter except, these days, uPortFree()) it is really only there so that, internally, we can start up all platforms in the same way when testing; all that ever follows a call to uPortPlatformStart() is U_ASSERT(false).

This is why the Arduino code looks as it does: uPortPlatformStart() allows us to transfer execution into a task that we can set the stack size of, at pEntryPoint, and kill the "fixed stack size" place that Arduino always starts us up in.

[alonbl]

Thanks, so let me understand this better.
Although the ubxlib relay heavily on u-port and abstract operating system syscalls, a reference example is uGnssMsgPrivateReceiveStart(), you suggest the user code will use native services and mix abstraction implementations instead of relaying on the u-port abstraction to the entire implementation.
Is this correct?

[RobMeades]

That's correct: we probably don't make this very clear though. It says on the main README.md (bottom of the APIs section):

"- The port API permits all of the above to run on different hosts; this API is not really intended for customer use - you can use it if you wish but it is quite restricted and is intended only to provide what ubxlib needs in the form that ubxlib needs it."

And we muddy the waters further because, of course, all our examples use the port API because they need to work on all the platforms that ubxlib supports.

I think I should add a bigger notice in the port README.md.

[alonbl]

Thank you for the clarification, indeed I missed this. In any case I do believe this patch is valid, feel free to reject, I will rewrite my code without using the u-port.

[alonbl]

Just to make sure, should I not call these as well?

uPortInit()
uPortDeinit()

[RobMeades]

You are correct, I mis-spoke/wrote, you do need to call uPortInit() and, for neatness, uPortDeinit().

[RobMeades]

The note in the README.md under the port directory was updated in e324d82 to emphasize that, aside from uPortInit(), uPortDeinit() and, if you are freeing memory that ubxlib has allocated, uPortFree() , the port API is not really intended for customer use. Hopefully that clarifies things, will close this now.