RE: 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

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Kees
Zagers
Sent: January-18-13 12:23 AM
To: [email protected]
Subject: Re: [CANLIST] Single shot mode with arbitration support

 

Hello John, Daniel,

 

I agree with Daniel. The errorframe is essential. Presume a transmitting
node detects a biterror during sending. If it just stops, how would the
receiving nodes, which have not detected the error, know that an error
occured. OK if the transmission just stops, they will see only recessive
bits and in that case they would also like to send an errorframe. This
should also be prohibited, which really means you don't have a CANbus
anymore. I would call this CAN version 0.0.

 

The SJA1000 does a single-shot transmission. If it does not succeed, it
sends its errorframe and waits until the software says: "Try again". This
should fulfill the MILCAN specification.

 

In the design of the network you should calculate a maximum frame length not
only the CANframe, including maximum number of stuffbits, but also the 20
bits of one extra errorframe (12 times 0 + 8 times 1). I must correct this
during my writing, because if an error occurs the errorframe will come
before the EOF/IFS starts, so we can subtract 10 bits, which leaves 10 bits
extra in the calculation. This seems no problem to me.

 

Kees

 

----- Original Message ----- 

From: Daniel Leu <mailto:[email protected]>  

To: [email protected] 

Sent: Friday, January 18, 2013 7:50 AM

Subject: Re: [CANLIST] Single shot mode with arbitration support

 

Hi John, 

 

The revision history of MilCAN A Complete Rev3 has as first entry

 

page3image9528
1 March 2006 Initial publication.
Merger of the following documents: MilCAN A Physical Layer Specification
(IHSDB-APP-GEN-D-030 Rev 3)
MilCAN A Data Link Layer Specification (IHSDB-APP-GEN-D-031 Rev 4)
*********
MilCAN A Application Layer Specification (IHSDB-APP-GEN-D-032 Rev 2)

 

Looks like the specification you referenced is now included in MilCAN A,
rev3.

 

Paragraph 3.10 becomes 3.2.10

 

. 3.2.10  Link Layer Re-transmission on Error - Compulsory

The LLC sub-layer of the ISO11898 CAN standard includes amongst its
functions the re- transmission of frames that have been disrupted by errors
during transmission. This process can result in an unpredictable number of
re-transmissions of the same frame in the event of errors.

Automatic re-transmission on error shall be prohibited where this would
violate the requirements of prioritised queuing as stated in section
3.2.7.1. Corrective procedures appropriate for the system application may
then be executed by the node/device application software.

 

To me this defines the requirement for disabling automatic re-transmission.
But this doesn't say anything about not having an error flag.

 

I can't really imagine that a CAN HLP disallows an essential CAN feature
such as the error flag.

 

 

Regards,

Daniel

 

 

 

 

On Jan 17, 2013, at 6:46 PM, John Dammyer <[email protected]> wrote:





Hi Daniel,

See below.  Unless it's changed.

John

From:
MilCAN A
Data Link Layer Specification
IHSDB-APP-GEN-D-031
Revision 4

3.10 Link Layer Re-transmission on Error - Compulsory
The LLC sub-layer of the ISO11898 CAN standard includes amongst its
functions the retransmission
of frames that have been disrupted by errors during transmission. This
process can result in an unpredictable number of re-transmissions of the
same frame in
the event of errors.
This function shall be disabled by selecting CAN controllers that provide
the capability to
disable re-transmissions. Corrective procedures appropriate for the system
application
may then be executed by the node/device application software



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Daniel Leu
Sent: January-17-13 6:09 PM
To: [email protected]
Subject: Re: [CANLIST] Single shot mode with arbitration support

Hi John,




The problem is MilCAN doesn't allow error flags since a bad message 
retrying could easily overlap into the next SYNC message window.  The 
architecture of a MilCAN system is such that the designer plans what 
messages occur during each SYNC slot.  A node may broadcast only when the

SYNC COUNTER was 24.



Another only when 32 and so on.   


Just wondering where in the MilCAN spec it says that error flags are not
allowed. Thanks!


Regards,
Daniel




--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to
<[email protected]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>