Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #29663

Re: Tests in embedded

Path csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From Mikko OH2HVJ <mikko.syrjalahti@nospam.fi>
Newsgroups comp.arch.embedded
Subject Re: Tests in embedded
Date Sat, 16 May 2020 10:26:33 +0300
Organization A noiseless patient Spider
Lines 47
Message-ID <m28shsbas6.fsf@mspro.home> (permalink)
References <r9o23d$9ln$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain
Injection-Info reader02.eternal-september.org; posting-host="67b066a68f47fdcca64cdc93ef742cfd"; logging-data="2296"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UVIZ5jLZrzFsQP0JxpptxXcMrvIqDTrk="
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin)
Cancel-Lock sha1:RfxQWuDO3BK3UBenW609MF+urhM= sha1:vaLygwuAAHxwGIs8Aa8mjb02SKA=
Xref csiph.com comp.arch.embedded:29663

Show key headers only | View raw


pozz <pozzugno@gmail.com> writes:

> Another question. Usually tests are software that checks other
> software (the final application). They can be run automatically if the
> build system is well organized.
> What about when you need to test the firmware/hardware? For example,
> how do you test a SPI GPIO expander driver? The only way to test if
> the driver is able to pull high or low a pin on the expander is to
> inspect the voltage with a voltmeter. Of course this isn't automatic.

Having hardware in the loop testing takes more work than pure software
testing, but can certainly be done.

You can set up a laptop or something like Raspberry Pi to program and
communicate with the target. Then run external test code on that
host. Eventually you might end up with a whole rack full of these..

Simplest case is testing that drivers work and access peripherals that
can somehow identify them and possibly even report their state.

In my view the next level is having something that simulates something
in the 'world' around the target. Or even real sensors and actuators.

If you're doing micropower stuff, you can setup a supply current
measurement to the test host so you can see if the code stays within
energy budget.

Then you can start adding external measurements and stimuli controlled
by the host. Sometimes I've used a modified target board acting as IO
simulator, too. LabJacks are also great for this. Sometimes I use
GPIB/LXI controlled test gear, too, but those can get expensive if you
want to store the whole test setup for future use.

I have not seen too much good frameworks for this, but I've also not
been looking for those for a few years. Typical setup is  building the
code using the usual CI pipelines (I'm using Bitbucket and Gitlab),
running software tests there and then SSHing to the HIL test host to run
HW-connected tests there. Tests are usually in Python.

The design companies I've been working with have their own in-house
test systems, which they're using for production testers - I've stolen a
few good ideas from them on how to organize the test code
structure. Some of the tests can then be run in the production testers,
too!

--
mikko

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Tests in embedded pozz <pozzugno@gmail.com> - 2020-05-16 08:43 +0200
  Re: Tests in embedded Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2020-05-16 10:26 +0300
    Re: Tests in embedded Paul Rubin <no.email@nospam.invalid> - 2020-05-16 02:04 -0700
      Re: Tests in embedded Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2020-05-16 20:08 +0300
        Re: Tests in embedded pozz <pozzugno@gmail.com> - 2020-05-16 20:51 +0200
          Re: Tests in embedded Clifford Heath <no.spam@please.net> - 2020-05-17 09:35 +1000
          Re: Tests in embedded Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2020-05-17 11:26 +0300
      Re: Tests in embedded Dave Nadler <drn@nadler.com> - 2020-06-11 05:38 -0700

csiph-web