cpu/stm32f: boards/iot-lab_M3: cleanup and intermediate workaround #1756
Conversation
|
If this works as a workaround for now, I'm fine, but cannot test. |
|
@OlegHahm ping |
|
Sorry, still couldn't test, but I guess we could merge anyway. |
|
hm... seems to be an alignment problem. I'm experiencing similar issues in other branches with this fix. Happens for all except |
76fc75b to
165e6b3
Compare
|
These changes put the iot-lab_M3 board into a working state again. Compare #1775. |
165e6b3 to
42a0cf4
Compare
|
I still cannot test, because I don't have the hardware. |
|
@OlegHahm seems to work correctly again. Let's hope the best. |
There was a problem hiding this comment.
if these are not used and you mask the corresponding interrupt routines with #ifdef xx, shouldn't comment out or remove these two lines completely?
There was a problem hiding this comment.
I would have done but the compiler then complains in the assignment in gpio_init_int(). We'd have to find a way to define GPIOs that are not used with interrupts -> more #ifs I'd guess.
There was a problem hiding this comment.
hm, how about #define GPIO_IRQ_0 (-1)
and `#if GPIO_IRQ_0 < 0``
There was a problem hiding this comment.
Turned out I was still using GPIO_IRQ_x <-> GPIO_y wrongly (for all but the pin I tested with). Now it is correct and no additional #ifs needed.
aa7a68c to
3342b09
Compare
|
looks good and works. ACK when squashed. |
This fixes a bug where the callback to unlock the thread, put to sleep by `vtimer_usleep` wouldn't be woken up due to overhead. Using hwtimer_wait works for now, but this section will be replaced a driver refactor anyway.
3342b09 to
420f20f
Compare
|
squashed & go |
cpu/stm32f: boards/iot-lab_M3: cleanup and fixes
This fixes a bug where the callback to unlock the thread, put to sleep by
vtimer_usleepwouldn't be woken up due to overhead. Using hwtimer_waitworks for now, but this section will be replaced a driver refactor anyway.
see #1752 (comment)