Timers

Hi Guys,

I have a build of riot and the example app ipc_pingpong running on the stm32f4discovery board but can’t seem to get any timers going …

I first tried the hardware timer, but that seems to get stuck in hwtimer_wait() … and yes I did call the hwtimer_init() function.

I then tried the software timer vtimer by trying to include that module, compile failes with vtimer not able to find timerx or some sort …

Is there any better documenation around to get this going, I only have what is in doxygen i.e http://riot-os.org/api/

Also to get the print output from ipc_pingpong, where do I attach a TTL–>USB adapter, i.e what pins? …

Seems to me there should be some more documenation around for particular board types … just to get up and started.

My 2c

Cheers, Bernie

Hi Bernie,

to use a TTL/USB adapter with your stm32f4, you need to connect:

- board TX pin PA2 -> RX adapter - board RX pin PA3 -> TX adapter - GND -> GND

I'll have a look at the timers. Or maybe someone instantly knows?

Regards, Peter

Hi Bernie,

  1. is the hello_world application running on your board? This would mean that your UART is connected correctly -> as Peter suggested.

  2. from which branch is your code from? Are you working with the newest version of my board_stm32f4discovery branch? I just tested it again against tests/test_hwtimer and tests/test_vtimer_msg, both work fine.

  3. a small remark, that might be helpful: RIOT has a module called auto_init. This is to my knowledge included by default and the purpose of this module is to initialize all active modules, that do not need any arguments for initialization (e.g. hwtimer, vtimer…). So if you want to use the vtimer in you project, you should no call vtimer_init(), as this is already called by auto_init.

Hope this helps, let us know if you need more infos!

Cheers, Hauke

Hi Guys,

I am running the ipc_pingpong example and just wanted to see the printf’s

So the pins that Peter mentioned are USART2? and that is setup to use as stdout/stdin?

Is it also used for the shell io?

I am all confused as to how it all links together.

Hauke, I did a remote checkout of your branch a few days ago, has this been modified since?

Thanks for the hint about auto_init …

So can you give me some examples of waiting for x microseconds using either the vtimer or the hardware timer, I was trying to follow the doxygen docs …

Cheers,

Bernie

Hi Bernard,

So if I understand you right, you want to run the ipc_pingpong example and add a little delay between each send message? The easiest way to do this includes two steps: 1) include “export USEMODULE += vtimer” to the applications Makefile 2) add "#include “vtimer.h” in the top of the main.c file and insert “vtimer_usleep(1000 * 1000);” after msg_send_receive(…) in the while loop at the bottom of the file. This should give you a nice 1s deley between each “ping-pong”. (I just tested it, works fine). That is correct, hardware-wise the pins PA2 and PA3 are connected to the USART2. But for RIOT you don’t have to care about this, as the low-level UART driver takes care of this. Have a look at the boards/stm32f4discovery/include/periph_conf.h file. Here you find the peripheral mappings for your board. For the UART the following mapping is done: uC:USART1 -> RIOT:UART_0 So all you need to know is that RIOTs UART_0 is connected to pins PA2 (TX) and PA3 (RX). For short reference of the used pin mappings have a look at [1], there is a second sheet in the bottom which gives a quick overview. Now for the stdio: the syscalls implemented in cpu/stm32f4/syscalls.c use the low-level UART driver and access the device STDIO. This is defined in boards/stm32f4discovery/board.h and voila, mapped to UART_0. Yes, I think I did last week a little rebasing, so best you update to the newest version of the branch. You’re welcome! done. Cheers, Hauke [1]

Wow, thanks Hauke… totally understand now, great! …,

So regarding modules, how do I know which ones will work with the stm32 … or will they all?

Thanks,

Bernie

Hi Bernie,

a quick & dirty way to determine which modules works and which not is looking at the tests makefiles. Not sure if every module has a test, but most should.

Use this script to have the build system check it for you:

export BOARD=stm32f4discovery for F in tests/test_*/Makefile; do     D=$(dirname ${F})     make -C ${D} clean all >/dev/null 2>&1 \         && echo ${D} works \         >> echo ${X} fails done

Cheers, Ludwig

Hi Hauke,

So I tried the vtimers as per your suggestion, but I still get the timerx… errors, i.e.

Hi again guys,

I worked out why vtimer did not build, it has a dependency on timex module, so I had to include that in my makefile as well …

So my makefile included:

Hi Bernie,

Almost! Have a look at “Makefile.dep”. In fact that dependency is already modeled… (at least in master.) Not sure what might be falling you.

Cheers, Ludwig

PS: Sharing your code might help.

Hi Ludwig,

Not much code to share … I only added the lines to my project Makefile as per previous post, and in the main.c file I am calling the vtimer_usleep(10);

This only works if I include both modules as I mentioned .

Hi Ludwig,

I tried the script and this is the output:

Hi Bernard,

No, everything is checked in. I just tried to compile the test_vtimer_msg on a different computer, and it works fine. Are you sure you include the “USEMODULE += vtimer” in your Makefile? Cheers, Hauke

Hi Bernard,

This should normally not be needed, would be nice if we could find out why the dependencies in Makefile.dep are not working for you… I have not really measured out the precise timing modalities for the timers on the STM32F4discovery board yet. But you will not get a timing granularity of 1us with the vtimer, due to task switching overhead, as the underlying hardware timer is programmed to run with 1MHz… The hardware timer does not need a module, as it is part of core and always available. But the hardware timer is not really intended to be used in the user/application context. If you need this really precise timings, my suggestion would be to use a second low-level timer instance for this purposes. Have a look at drivers/include/periph/timer.h. TIMER_0 is used as hardware timer, but TIMER_1 is not used anywhere, so you could access it directly though this interface… Cheers, Hauke

Hi Hauke,

There is an easy way to duplicate the vtimer module issue, just add these two line to the hello-world project.

  1. to Makefile add: export USEMODULE += vtimer

  2. to main.c and in main() add the line vtimer_usleep(200);

You will see the following error when you make.

Hi Bernie,

Did you just run ‘make’, or did you ‘make clean all’?

Cheers, Ludwig

Hi Bernie,

this seems to be tricky one, I just tested again with you description down below:

  1. added vtimer to the Makefile in the hello_world project
  2. added vtimer_usleep() to the main function, and of course added #include “vtimer.h” to the main.c
  3. build with “BOARD=stm32f4discovery make clean all” This works fine on my system. I am wondering if this could be some toolchain related issue? I am using

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322]

Hope we can figure this out!

Cheers, hauke

I will start to test my code using the f4, but I'll wait until the support is in master.

I see a growing f4 community here, nice!

Best Christian