[riot-devel] HIL testing

Peter Kietzmann peter.kietzmann at haw-hamburg.de
Tue Nov 28 09:21:55 CET 2017


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 at 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


More information about the devel mailing list