search

cvra / can-bootloader

The bootloader used to flash our CAN-connected boards
BSD 2-Clause "Simplified" License
146 stars 51 forks source link

Write command #6

Closed Stapelzeiger closed 10 years ago

Stapelzeiger commented 10 years ago

I suggest the write command also sends a crc, so that a erroneous page is never written to flash.

antoinealb commented 10 years ago

The datagram already contains a CRC, so the parameters are guaranteed to be correct (excluding collisions).

Stapelzeiger commented 10 years ago

what if you loose a datagram / someone else writes a datagram with the same id?

antoinealb commented 10 years ago

Well I thought you would put a whole page into one big datagram, so it is CRC checked.

Stapelzeiger commented 10 years ago

Are we talking about CAN datagrams?

antoinealb commented 10 years ago

Arf, maybe it was not clear in the specification. Both serial and CAN encapsulates the given datagram format. The CAN transport layer is only used to adapt from message oriented to stream oriented.

Stapelzeiger commented 10 years ago

Ok, I thought the datagram format was just to be able to send the equivalent of a can frame over a uart byte stream. I think it would be more efficient and simpler to have a different format for CAN.

antoinealb commented 10 years ago

More efficient ? I think the overhead of the datagram format is really low, if you take into account that the length of the data will be very big most of the time (~1kB if we send one page per datagram).

I don't think it would be simpler to have another format for CAN because it would mean less code reuse between the two versions of the bootloader.

If you have any idea I am open to suggestions.

Stapelzeiger commented 10 years ago

Since you have multiple bytes in a can frame you don't have to reserve and escape bytes over can. Of course the datagram format for uart would also work over can, but it's not very elegant.

A very simple protocol over can would be to use one of the can-id bits as a first-frame-of-datagram indicator and just put all the bytes in the can frame without any transformation.

antoinealb commented 10 years ago

How would you handle lost frames in a given datagram ?

Stapelzeiger commented 10 years ago

via a crc Edit: could be transmitted in the first frame for example

antoinealb commented 10 years ago

So the format would look like this ?

  1. Data length (n) : 2 bytes
  2. CRC32 of the whole datagram : 4 bytes
  3. Data : n bytes

That's ok for me, it is almost the same format as for the UART (except start marker escaping).

Stapelzeiger commented 10 years ago

Yes, that would work

antoinealb commented 10 years ago

After discussing, I propose the following format for CAN messages ID :

  1. 1 bit for unicast/multicast.
  2. 7 bit for the source ID to avoid conflicts (similar to UAVCAN).
  3. 1 bit for datagram start marker
  4. 2 bit reserved

Then for the datagram format I propose the following :

  1. Destination NodeID : 1 byte
  2. Data length (n) : 2 bytes
  3. CRC32 of the complete datagram : 4 bytes
  4. Data : n bytes

Ok for you ?