I disagree. There is just no way that you are going to want one variable at a time, and even if you did, you would need a pause in between to know which byte was which. If the bytes are one after the next, where is the type and where is the value? Hence the packetising in the first place that Stu was nice enough to draw up for us some months back. Just for example, MS uses about 112 bytes for the basic stuff. I just added up the current basic variables and they come to 27 * 4 bytes total. Regardless, at 100 bytes, 14 bytes of start, stop, header, checksum, escape is not really that significant, esp when it guarantees you accurate data. Then you'd also want some sort of time stamp etc in there too. So call it 100 for now for the purpose of conversation. Past that, same goes for debug, you are going to want say "all the runtime vars" or "all the counters" or "all of the latencies" etc. At the 100 mark you are going to want data integrity for the packet, and the cost of it is low enough IMO. In fact, the larger the packet, the lower the cost of it at the end of the day, so sending in little bits is probably a bad idea and will increase overheads a bunch.EdG wrote:in the case of just having runtime information out of the ECU, you're going to want it with as little overhead as possible (small 'packets')
The last two are effectively the same.For now, it appears we want the serial comms to:
Download flash block data for programming.
Code debugging of variables.
Runtime system information (for display/datalog/tuning)
We want to :
Send data to memory while tuning
Tell it to burn memory to flash when tuned
Send data straight to flash for config and sensor calibration
Get logging/realtime/debug/etc live data out
Get previous config and tune out
Tell it to reset
And a million other things :-)
That is the goal :-) As with everything it is a compromise though right. What you see as best and what I see are bound to differ :-) The trick is in coming to some agreement in the middle ground and getting on with it.I'd say keep that in mind & engineer the serial comms to do just that, and as efficiently as possible.
I'm half inclined to agree and half inclined to disagree. Certainly it's not a big thing to add later as it only affects the IF in dealing with a packet or ignoring it. Without that all packets will be dealt with.Making the serial link part of a higher level network, where the ECU is one of many addressed devices, to my mind, isn't necessary. Certainly not at this point.
But it is a certainty that there will be a datalogger, and a display attached, and maybe a wideband and extra PC and IO extender etc. I don't think it will be that difficult to cover those bases now, we just have to be very careful to make sure I don't muddy the line between protocol and application. As it stands I think I may have already and that may require a bit more work to redefine what is mandatory and what is application dependent.If that becomes obviously necessary at some later time, when other 'nodes' are present, then extend or rewrite the serial protocol then, though I suspect it may never be necessary.
Well, I've realised that to "just forward" a packet onto CAN will be tricky, SO, I've pushed that out to the tuning authors and other CAN authors to deal with by saying that you can send a freeems serial packet with ID = CAN fwd and the first X bytes are the can ID and parameters and the balance is data to be sent or similar.If you had, say 5 different devices in the car, networked via CAN & wanted to plug your serial cable into any one of them to tweak your ECU tune, then fair enough. For now, KIS :)
The trouble is, if you ditch it, you pickup other overheads like multiple false starts etc. If you can almost guarantee that a start IS a start you will waste less time getting synced in.I agree with the point about the ESC start assuring you of a start condition, but there will only ever be a transmitter & receiver on the serial and I think it's an unnecessary overhead.
It isn't my idea, it's Stu's idea (a fellow POHM (http://www.diyefi.co.uk)) but I do like it and I think it should stay unless there is a compelling reason not to have it. After all, whatever is in all of our best interests is what I want to have.
Well, let's look at it :That's just my take on it. In short, I'd go for less overhead at this point, rather than more.
start - gotta have it unless you use time and quiet periods to determine start.
flags - probably want some for various things regardless of design
source - only for promiscuous serial use
dest - only for promiscuous serial use
ack - only for some packets, but flagging it in and out seems more trouble than it's worth
payload ID x 2 - gotta have it
payload Length x 2 - gotta have it
escapes (x3 on a typical 100 byte packet) - if you have start, you probably want this, plus, low cost, and extra error checking
checksum - gotta have it
stop - not strictly required as you could base on length and checksum etc but keeps the code isolated and clean.
If you ditch the escape/start/stop scheme, you instantly push a bunch more logic down into the lowest layer. If you keep them, the only things the low layer must know about are those three bytes and what they mean. I have it setup to check the checksum when the stop byte comes in so that if flagged it is definitely a goer, but that could be moved out to main loop flag handling too.
I've looked at it, but I don't like it and think it would be a headache to try to align with that. I also don't see any value in trying to fit in with that on a data level. However, if we keep the ability of the serial side open to do almost anything when forwarding CAN packets then we can communicate with whatever is out there using the EMS only as a bridge. For personal CAN use, I think either custom, or aligned with the MS spec in some fashion is the best idea. I'm not sure what the MS spec is like though, it could be that it's a dirty standard that I don't want to align with. Either way, the CAN hardware and network of local devices feature is a nice thing to have, and there is after having thought about it quite a lot, no reason to think about that now at all. The only thing we should think about is having the ability to pass messages on verbatim using a special call.As for CAN, is there some standard you intend to be compatible with? I found references to J1939. Is anyone looking at that right now?
Try Controller Area Network :-)('CAN' isn't the easiest thing to search the forum for!)
I trust you saw your name in that doc?
Thanks again for your input :-)
Fred.