WTF is this communication protocal?

[Simon]

Looking for an RTC so came across this, "thing". https://www.mouser.co.uk/datasheet/2/302/PCF85063BTL-1127645.pdf

It claims to be SPI but it has one pin for data in and out, how on earth does that work? Page 31 starts to try to explain but what? I am supposed to clock out from my MCU the command byte and then what? just keep pulsing and expect data back like nothing was? we just do the hokey kockey with data direction mid message? what is this crap? And how the hell can they call it SPI? more like I2C if you ask me or is that what they meant?

At this rate I may as well learn to use the frigging MCU as an RTC.

[ataradov]

What is the device name?

Usually bidirectional SPI is implemented by combining RX and TX with resistors. In this case master will always will hear its own echo. And to receive the data, master sends 0xff (MOSI high) and slave drives the bus low. In that instance master high output is essentially a pull-up.

This is very common for low pin count devices and displays.  And usually all you have to do is follow the recommended connections.

Also, RTCs are slow, you can just bit bang the protocol without thinking how to adapt it to the SPI peripheral.

[SiliconWizard]

Yup. Actually it's just a... bidirectional synchronous serial bus (duh). You can either implement this as ataradov suggested, using series resistors, or handle bus turnaround in logic according to some protocol. Inside a given peripheral IC, it's very easy to implement. On a MCU, it is if you use resistors as again suggested, otherwise you can always handle the bus turnaround manually, that will slow down the overall throughput a bit, but I'm pretty sure such interfaces - with 1 bit of data - are dedicated to slow communication anyway. So, that can also be bit-banged if you're not comfortable with using regular SPI for this, or you just want to also only use 1 IO for the data signal instead of 2 to save one pin.

There's nothing weird about it. Actually, this is what QSPI is all about (just with -usually- more than 1 bit of data, but the principle is the same.) And QSPI is not slow, but bus turnaround is usually implemented on a low level in MCUs, so that's taken care of for you.

[T3sl4co1l]

Just write a wrapper function that toggles the data direction and CS bits, no biggie.  A bit more annoying if interrupt serviced (you'll need to manage state between transactions).  Discard the data received during TX, and send whatever during RX (disable output pin driver or use a resistor between MOSI/MISO).

Have seen it on a few LCDs, not that you need to read much from those, but when you can, it saves a pin I guess.  Hardware support change is minimal, either tying MISO-MOSI, or bridging with the resistor (particularly if for some reason you can't deassert the pin during RX, or the device replies too soon to deassert in time, say because you can't mind it every instant because it's interrupt serviced).

A number of programmers use a similar scheme, I think.  The AVR UPDI port isn't even synchronous, it's straight up async serial, with auto baud rate detect.  Impressively easy to work with, you only need a generic logic-level serial adapter.


Or do you mean, one pin at all?  In which case, one-wire comms aren't anything new, Dallas (now Maxim) I think was one of the first (did they patent their scheme or anything..?), even including bus-powered devices which is kinda crazy, but there you go.  These don't usually have hardware support, so find a library and drop it in for bit-banging or whatever.  Hm, support is probably easier with MCUs with configurable logic, might be feasible to interface it to a USART that way.  But not portable enough to drop in a library for it.

Tim

[Simon]

I forgot to put a link in, I have now (https://www.mouser.co.uk/datasheet/2/302/PCF85063BTL-1127645.pdf)

But really it looks more like I2C to me but without the pull ups, I mean why didn't they just make it I2C, I've not used either yet but usually I would expect to do serial comms using an interrupt but as ataradov said it would be simpler to bit bang it.

My MCU does allow connecting in and out pads together but if I am to send a btye that asks for data then I need to keep clocking the line the right amount of times, usually this it done by putting a byte into the transmit buffer even if it is just a filler to make the port do a transaction it means you can receive a byte too but here I can't do that so yea, actually bit bang is all I can do as the automation of byte transaction no longer exists.

[rstofer]

But really it looks more like I2C to me but without the pull ups, I mean why didn't they just make it I2C, I've not used either yet but usually I would expect to do serial comms using an interrupt but as ataradov said it would be simpler to bit bang it.

Because I2C is a difficult protocol to implement when there is no I2C peripheral.  ACK/NAK and START/STOP conditions are ugly to bit-bang properly.  Particularly when the uC is acting as a slave.  What to do about clock hold?

Bit-banging SPI is dead simple and combining MOSI and MISO with resistors is pretty clever, actually.

How would you interface this gadget to a 8-pin uC?

[SiliconWizard]

I'm confused - the link the OP just posted is an I2C device. And a NXP one (so the I2C license stuff would not even be a concern for them.)

But anyway - one reason to avoid I2C, beyond it being a bit hairy to implement properly, would also be a question of license. I2C used to be licensed, so IIRC you could not just design a chip with I2C without paying this. There is no license fee anymore these days AFAIK, but you still need to register for slave addresses, which is a paid service. So there are reasons to avoid I2C if you don't care about being I2C compatible.

[Monkeh]

It claims to be SPI

All addresses and data are transferred serially via the two-line bidirectional I²C-bus.

.....

[ataradov]

Wrong datasheet probably, since there is nothing special on the page 31 in this one.

[Simon]

Sorry, yes there's an A and a B version mabe there is a C version that is proper SPI, this one is just the bastard child of two beasts Links fixed

[DavidAlfa]

Most SPI devices do half-duplex, SDO is usually Hi-Z when receiving data on SDI, SDI is "don't care" when sending it through SDO, thus, both data lines can be joined without causing collision.
STM32 let's you do this by configuring the SPI peripheral in half-duplex mode, uses MOSI pin for everything, setting it as input or output depending on the transfer mode.

[SiliconWizard]

Sorry, yes there's an A and a B version mabe there is a C version that is proper SPI, this one is just the bastard child of two beasts Links fixed

So the rationale here, as they provide multiple versions, is obviously just to offer a variety of interfaces. Non-I2C versions will be good to interface with controllers that do not implement I2C for whatever reason. And as, as I said, I2C was actually licensed from Philips/NXP, the fact NXP (but I wonder if this chip was not already exisiting as Philips) offers interfaces other than I2C looks like a very reasonable way of not forcing their customers to use I2C.

And saving one IO is actually a bonus since they do not implement full-duplex communication anyway.

Thanks to DavidAlfa for pointing out that STM32 MCUs allow that very easily with their SPI peripherals without requiring external resistors or bit-banging.

[Simon]

Yes the microchip SAMC allows you to make allocate both the transmit and receive pad to the same pin. What I don't understand is why this is even called SPI, most manufacturers that use some dubious serial port call it just that, serial, these people used the terminology but I'm not sure it's proper SPI.

[ataradov]

Yes the microchip SAMC allows you to make allocate both the transmit and receive pad to the same pin.

I'm not sure that combination would actually work. And in any case, it would not help, you can't connect SDIO directly to the MCU pins in SPI mode, since SPI TX (MOSI) would drive the bus at the same time as this device. You would have to come up with a way to disable the MCU driver.

It would be easier and faster to just bit bang this.

[Simon]

Yes the microchip SAMC allows you to make allocate both the transmit and receive pad to the same pin.

I'm not sure that combination would actually work. And in any case, it would not help, you can't connect SDIO directly to the MCU pins in SPI mode, since SPI TX (MOSI) would drive the bus at the same time as this device. You would have to come up with a way to disable the MCU driver.

It would be easier and faster to just bit bang this.

Yes you are right, which is why I call BS on this so called SPI interface, even a serial port as flexible as the SAMC has cannot interface to it. If they had just made the output open collector it could have worked but copying the I2C interface in everything but name and not using pull up resistors was stupid. I think I will look for something else. at this rate I may as well learn no use my microcontroller as the RTC.

[DavidAlfa]

even a serial port as flexible as the SAMC has cannot interface to it

It's very rare that you cannot disconnect the pin from the peripheral, most mcus allow this by one way or another.

I know nothing about that architecture, but got this after a quick glance to the datasheet.
SAMC21 uses PMUX register to select which peripheral the pin is connected to, and enables this connection when PMUXEN bit is set, otherwise it's a GPIO.

So where's the drama? Seems pretty easy.
- Physically connect SDO/SDI together.
- Configure SDO/DSI GPIO pins as inputs.
- Configure PMUX registers, connecting SCK/SDO/SDI pins to the SPI peripheral, but set PMUXEN only for SCK.
- When sending data: PMUXEN=0 for SDI, 1 for SDO.
- When receiving data: PMUXEN=1 for SDI, 0 for SDO.

[ataradov]

Yes, you can temporarily switch PMUX to a regular GPIO.

There is no point in complaining how they called it. It does not matter at all. Just do what is necessary to interface the device and move on with your life.

[langwadt]

I'm confused - the link the OP just posted is an I2C device. And a NXP one (so the I2C license stuff would not even be a concern for them.)

But anyway - one reason to avoid I2C, beyond it being a bit hairy to implement properly, would also be a question of license. I2C used to be licensed, so IIRC you could not just design a chip with I2C without paying this. There is no license fee anymore these days AFAIK, but you still need to register for slave addresses, which is a paid service. So there are reasons to avoid I2C if you don't care about being I2C compatible.

afaik the license was only for the name I2C, you could make all the I2C you wanted, just couldn't call it I2C. Some called it two-wire.

And bit-banging an I2C master isn't that bad

[gamalot]

As the company that invented the I2C bus, NXP (Philips) certainly has some RTC chips with an I2C bus, and the chip that OP mentioned here is just another option, and one more option is always good.

[langwadt]

I forgot to put a link in, I have now (https://www.mouser.co.uk/datasheet/2/302/PCF85063BTL-1127645.pdf)

But really it looks more like I2C to me but without the pull ups, I mean why didn't they just make it I2C, I've not used either yet but usually I would expect to do serial comms using an interrupt but as ataradov said it would be simpler to bit bang it.

it is perfectly common 3 wire spi

My MCU does allow connecting in and out pads together but if I am to send a btye that asks for data then I need to keep clocking the line the right amount of times, usually this it done by putting a byte into the transmit buffer even if it is just a filler to make the port do a transaction it means you can receive a byte too but here I can't do that so yea

sure you can, just disable the output pin during the filler bytes

[Simon]

even a serial port as flexible as the SAMC has cannot interface to it

It's very rare that you cannot disconnect the pin from the peripheral, most mcus allow this by one way or another.

I know nothing about that architecture, but got this after a quick glance to the datasheet.
SAMC21 uses PMUX register to select which peripheral the pin is connected to, and enables this connection when PMUXEN bit is set, otherwise it's a GPIO.

So where's the drama? Seems pretty easy.
- Physically connect SDO/SDI together.
- Configure SDO/DSI GPIO pins as inputs.
- Configure PMUX registers, connecting SCK/SDO/SDI pins to the SPI peripheral, but set PMUXEN only for SCK.
- When sending data: PMUXEN=0 for SDI, 1 for SDO.
- When receiving data: PMUXEN=1 for SDI, 0 for SDO.

When receiving data? It's nearly that simple yes, the RTC is sent a byte, depending on the byte, bytes will follow for transmitting to the RTC but if it is a request then the interface does an immediate about turn and starts to transmit back, so I guess you dump the header byte into the transmit buffer, as soon as that is done you do the musical chairs with the pins and then dump dummy bytes into the transmit register to instigate a clock signal, uh yuck. Why call something a protocol when nothing else speaks it and has to be hand fished into place.

[Simon]

I forgot to put a link in, I have now (https://www.mouser.co.uk/datasheet/2/302/PCF85063BTL-1127645.pdf)

But really it looks more like I2C to me but without the pull ups, I mean why didn't they just make it I2C, I've not used either yet but usually I would expect to do serial comms using an interrupt but as ataradov said it would be simpler to bit bang it.

it is perfectly common 3 wire spi

My MCU does allow connecting in and out pads together but if I am to send a btye that asks for data then I need to keep clocking the line the right amount of times, usually this it done by putting a byte into the transmit buffer even if it is just a filler to make the port do a transaction it means you can receive a byte too but here I can't do that so yea

sure you can, just disable the output pin during the filler bytes

actually reminds me of LIN - oh without the pull ups of course - funny isn't it? this would work well with pull up resistors, they just chose to use an interface that does not use pull up resistors....

[free_electron]

 send 8 bits, tristate your driver, receive 8 bits. SPI comes in many different flavors...

[SiliconWizard]

This sounds trivial to do, whether you actually use a SPI peripheral, or just bit-bang it.
Writing the bit-bang version would probably have taken a lot less time than creating/participating in this thread.

[T3sl4co1l]

Not sure what the disconnect is, you've got a mental block... just chill, sleep on it, and it'll probably be a 'duh' moment. *shrug*

It's nothing like I2C, and would be worse with pull-ups -- the CS pin is there for a reason, it's not addressed, and it's only vaguely (superficially) like I2C in that it's a two-wire clocked interface.  It can be shared between devices, only as far as you have enough CS pins to go around.  The frame/packet sizes are different, the bus signaling is different (full driven vs. pullup), the timing is faster, there's no clock stretching shenanigans (not that all "I2C" devices support it anyway, or, give or take vs. SMBus, etc.).  You can just about talk it with a pair of logic chips (shift registers), it's much simpler than I2C.

Tim

[DavidAlfa]

You're the master, so there's no "inmediate answer" unless you cause it:
- Enable SDO
- Enable CS
- Send "I wanna read" command
- Disable SDO
- At this stage you can take a break, have some tea and cookies, the slave is waiting for clocks and won't do anything until then.
- Receive data by sending clocks
- Disable CS
- Done

[Simon]

Not sure what the disconnect is, you've got a mental block... just chill, sleep on it, and it'll probably be a 'duh' moment. *shrug*

Well first one I come across, I was not aware there was supposed to be a bidirectional single data wire SPI, every explanation of SPI I have seen is data in data out. Yes it's doable I was just rather taken aback by the way this works and as others confirm no I can't use even a flexible SPI port to deal with this chip without some creativity mid message, that is not a standard.

But there is 1/10 the stock of these compared to the I2C version so maybe yea, these are are easier than I2C.

[mikerj]

Not sure what the disconnect is, you've got a mental block... just chill, sleep on it, and it'll probably be a 'duh' moment. *shrug*

as others confirm no I can't use even a flexible SPI port to deal with this chip without some creativity mid message,

As others have suggested you can simply join MOSI and MISO together with a resistor at the master end which allows the use of any regular SPI master peripheral.  The resistor allows the slave to drive the data line without contention.  This is a very common scheme that has been used for a long time where full duplex SPI isn't needed.