native: add native periph timer

[kaspar030]

This PR adds a simple wrapper from periph/timer.h to host itimers.

It is based un @LudwigOrtmann hwtimer implementation. I've dropped the multiplexing, though.

One of the commits marks some functions in hwtimer.c static, as one of them was colliding with timer.c.

[LudwigKnuepfer]

PR needs rebase for Travis mirror setup

[kaspar030]

rebased.

[kaspar030]

I'm aware that this will collide with the native hwtimer implementation. But the (soon to come) new timer subsystem will drop hwtimer, and I'd like native users to be able to test...

edit "collide" meaning, if anyone uses hwtimer and this PR's driver to actually set a timer, one will overwrite the other.

[LudwigKnuepfer]

Maybe catch this case in make?

[kaspar030]

Not so easy as hwtimer is still a core dependency with lots of uses.
But in my tests, just using this native periph timers works fine for testing timers. ;)

[LudwigKnuepfer]

Print out a big red blinking warning instead of failing then..

[kaspar030]

Could we also use the hwtimer wrapper used by some platforms to keep compatibility?

[LudwigKnuepfer]

I don't know about the details, but I'd actually prefer that if it is what I think it is.

[kaspar030]

Some platforms wrap the hwtimer interface around one periph timer so as to fulfill the core hwtimer dependancies. We could do the same here. Will do shortly.

[kaspar030]

• rebased (was missing vtimer test fixes for review)
• native now uses the slim periph timer + hwtimer_compat (compare sys: add hwtimer compatibility layer for periph timers #2913)

[LudwigKnuepfer]

This PR includes parts of #2913 now?

[kaspar030]

uff, yes. I didn't want to just copy the hwtimer->periph wrapper. So I made it a module and PR'ed it. It's very simple, and Hauke already ACKed it, but yes, I cherry-picked it in here.

[LudwigKnuepfer]

I just wondered if this PR needs a label indicating its dependency on another PR.

[kaspar030]

• rebased, sys: add hwtimer compatibility layer for periph timers #2913 is in master now

[LudwigKnuepfer]

/home/lo/RIOT/sys/compat/hwtimer/hwtimer_arch.c: In function ‘hwtimer_arch_init’:
/home/lo/RIOT/sys/compat/hwtimer/hwtimer_arch.c:36:55: warning: unused parameter ‘fcpu’ [-Wunused-parameter]
 void hwtimer_arch_init(void (*handler)(int), uint32_t fcpu)
                                                       ^

PS:
I realize this is unrelated to this here PR...

[LudwigKnuepfer]

s/hwtimer_arch_now/timer_read/

[emmanuelsearch]

I could also try to test this on OS X if someone explains how I should test ;)

[kaspar030]

@emmanuelsearch If the vtimer_msg test works, everything should be fine!

[emmanuelsearch]

mmmh define working. It seems to hang after some time (no consistent duration after which it hangs though). Below an example of what I get (but it can also happen that it hangs sooner, e.g. right after the first message is received in the second thread):

kernel_init(): This is RIOT! (Version: 2014.12-1718-gd3dadd-native-timer)
kernel_init(): jumping into first task...
This is thread 3
sending 1st msg
now=0:79 -> every 2.0s: Hello World
sending 2nd msg
now=0:147 -> every 5.0s: This is a Test
This is thread 4
sec=1 min=0 hour=0
now=2:308 -> every 2.0s: Hello World
sec=2 min=0 hour=0
sec=3 min=0 hour=0
now=4:2115 -> every 2.0s: Hello World
sec=4 min=0 hour=0
now=5:3641 -> every 5.0s: This is a Test
sec=5 min=0 hour=0
now=6:2658 -> every 2.0s: Hello World
sec=6 min=0 hour=0
sec=7 min=0 hour=0
now=8:4536 -> every 2.0s: Hello World
sec=8 min=0 hour=0
sec=9 min=0 hour=0
now=10:8861 -> every 5.0s: This is a Test

(and then it hangs)

[kaspar030]

You might be hitting the vtimer bugs. Can you check the master branch?

[emmanuelsearch]

Master branch does not compile right now on OS X for the vtimer_msg test. Below the error I get:

RIOT/core/include/thread.h:138:14: error: conflicting
      types for 'thread_create'
kernel_pid_t thread_create(char *stack,
             ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/mach/task.h:193:15: note: 
      previous declaration is here
kern_return_t thread_create
              ^
1 error generated.

[LudwigKnuepfer]

@emmanuelsearch Please open an issue for this problem including your system and toolchain version.

[emmanuelsearch]

done #3175
@LudwigOrtmann can you label it as you see fit?

[kaspar030]

• rebased
• fixed OS X compile, see cpu: native: hwtimer: change mach includes #3288

[kaspar030]

@emmanuelsearch please retest!

[emmanuelsearch]

Does not compile on OS X as is. Will PR a small change that makes it compile later today.

Still hangs after random amount of time (sometimes seems to run normally).
If merged with #3288 it consistently hangs as show below.

kernel_init(): jumping into first task...
This is thread 3
sending 1st msg
now=0:97 -> every 2.0s: Hello World
sending 2nd msg
now=0:156 -> every 5.0s: This is a Test
This is thread 4
sec=1 min=0 hour=0
now=2:5457 -> every 2.0s: Hello World

should I try merging/testing something else?

[kaspar030]

@emmanuelsearch Does master behave differently for that test?

[OlegHahm]

I meant this one: master is not even building on OS X,b ut with #3288 and #3290, the tests behaved more or less the same IIRC. @emmanuelsearch, might correct me.

[kaspar030]

IMHO, if this is as good or better as master, we should merge and wait for improvements by #3282.

[OlegHahm]

👍 Let's wait what @emmanuelsearch says.

[emmanuelsearch]

Still does not work as well as on master...
Hangs often (like 75% of the time) after a few seconds (between 2 and 6)
Current master never failed in my last round of tests.

[kaspar030]

Actually this is obsoleted by #3282, master contains this.

[emmanuelsearch]

great ;)