Hi Hauke,
thanks for you efforts! This is great and really useful work. IMO it is
the right direction, even though I always hoped to find a way around
implementing our own I2C slave device. That's why I wanted to take this
opportunity to ask around for other experiences with I2C (slave) test
devices. Anyone, anything?
Best
Peter
Am 27.11.2017 um 18:33 schrieb Hauke Petersen:
> Hi everyone,
>
> in today's developer meeting the discussion passed by the topic of HIL
> testing once again, this time in the context of the upcoming re-modeling
> of the I2C interface. Some weeks ago I had an idea for a simple HIL
> setup for automatically testing perihp/i2c drivers, and I promised to
> share it (although it is in very very early state). So here it is.
>
> So the basic idea is to connect the I2C pins of the 'board-under-test'
> (i2c master for now) to a 2nd board (lets call it 'test peer'), running
> a fully controllable software i2c slave implementation. On the
> device-under-test we simply run the 'tests/periph_i2c' app, that lets us
> control the I2C master using shell commands (init/read/write incl
> parameters). On the 'test peer' we run a programmable soft i2c client,
> that offers shell commands expressing expectations, e.g. "expect 4 byter
> [abcd] written to addr 0x23".
>
> Now for creating an automated I2C test-suite, I imagine something
> similar to our existing pyexpect scripts (testrunner), just with the
> added capability of handling two clients. So the test script could look
> something like this (mostly pseudocode...):
>
> `PORT=/dev/ttyACM0 TESTPEER=/dev/ttyACM1 make hil-test`
>
> triggers:
>
> ```python
> ...
> def testfunc(testie, peer):
> ...
> # tell the 'test peer' to expect something to be written to addr 0x23
> and respond with a NACK
> peer.sendline("expect_addr 0x23")
> # write a random byte the addr 0x23
> testie.sendline("w 0x23 a")
> # the 'test peer' will tell if it sees the expected address
> peer.expect("[SUCCESS]")
> # the 'device-under-test' should recognize the NACK
> testie.expect("error: no device with that address found on bus")
>
> # test writing (expect 4 bytes [affe] written to address 0x42)
> peer.sendline("expect_write 0x42 a f f e")
> testie.sendline("w 0x42 a f f e")
> peer.expect("[SUCCESS]")
> testie.expect("I2C_DEV(0): successfully wrote 4 bytes to the bus\n")
>
> ...
> # many many more test cases here, including simulation of badly
> behaving slaves and bus recovery...
> ```
>
> I have sketched a I2C slave implementation to run on the 'test peer' in
> [1] (under `tests/softi2ccli`). It is in no means production code, but a
> quick prove of concept. But IMHO this would be a very easy and straight
> forward way to have an automatic test-suite that would work on someones
> desk for now.
>
> Integration into the bigger picture would hopefully be easy doable, but
> this not in the scope of this particular proposal here...
> For now my goal would simply be to build a test suite for assisting with
> the upcoming I2C remodeling to get some hands-on experience and speed up
> the testing efforts for that task.
>
> Cheers,
> Hauke
>
> [1] https://github.com/haukepetersen/RIOT/tree/add_softi2cli
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
--
Peter Kietzmann
Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
