ARMmbed / ARMmbed/ci-test-shield
Test cases - the summary
- Dominant language
- C++
- Stars
- 9
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Description
This issue is to track what this CI shield test repo covers and extend it. I would like to keep this updated ,thus take this as a first draft and based on the feedback we update it as needed, and start implementing additions/changes.
```
1. AnalogIn
Test cases
- Analog create and destroy AnalogIn object
- Analog Input on AIN0 - read() + read_u16()
- Analog Input on AIN1 - read() + read_u16()
- Analog Input on AIN2 - read() + read_u16()
- Analog Input on AIN3 - read() + read_u16()
- Analog Input on AIN4 - read() + read_u16()
- Analog Input on AIN5 - read() + read_u16()
2. AnalogOut
Test cases
- AnalogOut create and destroy AnalogOut object
- AnalogOut on AOUT - read(), write(), write_u16()
3. BusIn/Out/InOut
Test cases
- BusIn, BusOut and BusInOout create and destroy objects
- BusInOut to BusInOut - read and write, input and output
- BusIn - mode() - pullup/down
4. Digital IO
Test cases
- DigitalIn/Out create and destroy objects
- DigitalIn, Out - read/write
- mode()
- is_connected()
5. I2C
Test cases
// all below are using the default frequency
- create and destroy I2C object
- Invalid write/read (to check return values for failures)
- LM75B temperature read
- EEPROM WR single byte
- EEPROM WR 2 bytes
- EEPROM WR 10 bytes
- EEPROM WR 100 bytes
6. InterruptIn
Test cases
- create and destroy InterruptIn object
- Register callback for falling edge
- Register callback for raising edge
- enable and disable IRQ
- read() values
7. PWM
Test cases
- create and destroy PWM object
- Frequency 10ms, 30, 100 and 500ms on all PWM pins available
- Duty cycle 10, 30, 100, 500ms on all PWM pins available
8. SPI
Test cases
// assumes the default frequency
- create and destroy SPI object
- open filehandle for SD card
- write to the SD card
- read from the SD card
```
Contributor guide
No contributing guide indexed for this repository
Research direction
No files, test entry points, or target hardware are named. Start by reading the repository's existing CI shield tests and confirm which listed peripherals and boards are available. Define a bounded subset before implementing; done should be an agreed, runnable set of coverage for the selected cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100