Serial Communication Take 2

[jbelanger]

Actually, the CAN hardware is already on the TA board (2 transceivers). The issue is to do the software to handle both CAN and serial in an integrated fashion.

I agree that CAN can be left off for a later release and that serial is the important one to get the system working. I don't think it will really be possible to have a unified system for both serial and CAN. However, since the PC will always be the master in any communication it does, the ECU connected to it can somehow act as a proxy for it on the CAN bus.

Jean

[Fred]

The issue is to do the software to handle both CAN and serial in an integrated fashion.

Exactly, it's a software design/architecture thing, hence the firmware section :-)

I don't think it will really be possible to have a unified system for both serial and CAN.

I read somewhere that protocols that try to join other protocols become the worst of both worlds. Increasingly it is looking like that.

Fred.

[Delta]

Communications protocols are my thing

Without knowing exactly what you want or how big anything is - this is my first approximation of what it should look like at a MAC level - ie firmware headers. Assuming some form of stop start is in the hardware.

1st Byte
4bits Destination address - 0000 is always computer - 1111 is always broadcast
4bits Source Address

2nd Byte - Sequence number

3rd Byte - 4 bits length of data frame 1-16 bytes - 4bits Header CRC

Following 1-16 bytes are data

ACK (if you want one - and only for point to point - no ACK for broadcast)

1st Byte same as above - only source/destination reversed

2nd Byte Sequence number same as above

3rd - 4th byte indication of 1-16bytes received without error a 1 = ok 0 = errored (for retransmission if you want it)

5th byte CRC for full packet.

Probably the best I can come up with for the time being without knowing more about what you want to send - how big it is etc etc.

[Fred]

There is a full thread on the currently proposed serial comms spec. The document is a little out of date, but it's fairly nailed down and ready to implement already. This is really to discuss the possibility of CAN and serial and a single addressable protocol. I'm not sure it's a good idea though.

The only things I'll say about your proposal at this stage are :
* single check sum at the END for the whole packet header inclusive. Saves computation time and breaks it up.
* other than flags everything is at least a byte - KISS code masking a byte for 16 addresses is too mcuh work when you could have 256 easily.
* No hardware start stop at the data level, only the hardware level which is not relevant, so we have an escaping scheme.

It would be best if you take your time and read the 15 page thread end to end and the document that Stu started before going any further.

I'm keen to discuss the addressing modes though and how you forsee implementing that sort of thing in software - ie the semantics around it. It's easy to just chuck some addresses in, less easy to define how to interact with them I guess.

Fred.

[Fred]

I've started documenting the implementation of the serial code in an open doc file. I thought that I should clarify it before I went ahead and developed the code. That way it can be criticised here and save me some work :-) If I think it through and articulate it first it should be much more straight forward to code up too.

I've decided that because the cost of checksumming is so low and also because it is most convenient all packets will be checksummed as part of reception and transmission.

Basic transmission will cover start, stop and escaping along with checksumming.

What we do with headers and content etc is entirely independent of that. This is nice for many reasons, but foremost at the moment, it means I can start work on it tomorrow morning.

I'll put some more work into the document tonight and post it up here. Perhaps I can put some work into the serial spec docs too and release them again.

Fred.

[Fred]

Sorry no time to work on the spec doc tonight. On the implementation doc I did complete the send section for now, but it is a bit rough. Bear in mind that this stuff is fairly basic and straight forward, I'm just wary of rushing headlong into coding something that a lot of people will potentially use as developers in the future without it being crystal clear first. I can't help but think about the huge pain that David and others faced when trying to develop for the then totally undocumented "RTFSC" ms serial "interface". I don't want to be a part of creating a similar situation now, so docs come first for this aspect and for good reason. It needs to be right, and it needs to be crystal clear for everyone. What goes on in the code on each side of the comms is irrelevant, but the interface MUST be clean.

File attached for your perusal.

Fred.

[jharvey]

So when you say start byte, do you mean like a barker code?

http://en.wikipedia.org/wiki/Barker_code

Have you setteled down on a start byte yet. You say byte, so it seems you're going for 8 bit 2 nibbles, ect.

[Fred]

No I don't, the hardware takes care of that stuff. This is to identify where in a valid stream of data bytes the packets start and end reliably. Just a random value between 0 and 255 as already chosen and specced in the other thread/doc you should read if you haven't already. It does say that that is a prerequisite ;-)

Fred.

[jharvey]

And what make you think I can read? I'm sure you've noticed I can't spell or write.

I've got lots to read up about here. I'll likely go a bit more silent for a while. Lot of catch up, and I'm also a bit slow when it comes to software.

[Fred]

And what make you think I can read? I'm sure you've noticed I can't spell or write.

LOL, I did notice that you used e instead of a somewhere other than than the other day. I guess it's an accent thing for you. I know I screw up pronunciation and spelling of things that I learned via spoken word. Anyway, fair enough, get on with it :-)