CAN BUS on PIC24EP

[championx]

Hi! I'm using the pic24ep512Gu810 and I'm trying to read a canbus signal.

The thing is that i don't know which oscillator frequency is the one that i have to put in the CAN bit timing calculator tool.

This is my oscillator config:

#use delay(crystal=8Mhz, clock=120Mhz, AUX:clock=48Mhz)

Sorry for the noob question.

[Ttelmah]

Actually none of them!....

The 'crystal' value, is just that. The source oscillator feeding the internal PLL/divider. Nothing except the clock generator actually 'uses' this. The 'aux' clock only feeds the USB. The master oscillator, is Fosc (the clock= value), but the actual processor Fcy, and the clock that feeds the peripherals, is this /2. It is this value that most of the calculators use.
So 60Mhz.

Double check the results you get, and look in the file can-pic24.h

Note lines like:

[championx]

Thanks Ttelmah! That did the trick! The frequency input for the CAN bus timing calculator is 60 MHz.

Thanks!

[echimga]

Hey,

I need a little help with the CAN bus for pic24ep, I'm trying to read the Rx signal from a MCP2551 but the dumb question is: since the pic hasn't CAN pins, can I use whatever pin that I want to read the signal?

FYI I'm using CCS compiler and trying can-PIC24 library (examples for pic24H or none that I have), so I'm trying to rebuild the library for my case.

Also if you guys have an example or hint, it will be so much appreciated.

Thanks.

[Ttelmah]

You can only do CAN on chips that do have a CAN bus controller. CAN requires some very tight timings that can't be done in software. So chips like the PIC24EP256GU810. If your chip has such a peripheral and it is not connected to fixed pins, then you need to select it to the pins you require first (#PIN_SELECT).

So:

#PIN_SELECT C1RX=PIN_A0
#PIN_SELECT C1TX=PIN_A1

Would connect can peripheral 1 to A0 and A1.

The can-pic24 library already contains the code to handle these chips.

[echimga]

Thanks Ttelmah,

I'm working actually with a PIC24EP256GU810. I did what you said, got PIN_D1 and PIN_D2 to be my TX/RX for ECAN. TX works just fine, tested it seeing the signal with an oscilloscope, but I'm having trouble to read data from the BUS.

I do not know how my data is coming from a sensor (id, data,..), so I was expecting to see at least a bunch of info may or not with sense, it is possible? Catch it in the ECAN/DMA buffer without using id or mask filters?

I checked configuration words but I didn't catch some way to, any hint?

I've nowhere to upload it but drive may work to check what I say
[img]https://drive.google.com/file/d/0B_eEvfNlrnYvQXpCTlpsak1rTGM/view?usp=sharing[/img]

[Ttelmah]

Can filters _everything_. It has to. It's part of the specification that all nodes _must_ filter out all messages they don't want. Get yourself a bus sniffer. CanAnalyser is free, and all it needs is the little CanDo interface to a PC and you can see what is going on.
However if your timings are wrong, you won't even be starting. So you need to get the timing settings right (use one of the online tools to generate the settings). The Microchip CAN Bit Timing Calculator is the place to start.
If the timings are wrong, the chip will almost certainly go into the 'bus off' state.
Make sure the times generated by the PIC match those from the sensor. Once the timings match, the PIC will ACK every message on the bus (all CAN devices must acknowledge all messages). Set all the mask bits to 0, and you will receive all messages, but then be prepared for just how much data you will get....

[RF_Developer]

To receive anything on CAN the timing must be right. You need to the speed of the device sending the CAN messages. Typical speeds are 100kb/s, 125kbps (this is what the CCS routines generally default to, assuming a 20MHz clock speed), and 250kb/s. Some systems go up to 1Mb/s. It is also possible to have more than one virtual CAN net working at different speeds on one physical bus. That can be very confusing, especially at first, but not so bad once you get the hang of it, and know which virtual net you want to work with. Best to start with one thing working at one known speed with one known ID format sending known messages.

Once you've got the CAN speed set up right, then you should receive something. In fact, you'll receive everything sent using that bus speed! This is where the filters can come in, as you can use them to filter out messages you don't want to bother with. Using the CCS code, however, the default is to leave all the filters open and so you'll receive every message, which is often okay. Filtering is not as simple as it should be, and starting off, at least, receiving everything is generally the easiest ay to go.

Do you know anything about this sensor? Do you have a datasheet? Do you know what messages it will send and when? I think you're saying you have not, and that give you a problem. Even knowing whether the messages are extended ID or not will be a start. Again by default the CCS code will receive messages with both ID formats, and will need a modified set-up to received only one or the other.

For a sensor to need to use CAN its probably going to be fairly complicated. Though, some automotive sensors use CAN and are fairly simple - this is because CAN was first developed for automotive use, primarily as a way of reducing wiring and simplifying car systems design. Even simple sensors that only send measurements now and then may require a command message to get them started, so unless you know what that message is, and you successfully send it, you'll get nothing.

Once CAN is set up and running, its generally pretty tough. You can abuse CAN quite badly and the messages will still get through.

CAN is not like RS232 serial or even USB: it is not point to point, it is a broadcast bus, and generally nodes send out messages that any other node can read and use, or filter out, as they want. CAN itself provides no way to send data from A to B. it also is very unlikely to receive rubbish. CAN messages have CRCs and other checks, and by default you'll only receive good messages. You will not receive a stream of charaters like RS232/serial, you either get good messages or nothing at all. The datasheet for your sensor (that you don't seem to have) will tell you what the message mean. Trying to reverse engineer the messages may be very difficult, especially with anything other than a simple one or two parameter sensor (e.g. an RPM sensor).

[newguy]

[RF_Developer]

[newguy]

[echimga]

Hey, First, I still in the same place as I've say. I got nothing from my sensor.

[RF_Developer]