How about to release new version?

[lexxvir]

Hello,

Thank you for such good crate. I tried version 0.1.0 from crates.io, basically all fine, but there is issue with Duration::ms(). As I see you made some fixes/modification since 0.1.0, would you like to publish new version to crates.io ?

Thanks in advance.

[rudib]

Can you elaborate on the Duration::ms() issue? Is this present in the 0.1.0 release or the latest master as well?

I have just updated the master branch to be up to date with the latest changes to Rust. However, at the moment, I don't have an actual hardware test environment. I would also like to look into updating the project for FreeRTOS 9.0. These two issues would be blockers for a 0.2.0 release from me.

[lexxvir]

I think this issue presents only in 0.1.0 version:
https://github.com/hashmismatch/freertos.rs/blob/0.1.0/src/units.rs#L26

freertos_rs_get_portTICK_PERIOD_MS() expands macro portTICK_PERIOD_MS that expands to ( ( TickType_t ) 1000 / configTICK_RATE_HZ )

Let configTICK_RATE_HZ = 600, then freertos_rs_get_portTICK_PERIOD_MS() returns 1.
Let ms == 1000, then Duration::ms() returns 1000, but I believe it should returns 600.

I use FreeRTOS v8.2.3.

Regarding changes for 0.2.0:
Unfortunately I tied to FreeRTOS v8.2.3 (by chip vendor) and to nightly-2017-06-15 (due to core_io last release). So I need to "backport" you changes to these versions.

[rudib]

That same problem is present in the latest version. I've logged an issue (#10) for this.

Note that such high switching frequencies really aren't typical for embedded projects, even 1000Hz is a bit of an anomaly, but the shim API should be flexible enough for this not to be a problem (even with frequencies above 1000Hz). In the meantime, you might want to try to use a tick rate of 500Hz.

[lexxvir]

Ok, thank you for explanation.

I'm just start digging into embedded programming, that configTICK_RATE_HZ was set by the vendor in their demo application.