Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cpu/stm32f: boards/iot-lab_M3: cleanup and intermediate workaround #1756

Merged
merged 3 commits into from Oct 13, 2014
Merged

cpu/stm32f: boards/iot-lab_M3: cleanup and intermediate workaround #1756

merged 3 commits into from Oct 13, 2014

Conversation

thomaseichinger
Copy link
Member

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.

see #1752 (comment)

@thomaseichinger thomaseichinger added Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Impact: major The PR changes a significant part of the code base. It should be reviewed carefully Area: network Area: Networking labels Oct 1, 2014
@thomaseichinger thomaseichinger added this to the Release NEXT MAJOR milestone Oct 1, 2014
@thomaseichinger thomaseichinger mentioned this pull request Oct 1, 2014
Merged
@OlegHahm
Copy link
Member

OlegHahm commented Oct 1, 2014

If this works as a workaround for now, I'm fine, but cannot test.

@thomaseichinger
Copy link
Member Author

@OlegHahm ping
Current at86rf231 is broken for stm32f1 boards. This one line change fixes it again.

@OlegHahm
Copy link
Member

OlegHahm commented Oct 7, 2014

Sorry, still couldn't test, but I guess we could merge anyway.

@thomaseichinger
Copy link
Member Author

hm... seems to be an alignment problem. I'm experiencing similar issues in other branches with this fix. Happens for all except -O0 flags. Sadly #1268 seems not to fix it.

@thomaseichinger thomaseichinger changed the title at86rf231: replace vtimer_usleep by hwtimer_wait cpu/stm32f: boards/iot-lab_M3: cleanup and intermediate workaround Oct 8, 2014
@thomaseichinger
Copy link
Member Author

These changes put the iot-lab_M3 board into a working state again. Compare #1775.
Updated the title and added needed GPIO cleanup/changes.

@thomaseichinger thomaseichinger mentioned this pull request Oct 8, 2014
Closed
@OlegHahm
Copy link
Member

OlegHahm commented Oct 8, 2014

I still cannot test, because I don't have the hardware.

@OlegHahm OlegHahm assigned miri64 and unassigned OlegHahm Oct 8, 2014
@thomaseichinger
Copy link
Member Author

@OlegHahm seems to work correctly again. Let's hope the best.

@thomaseichinger thomaseichinger mentioned this pull request Oct 8, 2014
Closed
haukepetersen
haukepetersen reviewed Oct 9, 2014
View reviewed changes
boards/iot-lab_M3/include/periph_conf.h
#define GPIO_IRQ_15 GPIO_11
/* not configured */
#define GPIO_IRQ_0 (GPIO_NUMOF-1)
#define GPIO_IRQ_10 (GPIO_NUMOF-1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, how about #define GPIO_IRQ_0 (-1)
and `#if GPIO_IRQ_0 < 0``

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@thomaseichinger thomaseichinger added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Oct 9, 2014
@haukepetersen
Copy link
Contributor

looks good and works. ACK when squashed.

@thomaseichinger
at86rf231: replace vtimer_usleep by hwtimer_wait
c27e250 
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.
@thomaseichinger
cpu/stm32f1:board/iot-lab_M3: fix and cleanup for GPIO low level driver
19db6de
@thomaseichinger
cpu/stm32f1: overwrite HWTIMER_WAIT_OVERHEAD
420f20f
@thomaseichinger
Copy link
Member Author

squashed & go

thomaseichinger added a commit that referenced this pull request Oct 13, 2014
@thomaseichinger
Merge pull request #1756 from thomaseichinger/welq-fix
86c85d8 
cpu/stm32f: boards/iot-lab_M3: cleanup and fixes
@thomaseichinger thomaseichinger merged commit 86c85d8 into RIOT-OS:master Oct 13, 2014
@thomaseichinger thomaseichinger deleted the welq-fix branch October 13, 2014 09:58
@thomaseichinger thomaseichinger mentioned this pull request Oct 14, 2014
Closed
@thomaseichinger thomaseichinger restored the welq-fix branch May 11, 2017 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@miri64 miri64

Labels
Area: network Area: Networking CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable Impact: major The PR changes a significant part of the code base. It should be reviewed carefully Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Milestone
Release 2014.12
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@thomaseichinger @OlegHahm @haukepetersen @miri64