Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29663
| From | Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Tests in embedded |
| Date | 2020-05-16 10:26 +0300 |
| Organization | A noiseless patient Spider |
| Message-ID | <m28shsbas6.fsf@mspro.home> (permalink) |
| References | <r9o23d$9ln$1@dont-email.me> |
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
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