Can osDelay be emulated via getTimeStamp?

[puzrin]

PolicyEngine already has getTimeStamp, but still requires osDelay for rare cases. Can osDelay be emulated via getTimeStamp internally?

Reasons: simplify use without RTOS.

[Ralim]

Could it be implemented that way: yes
Why isn't it: Don't want to lock up the thread for that long when using an RTOS. Also harder to ensure timing match if using extra wait states and ensuring the outer object is called often enough. Both are rare cases, so odds of running into it is low.
Also, almost all HAL's provide this exact function already, so its literally one extra param.

[puzrin]

How about constructor variants? If osDelay not passed => emulate

[Ralim]

Why though 😂
Like, why should a library be responsible for this?
Given this is primarily going to be used on small devices, the duplicated code doesnt feel wise :)

[puzrin]

Is library for "hardware first" or for "user first"? I can operate in any context :). But as OSS developper, wishing to make project popular, i'd prefer "user first" approach when possible.

the duplicated code doesn't feel wise :)

IMO such statements are discuss-able only when metrics/bounds available. Without clear criterias talk will tend to fall into holywar without constructive output :)

[Ralim]

Is library for "hardware first" or for "user first"? I can operate in any context :). But as OSS developper, wishing to make project popular, i'd prefer "user first" approach when possible.

Its user-first assuming user is at least competent in knowing roughly what they are setting up.
Its not user-first in the Arduino / PlatformIO way of usability>performance.

IMO such statements are discuss-able only when metrics/bounds available. Without clear criterias talk will tend to fall into holywar without constructive output :)

Naturally, and to prove this point ill just save that my preference is smaller code size and to leave it up to the user to handle at their discretion. Given how trivial of a function it is in the simplest case, and how complex it can be in complex cases; that is a wide enough span to prefer to encourage the user to use their available functions. :)

[puzrin]

Its user-first assuming user is at least competent in knowing roughly what they are setting up.
Its not user-first in the Arduino / PlatformIO way of usability>performance.

• Knowing how to install cmake / gcc / flash uploader is too much for beginners (especially on windows). It's more easy [for beginners] to install single vscode and let it organize the rest at project open.
• There are cases when you can ask "please change this line, upload on your device and see if problem fixed". Then user may be "not programmer" at all (but still able to install vscode).

I have nothing against your personal preferences/expectations, but IMO possible use is more wide.

[Ralim]

I completely agree with your statements, but if you are using a framework that is integrating this code, its that framworks job to provide a good user experience for integrations.

The minimal required functions are relatively workable, while not abstracted away to the point of being useless for custom integrations.

I agree that example is quite long, but it could be shortened easily, but prefer the most verbose example possible.

No-one is going to download vscode + this library and be able to flash it to a board. There is at least a good 2 more steps in the middle there. A lot of the work on installing this code, or how to hook to i2c or how to hook to delay is partly on those frameworks more so than this library.

[Seneral]

Just to add to the discussion, I'm looking to eventually implement this without a blocking function as well.
I'm not using a RTOS at all, so for me, it'd require quite a rewrite since I'd need the function to exit, let my code handle the waiting, and re-enter at a later time.
This is not super high priority for me at all, as the PD is currently setup at a time where a bit of blocking code isn't super harmful and I don't use PPS (yet).