RP time driver alternatively using mtimer, timer0, timer1, or aot

[mschnell1]

adding potential features in cargo.toml

[bugadani]

Why are you closing a PR, and reopening a new one with the same thing?

[mschnell1]

Why are you closing a PR, and reopening a new one with the same thing?

I am not familiar with GitHub PRs (Just plain old GitLab.)

I did not think a PR that issued error message to me is of any relevance and therefore I closed them.

Is the better way to "elongate" the PR by committing something to the fork and then do (what ?) ?

Anyway. Even though it now actually seems to build in the pipeline I was not able to have the commit be accepted to be error-free, and I don't know what I could improve (in fact I even needed to mingle the cargo.toml file inappropriately to make it build).

I suppose the problem is due to the cfg features settings I introduced.

Here I am not sure if I did it correctly.

IMHO for the 235x the default should be the mtimer.

• The users will prefer to use the more versatile timer0 and timer1 for more complex purposes.
• mtimer might be more secure due to alarm comparing greater instead of equal and extremely simple interrupt handling (just statically controlled by the alarm value).

I think,. the system tick should be somehow automatically be 1_000_000 with timer0, timer1 and mtimer, but 1_000 with aot.
I have no idea how to accomplish this.

BTW: I can't compile the cloned repository due to error: failed to install component: 'llvm-tools-preview-x86_64-pc-windows-msvc', detected conflict: 'lib/rustlib/x86_64-pc-windows-msvc/bin/llvm-ar.exe'

[bugadani]

If you commit to the same branch, the PR will be updated, and CI will run on it. However, closing and creating a new PR will send 2 messages to the matrix chat for 1700 people to see.

[mschnell1]

If you commit to the same branch, the PR will be updated, and CI will run on it. However, closing and creating a new PR will send 2 messages to the matrix chat for 1700 people to see.

Ooops :(
Even if the pipeline fails ? (I supposed exactly nothing to happen in that case)
Weird ....

So just committing tho the forked is enough to have you be aware of the changes (even if the pipeline fails) ?

[mschnell1]

Should we refacture this moving the code for each hardware alternative to a dedicated module ?
(Right now I tried to touch the original code as little as possible.)