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

Reply via email to