is the hello_world application running on your board? This would mean that your UART is connected correctly -> as Peter suggested.
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.
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!
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 …
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]
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
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 .
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
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
this seems to be tricky one, I just tested again with you description down below:
added vtimer to the Makefile in the hello_world project
added vtimer_usleep() to the main function, and of course added #include “vtimer.h” to the main.c
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]