Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Whats the difference between SSP And BSSP?

Status
Not open for further replies.
A B? It's a little difficult to answer a question like that without some information.
 
Sceadwian said:
A B? It's a little difficult to answer a question like that without some information.

Sorry.

Ive been reading up about Pic serial data transfer.

This pdf is about Microchip Pic midrange devices.

It has a section on the Syncronous Serial Port (SSP) and another on Basic Syncronous Serial Port (BSSP), The problem is that I cant really see what the difference is between them.

Cheers
 
Last edited:
SSP has SSPSTAT bits 7 and 6 activated with functionality (SPI Data Input Sample Phase and SPI Clock Edge Select), whereas BSSP says these bits in the register are unimplemented. It also says that SSP supports all 4 modes of SPI (Including Microwire), whereas BSSP (I presume) doesn't.
 
Funny, I was reading up on the same thing yesterday (in fact, I still have the .pdf open!) and had the same question. :)

How about MSSP? (Master Synchronous Serial Port)

TIA!
 
A simplistic view of the MSSP would be starting with the larger 28 pin devices, or possibly 20 pin (don't know), you get the addition of a master I2C. So with that, you get to read and write to other I2C devices and Pic Slaves (SSP) using built in hardware. The hardware master I2C most likely gives you faster, leaner code execution over a software version required on the smaller pin devices. The most obvious reason I can think of, is you get to get to read or write a byte at a time thru the SSPBUF register, instead of bit-banging in software. Someone else might have a better more detailed explanation.
 
I wish the datasheets/manuals were as simplistic! Answer -- SSP/BSSP is software based, while MSSP is hardware based. Thank you!

I was reading up on SSP in the Midrange Manual (as linked to above), but learned a valuable lesson at the same time -- always check the datasheet of the product you're working with! I was trying to read up on SSP, BSSP, and MSSP in the Midrange Manual to see which I would need to use and learn more about... a waste of time considering when I got into the 16f873 datasheet... which appears to only have MSSP (at least I didn't see any info on SSP or BSSP, other than references to SSP throughout the MSSP chapter).
 
Code:
I wish the datasheets/manuals were as simplistic! Answer -- SSP/BSSP is software based, while MSSP is hardware based. Thank you!

Well no, thats not what I meant. To say it a different way; you must employ a software solution for non-MSSP devices to act as an "I2C master". For instance, a 16f88 does not have a MSSP module. So in order for the 16f88 to communicate with an I2C EEPROM, or RTC etc., a software solution is required.

As for the simplistic view comment, the implication is only to my depth of knowledge. There are a couple of Microchip appnotes that spell out the code requirements for a master I2C MSSP. Same for the SSP module if you wanted to control another Pic with a master Pic. Of course you could use SPI to do the same thing, a matter of preference I guess.
 
Well, that's kinda what I meant -- by "SSP is software based" that is what I am referring to -- that it (16f88, etc.) needs to be controlled through software to act as a master. MSSP, the hardware (16f87x, etc.) takes care of that for you.

As for SPI -- yeah, there are a few protocols that could be used -- that's why I'm reading up on the different ones and what they can and cannot do. From what I've been reading, it appears that I2C doesn't like long distant communications (like over a few inches) and was designed for communications with peripherals and other :mu:C's on the same board (or maybe a daughterboard). I have a project in mind where I'd like to communicate with another :mu:C across a few feet of wire (3 -6 on average), so this route will probably not work in that application. Maybe RS485 is the way to go, I don't know, haven't read anything on that yet. :) (I'll cut that short as I don't want to hijack the thread.)

I've picked up a couple of I2C peripherals (24LC256 and DS1307) to experiment with -- so let the fun begin! :)
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top