![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
championx
Joined: 28 Feb 2006 Posts: 151
|
CAN BUS on PIC24EP |
Posted: Fri Jun 05, 2015 1:54 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Sat Jun 06, 2015 2:00 am |
|
|
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:
Code: |
#IFNDEF CAN_BRG_PRESCALAR
#define CAN_BRG_PRESCALAR 4 //baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/(Fosc/2) )
#ENDIF
|
It uses 'Fosc/2', throughout. |
|
![](templates/subSilver/images/spacer.gif) |
championx
Joined: 28 Feb 2006 Posts: 151
|
|
Posted: Mon Jun 08, 2015 7:07 am |
|
|
Thanks Ttelmah! That did the trick! The frequency input for the CAN bus timing calculator is 60 MHz.
Thanks! |
|
![](templates/subSilver/images/spacer.gif) |
echimga
Joined: 04 Apr 2017 Posts: 3
|
Question |
Posted: Tue Apr 04, 2017 10:41 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Tue Apr 04, 2017 2:11 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
echimga
Joined: 04 Apr 2017 Posts: 3
|
|
Posted: Wed Apr 05, 2017 2:46 pm |
|
|
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] |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Thu Apr 06, 2017 12:27 am |
|
|
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.... |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Apr 06, 2017 8:36 am |
|
|
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). |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Thu Apr 06, 2017 9:21 am |
|
|
RF_Developer wrote: | Once CAN is set up and running, its generally pretty tough. You can abuse CAN quite badly and the messages will still get through. |
Agreed. The only thing that will consistently stop a CAN bus is interference, which will induce CAN errors. If the errors are high enough, the bus effectively gets strangled by the error messages.
RF_Developer wrote: | 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's true that there is no way to send a message from node A to only node B, but there's a way to fake it. It's easier if you're using the extended addressing scheme. Set aside bitfields in the address to correspond to "sender", "destination", "message purpose", "message ID", perhaps a counter for large transfers, etc. Then each node really only requires two filters: messages addressed only to "me", and messages broadcast to "everyone". Sending a reply is easy because it can be addressed to the original "sender". |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Fri Apr 07, 2017 3:24 am |
|
|
newguy wrote: |
It's true that there is no way to send a message from node A to only node B, but there's a way to fake it. It's easier if you're using the extended addressing scheme. Set aside bitfields in the address to correspond to "sender", "destination", "message purpose", "message ID", perhaps a counter for large transfers, etc. Then each node really only requires two filters: messages addressed only to "me", and messages broadcast to "everyone". Sending a reply is easy because it can be addressed to the original "sender". |
This is exactly what I do with my message scheme. I use 29 bit IDs and have two "classes" of messages, addressed and broadcast. Both have the source/sender in the ID, but obviously only the addressed class has a destination. Since introducing the scheme I have found I very rarely use addressed messages. One reason is that without a destination address, broadcast messages can carry what I term a "payload" byte, which is is effectively an additional data byte. I use this for things like the counter for large transfers, some status byte or other, or in quite a few cases, the message data itself. It makes broadcast messages more flexible and useful.
This is not inherent in CAN however, it is a protocol layer on top. All CAN nodes see all messages, but can filter some out if they need to. How they filter is up to the systems designer and implementor. One method is to arrange some sort of destination addressing and to filter on that. Also CAN has no send and response mechanism (except RTRs, which are limited in utility). It is up to the user to implement responses as part of a higher level protocol.
I think this is way over the level of what the original poster is looking for. I suspect there the issue is that they've got some sensor and they don't know what's coming out of it and are trying to reverse engineer it. The first step of doing that is to establish the bit rate, then to determine if its using extended or normal IDs. Only then can the types of messages (quite likely more than one with even simple sensors, as if you're using CAN, "simple" is not a word that tends to spring to mind) be worked out. If the sensor requires control, then unless there is a working system on which to listen in, all you can do is exhaustively search to find what messages it responds to, that potentially means all IDs and all data contents. Not impossible, but could take a while... |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Fri Apr 07, 2017 6:15 am |
|
|
RF_Developer wrote: | I think this is way over the level of what the original poster is looking for. I suspect there the issue is that they've got some sensor and they don't know what's coming out of it and are trying to reverse engineer it. The first step of doing that is to establish the bit rate, then to determine if its using extended or normal IDs. Only then can the types of messages (quite likely more than one with even simple sensors, as if you're using CAN, "simple" is not a word that tends to spring to mind) be worked out. If the sensor requires control, then unless there is a working system on which to listen in, all you can do is exhaustively search to find what messages it responds to, that potentially means all IDs and all data contents. Not impossible, but could take a while... |
At this point I really don't think they for sure know the bit rate of the sensor let alone anything else. As you said, not impossible but not easy (I'm paraphrasing a little ). |
|
![](templates/subSilver/images/spacer.gif) |
echimga
Joined: 04 Apr 2017 Posts: 3
|
|
Posted: Tue Apr 11, 2017 5:06 pm |
|
|
Hey, First, I still in the same place as I've say. I got nothing from my sensor.
RF_Developer wrote: | 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.
|
About the baud rate: I'm using 250,000, by using the CCS library for PIC-24.
Code: |
#fuses NOWDT, PR_PLL
#use delay(clock = 140MHz, crystal = 20MHz)
#define CAN_BRG_PRESCALAR 34 //Set CAN Baud Rate to 250K
#define CAN_BRG_PHASE_SEGMENT_1 1 //Tq = (2(1+34))/(Fosc)
#define CAN_BRG_PHASE_SEGMENT_2 1 //Tq = (2(1+34)/(140000000) = 0.0000005
#define CAN_BRG_PROPAGATION_TIME 2 //Baud Rate = 1/(((PHASE_SEGMENT_1+1)+(PHASE_SEGMENT_2+1)+(PROPAGATION_TIME+1)+(JUMP_WIDTH+1))*Tq)
#define CAN_BRG_SYNCH_JUMP_WIDTH 0 //Baud Rate = 1/(((1+1)+(1+1)+(2+1)+(0+1))*0.0000005) = 250,000 |
I got the values by using 140MHz FCAN and using CAN_CANCKS bit at 1 (tried 0 for a hint but nothing happen).
Any clue? sensor it's 235,000 and up. |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Wed Apr 12, 2017 4:14 am |
|
|
echimga wrote: | Hey, First, I still in the same place as I've say. I got nothing from my sensor.
RF_Developer wrote: | To receive anything on CAN the timing must be right. You need [know] to the speed of the device sending the CAN messages. Typical speeds are... 250kb/s.
|
About the baud rate: I'm using 250,000, by using the CCS library for PIC-24.
...
sensor it's 235,000 and up.
|
As I wrote, CAN timing has to be right, it cannot be "235,000 and up". Well, it could be in the sense that the timing may be able to be set up, but once running only one bit rate will work. let us assume you are right and that bit rate is 250kb/s, which seems sensible. It had better be, as it turns out that with your processor clock you cannot generate 235kb/s.
Your bit rate timing calculations are out by a factor of two. As Ttelmah pointed out back on this thread in June 2015, the clock rate used for the CAN (and other peripherals) is half the processor clock, so not 140Mhz, but 70MHz. Your timings assume 8 Tq in a bit (the CAN bit time is divided up in to eight Time Quanta which are then assigned to the four segments of the bit). You can't do that with the correct CAN clock of 70MHz, instead use 10 (or 20 or even 14, but I generally use 10 if I can). For this your set-up needs to be:
Code: |
#fuses NOWDT, PR_PLL
...
#use delay(clock = 140MHz, crystal = 20MHz)
...
#define CAN_BRG_PRESCALAR 13 //Set CAN Baud Rate to 250K @ 10 Tq per bit.
// Segments - these are in the order they occur in the bit.
#define CAN_BRG_PROPAGATION_TIME 0
#define CAN_BRG_PHASE_SEGMENT_1 4
#define CAN_BRG_PHASE_SEGMENT_2 2
#define CAN_BRG_SYNCH_JUMP_WIDTH 0
...
#include <can-PIC24.c>
|
It is easy to overthink CAN set up. I use mbtime which can be confusing especially with PIC24s due to the confusion about which frequency to use, the actual oscillator, the processor clock, or the cycle clock, i.e. half the processor clock? The answer for 24s is the cycle clock. However, mbtime does use the Tq concept which I certainly recommend. For PIC18s I have my own CAN routines, that call the CCS code. My stuff can deal with the wide range of clock speeds I use by setting the prescaler (BRP/ BRG_PRESCALER) to give 10 Tq in the bit at my standard rate of 100kb/s and then using my now standard "1,5,3,1" timings for the segments, which is what I did above: they translate into the 0, 4, 2, 0 values.
Please do not try to "rebuild" the "library", by which I take it that you intend to edit can_PIC24.c. Leave it as it is and simply define the values as I have shown in your main code. The defines must be before the include. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|