I can hear that is an opionion of yours.

Once more you post a comment without any reference to let anyone know what text you are referring to (you basically quoted a full post there).

Don't believe that an alarm panel can be complex? Alas, google normally only shows user manuals, not the installation manuals. But this is a link to an installation manual for a quite small alarm. There are panels with way more complex keypad programming...
http://www.mainelectronics.com/pdf/PC155...nstall.pdf
This little one has 97 main function codes, but several of them branches so I stopped counting at +250 unique valid alternatives that needs testing. Real figure might reach 500. And this is not a large alarm panel.

I didn't do the above, so it doesn't matter if you believe anyone but me would consider doing one. Someone else most definitely already have. If that was what you meant with your doubt.

Or maybe you did mean test also invalid combinations? Not sure about the alarm panel manufacturer who did the alarm I linked to. But I'm pretty sure all manufacturers of products that gets programmed by a keypad tries to test all invalid paths too. If they don't then they would be incompetent. If they miss a couple of paths, it would be bad luck, but I'm pretty sure they have tried to find them all.

Or maybe you doubted the part about number of states of an FSM not really being a factor controlling the complexity, but the number of interconnects?

for (;;) {
    switch (state) {
        case ENTER_FIRST_FIELD:
            eval_new_state(get_field(data[state]));
            break;
        case ENTER_SECOND_FIELD:
            eval_new_state(get_field(data[state]));
            break;
        ...
        case ENTER_BILLIONTH_FIELD:
            eval_new_state(get_field(data[state]));
            break;
        case FINALLY_GOT_THEM_ALL:
            process_fields(data);
            state = ENTER_FIRST_FIELD;
            break;
        default:
            state = handle_invalid_state(state);
    }
}

Now - that state machine had a billion and one states (and hefty memory requirements). Obviously without any real complexity. Still doubting?

So what are you doubting?

That anyone but me would use CRC32 in an 8-bit processor?
Read: http://www.ece.cmu.edu/~koopman/...rithms.pdf

That anyone but me would use CRC32 in a protocol used by 8-bit processors? How about the ZMODEM protocol?

You obviously can't doubt the use of the term "test harness" as used for helper code to module test software? I didn't count off some random Google hits. I did end after having linked the first 6 hits. But the list could have continued.

Doubt anyone but me would use the term "test vector" for anything but digital, physical, signals to hardware? I'll admit that while the the use of "test harness" is mainly relating to software, "test vector" is more used about hardware. Anyway - a tool that does scan source code to create a test harness to run test vectors on it:
http://www.vectorcast.com/software-...esting.php
You can even download a 30-day trial edition. Then your random wild card doubts can at least be expressed a bit more specifically.

Need test vectors for the floating point library? http://www.eecs.berkeley.edu/IPRO/Soft...e.754.html

I have test vectors for Modbus (a yes - the serial port you so much doubted in a previous post).

Or maybe you doubt that lookup tables grows faster than the corresponding code when the number of conditions to react to grows? Look at page 7 of the link I gave about about CRC32. The bit-shift loops needs almost no space. The table lookup requires lots of space. Not applicable? Yes, it really is applicable. Exactly the same thing happens for a large percentage of traditional FSM. And exactly like the CRC32 document, you can create hybride solutions where you factor the large state table into smaller tables while adding extra code lines. Having a single large lookup table, you need to index on everything that may ever affect a state change. Having a switch statement (or jump table or similar), you can have multiple smaller state tables based on the (often very much smaller) number of input + memory states that may result in a state change. But that fully factored solution will often degenerate into full source code without tables because the code needed to combine a lookup index will often be of similar size to the code that actually perform a state change, negating the use of the table.

The main advantage of lookup tables are speed. But they often come out at a loss when comparing size because of their quick growth rate.

Maybe you are doubting the use of a state machine or history to process battery voltages? You give me too much credit if you think I would be the only one thinking about such a solution to figure out what is noise from varying load, what requires a charge cycle to start and what should result in an alarm that the battery is broken.


Once more a complete bull sentence. An attempt to misdirect. Why do you feel this need to misdirect?

You have still never seen any of my code. So why are you still again, and again so constantly convinced that it is huge and convoluted. And your code for the same problem is to nice and tiny? But think again about what you said. If my code would be bloated and convoluted, then it would be in big need of good testing. So why not follow through with some of the potential fallouts your reasoning - maybe I do have a couple of good ideas about testing?

My guess is that you read the first two words of every sentence, or maybe the first sentence of every paragraph. Then you assme you know what the text is about and switch to output mode. Alas, you often guess wrong, so it would be better if you did read at least the full texts you quote before writing a response.

Unless you run a JTAG interface - or support monitor commands using a serial port - you would have a huge problem to use an external test vector generator, in case the tested equipment has an internal, battery-backed RTC. Remember what happens with an RTC when you use a test vector to reset the processor? Exactly. The RTC will continue to tick. So when you play your vectors, you can't know the internal time unless you manage to read LCD data - if the subject do have an LCD to display the time.

You have several times said that you have never written a state machine that requires the use of memory variables. Not only that, but you seem to think it extremely unprofessional and strange if someone would need such a state machine. An alarm panel would store huge amounts of configuration in EEPROM. If that EEPROM is internal to the chip, you can't have the external test equipment force known programming states. Unless you have a JTAG interface. Or you drive that keypad (the one with the huge number of command sequences that you doubted anyone would every make). But many non-trivial alarms wouldn't just keep configuration in an EEPROM (or flash or other nonvolatile memory). They would also store log information. In some situations, it's just for alarm call-in or post-mortem dumping of information. What sensors did the system see alarming during the burglary? But in some situations, it's calibration data to adapt. You can have sound sensors ignoring normal talk, but that trigs an alarm as soon as someone screams. Temperature sensors that ignores slow temperature changes from the sun but trigs an alarm from a quick temperature envelope of a fuel flash explosion.

Self-adapting systems can be seen everywhere. Speaker phones does echo cancellation. Car ignition systems adjusts the allowed range of fuel-air based on knock sensors, meaning some cars runs absolutely lousy for the first miles after you have removed the battery. In embedded, you may often have to work with "standardiszed" protocols, where the different manufacturers have "understood" the protocol differently, or have added their own "improvements". So the code have to look at minor details in timing and message contents to try to figure out what dialect to autoadjust to. And in some situations, you don't know until you have already failed so you need to store "score info" to try better guesses on the next message or next communication session.

But based on your comments, such things does not exist. Or would only exist if someone very perverted did create them.

I did write previously:

And you really do prove how right I was with your:


You never write: Why would you do like that?
You never write: Would that work?
You never write: Do you have some references?
You never write: What would be the advantage?
You never write: But wouldn't it be better if you [...]
You never write: I have tried that, but prefer to do xxx because [...]

Why is that? It seems like you have always (20 years ago) decided that whatever method you don't use can't work or don't exist or is just bad. Never once do you show some interest in alternative routes. Not only are you not interested in learning more about them, but you are putting on blinders and trying to pretend they don't exist.


Please do. But then try to be specific enough that it is possible to know exactly what you mean.