[riot-devel] HIL testing
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
Re: [riot-devel] Updates to the build system - modules definition
Hi, I think the problem to solve is that RIOT is very difficult to configure. While working with other IoT operating systems, one can notice that RIOT is very hardly configurable, unless we are very familiar with the build system and specific RIOT CFLAGS and special key-words (USEMODULE, USEPKG, etc…). Besides, I have no knowledge of a tool that can parse RIOT makefiles and give an insight about module usage, dependencies, features, etc. Thus IMHO a way to make, first, RIOT more *friendly* configurable it’s a good and necessary feature. This would also allow to eventually build a dependency tree in a more human-readable fashion, as well as give some help to get different product lines according to the selected features. However, I’d say that *deep* modifications to the current build system can lead to instability or buggy builds. I’m not against any improvement to the build system, but maybe as a first approach some additions like files in any more descriptive (parseable) language can help to describe RIOT in a higher level, without affecting at all the underlying system. Then, with the knowledge obtained thanks to such a description, we can imagine to generate makefiles or make “make” calls with the specific RIOT CFLAGS, USEMODULE, etc. My 2c. Cheers, -- Francisco Javier Acosta Padilla Research Engineer at INRIA Saclay INFINE Team On 24 November 2017 at 19:16:29, Thomas C. Schmidt (t.schm...@haw-hamburg.de) wrote: Hi Dan, Gaetan, I wonder, what problems are we trying to solve? Maybe we can clearly enumerate them first so that we can check later, whether an improved solution really solves these problems. Cheers, Thomas On 24/11/2017 16:47, Daniel Petry wrote: > Hi Gaetan > > >> I would like to introduce some packaging concepts around RIOT. >> To consider modules like well defined distribution packages and not only >> source files added to an application firmware. > > From what you're saying, I understand that the aim is to make modules > completely self-contained with respect to build definitions, and make > those definitions much more human readable. In this way, an application > developer can go to only one place to find out information regarding a > module's build (dependency information, etc.), and a module developer > only has to write/change the module directory Makefile and can do so > with declarative language. Also, the information can be easily parseable > for eg a user interface. > > So the changes you're proposing are: > > 1) Move build information concerning a particular module into that > module's Makefile > 2) Make the module makefiles able to be written with purely declarative > language > 3) Retain backwards compatibility with the current build system > > Is this correct? > > I think 2) would be great for user friendliness, and 3) is a no-brainer. > 1) is a bigger topic as there are a number of different ways in which > dependencies are manifested for example, so I think this can be a point > for further discussion... do you have any particular examples? > > > Dan. > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT developers monthly meeting
RIOT developers monthly meeting Scheduled: 27 Nov 2017 17:00 to 18:00 Location: https://zoom.us/j/235153205 Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla Hi there, Francisco Acosta is inviting you to a scheduled Zoom meeting. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205 Or iPhone one-tap : US: +16699006833,,235153205# or +16465588656,,235153205# Or Telephone: Dial(for higher quality, dial a number based on your current location)： US: +1 669 900 6833 or +1 646 558 8656 Meeting ID: 235 153 205 International numbers available: https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB -- Francisco Javier Acosta Padilla Research Engineer at INRIA Saclay INFINE Team___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Monthly RIOT developer meeting @ Mon Nov 27, 2017 5pm - 6pm (RIOT Events)
Hi RIOTers! Today is our second monthly meeting. So far, I noted the following agenda: 1. Look at the issues solved during the month. 2. Enforce the usage of issues for WIP. 3. Update maintainers list. If you have other concerns which we might talk about with other developers please add them to the agenda. I’ll try to use the features of the zoom.us app to schedule the meeting and agenda bashing, you should receive another invitation e-mail with the meeting link. Cheers, Francisco. On 26 November 2017 at 17:00:13, Google Calendar (calendar-notificat...@google.com) wrote: more details » Monthly RIOT developer meeting When Mon Nov 27, 2017 5pm – 6pm Berlin Where Online (map) Calendar RIOT Events Who • Martine Lenders - creator Invitation from Google Calendar You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
