CAN Eblock

For E-blocks user to discuss using E-blocks and programming for them.

Moderators: Benj, Mods

Post Reply
Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

CAN Eblock

Post by Docara »

Hi,

First of, am I able to use the circuit design in the following link as a basis for my project although I will be using a different transceiver (is it protected, copyrighted etc) http://www.matrixtsl.com/resources/file ... 8-30-2.pdf

Secondly, presuming 1 is a yes what is the purpose of the three push button switches PB2, PB3 AND PB4

Thirdly, I intend to use the CAN Component in FC , are the LEDs D1 and D2 included in the functionality of the FC component. (will they flash on reception of data)

Thanks
Matt

EtsDriver
Posts: 444
Joined: Tue Apr 15, 2014 4:19 pm
Location: Kajaani, Finland
Has thanked: 345 times
Been thanked: 227 times
Contact:

Re: CAN Eblock

Post by EtsDriver »

Hi Matt!

For your second and third question about the purpose of push buttons/leds, take a look at the datasheet; http://ww1.microchip.com/downloads/en/D ... 21801d.pdf
mcp2515.PNG
(315.94 KiB) Downloaded 3773 times
So it means in general that theyre configurable. But mostly i think the flowcode component just uses them as extra pins to input and output things.

I personally use the other output pin on MCP2515 in my own pcb design CAN nodes as error detected indication near port... :D
Ill just keep the good work up!

Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

Re: CAN Eblock

Post by Docara »

HI EtsDriver,

Generally, I really struggle with Datasheet 'speak' and have a tendency to develop local dyslexia when I try and read them - its a shame Google Translate include it as one of their languages :D

Seriously, what threw me was that I would expect them to be connected to the host, I wasn't sure if Matrix made them available just to manually simulate a condition or similar for the purpose of a learning eBlock.

So how dies their component deal with data flow on the CANBus - cannot it be used in a practical system then?

Matt

Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

Re: CAN Eblock

Post by Docara »

Matrix??

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Re: CAN Eblock

Post by Steve »

Docara wrote:So how dies their component deal with data flow on the CANBus - cannot it be used in a practical system then?
Hi Matt,

It can certainly be used in a practical system. The issue around transmit/receive buffers and filters/masks is a layer on-top of CAN that is implemented in this Microchip device (and in some of their micros) to make it a bit easier when using CAN. For example, you can set up filters and masks to look for a certain subset of CAN messages and then use the interrupt feature to react when one of these messages is present on the bus. Or buffers with set information and message IDs can be set up to make the transmission easier.

It has been a long time since I used these devices, but I did find them relatively easy to use and I hope we have exposed their functionality suitably in the component.

Regards,
Steve.

Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

Re: CAN Eblock

Post by Docara »

Hi Steve,


Thanks for that,. Can I presume that it is OK to uourschematic I my design and can you confirm the function of the switches - I don't fully understand the previous explantion

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Re: CAN Eblock

Post by Steve »

Feel free to use our schematic if you wish.

Regarding the switches, these are connected to the TXnRTS pins of the CAN controller and can have two alternate functions. One is to request-to-send one of the TX buffer CAN messages and the other is as a general purpose input. The request-to-send is probably not that useful in practice as you would typically be controlling the sending of messages via the microcontroller itself. As general purpose switches, this can be useful if you are running out of free microcontroller pins.

The two LEDs are similar - either a flag to say one of the buffers has received a message or as a general purpose output.

If you have no specific need to extend the i/o or to trigger a CAN message transmission outside of microcontroller control, then I'd ignore the switches (and LEDs).

Post Reply