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

Groups > comp.programming > #8916 > unrolled thread

A question about building a large and complex piece of software

Back to article view | Back to comp.programming

Contents

  A question about building a large and complex piece of software Chad <cdalten@gmail.com> - 2018-06-08 16:47 -0700
    Re: A question about building a large and complex piece of software Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-06-09 08:11 +0200
      Re: A question about building a large and complex piece of software Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-06-09 08:33 +0200
        Re: A question about building a large and complex piece of software Chad <cdalten@gmail.com> - 2018-06-09 07:59 -0700
          Re: A question about building a large and complex piece of software Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-06-10 20:21 +0200
          Re: A question about building a large and complex piece of software Ed Prochak <edprochak@gmail.com> - 2018-06-12 06:46 -0700
            Re: A question about building a large and complex piece of software Chad <cdalten@gmail.com> - 2018-06-13 06:45 -0700

#8916 — A question about building a large and complex piece of software

I've been working on a fairly sophisticated piece of software for the past 10 months. Right now I managed to get the core technology to work. But there seems to be two classes of bugs that have arisen.

The first is your typical "it doesn't work under certain conditions yet."

The second is a derivative of the first. By this I mean the bug transfers my radio signal from standby to full power. This results in more power being consumed on the circuit board. Also, under some circumstances, it will also increase the amount of data that is sent to and from a socket.

So the question becomes, should I attempt to fix the second part before I move on? Because as it stands, this second part won't actually bring the software side to a screeching halt.

[toc] | [next] | [standalone]

#8917

Chad <cdalten@gmail.com> writes:

> I've been working on a fairly sophisticated piece of software for the
> past 10 months. Right now I managed to get the core technology to
> work. But there seems to be two classes of bugs that have arisen.
>
> The first is your typical "it doesn't work under certain conditions
> yet."
>
> The second is a derivative of the first. By this I mean the bug
> transfers my radio signal from standby to full power. This results in
> more power being consumed on the circuit board. Also, under some
> circumstances, it will also increase the amount of data that is sent
> to and from a socket.
>
> So the question becomes, should I attempt to fix the second part
> before I move on? Because as it stands, this second part won't
> actually bring the software side to a screeching halt.

You should correct all defects in your sources as soon as you detect
them!

The longer you wait correcting defects, the more time consuming it
becomes to correct them.

Greetings,

Jacob
-- 
People in cars cause accidents. Accidents in cars cause people.

[toc] | [prev] | [next] | [standalone]

#8918

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

> You should correct all defects in your sources as soon as you detect
> them!

And you should document them in the form of executable tests you run
routinely as a part of you test suite.

Greetings,

Jacob
-- 
"The problem with America is stupidity. I'm not saying there
 should be a capital punishment for stupidity, but why don't
 we just take the safety labels off of everything and let
 the problem solve itself?"

[toc] | [prev] | [next] | [standalone]

#8919

And this is probably where I don't understand testing as well as what I should. For reasons that elude me, testing under an emulated piece of hardware is vastly different than testing it on the actual piece of hardware itself.

I do have set of tests that I think bridges this gap. However, I don't have any idea if this does in fact brige the gap. And I even am more clueless on how to do the tests. This is because I'm required to program the debugger myself. However, there is no tutorial on how to go about doing it.

[toc] | [prev] | [next] | [standalone]

#8927

[cross-posted to comp.embedded, as it contains questions specific to
 embedded programming]

Chad <cdalten@gmail.com> writes:

> And this is probably where I don't understand testing as well as what
> I should. For reasons that elude me, testing under an emulated piece
> of hardware is vastly different than testing it on the actual piece of
> hardware itself.

Yes.

The trick is to have a good abstraction layer reasonably close to the
hardware.  When you run tests on your development ("host") system, you
use an implementation, which emulates the actual hardware, while an
actual deployment of course maps the abstraction layer to the actual
hardware.

> I do have set of tests that I think bridges this gap. However, I don't
> have any idea if this does in fact brige the gap. And I even am more
> clueless on how to do the tests. This is because I'm required to
> program the debugger myself. However, there is no tutorial on how to
> go about doing it.

If you have an abstraction layer, you can write tests, which verify that
your emulator and the actual hardware behaves in the same way.  Once
you're sure of that, you can use the emulator to perform automated
testing on the host system, so you with some confidence can postpone
testing on the target system.

Greetings,

Jacob
-- 
"Very small. Go to sleep" - monster (not drooling)

[toc] | [prev] | [next] | [standalone]

#8928

On Saturday, June 9, 2018 at 10:59:20 AM UTC-4, Chad wrote:
> And this is probably where I don't understand testing as well as
> what I should. For reasons that elude me, testing under an emulated
> piece of hardware is vastly different than testing it on the actual
> piece of hardware itself.

So you have to step back and ask yourself:
 what is my goal on the emulator?

This breaks down into two main areas: Functional and Performance.
Usually an emulator allows you do basic functional development
before the real hardware arrives. Because an emulator often lacks
the speed of the real hardware, it is difficult and sometimes
impossible to conduct performance tests on the emulator.

Identifying what features and functions the emulator lacks
should go a long way in focusing your testing on the emulator.

> 
> I do have set of tests that I think bridges this gap. However,
> I don't have any idea if this does in fact brige the gap. And
> I even am more clueless on how to do the tests. This is because
> I'm required to program the debugger myself. However, there is
> no tutorial on how to go about doing it.

Is this debugger actually the emulator or a separate tool?

So is this debugger for a peripheral card, a connected device
(say via some network), or a SOC/motherboard. 

An emulator for either of the first two would look very different
from the SOC/motherboard.

So maybe I missed information on an earlier post. Can you
provide a little more information on the hardware you are
emulating and the software being tested?
 
Ed

[toc] | [prev] | [next] | [standalone]

#8929

On Tuesday, June 12, 2018 at 6:47:00 AM UTC-7, Ed Prochak wrote:
> On Saturday, June 9, 2018 at 10:59:20 AM UTC-4, Chad wrote:
> > And this is probably where I don't understand testing as well as
> > what I should. For reasons that elude me, testing under an emulated
> > piece of hardware is vastly different than testing it on the actual
> > piece of hardware itself.
> 
> So you have to step back and ask yourself:
>  what is my goal on the emulator?
> 
> This breaks down into two main areas: Functional and Performance.
> Usually an emulator allows you do basic functional development
> before the real hardware arrives. Because an emulator often lacks
> the speed of the real hardware, it is difficult and sometimes
> impossible to conduct performance tests on the emulator.
> 
> Identifying what features and functions the emulator lacks
> should go a long way in focusing your testing on the emulator.
> 


Yeah. That sound about right. However, the engineers around here use slightly different terminology.

> > 
> > I do have set of tests that I think bridges this gap. However,
> > I don't have any idea if this does in fact brige the gap. And
> > I even am more clueless on how to do the tests. This is because
> > I'm required to program the debugger myself. However, there is
> > no tutorial on how to go about doing it.
> 
> Is this debugger actually the emulator or a separate tool?
> 

I'm really not that sure. 

> So is this debugger for a peripheral card, a connected device
> (say via some network), or a SOC/motherboard. 
> 
> An emulator for either of the first two would look very different
> from the SOC/motherboard.
> 
> So maybe I missed information on an earlier post. Can you
> provide a little more information on the hardware you are
> emulating and the software being tested?
>  

I'm emulating the radio signal on my Wifi. The emulator fails miserably. As for the software, I don't *think* I'm allowed to discuss it's job related.

I'm I being vague enough yet?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web