Skip to content

Nanostack HAL: Convert to Chrono #12903

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.

Sign up for GitHub

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
Merged
merged 1 commit into from
May 15, 2020
Merged

Nanostack HAL: Convert to Chrono #12903

merged 1 commit into from
May 15, 2020

Conversation

kjbracey
Copy link
Contributor

Summary of changes

Convert Nanostack HAL to use new APIs from #12425.

Impact of changes

Eliminate use of deprecated APIs

Migration actions required

n/a

Documentation

None

Pull request type 

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results 

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@ciarmcom ciarmcom requested review from a team April 30, 2020 11:00
@ciarmcom
Copy link
Member

@kjbracey-arm, thank you for your changes.
@ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

kjbracey
kjbracey commented May 5, 2020
View reviewed changes
features/nanostack/nanostack-hal-mbed-cmsis-rtos/arm_hal_fhss_timer.cpp Outdated
@@ -114,7 +111,7 @@ static int platform_fhss_timer_start(uint32_t slots, void (*callback)(const fhss
equeue = mbed_highprio_event_queue();
MBED_ASSERT(equeue != NULL);
#endif
timer->start();
sleep_manager_lock_deep_sleep();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should really be HighResClock::lock(), self-documenting why it's needed - keeping that clock running for platform_fhss_timeout_read.

Copy link
Contributor

Choose a reason for hiding this comment

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

updating this PR or this will be in the new PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, let's do that now.

@kjbracey kjbracey mentioned this pull request May 5, 2020
Closed
0xc0170
0xc0170 previously approved these changes May 11, 2020
View reviewed changes
@mergify mergify bot added needs: CI and removed needs: review labels May 11, 2020
@mergify mergify bot dismissed 0xc0170’s stale review May 11, 2020 09:36

Pull request has been modified.

@mbed-ci
Copy link

mbed-ci commented May 11, 2020

Test run: FAILED

Summary: 1 of 3 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-GCC_ARM

@kjbracey
Copy link
Contributor Author

CI retriggered

@mergify mergify bot added needs: work and removed needs: CI labels May 12, 2020
@mbed-ci
Copy link

mbed-ci commented May 12, 2020

Test run: FAILED

Summary: 1 of 7 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_wisun-mesh-test

@kjbracey
Copy link
Contributor Author

Is this a real failure? Seems like it should be, given the subject of the PR, but can't navigate the results.

@kjbracey
Copy link
Contributor Author

@JarkkoPaso, could you review and/or comment on results? I'm rereading the changes.

@JarkkoPaso
Copy link

@kjbracey-arm Looks like bad FHSS synchronization but not enough information to be sure or to say how bad it is. I'll try this locally later... today or tomorrow.. Unless you find the issue before.

@JarkkoPaso
Copy link

I tested with Nucleo_F429ZI and it looks like this makes too short timeouts for some reason. For example: 255ms broadcast dwell time is around 190ms when measuring with oscilloscope.

@kjbracey
Copy link
Contributor Author

kjbracey commented May 12, 2020 •
edited
Loading

Could that be down to a flaw in the remaining_time calculations? Not quite sure how that's being used.

Oh, actually, it's a fundamental part of triggering the callback, isn't it?

@JarkkoPaso
Copy link

JarkkoPaso commented May 12, 2020 •
edited
Loading

Yes, could be that function. It should just return the time left for the given callback. Assuming timeout for this callback was started earlier.
Edit: So this comment was about get_remaining_slots function which is working properly.

@kjbracey
Copy link
Contributor Author

Sign for "overrun" callback parameter fixed. CI started.

@mbed-ci
Copy link

mbed-ci commented May 13, 2020

Test run: FAILED

Summary: 1 of 7 test jobs failed
Build number : 3
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_dynamic-memory-usage

@kjbracey
Copy link
Contributor Author

CI retriggered

@mbed-ci
Copy link

mbed-ci commented May 14, 2020

Test run: FAILED

Summary: 1 of 7 test jobs failed
Build number : 4
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_dynamic-memory-usage

@0xc0170 0xc0170 merged commit e48a659 into ARMmbed:master May 15, 2020
@mergify mergify bot removed the ready for merge label May 15, 2020
@kjbracey kjbracey deleted the chrono_ns branch August 19, 2020 08:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@0xc0170 0xc0170 0xc0170 approved these changes

@JarkkoPaso JarkkoPaso JarkkoPaso approved these changes

Assignees
No one assigned
Labels
release-version: 6.0.0-rc1
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@kjbracey @ciarmcom @mbed-ci @JarkkoPaso @0xc0170