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

Add SPI basic test and test header file. #7976

Merged

Conversation

mprse
Copy link
Contributor

@mprse mprse commented Sep 4, 2018

Description

Provide SPI test and test header file based on the new HAL API description provided here:
https://github.com/ithinuel/mbed-os/blob/rfc-spi-overhaul/hal/rfcs/0000-spi-overhaul.md

This PR can not be merged until PR which defines the new HAL API and adds at least one example implementation is merged. Probably then the test will have to be adapted to the final API version.

This test is a first part of entire SPI testing scheme which provides non-communication, full-automated test which will run on CI.

PR Description
RFC SPI: Reference Implementation. #8445 New HAL API definition and example implementations for K66F anf NUCLEO_F429ZI
Add SPI test and test header file. #7976 SPI Green Tea basic test
Add GreeTea SPI communication test. #8216 Two boards Green Tea SPI communication test (closed)
Add Ice Tea SPI communication test. #8443 Two boards Ice Tea SPI communication test
Add one board Green Tea SPI Communication Test #8919 One board Green Tea SPI communication test

Please assign @ithinuel as a reviewer.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Breaking change

@cmonr
Copy link
Contributor

cmonr commented Oct 12, 2018

@ARMmbed/mbed-os-hal ?

Copy link
Member

@fkjagodzinski fkjagodzinski left a comment

Choose a reason for hiding this comment

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

Also please run astyle on files from this PR.

Ok, please ignore my comments regarding the outdated API. I checked existing header instead of the markdown doc.


TEST_ASSERT(capabilities.minimum_frequency <= FREQ_200KHZ);
TEST_ASSERT(capabilities.maximum_frequency >= FREQ_2MHZ);
TEST_ASSERT_TRUE(capabilities.symbol_length & CAPABILITY_WORD_LENGTH_8);
Copy link
Member

Choose a reason for hiding this comment

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

It might be useful to comment this is actually defined behavior / requirement from the docs.

spi_t spi_obj =
{ 0 };
spi_capabilities_t capabilities =
{ 0 };
Copy link
Member

Choose a reason for hiding this comment

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

These lines break for no reason.

}

/* Indicate that test case has been successfully executed. */
TEST_ASSERT_TRUE(true);
Copy link
Member

Choose a reason for hiding this comment

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

This looks a little odd. I think this line is unnecessary for the test case to be valid, but isn't there anything to check during code execution?


spi_format(&spi_obj, 8, SPI_MODE_IDLE_LOW_SAMPLE_FIRST_EDGE, SPI_BIT_ORDERING_MSB_FIRST);

real_freq = spi_frequency(&spi_obj, FREQ_200KHZ);

This comment was marked as outdated.

p_fill_sym = (void*) &fill_symbol_32;
}

const uint32_t sym_cnt = spi_transfer(&spi_obj, p_tx_buf, BUF_SIZE, p_rx_buf, BUF_SIZE, p_fill_sym);

This comment was marked as outdated.

handler_called = false;
expected_event.transfered = 0; // Success will have to be indicated here

const bool async_status = spi_transfer_async(&spi_obj, p_tx_buf, BUF_SIZE, p_rx_buf, BUF_SIZE, p_fill_sym, (void*)&some_ctx, dma_modes[mode_id]);

This comment was marked as outdated.

@cmonr
Copy link
Contributor

cmonr commented Oct 19, 2018

@mprse @fkjagodzinski
How is #8443 relate to this? Does this still need to be reviewed, or is this considered good to move forward?

@cmonr
Copy link
Contributor

cmonr commented Oct 29, 2018

@mprse @fkjagodzinski

Any updates? If not, then we'll have to close due to inactivity.

@mprse
Copy link
Contributor Author

mprse commented Nov 2, 2018

@cmonr Please do not close. This one is needed.

@mprse
Copy link
Contributor Author

mprse commented Nov 5, 2018

Refreshed the test.
Reference implementation required by this PR is still not merged, but this one is ready. Please review.

@cmonr
Copy link
Contributor

cmonr commented Nov 9, 2018

@mprse I wonder if this branch needs to be rebased, since it's not passing unittests.

@mprse
Copy link
Contributor Author

mprse commented Nov 13, 2018

@mprse I wonder if this branch needs to be rebased, since it's not passing unittests.

Probably its not passing since there is no new SPI HAL API on the branch.

@cmonr
Copy link
Contributor

cmonr commented Nov 15, 2018

@mprse Ah, gotcha. So this is waiting on #8445?

@mprse
Copy link
Contributor Author

mprse commented Feb 4, 2019

@theamirocohen Thank you for the solution!

@0xc0170 Can we start CI again?

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 4, 2019

CI restarted

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 4, 2019

CI restarted (Java error, if repeats, will investigate with CI team)

@mbed-ci
Copy link

mbed-ci commented Feb 4, 2019

Test run: FAILED

Summary: 4 of 8 test jobs failed
Build number : 10
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-ARMC6
  • jenkins-ci/mbed-os-ci_build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-ARM
  • jenkins-ci/mbed-os-ci_build-IAR

@mprse
Copy link
Contributor Author

mprse commented Feb 4, 2019

Now the results are very strange. In the last commit I modified examples.json file as suggested @theamirocohen. I made the list of targets empty for the following examples: mbed-os-example-sd-driver and mbed-os-example-bootloader as those can't be build on spi feature branch (at least now). So the mbed-os-example-sd-driver config looks as follows:

https://github.com/ARMmbed/mbed-os/blob/3d439338d3aa8b363903cb673753fbf133ef63fc/tools/test/examples/examples.json#L356-L368

As a result of these changes (targets list is empty) it looks like the examples have been built for all targets, so empty targets array means all? @0xc0170 @cmonr Is that intended behaviour?

If this is intended behaviour then I believe I should set compile flag to false for these examples also. Is that correct and sufficient?

@theamirocohen
Copy link
Contributor

Now the results are very strange. In the last commit I modified examples.json file as suggested @theamirocohen. I made the list of targets empty for the following examples: mbed-os-example-sd-driver and mbed-os-example-bootloader as those can't be build on spi feature branch (at least now). So the mbed-os-example-sd-driver config looks as follows:

mbed-os/tools/test/examples/examples.json

Lines 356 to 368 in 3d43933
{
"name": "mbed-os-example-sd-driver",
"github":"https://github.com/ARMmbed/mbed-os-example-sd-driver",
"mbed": [],
"test-repo-source": "github",
"features" : [],
"targets" : [],
"toolchains" : [],
"exporters": [],
"compile" : true,
"export": true,
"auto-update" : true
}

As a result of these changes (targets list is empty) it looks like the examples have been built for all targets, so empty targets array means all? @0xc0170 @cmonr Is that intended behaviour?

If this is intended behaviour then I believe I should set compile flag to false for these examples also. Is that correct and sufficient?

Hi,
I guess that by removing K64F from "targets" you allowed all boards to be built.
My intention was that you completely remove the sd-driver-example.

mbed-os-example-sd-driver: on spi feature branch SD componen is disabled for K64F - disable this example.
mbed-os-example-bootloader: example is using SPI pins which are now undefined on NUCLEO_F429ZI - disable this example.
@mprse
Copy link
Contributor Author

mprse commented Feb 5, 2019

Fixed as suggested by @theamirocohen.

@0xc0170 Can we try again?

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 5, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Feb 5, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 11
Build artifacts

@mprse
Copy link
Contributor Author

mprse commented Feb 5, 2019

This one should be ready to go. Later changes (after review) were related to CI problems.

@mprse
Copy link
Contributor Author

mprse commented Feb 6, 2019

@donatieng This one should be ready to go. After this one is merged review and CI here is needed:
#8919 .

@NirSonnenschein
Copy link
Contributor

@ithinuel @MarceloSalazar @screamerbg would you like to review?

@donatieng
Copy link
Contributor

Thanks a lot @mprse - @ARMmbed/mbed-os-maintainers I'm happy to get this one merged - if @MarceloSalazar and @screamerbg see missing tests we can add them in a following PR

@@ -0,0 +1,561 @@
/*
* Copyright (c) 2018 ARM Limited
*
Copy link
Contributor

Choose a reason for hiding this comment

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

Can be fixed in separate PR, adding SPDX identifiers for new files

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2019

I'm happy to get this one merged - if @MarceloSalazar and @screamerbg see missing tests we can add them in a following PR

As this is targeting feature branch, please add your comments when you are able to, they will be addressed. We mark this as ready for merge now to be integrated in the next 24 hours.

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.