| View previous topic :: View next topic |
| Author |
Message |
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
| Anyone here used SENT (Single-Edge Nibble Transmission)? |
 Posted: Fri Aug 17, 2018 8:41 am |
 |
|
I am trying to implement the above protocol for a project that I may be working on and although I am aware and have some understanding of such protocol I have never used it before. There are very few MCU manufacturers out there that have hardware support for this particular protocol which only seems to be used in the automotive industry.
It appears that Microchip only has a single flavor offering MCU that incorporates a SENT module and that particular PIC is the dsPIC33EVXXGM family. For some reason it is not incorporated in any of the other PIC families, even though CAN an LIN protocols are available across the entire PIC family line. If I end up using the dsPIC33EVXXGM which seems the most reasonable and expeditious way to go I can just use some of the code support available from Microchip and port it over to CCS which unfortunately does not have any built in drivers for this module.
On the other hand, I thought of doing my own bit-banging hardware driver that could be used on other PIC's like the PIC24 series. Looking at this protocol format it seems to me that the transmit driver implementation is far simpler than the receive or decode driver which appears far more complex to write. So I am wondering if anyone in this forum has some experience or advice that are willing to share.  |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Fri Aug 17, 2018 10:46 am |
|
|
Yeesh.. yet another serial protocol......sigh.
OK, I had a quick look
This...
| Quote: | | The SENT protocol is a one-way, asynchronous voltage interface which requires three wires: a signal line (low state < 0.5V, high state > 4.1V), a supply voltage line (5V) and a ground line. |
seems silly to me.
So the sensors blasts away data to a receiving computer. That computer has to have some great smarts to KNOW when the sensor fails to transmit it's data. It's the 'little details' like maybe not being able to tell if the sensor is good, offline, powerless, etc. Also I assume one pin per sensor....?
I can't see any obvious reason to use it over say RS-485 or the MSC500 protocol I've used for 4 decades. MSC500 was/is a 24 baud, bidirectional, interlaced, 3 level, true single wire, 15 mile signalling system. Among it's features was the ability to detect WHERE in 15 miles the wire was busted(say by a backhoe or car hitting a telephone pole).
I don't know the speed or distance SENT works but RS485 is probably better, unless you've got SENT modules to listen to. Having to buy a ds33 seems overkill, I'd try an 18F46K22 and bitbang. A small 16F PIC might work great as a SENT to ASCII interface ?
Jay |
|
|
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
|
| Posted: Fri Aug 17, 2018 11:17 am |
|
|
| Thanks for the info however I have to interface to a sensor that sends out a SENT data stream and I have to abide to SAE J2716 as this will be an automotive application. So any other implementation would not be allowed. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Aug 17, 2018 12:00 pm |
|
|
SENT actually came out something like 10 years ago. It was very unpopular initially. It then underwent three major revisions and the latest versions are more popular.
It's basically a PWM. Uses pulse widths to encode each nibble.
If you know the frequency it is using, you can decode it with a CCP. However it gets hard, because the actual frequency used can vary from 3 to 90uSec, and this is signalled to the devices in the start pulse. This is 56 ticks long. The key is the hardware receiver includes automatic synchronisation to this.
It is fairly simple to use, except you need to program boundary conditions for the syncronsation into two registers before you start. You also need to know whether you are only going to support the full message protocol or short messages as well. Data sheet for the sensor is vital for both of these.
There is an interrupt when the message has been received.
You should also read the value in the sync register, and have an error if this varies more than a certain percentage from the start (you'll have to check the specification, but it is something under 2% allowed).
Everything depends on your sensor. There are also issues with some devices not using the standard CRC, and on these you will have to perform the CRC calculations yourself if you want to check this.
It never really gave it's supposed advantages over other protocols. Some automotive CANbus systems do have it for things like throttle sensors. |
|
|
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
|
| Posted: Fri Aug 17, 2018 2:13 pm |
|
|
I guess the only choice I really have without having to "re-invent the wheel" is to use the dsPIC33EVXXGM and just use the internal SENT hardware modules and write a driver to access this feature on the CCS compiler.   |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Fri Aug 17, 2018 3:18 pm |
|
|
Any chance there's a stand alone SENT to any-other-protocol converter 'chip' available ?
If not, maybe find the 'smallest' DS33PIC with SENT in it. Depending on application it may be cheaper or easier to use a PIC well KNOWN to you as the 'brains' and the DS33PIC as the 'converter' section.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sat Aug 18, 2018 1:12 am |
|
|
Do a search online for 'FULLTEXT02'. This is published thesis for a group doing some example SENT communications. Part is building a SENT receiver using a PIC18F67J50. It includes full flowcharts of their receiver algorithm (just done by reading Timer2 on the PIC).
Just tell us the transmitting device?.
With this data I may be able to give some help setting up the sent peripheral. Without this, 'no hope'....
Remember this interface will only exist on PIC's specifically targeted for the 'noisy' automotive environment. Hence chips like the dsPIC33EV32GM002 and it's larger brethren. There are other chips with it (the 33CH128MPxxx and 33CK256xxx for example). |
|
|
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
|
| Posted: Sat Aug 18, 2018 7:41 am |
|
|
Thank you guys, I certainly appreciate your tips and help, this has always been a great forum with a lot of very smart people. I have learned a lot from some of you throughout the years. To reply to some of your questions and suggestions, I have found some dedicated hardware from various vendors that supports SENT, but most of these consist of signal conditioning and transmitters have yet to find any device that is a stand alone SENT decoder.
I did find the thesis on this subject from Jonkoping University (FULLTEXT02) a very good and informative paper on the subject. As far as what the exact SENT transmitting device that I will be interfacing with, I am waiting to find out. Because this is basically a project that I will be doing for someone else with budget restrictions I don't think they would be willing to spend the time and $$ to write specific code for decoding this algorithm on other devices. However, I find that it is something I may be interested in doing in my spare time in the near future when I feel bored and need to keep busy. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sun Aug 19, 2018 3:24 am |
|
|
No Guarantees on this. It is based on something I did a little while ago, but has had to be 'trimmed' rather a lot to extract it from the customer's code, so I may have got things missed/wrong....
I'm particularly 'not sure' about the clock calculation bit this I had to change radically.
| Code: |
//sent.h
//First define all the peripheral registers and the bits in these
struct {
unsigned int16 NIBCNT:3;
unsigned int16 skip1:1;
unsigned int16 PS:1;
unsigned int16 skip2:1;
unsigned int16 SPCEN:1;
unsigned int16 PPP:1;
unsigned int16 CRCEN:1;
unsigned int16 TXPOL:1;
unsigned int16 TXM:1;
unsigned int16 RCVEN:1;
unsigned int16 skip3:1;
unsigned int16 SNTSIDL:1;
unsigned int16 skip4:1;
unsigned int16 SNTEN:1;
} SENT1CON1;
#byte SENT1CON1 = getenv("SFR:SENT1CON1") //locate structure here
#word SENT1CON2 = getenv("SFR:SENT1CON2")
#word SENT1CON3 = getenv("SFR:SENT1CON3")
struct {
unsigned int16 SYNCTXEN:1;
unsigned int16 RXIDLE:1;
unsigned int16 FRMERR:1;
unsigned int16 CRCERR:1;
unsigned int16 NIB:3;
unsigned int16 PAUSE:1;
} SENT1STAT;
#byte SENT1STAT = getenv("SFR:SENT1STAT")
#word SENT1SYNC = getenv("SFR:SENT1SYNC")
struct {
unsigned int16 CRC:4;
unsigned int16 DATA6:4;
unsigned int16 DATA5:4;
unsigned int16 DATA4:4;
} SENT1DATL;
#byte SENT1DATL = getenv("SFR:SENT1DATL")
struct {
unsigned int16 DATA3:4;
unsigned int16 DATA2:4;
unsigned int16 DATA1:4;
unsigned int16 STAT:4;
} SENT1DATH;
#byte SENT1DATH = getenv("SFR:SENT1DATH")
int1 Soft_CRC=FALSE;
int1 Have_message=FALSE;
int1 CRC_Error=FALSE;
int8 FRAME_Error=FALSE;
byte sent_message[6]; //6 character message buffer
unsigned int8 CRC;
unsigned int8 STATUS;
//I store the message into separate bytes in the array 'sent_message'
//with the CRC extracted to 'CRC' and the status nibble to 'STATUS'
void Sent_RX_Setup(int32 Speed, int8 NumNibbles, int1 CRC, int1 Pause)
{
//Now configure SENT RX. If CRC is 'TRUE' use the hardware CRC. Otherwise the CRC function
//First I need to calculate timing limits from clock and speed required.
int32 Sync_Count;
SENT1CON1.SNTEN=FALSE; //disable module
SENT1CON1.RCVEN=TRUE; //enable receive
Sync_Count=(getenv("CLOCK")/2)*Speed*8; //Using FCy
SENT1CON1.PS=0; //start without prescaler
if (Sync_Count>54600) //This is 65536 less 20%
{
//Problem need to switch to using Fcy/4
Sync_Count/=4;
SENT1CON1.PS=1; //enable prescaler if needed
}
//Now the limits need to be set to +/- 20% of this
//I have left 'space'in the 65536 counts allowed for this
SENT1CON3=(unsigned int16)0.8*(1.0/Sync_Count);
SENT1CON2=(unsigned int16)1.2*(1.0/Sync_Count);
If (CRC)
{
SENT1CON1.CRCEN=TRUE;
Soft_CRC=FALSE;
}
else
{
SENT1CON1.CRCEN=FALSE; //enable/disable hardware CRC
Soft_CRC=TRUE;
}
SENT1CON1.NIBCNT=NumNibbles; //expected number of nibbles
If (Pause)
SENT1CON1.PPP=TRUE;
else
SENT1CON1.PPP=FALSE; //enable/disable pause pulse acceptance
SENT1CON1.SNTEN=TRUE; //enable module
enable_interrupts(INT_SENT1);
enable_interrupts(INT_SENT1ERR);
}
#INT_SENT1
void sent_interrupt(void)
{
Have_Message=TRUE; //flag I have a message received
CRC=SENT1DATL.CRC;
STATUS=SENT1DATH.STAT;
sent_message[0]=SENT1DATH.DATA1;
sent_message[1]=SENT1DATH.DATA2;
sent_message[2]=SENT1DATH.DATA3;
sent_message[4]=SENT1DATL.DATA4;
sent_message[5]=SENT1DATL.DATA5;
sent_message[6]=SENT1DATL.DATA6; //Move the nibbles into byte buffers
}
#INT_SENT1ERR
void sent_error(void)
{
//Now potentially have either a CRC error or a framing error
FRAME_Error=SENT1STAT.FRMERR;
CRC_Error=SENT1STAT.CRCERR;
}
//Crude main------------------------------------------------------------------
//main.c
//Processor stuff here
#include "sent.h"
void main()
{
Sent_RX_Setup(125000, 6, TRUE, TRUE);
//125KHz tick, 6 nibbles, hardware CRC with pause supported.
enable_interrupts(INTR_GLOBAL);
while(TRUE)
{
if (FRAME_Error)
{
//do what you want to handle this
}
if (CRC_Error)
{
//do what you want to handle this
}
if (Have_message)
{
Have_message=FALSE;
//message is now in 'sent_message[0] to sent_message[5]
//CRC nibble is in CRC
//instrument status nibble is in STATUS
//process the data.....
}
}
}
|
Edited I had missed a reciprocal in float out of the clock calculation....
Last edited by Ttelmah on Sun Aug 19, 2018 10:39 am; edited 1 time in total |
|
|
cbarberis
Joined: 01 Oct 2003
Posts: 172
Location: Punta Gorda, Florida USA
|
|
| Posted: Sun Aug 19, 2018 7:03 am |
|
|
Thank you so much Ttelmah, your help is greatly appreciated, specially when it is posted at 4AM, I hope you are on a different time zone. Your code here gives me a good start at least a fresh idea in writing this with the CCS compiler which is my compiler of preference.  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sun Aug 19, 2018 7:07 am |
|
|
I'm in the UK, so very much a different time-zone. Mid morning when I posted here.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
