Fw: Single shot mode with arbitration support

Hi John,

I really believe that your concern has nothing to do with the to be used CAN-controller, but only with the system design.

In principle in every synchronized system every node should know when it is free to shoot the event driven messages and when it is only allowed to send synchronized frames.

I don't know the MILCAN specification, but studied the TTCAN and also have experience with CANopen SYNC systems.

For the not very hard CANopen SYNC systems your design should be as follows: The PDO's which are to be synchronized, should have the lowest ID's. The event driven PDO's the higher ID's. This means after a SYNC only an NMT (id 0) or an EMCY (ids 129-255) can come in between the synchronised messages. Also retransmissions are possible offcourse. But the conclusion is: all nodes should be designed in a way that the event driven PDO's have a lower priority than the synchronized ones.

In TTCAN windows are defined and these windows can have multiple messages. In the design you define your windows. The exclusive windows normally will have only room for one message and some delay to have a reacting message available for the next exclusive window. So you can have a closed-loop control without intervention of other messages. Within one SYNC cycle you can have multiple exclusive windows, but the rest of the time will be filled with arbitration windows. Here you can have the normal event driven messages. The only restriction herewith is that all event driven messages know that they are not allowed to come into the exclusive windows. So no retransmissions here also.

So if you mix a MILCAN bus with standard J1939 devices the J1939 devices should be capable to prevent sending or resending in the synchronized area. This will be a problem of the off-the-shelve J1939 ECU's. So I think MILCAN claims it can integrate the J1939 protocol, but not the standard J1939 ECU's.

Kees

  ----- Original Message ----- 
  From: John Dammyer 
  To: [email protected] 
  Sent: Friday, January 18, 2013 9:49 AM
  Subject: RE: [CANLIST] Single shot mode with arbitration support


  Hi guys,

   

  Maybe I haven't interpreted the spec correctly.  I understand that it allows an error flag.  That's just common sense otherwise you couldn't promise that a message had valid data.

   

  It's the retransmission after an error flag that is not allowed.  

   

  Think of it this way.  

  1.       Message goes out and has an error.  

  2.       Either transmitter or a receiver detects that there is an error.  

  3.       Either the transmitter or receiver creates the error flag and the message is destroyed.  

  4.       In fact regardless of who generated the error, the flag itself breaks the stuff rule so any node that didn't see the error will now flag an error on the error which is why a 6 bit dominant error flag can become a 12 bit dominant. And Kees is right, the extra 12 bits should be factored into the worst case length of each message.

  5.       Finally, MilCAN states that the message damaged by an error flag 'may not be retransmitted'

   

  I don't have a problem with that.  For any slot based HLP that's almost mandatory to avoid bumping into the adjacent slot.  And it's up to the HLP to deal with a message that didn't get through.

   

  So the single shot mode of the SJA1000, MCP2515 and some of the other processor based CAN devices fills this requirement.

   

  However, the MilCAN specification doesn't say that arbitration is to be prevented.  And as I read it the 'Single Shot' mode causes the transmitting node that loses arbitration to not resend.  Yes, it tells the processor through a status flag and possibly an interrupt that 'arbitration is lost'.   

   

  The processor doesn't know this has happened until it gets the event.   In the case of the MCP2515, you lose even more time because you get an interrupt and then you have to use SPI to get at the status.  Using the SJA1000 in byte wide mode makes that simpler but now we have to multiplex address and data and toggle ALE.

   

  Some of the TI ARM based units look like they have the One Shot mode.  I haven't checked the Microchip ECAN but the PIC30F series CAN module doesn't.  Or else I'm misinterpreting the data sheet.

   

  My point was and still is that I understand why for TTCAN that you cannot even have a retry on arbitration since I believe the slots are too small for two messages.  Not really sure about that as I'm not that familiar with TTCAN.

   

  But when the slots are large enough for multiple messages then we need arbitration and we don't need dead space between messages.  So I don't think the 'Single Shot mode' is a great solution.  It may well be the only one that's available. 

   

  And, truthfully, if a MilCAN system is going to share the bus with J1939 the whole error flag and retry and arbitration goes out the window as J1939 to my knowledge doesn't have any problems with retry after error flag. 

   

  Does that clear up my concerns.  Is there a processor out there that can do Single Shot and not resend on an error flag and still do arbitration without processor intervention?

   

  John Dammeyer