Skip to content

test: add us ticker test #4690

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

Merged
merged 1 commit into from
Aug 7, 2017
Merged

Conversation

0xc0170
Copy link
Contributor

@0xc0170 0xc0170 commented Jul 3, 2017

This test exercises us ticker API

  • init should be executed just once
  • read timestamp
  • setting interrupts

Disable interrupt shall be also tested, should be proparly in its own test,
as it is the very last function to be executed (we dont have API to reenable interrupts), thus cant be in the same test unit.

Need to add documentation to this test.

This is very basic test, init version that can expand. I can add disable also but it is own file, was thinking something like this:

void test_us_ticker_disable_interrupt(void)
{
    // we use here ticker API to set properly callback to set our complete flag
    const ticker_data_t *us_ticker = get_us_ticker_data();
    ticker_event_t event;
    const uint32_t future_margin = 1000; // 1ms margin for interrupt to be fired 

    complete = false;
    ticker_set_handler(us_ticker, us_ticker_handler_test);
    timestamp_t future_timestamp = us_ticker_read() + 1000UL;
    ticker_insert_event_us(us_ticker, &event, future_timestamp, 1);
    us_ticker_disable_interrupt();
    while (us_ticker_read() <= (future_timestamp + future_margin));
    TEST_ASSERT_TRUE_MESSAGE(complete == false, "Interrupt was disabled and still fired");
}

I can refactor this to be us ticker and lp ticker tests (via that ticker data API), would our test allow it? This would be the idea:

ticker_lpus/ticker_header_test.h - would contain definitions for both
ticker_lpus/lp_ticker/main.cpp - this would use lp ticker data
ticker_lp_us/us_ticker/main.cpp - this would use us ticker data

Tested with ARM on K64F and NCS36510 so far, more testing required.

cc @pan- @c1728p9 Anyone else interested in tickers?

@theotherjimmy
Copy link
Contributor

@pan- @c1728p9 Could you review?

Copy link
Contributor

@c1728p9 c1728p9 left a comment

Choose a reason for hiding this comment

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

This test seems like it would apply just as well to the lp_ticker. Maybe it could be combined with #4628 and applied to both the us_ticker and the lp_ticker?

Case cases[] = {
Case("us ticker - Init", test_us_ticker_init, greentea_failure_handler),
Case("us ticker - Read", test_us_ticker_read, greentea_failure_handler),
Case("us ticker - Read wiht loop", test_us_ticker_read_loop, greentea_failure_handler),
Copy link
Contributor

Choose a reason for hiding this comment

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

type - should be "with"

complete = false;
ticker_set_handler(us_ticker, us_ticker_handler_test);
timestamp_t future_timestamp = us_ticker_read() + 5000UL;
ticker_insert_event_us(us_ticker, &event, future_timestamp, 1);
Copy link
Contributor

Choose a reason for hiding this comment

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

Using the ticker_* layer here adds extra code that could interfere with testing of the hal. You might consider using the us_ticker_* API here directly, so changes in ticker_* don't effect hal testing.

Copy link
Contributor Author

@0xc0170 0xc0170 Jul 12, 2017

Choose a reason for hiding this comment

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

That was the intention but current us ticker API does not provide this, the handler calls directly upper layer, and there is not API to redirect this. Only the upper layer provides that.

We can set interrupt, but handling ISR is in the handler that calls the upper layer. We can remove this test, and the upper layer then exercises set_interrupt() ?

It could be via weak, but then we would not exercise IRQ handler. Therefore I can just remove this code from here completely, and set interrupt needs to be tested via upper layer tests

@0xc0170
Copy link
Contributor Author

0xc0170 commented Jul 12, 2017

This test seems like it would apply just as well to the lp_ticker. Maybe it could be combined with #4628 and applied to both the us_ticker and the lp_ticker?

As stated above, yes this could be refactored, I'll do that, rebase soon

@0xc0170
Copy link
Contributor Author

0xc0170 commented Jul 25, 2017

I pushed an update. @c1728p9 now exercises HAL ticker API.

+--------------+---------------+------------------------------+----------------------------------+--------+--------+--------+--------------------+
| target       | platform_name | test suite                   | test case                        | passed | failed | result | elapsed_time (sec) |
+--------------+---------------+------------------------------+----------------------------------+--------+--------+--------+--------------------+
| K64F-GCC_ARM | K64F          | tests-mbed_hal-lp_us_tickers | hal tickers - Init               | 1      | 0      | OK
    | 0.05               |
| K64F-GCC_ARM | K64F          | tests-mbed_hal-lp_us_tickers | hal tickers - Read               | 1      | 0      | OK
    | 0.06               |
| K64F-GCC_ARM | K64F          | tests-mbed_hal-lp_us_tickers | hal tickers - Read with the loop | 1      | 0      | OK
    | 0.07               |
+--------------+---------------+------------------------------+----------------------------------+--------+--------+--------+--------------------+

This test exercises ticker API
- init should be executed just once
- read timestamp

Set interrupt should be tested via upper layer, as it does not provide
API to change handler that is invoked in the ISR ticker handler.
@0xc0170
Copy link
Contributor Author

0xc0170 commented Jul 26, 2017

Rebased, now using setup handler to setup interface (lp vs us ticker), as @c1728p9 proposed. Tested with K64F, same result as previously, all OK

@0xc0170
Copy link
Contributor Author

0xc0170 commented Jul 26, 2017

/morph test

@theotherjimmy
Copy link
Contributor

@studavekar It looks like this did not report to github properly.

@studavekar
Copy link
Contributor

This is due to java process crash , re-triggering request

/morph test

@mbed-bot
Copy link

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 919

Example Build failed!

@0xc0170
Copy link
Contributor Author

0xc0170 commented Aug 3, 2017

/morph test

@mbed-bot
Copy link

mbed-bot commented Aug 3, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 928

All builds and test passed!

@0xc0170
Copy link
Contributor Author

0xc0170 commented Aug 3, 2017

/morph test-nightly

@mbed-bot
Copy link

mbed-bot commented Aug 4, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 935

All builds and test passed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants