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

Groups > comp.arch.embedded > #28290

Re: How to transmit the value of an enumeration

Show all headers | View raw

On 26/10/18 01:38, Joe Chisolm wrote:
> On Thu, 25 Oct 2018 09:31:47 +0200, David Brown wrote:
> 
<snip>
>>
>> I can't help thinking this is extremely inefficient, and completely
>> unnecessary.
>>
> 
> 
> switch(t) {
> case TYPE_1 ... TYPE_100:
> 	out=table[t];  // table being defined for values of t in the range
> 	break;
> case TYPE_101 ... TYPE_256:
> error_log();
> break;
> default:
> worse_error_log();
> break;
> }
> 
> Even having
> 
> case TYPE_1:
> blah
> case TYPE_2:
> blah
> ...
> case TYPE_101:
> case TYPE_102:
> case TYPE_103:
> error_log();
> break;
> default:
> worse_error_log();
> break;
> }
> a good compiler is going to roll all that together.

I have several points here:

First, my biggest concern about efficiency is /developer/ efficiency.
Writing endless realms (the second version) of unnecessary "translation"
code is a big waste of time and effort - and a very easy source of bugs
and maintenance problems, especially copy-and-paste errors.  Even with
the case range version, you still have the table to define.

Second, there is device efficiency.  Not everyone has good compilers -
and not everyone with good compilers is able to use them correctly.
Sure, many of use use mainly gcc with its useful extensions and solid
optimisations.  But others have to use weaker tools, or (for good
reasons or bad reasons) stick to restricted subsets of the language, or
use cpu cores for which there really is no efficient way to handle such
code.  And a depressingly large proportion of embedded developers work
with little or no optimisation because "optimisation breaks my code"
(i.e., they don't properly understand the language and how to code it).

Third, you are adding an extra layer for developer confusion.  Instead
of "message types" that everyone can agree on, you now have "message
types" and "message implementation types" which are different and
confusing.  Imagine the conversation between the server programmer and
client programmer trying to figure out a problem:

"There's a problem with message 3."
"Is that /your/ message type 3 or /my/ message type 3?"
"I don't know, maybe it is protocol message type 3?  I just got an error
message saying there was a bad length for message type 3."
"When I looked in the debug log, it said type 7."
"But the value shown in my debugger was type 73 when the breakpoint hit."
"There is no message type 73 - something has gone badly wrong.  No,
wait, did you mean /your/ message type 73 rather than /my/ message type 73?"


You are trying to over-engineer a very simple situation.  Write the
message definitions /once/, simply and consistently.  Don't write
translation layers unless you actually need to translate things.

> 
>> In reality, in a small system you might have perhaps a dozen different
>> message types - "protocol types".  Make an enum for these.  Make
>> documentation for them (which will use the real numbers).  Have a little
>> static assert at the end of the enum definition to make sure you have
>> not missed one out by accident.  Put the enum definition, and other
>> protocol-related common declarations, in a single header that is shared
>> by both the client and server sides.  If the client programmers and the
>> server programmers get mixed up versions or make their own independent
>> changes, fire the project manager (not the programmers).
>>
> 
> And eventually this gets shipped and you have a customer with version 1
> box talking to a version 2 box talking to a version 3 box because they
> dont want to update all the boxes at the same time.  

I said in an early post in this thread that you want to add protocol
version numbering, and several others have confirmed that as a good
idea.  Message number 1 in any protocol should be a handshake or
"helo/ehlo" to establish compatibility of protocol versions, software
versions, etc.


> The protocol
> handler is a black box that you can unit test with a reasonably robust
> test harness.  That test suite validates the protocol and gives you a
> known base.  Transmitter test vectors are compared against receiver test
> vectors.  Once built these test suites only have to be changed if the
> protocol changes but get used in verification for each release. If it
> is duplex you have a->b vectors and b->a vectors.
> 
>> All this extra code - the endless unnecessary declarations of "spare"
>> values, the vast useless switches - they are nothing but magnets for
>> errors, typos, copy-and-paste errors, maintenance nightmares, and are
>> going to be completely untestable.
> 
> That's because you live in the old world of actually typing all this
> stuff in.  You have abundant tools at your disposal to create this
> code.   You have a  input file of some type, a state diagram or other
> "document" for the protocol and your tools auto create the code from that.
> The make file auto generates the headers and code.  Hell, even lowly
> awk can generate code for you.  20 years ago we were using simple
> tools to take register definition files and spit out VHDL and C 
> headers and functions. We did the same thing with a CAN bus protocol.
> This is robot work, make the computer do it.
> 

I can automate code generation fine - I do so when it is useful.  I
don't do it when it is unnecessary, and I don't use it as an excuse to
add extra layers in the design instead of getting /one/ layer correct.

In an ideal world, you may be defining your protocols using some
high-level tool that automatically generates your code.  Very few
embedded programmers live in ideal worlds - many are going to do this by
hand.  And many more are going be handed existing code that came from
somewhere else - perhaps another developer who left the company years
ago - and be asked to "just make this simple fix" or "just add this one
extra message type".  Imagine you no longer have a copy of the original
state diagram files, or the software for generating the code.  Or
imagine that you /do/ have these, but somewhere between the last run of
the tools and the current state of the code, someone manually changed
the code because it was faster and easier than going through all that
"UML nonsense".  This is reality for many people.

So do not make things more complicated than they have to be.  By all
means make layers and black boxes when they make sense, but don't add
them "just in case".

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

How to transmit the value of an enumeration pozz <pozzugno@gmail.com> - 2018-10-24 13:18 +0200
  Re: How to transmit the value of an enumeration Jack <jack4747@gmail.com> - 2018-10-24 04:45 -0700
    Re: How to transmit the value of an enumeration pozz <pozzugno@gmail.com> - 2018-10-24 15:18 +0200
      Re: How to transmit the value of an enumeration David Brown <david.brown@hesbynett.no> - 2018-10-24 17:05 +0200
  Re: How to transmit the value of an enumeration David Brown <david.brown@hesbynett.no> - 2018-10-24 15:10 +0200
    Re: How to transmit the value of an enumeration pozz <pozzugno@gmail.com> - 2018-10-24 15:27 +0200
      Re: How to transmit the value of an enumeration David Brown <david.brown@hesbynett.no> - 2018-10-24 16:59 +0200
      Re: How to transmit the value of an enumeration Clifford Heath <no.spam@please.net> - 2018-10-25 08:57 +1100
  Re: How to transmit the value of an enumeration Joe Chisolm <jchisolm6@earthlink.net> - 2018-10-24 12:48 -0500
    Re: How to transmit the value of an enumeration pozz <pozzugno@gmail.com> - 2018-10-24 23:20 +0200
      Re: How to transmit the value of an enumeration Joe Chisolm <jchisolm6@earthlink.net> - 2018-10-24 22:21 -0500
    Re: How to transmit the value of an enumeration David Brown <david.brown@hesbynett.no> - 2018-10-25 09:31 +0200
      Re: How to transmit the value of an enumeration Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-10-25 09:58 -0700
      Re: How to transmit the value of an enumeration Joe Chisolm <jchisolm6@earthlink.net> - 2018-10-25 18:38 -0500
        Re: How to transmit the value of an enumeration David Brown <david.brown@hesbynett.no> - 2018-10-26 09:24 +0200
  Re: How to transmit the value of an enumeration George Neuner <gneuner2@comcast.net> - 2018-10-24 15:19 -0400
  Re: How to transmit the value of an enumeration Les Cargill <lcargill99@comcast.com> - 2018-10-26 20:30 -0500

csiph-web