Serial Communication Take 2

[Fred]

Here is another version of the imp doc, this time in pdf and generated by star office instead of open office. It's got one more section, and some changes to the wording in both of the other two. Hopefully soon I can fill out the other three sections as I pull everything together.

Fred.

[jharvey]

I just converted the released FreeEMS-serial-spec-v0.4, as PDF. It's the same thing as the zip, however, now I can read it at work on lunch.

[jharvey]

I've now at least skimmed the part 1 and part 2.

You are contemplating changing from all ASCII to binary correct? Do you think it's feasible for both? ASCII is handy for human readable, debugging, ect, however you may be pushing through put limits with ASCII. The binary should decrease time for firmware uploads, map file uploads, ect, but you only do them every so often. Likely more often then not. How about binary for the large files, and ASCII for traffic of a slower nature? Perhaps a header bit can signal if it's binary or ASCII.

You haven't specified the type of CRC yet, right? Can I recommend MD5, it seems fairly light weight, and well tested.

Also yes CRC the header, increases data integrity, MD5's are so fast I don't think it will slow down the through put significantly.

I think we are looking at two types of traffic really, bulk and block. Perhaps we want CRC on bulk and not on block. Or perhaps only on some block packets. I'm picturing some one using the serial spec to get data to say an RPM gauge. A small blip isn't a big deal, so is CRC a big deal... I think we have enough power at the brain to create it, and we don't need to use it at the device end, so I think I'd lean to create it, but remember we may want to strip it as we start to push the limits of the CPU.

Any how just 2 cents. Damn inflation went up, it's now only 1 cent.

[Fred]

Thank you for your 2c, inflation went up again and you now owe me another 1c :-p ;-)

I'm sure you'll pay up soon :-)

ASCII was a very short term hack to test serial and get some data out to a console. There are a stack of reasons why we can't use ascii long term unfortunately.

MD5 is great, but it's also 128 bits, so it also is no go. There was discussion on this, and we all decided that an 8 bit basic checksum was sufficient for our purposes.

As with delta, see the old thread and have a good read there.

Fred.

[Delta]

Alrighty after reading through the old serial thread and this one fully I only have a few small suggestions. If this protocol is to be extensible it must have the ability to address multiple devices on one bus (for CAN) yet be small enough to not take up huge amounts of bandwidth. All I would add to the current setup is to have a destination and source address right after the start byte.

Then it comes down to if you value cpu cycles or serial bandwidth. Lets say the EMS is device 0 always. And the Computer is device 1 always and device -1 (last value in unsigned int) is broadcast.

For CAN -
If you say I only need 15 devices max then 4 bits is fine so you have 8bits for source/destination. In the EMS you only have to do a simple AND 00001111 and compare to zero. If true its for you. Then if needed you do an AND 11110000 and compare the value to get the source. This uses a few cycles to compute but its not that bad.

If you want more than 15 devices then 8 bits each for source and destination and it will do a compare to zero for destination. But of course this uses up another 8 bits of bandwidth per packet over the previous system.

For serial its easy, you only have two devices on the line and its easy to tell which is which so no need to do anything unless you want forwarding to the CAN network (the source and destination can be left blank or filled it doesn't matter). If you want forwarding then the EMS after doing a comp to zero if its for it, it gets it, if its not for it it copies the buffer to the CAN buffer to be sent. Simple.

Considering in future it would be good to be able to interface the EMS with a GMS (gearbox management system) and a BCM (Body control Module) as well as the usual dash modules loggers laptop etc, I think having the addresses would very much come in handy - AND that setting some default values would be a very good idea - 0 = EMS, 1 = Computer, 15/255(4/8bit) = Broadcast, Perhaps 2 = GMS, 3 = BCM, 4 = Logger, 5 = Dash then user values or something.

[jharvey]

The header still has 4 bit left to designate right. Could these header bits be used as address bits? Also could EMS be 0000 and perhaps 1111 could be an expandable address, followed by another byte that is not common to other frames.

[Fred]

If this protocol is to be extensible it must have the ability to address multiple devices on one bus (for CAN) yet be small enough to not take up huge amounts of bandwidth. All I would add to the current setup is to have a destination and source address right after the start byte.

Excellent, I'm glad you approve. I really need to bring the protocol spec up to date, so I'll look at doing that on the way home tonight.

Then it comes down to if you value cpu cycles or serial bandwidth.

I value code readability as absolute number one. Any performance issues should be worked out later if there are any. Thus, for the address, 1 byte each is the way to go.

Lets say the EMS is device 0 always. And the Computer is device 1 always and device -1 (last value in unsigned int) is broadcast.

I have a fetish for unsigned ints :-) I say 0 and/or 255 should have special meaning (eg broadcast), and other arbitrary numbers should be assigned to devices. Perhaps we could use some half way mark as PC = 128 or 127 and 1 as the default ECU address? This leaves room for both controllers and controllees to have sequential ID's

This uses a few cycles to compute but its not that bad.

I understand, but it is slightly more ugly and for 8 bits benefit is barely/not worth it.

What I'm looking for with regards addresses is the semantics of handling and setting them etc. For CAN fwding I think a full packet wrapped in a serial packet is a good idea, perhaps something like :

<start><normal header with function ID = fwdtocan><can address><entire can packet with full headers etc><escape><stop>

There are a few ways you could do that, and I need to spend more time thinking about it.

I think having the addresses would very much come in handy - AND that setting some default values would be a very good idea - 0 = EMS, 1 = Computer, 15/255(4/8bit) = Broadcast, Perhaps 2 = GMS, 3 = BCM, 4 = Logger, 5 = Dash then user values or something.

Agreed, we just need to sort out what they are.

Thanks for your input, I appreciate it!

Fred.

[Delta]

I prefer unsigned ints/shorts too this is why I use -1 (I'll explain)

if you do this

unsigned short blah = -1;

then you actually get the largest value it can hold (255 for 8bit). In general for most networking protocols the broadcast address is always the last address and in software everyone instantiates their packets with a destination of -1 so unless you explicitly set a destination its automatically a broadcast packet. Things are done this way because you are meant to define your variables for source and destination in the headers to be an exact size - 8bits - 16bits - 2 bits what ever, since you use unsigned ints for these variables setting to -1 ALWAYS gets you the highest value - you don't have to remember if its 255 or 15 or what ever - you just KNOW that -1 is broadcast.

Perhaps its just because I've been around networking software too long hahahaha.

[Delta]

If possible I would look at the addresses for serial and CAN or what ever else you end up using (within reason) like a bridged system - And all addresses are across all communications subsystems. If a message arrives for the EMS it doesn't matter if it arrives via CAN or Serial - if the address is the EMS's address then its for it if not its for somewhere else. If it needs to cross the interfaces at the EMS then what I would do is have a simple packet like you had - but only to start or stop a bridge event - ie have a packet thats something like

<start><source><EMS as dest><escape><bridge start><destination><stop>

All the info you need is there. The EMS then has a small list of forwarding addresses
So lets say the table looks like this

FWD_TABLE
Source Dest
Then somewhere along the way it receives

<start><1><0><escape><bridge start><5><stop>
The table is now

FWD_TABLE
Source Dest
1 5

Later it receives

<start><1><0><escape><bridge stop><5><stop>

So the table would be empty again

I think thats the best way I can explain it.

Obviously then if ANY interface receives a packet with address 5 as dest and address 1 as source it copies it to the other interfaces buffer (but since the addresses span interfaces it will only ever be in one direction). Until the table is emptied of that forwarding entry. I personally think any broadcast packet should be forwarded, however with this system you could possibly waive that and have it so that only broadcasts from specific addresses are allowed to propagate to the other interface.

[Fred]

With regards the -1 thing, I fully appreciate what you are saying there, and it will keep the code portable across protocols, however one thing we are trying to do here is nail down a firm defined standard. That standard is going to include address sizes as well, and thus we should define the broadcast address explicitly. All that being the case, we should probably use zero as the broadcast address as that will still work in more cases than the -1 approach (-1 stored into 8 bits and then sent to 16 will yield a wrong result.).

As for the bridge thing, good discussion there. I need to chew it over more, but I think you are right about not wrapping it and just handling it differently. Good call there. The thing is, if a message comes in on CAN then all the other nodes have by default already seen it, so it should only be forwarded out the serial side.

I guess that is totally fine.

Code: Select all

If(address ours){
    handle the packet();
}else{
    fwd the packet on CAN transferring the address from out of the packet and putting it into the CAN address registers();
}

and similarly but reversed for CAN > serial.

That works, I like it. I'll get on with :

A writing it up in 0.5 protocol spec
B beginning implementation and documenting that in the imp doc

Thanks!

Fred.

(ps, enjoy your new colour)