RE: Receiving CAN messages with TouCAN

"Dobbin Allan-r11834" <[email protected]>
Newsgroups gmane.comp.hardware.motorola.microcontrollers
Message-ID <4147ED8B92A864498825C07E53594E4AD48847@az33exm20.fsl.freescale.net>
What you described is the correct operation of the Toucan module - it
puts the matching frame into the FIRST matching message buffer, not the
next empty one, thereby overwriting previous frames.  The reason for
this is the original intention of CAN was that if a new frame with same
ID was received, the can controller would automatically replace the old
frame with the new data for each ID (assuming seperate IDs per buffer).
 
If you want to receive all frames, this does become a limitation.  You
can mask a few of the ID bits and set them as required in your message
buffers to get some sort of partitioning i.e. allow two mask bits to be
compared and have four buffers to receive each of the four groups of
frames (00, 01,10,11).  Obviously this is not an ideal solution to your
problem and you may still get overruns.
 
If you want a trully lossless system, you would generaly enable CAN
interrupts and ensure you service them before the next CAN frame
arrives.  The interrupt could be short and could do a minimum of
changing the buffer's control field to off thus disabling it from future
receptions (therby allowing new frames to go into next available receive
buffer) and then your periodic polling routine could remove the frame
contents from the 'off' receivers when time allows.
 
One word of warning - when polling the toucan you MUST poll the
interrupt flag register and not the buffers control/status field for
correct operation.
 
- Allan
 
 

	-----Original Message-----
	From: [email protected] [mailto:[email protected]] On
Behalf Of Stefan Metzlaff
	Sent: Thursday, June 29, 2006 6:09 PM
	To: [email protected]
	Subject: [MPC500] Receiving CAN messages with TouCAN
	
	

	Hi,
	
	I've got the following problem: I want to receive CAN messages,
but without 
	any interrupts. The CAN messages should be fetched by the
application through
	polling. The reason why I can't use interrupts is, the
application is an environment
	in which each task has strict deadlines, that must not be
missed. Interrupts for 
	handling received messages in such application, would cause
fatal deadline misses 
	in phases where the CAN bus is at high load. So I have to check
the message buffers
	at defined times. 
	I'm using a MPC555 with TouCAN controller, which has 16 message
buffers. By the description
	of the controller, it should be possible to set several message
buffers to read mode. If
	a message arrives it sould be placed in one of the empty buffers
until all buffers are filled.
	So I can read out the filled buffers and thereby I minimize the
chance of missing messages.
	I've tried this out, but when I set some buffers (e.g. 4) into
read mode (each has the bit mask
	0x000000 and should listen for every can message, cause I do not
really know which messages will 
	arrive), the can controller fills the first buffer only. If two
or more messages arrive within the 
	time between two polls the message buffer tells me that an
overrun occured, and i missed at least one
	CAN message. 
	
	Does anyone has experience with (lossless) receiving CAN
messages without using interrupts?
	
	Thanks in advance,
	Stefan
	
	

	 



[Non-text portions of this message have been removed]



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Something is new at Yahoo! Groups.  Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/dN_tlB/TM
--------------------------------------------------------------------~-> 

-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MPC500/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.