Serial protocol pre-design discussion - give us your input!

[FlappySocks]

Here is my response:

4. "Too much to read". Also a proposed solution to stay constructive: Organize the options, arguments, opinions, etc in a dedicated place (a simple structured doc or a wiki) and keep forum thread(s) separately from this doc. To make one read through the whole discussion to understand where we stand is asking too much, which may be what discourages people.

Alex

Hooray! Another vote for a wiki

I'll comment on the other bits later.

Stuart.

[Fred]

But a wiki isn't the place for a detailed discussion about all the minute details that bit by bit should wind up in that document. Their could be a wiki later about the documents contents and various impacts of it etc. A wiki is a place you put facts (or what you think are facts). I want to discuss ideas with you and others first rather than just edit your work away and replace bits of it with mine without knowing if that is a good idea or not. You could replace the OO doc with a wiki. But you still need a place to talk about what goes in it.

Thread = discussion. (even if its just me and you :-) )

If it is just me and you we can do it via email if you prefer that medium?

Admin.

[ababkin]

Hi, since i was just made feel bad by certain someone for not contributing...

...I'll try to contribute.

In my opinion, one way to approach design of this is to defer it as much as we can.
Here is my proposed strategy on how to defer it:
1. Create and finalize a solid high level comm part of the comm stack, which will be like a front-end for EMS comms, and which will not change (hence finalize).
2. Create a very simple and potentially unreliable set of lower comm stack slices compatible with the high level stack slice in #1
3. Use this stack for the time being

Cheers
Alex

[Fred]

I'm sorry if I made you feel bad Alex :-)

Thanks for sharing your views.

Now we have you saying "leave it as late as possible by starting at the top and working down" and Stuart saying "design it first and get the details right from the out set" and me agreeing with Stuart.

Because you both want a wiki page :

http://freeems.wiki.sourceforge.net/Fre ... ol-Layer-1
http://freeems.wiki.sourceforge.net/Fre ... ol-Layer-2

Enjoy :-)

Right, back to discussing what to put in it. I made it fully public so it's susceptible to vandalism, but I doubt any will occur. If it does, I'll have to add users etc...

Admin.

[FlappySocks]

1. Create and finalize a solid high level comm part of the comm stack, which will be like a front-end for EMS comms, and which will not change (hence finalize).

That sounds like Part 1, which I said previously should be cast in stone very early on (although I would call it low level, not high level).

2. Create a very simple and potentially unreliable set of lower comm stack slices compatible with the high level stack slice in #1

Part 2. This document will always have finalized and unfinalized parts to it.

[gearhead]

Also feel bad as I am not contributing here, either...

Personally, a very simple comms protocol works for me. I have not had comms problems in my MS life. I killed 2 MS1 chips, but that was user error with a power cycle during burn because I was impatient waiting for the download.

Highly defined commms protocols, IMO, are a hedge against poorly designed or highly variable systems. We know what we have electrically and software-wise and whatever will be hooked to it will also know what to expect, right? Confirmation of a burn is interesting, though not absolutely required, IMO. I mean, it is not like I will loose a few years of my life to go back and doublecheck that a burn did occur.

$0.02,

Gearhead

[FlappySocks]

Would you prefer Flappy, Stuart, or Stu? (or any other nick name? I'm a fan of nick names )

Most people call me Stu, but I dont mind. I am known as FlappySocks on some of the BMW forums.

I checked out the ASCII for those double letter hex codes and none are standard codes but none are common chars or control chars. At the opposite end, if we use FF to XOR them (keeps it a double banger after XORing) 0xAA gives a 0x55 which is 'U', BB gives 0x44 which is 'D', 0xCC gives 0x33 which is '3', 0xDD gives 0x22 which is '"' and the rest give control chars. For this reason, I vote 0xAA for start, 0xBB for escape and 0xCC for stop with XOR via 0xFF (to produce 0x55 0x44 and 0x33). Unless we forget being able to see them in a stream and go with Keith's plan of using some visible start char, and a newline for end?

Happy with that. I think if your going to be debuging the stream, you would be looking at it in hex bytes, and not ASCII.

If we did want to have a console mode for simple quick by hand testing I think it would be best to do the swap n switch system and have dual protocols. If we do that, the "query" needs to be compatible with both such that you can tell first up which you are dealing with and/or the version of it etc. Some aspects of Keith's "readable" protocol might be a good idea here if we go ahead and do 2. I personally don't like the idea of having two sets of code to do one job though. But, I do like the idea of a simple access mode for testing and/or basic devices that want to be dumb. Perhaps the simple mode could give access to only the core values and none of the extra/intermediate stuff in some fixed format?

I build console modes into lots of my applications. However, having given it some thought, on this project, I cant really see much point. There is far too much live data being thrown out at you... your just going to want to find your copy of "Megatune" (for want of a better description), and use that.

Could you provide C code for stretchy integers / "BER compressed integers" so we can either put mtx_man's mind at rest or avoid using them. (trying to get some decisions made and work towards an end).

Sure.

Could you also comment on Karsten's ptp idea?

PPP? PPP could replace "Part 1" of my doc, but not "Part 2". I feel that PPP is a bit of an overkill really. It's more session oriented than I feel is necessary. Must say, I have only ever been a user of PPP - never developed with it, so i'll just have to go with my intuition on that one.

More comments later.

[Fred]

Highly defined commms protocols, IMO, are a hedge against poorly designed or highly variable systems.

I don't understand this, can you reword/clarify please?

We know what we have electrically and software-wise and whatever will be hooked to it will also know what to expect, right?

I agree with this by and large, but it's not a matter of what should be coming, it's a matter of the difference between would should be coming and what IS coming. This has proved to be troublesome to many people for many reasons. Many laptops don't support full speed, and rs232 can generate framing errors etc quite easily. Also, when the car is running there could be other electrical noise and interference around. This is something to reduce the support load as much as it is to have peace of mind ourselves. If a user has a red flashing light saying "do it again numb nuts" then you won't get a "I burned my table and the values didn't stick" message. You may instead eventually get one that says "I keep getting comms failures obviously my serial adapter sucks, what can I do about it?" which is infinitely easier to answer. Also far less frustrating for the user IMO.

Confirmation of a burn is interesting, though not absolutely required, IMO. I mean, it is not like I will loose a few years of my life to go back and doublecheck that a burn did occur.

That depends on how often you are doing it. If you care, that should be every time. If you have a single error once, you will do it every time there after from fear... Don't you want to not have to worry/think about whether the PC did what you wanted or not? Just have it work? and in the case where it doesn't, it will let you know?

I only want to code ONCE. That means design first, code second, code right the first time.

Simple yes, effective, also yes.

Admin.

[Fred]

Thanks Stu, I'm looking forward to it. I have to admit though : I may not see it till tuesday :-) I'll be in Holland and Germany at a Nurburgring track day over the weekend. Flights were half the price monday night and friday morning, so long weekend for me :-)

Admin.

[ababkin]

I'm sorry if I made you feel bad Alex

Thanks for sharing your views.

Now we have you saying "leave it as late as possible by starting at the top and working down" and Stuart saying "design it first and get the details right from the out set" and me agreeing with Stuart.

Because you both want a wiki page :

http://freeems.wiki.sourceforge.net/Fre ... ol-Layer-1
http://freeems.wiki.sourceforge.net/Fre ... ol-Layer-2

Enjoy

Right, back to discussing what to put in it. I made it fully public so it's susceptible to vandalism, but I doubt any will occur. If it does, I'll have to add users etc...

Admin.

updated the first wiki (need only one for now IMO)

I am also for designing things once and never touch again, but we live in the real world (i know i became quite cynical lately). Deferring this will give opportunity to concentrate on more fruitful parts. Also once all "fruitful" parts are more or less finalized, we'll have better idea about the best way to implement these lower comm layers. (i can see things like the time period of the main loop, for instance, affecting the comms implementation. Or what if we decide to push the lower layers of comm on to the XGATE cause the main core is overloaded with more important stuff? see what i mean?)