RE: Single shot mode with arbitration support

Kees,

 

You're right.  The MilCAN spec has flaws.  It wants to be J1939 compatible
by using the  J1939 reserved bit 25 in the 29 bit ID  to separate J1939
messages from MilCAN messages.  Unfortunately the reserved bit in J1939 is 0
(dominant) and in MilCAN it's 1 (recessive).  That automatically puts MilCAN
messages at a lower priority compared to J1939 messages and totally destroys
any determinism in the SYNC FLAG timing.  

 

So I'm not sure why the MilCAN specification even cares about J1939 since
that one little detail breaks the protocol.

 

In either case, I'm guessing no one knows of a CAN device that won't retry
on an error flag but will arbitrate on a collision and retry transmitting at
the end of the message if it loses arbitration.

 

John Dammeyer

 

 

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Kees
Zagers
Sent: January-18-13 2:04 AM
To: [email protected]
Subject: Fw: [CANLIST] 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 <mailto:[email protected]>  

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