Feature: Simulatenous drivers testing

[screamerbg]

It would be great if the CI test shield tests are verifying the simultaneous use of mbed OS driver APIs:

• Low level GPIO - DigitalOut, DigitalIn, InterruptIn, AnalogIn
• Comm APIs - I2C + SPI simultaneous use of EEPROM/I2C and SDCard/SPI.
  ** Simultaneous use in a single thread
  ** Simultaneous use in multiple threads
• Mixed - GPIO & Comm APIs - both for single and multi-threaded scenarios

Printing the tests output would effectively test the simultaneous use of UART as well.

@BlackstoneEngineering @mbartling @bridadan @sg-

[BlackstoneEngineering]

@mray19027 , can you comment on the feasibility of adding this?

[mray190]

Pretty easy to do. Just would involve combining the existing EEPROM and SDCard tests. Biggest problem I can see with this would be timing. We would have to make sure the data streams for both I2C/SPI are big enough to ensure that both are actually running at the same time.

CI Test shield tests already are verifying the simultaneous usage of DigitalIn/Out with InterruptIn as the interrupts are required for the tests.

@brandonboesch

[brandonboesch]

Yeah, I think this is a good idea too. The question is where does this fall into the certification program? Should we require this testing for a device to be mbed certified? Should this be tested in all level's of our level testing scheme?

Also as an aside note, I think that the UART testing should be expanded, because we are only really testing the UART block that is connected to the USB port when running greentea. For a more robust testing, we should really be testing all the UART hardware blocks specified in PeripheralPins.c.

[BlackstoneEngineering]

In current tests we would add this as a new test group called simultaneous. So we would have /api, /assumptions and /simultaneous

In level testing this would go into the corner case testing of the last level. Not required for certification, but reccomended to run.

@screamerbg what do you think?

[mray190]

@screamerbg - implementation of this feature is in PR #62

Can you review the code in that PR to verify that is what you were requesting?