I understand, long term support is important. I can do it for now, but I don't want to put a burden onto the project for whenever I am not able to continue.
One alternative would be to include the commands needed for each test into a script (shell probably). It these were all in a common directory, then it would be fairly easy to run a test. I don't like having to run a series of several commands over and over. It seems like I frequently miss one and things get confused. I was hoping that this system was not much more complex than that. The config file is almost a list of commands to run. Don On Fri, Jul 20, 2018 at 09:02:09AM +0930, David Rowe wrote: > Hi Don, > > It sounds nice in principal but I have some concerns over the amount of > work required to get it running reliably (on an embedded system) and > also how it will be maintained into the future. > > Based on experience to date very few people will ever run these unit > tests. AFAIK you, Steve, and Richard (cmake system) are the only people > developing stm32 code for Codec 2 at the moment. I can think of about 6 > unittests needed to port 700D to the stm32. Some other tests, such as > DAC/ADC drivers, require more subjective tests (e.g. listening to > audio), so aren't as applicable to automation. > > An alternative is a simpler manual system, e.g. some notes at the top of > each unit test the command lines you need to run and what the pass > conditions are. In some cases the test itself can work out a pass/fail > and printf a result. > > However if this framework is something you are really interested in, and > can commit to maintaining into the future, please feel free. Open > source is about following our passions :-) > > Cheers, > > David > > On 20/07/18 07:17, Don wrote: > > I have been working on a framework to make it easier to run a set of > > unittests, in this case for the stm32 implementation. > > > > This is still a work in progress but it's ready to show the idea and > > a first version. In order to make it visable I have checked it into a > > new directory (codec2-dev/stm32/unittest). It shouldn't affect anything > > else and I will remove it if people don't like it. > > > > Eventually I'd like to move the stm32 sources for tests there too, > > currently they are still in the stm32/src directory. > > > > The process of running st-util and arm-none-eabi-gdb is still not > > working reliably, but I have hopes that it can be made useful. > > > > I'd like to get this to the point that someone could enter a single > > command which would run all of the tests and report the results. > > > > I'll attach the README here too. > > > > Don - W7DMR > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > Freetel-codec2 mailing list > > Freetel-codec2@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2