Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Mikko OH2HVJ 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: References: 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 pozz 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