What communications protocol is this? - Page 1
Forum section: electronics / projects

author: robzy
author_rank: Regular Contributor
timestamp: July 27, 2021, 02:33:12 pm
content: I want to integrate the AS5040 Programmable Magnetic Rotary Encoder into a project (datasheet PDF), but it's serial protocol is really weird and I'm wondering - does anyone have any suggestions on the best way to read this with an STM32 Blue/Black Pill? (Or, really, any MCU?)It isn't quite SPI, and the 9 clock pulses that it requires (from a 'HIGH' state) would make it awkward to use a timer-based FIFO buffer. Is the only way to bitbang the protocol on an MCU?I've attached a graphic of the protocol from page 18 of the datasheet.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 27, 2021, 02:49:07 pm
content: Don't understand why you think it's not SPI - looks like pretty standard 16-bit SPI to me - am I missing something?

author: ajb
author_rank: Super Contributor
timestamp: July 27, 2021, 03:03:00 pm
content: Quote from: robzy on July 27, 2021, 02:33:12 pmIt doesn't--the diagram shows the clock in a high state when idle, but at the start of the transaction the clock transitions to a low state, and then the first bit is clocked on the first rising edge of the clock. SPI can have the clock idle high or low, and can clock data on the leading or trailing edge of each clock cycle, so this is perfectly valid. Most MCUs have two separate bits to configure clock polarity and phase, so you just need to make sure you set them correctly and everything should work fine. It may get a bit tricky if you're trying to use the same SPI peripheral for different parts that need different modes.more on SPI modes:https://www.mikroe.com/blog/spi-bus

author: Kjelt
author_rank: Super Contributor
timestamp: July 27, 2021, 03:04:15 pm
content: The datasheet states SSI.This differs from SPI:https://en.wikipedia.org/wiki/Synchronous_Serial_InterfaceQuote

author: Kjelt
author_rank: Super Contributor
timestamp: July 27, 2021, 03:08:43 pm
content: BTW the chip also has a quadrature encoded output and an STM32 has a quadrature decoder on its peripherals, so might also be a way to go.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 27, 2021, 05:32:27 pm
content: Methinks they're using the term "SSI" generally. It's quite clearly not RS-422. It could certainly be sent through such transceivers, but the same is true of SPI, async serial and other protocols.Timing diagram looks to be SPI and I see no reason to doubt it. They seem to suggest the serial register is reset on nCS high, as it should be. (This is something to look out for; some devices don't reset state when deasserted. Some especially pathological devices must bepower cycledto reset bus state!) There isn't a timeout delay or anything, at least, any more than a half clock pulse at Fclk(max), which pretty much suggests the internal MCU* is simply polling pins at that rate.*Assuming quite a lot there, but it's quite common for complex devices. 24b+ ADCs sometimes admit to this for example.Tim

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 05:39:15 pm
content: Quote from: mikeselectricstuff on July 27, 2021, 02:49:07 pmAlthough it is said to be "SSI" rather than "SPI", I don't see a reason from the chronogram why you couln't use any SPI peripheral for handling this, as long as you can configure the clock polarity and phase, and 16-bit data.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 06:17:13 pm
content: I've seen numerous devices in my days which don't label SPI or I2C as such, even though they are. I'm assuming it's due to some legal reasons. I'm not even sure of the current situation, but know for a fact that 20 or so years ago, Philips was going after some people using I2C without paying them royalties. The company I was working for at the time was dealing with that. Many companies used alternate names for the interface on their devices with the name "Serial" in the title of the interface, I guess so the copyright holder couldn't easily identify the exact interface. I think that's likely the case here, and it's SPI, but instead of identifying it as such, the title, "Synchronous Serial Interface" is just meant to describe the interface, not to mean specifically that it's the official SSI interface.

author: ajb
author_rank: Super Contributor
timestamp: July 27, 2021, 06:34:04 pm
content: Yes, it is a serial interface that is synchronous, but a quick look at the datasheet shows that it can't be 'SSI' as described in that wiki article because in addition to not having differential IO it relies on a separate CS signal for latching/framing instead of a clock timeout. Looks like you could easily adapt it to SSI with a couple of RS422 transceivers and an RC timer to derive CS from the clock signal though. Still no reason that this can't be used with a standard SPI peripheral in any case.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 27, 2021, 06:44:18 pm
content: There are a few variants, and most SPI peripherals don't do much with CS - in my book, "SPI" just means "anything that can be talked to via the SPI peripheral on the MCU I'm using"

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 11:02:25 pm
content: Note that the obvious, as I said, the ability to select clock polarity and phase (and number of data bits, although this part could be handled in software I guess if you only had access to 8-bit data) is very common to have on most MCUs these days...But I remember having worked with at least one that did not have this. IIRC, the Cypress FX1/FX2, which I had to use about 15 years ago, only had one mode for SPI. So if you needed any other mode, you were screwed (or had to bit-bang...)As to CS, yes, most SPI peripherals are so unflexible with the CS line that most of the time, you have to handle it "manually".

author: robzy
author_rank: Regular Contributor
timestamp: July 28, 2021, 12:10:56 am
content: Quote from: mikeselectricstuff on July 27, 2021, 02:49:07 pmThanks for the response. A few people seem to think its SPI, but I don't think it is because: CLK idles high, and has to go through a full low-high transition just to instruct the AS5040 to make the first bit available. It then has to wait t(D0 valid), which the datasheet says is 250ns, before the bit willactuallybe available.I've attached a screenshot of an STM32 datasheet (RM0008) that shows all of the SPI modes supported, that is for all possible values of the CPOL/CPHA settings bits. To my eyes none of these clocking schemes will work.There are two SPI clocking schemes that have some similarities, because they capture data on the falling edge, but they don't idle high AND generate a preliminary low-high transition to kick off the data transfer. Similarly, at the end of the transmission, there is no falling-edge for the last bit. Infact, there's no edge at all for the 'capture strobe' (in STM32 parlance) of the last 'Even PAR' bit.Perhaps I am missing something though? Which of these SPI modes will work with the AS5040's serial interface?The AS5040's serial interface actually looks a lot more like Wikipedia's description of Single Transmission SSI. I didn't realise that SSI was the name of an actual protocol. Unfortunately the STM32 doesn't have an SSI peripheral, so I might have to bitbang, or use the SPI peripheral and big-bang the CLK line before and after a transmission happens.https://en.wikipedia.org/wiki/Synchronous_Serial_Interface#Single_transmission

author: ZigmundRat
author_rank: Regular Contributor
timestamp: July 28, 2021, 02:02:09 am
content: Once upon a time they had a demo kit based on an Arduino - I have one somewhere in the basementBut the Arduino code could serve as a reference, there’s a good number of google hits on that (AS5040 Arduino) too. I know the code I used was just bit banged - no attempt to use SPI/I2C peripherals. If you get desperate I can try to dig it up.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 28, 2021, 04:47:06 am
content: Oh, that is a little weird. It's off by one actually.Looks like CPHA, CPOL = (0, 1) should do, ignoring the first bit (it's probably always 1, or trash) and reading the final value (MISO pin) in software manually, before deasserting nCS; shift that bit into the rest of the received word (shifting out the trash bit) manually. This should reproduce the waveform exactly.I would try the other modes to see if it doesn't actually care about the default line level and half-clock at the start, and that gets aligned data with whatever mode.Tim

author: Berni
author_rank: Super Contributor
timestamp: July 28, 2021, 05:41:34 am
content: Yeah this is a weird almost SPI but not quite SPI thing.But chances are you can get it to work with SPI using some trial and error.For example you can generate the first pesky high low transition by switching the GPIO alternate function from GPIO to SPI right before starting the SPI transfer. This generates the extra edge needed. Hopefully you didn't need to run this all via DMA.If you do want to DMA it and need the SPI peripheral to do all of this on its own then you can probably get away with bending the spec a bit. It might not require that idle high state on the clock line and works just fine with idle low. Other option is to configure the SPI controller for 17bit transfers, this generates the extra junk clock pulse at the start and then continues with the rest of the 16bits as normal, then you just use the lower 16bits of the data register. This does result in an extra clock pulse at the end when reading the last bit, but at this point we already have all the bits we need so we don't care if this werid SSI peripheral gets angry at us for the extra clock pulse.(Tho it might not accept any write commands in this form)And if all else fails you can still resort to bitbanging. This is a fully clocked protocol so bitbanging is easy as there are no strict timing requirements, just a matter of adding a few NOPs in there if the thing runs too fast for the slave device to keep up.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2021, 06:14:44 am
content: It's your everyday SPI."Your everyday SPI" being, it can be anything. There is no single, clear, well-defined SPI. SPI generally means a "type" of communication, details vary.Be thankful it's 16 bits. Weird bit counts (anything goes, like 13 bits) are usual, and not all MCU peripherals support all possible bit counts; most modern and advanced can be configured like for anything from 3 to 32 bits. Of course, you can configure the MCU in either 8 or 16 bit mode, in latter case you'd get only one interrupt / DMA request per packet which is of course desirable.Play with Clock Phase and Clock Polarity settings until it works reliably. There are just 4 combinations.The name can be anything. Maybe it's a trademark thing, or just tradition. It can be ASDFGH, but the distinctive features of SPI are:* Packets are delimited by nCS. High->low transition starts packet; low->high transition ends packet* Data is clocked synchronously using a clock signal* Clock signal is active only when nCS is active.It gets confusing when the manufacturer throws the Scrabble tiles on the table to coin the new name for their SPI, and it happens to clash with something that already exists, like we can see the SSI confusion above.

author: robzy
author_rank: Regular Contributor
timestamp: July 28, 2021, 06:59:49 am
content: Quote from: ZigmundRat on July 28, 2021, 02:02:09 amOh that's cool! Google turned up some sample code. Unsurprisngly it is bitbanging instead of using the SPI peripheral.Quote from: T3sl4co1l on July 28, 2021, 04:47:06 amIn my application I think I'd rather bitbang than those two optionsNo point in using the SPI peripheral if I need to do custom lead-in/out stuff in code, and I don't want to risk faulty readings due to questionable timing.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2021, 09:23:28 am
content: Try low CLK idle level first. Read at falling clock edge. Could work out of box no problem with 16 bits.If it indeed needs the first weird extra clock cycle then it's really just a 17-bit packet, such strange lengths are common. That's why many modern SPI peripherals support any arbitrary word length.Which MCU?You can also try to give it extra clock cycles, maybe it doesn't get mad at you. Then 3 x 8 bit words would work.

author: jpanhalt
author_rank: Super Contributor
timestamp: July 28, 2021, 10:07:34 am
content: If you prefer to use hardware communication, the AS5048(A/B) is similar and supports both I2C and SPI.

author: robzy
author_rank: Regular Contributor
timestamp: July 29, 2021, 05:36:03 am
content: Quote from: Siwastaja on July 28, 2021, 09:23:28 amSTM32F411. I might give the SPI interface a shot with 3 x 8 bit words, although I suspect it will just be easier to bit-bang. And for my application I think it will be sufficient.Quote from: jpanhalt on July 28, 2021, 10:07:34 amBut unfortunately it doesn't have an incremental interface. I need(/want) a digital interface to do get the initial state, and then the incremental interface to keep track of it after that.The AS5601 with its I2C, incremental output, and hand-soldering-friendly SO8 package would be aawweessommee. But unfortunately it only does up to 600rpm. I need to go to roughly 5000rpm.

author: Renate
author_rank: Super Contributor
timestamp: July 29, 2021, 10:47:44 am
content: Have you just tried normal SPI?Maybe the location of the first down transition on the diagram is arbitrary/wrong.Presume that the data changes on up transitions and sample it on down transitions.See if you can actually capture that first bit correctly.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2021, 11:07:07 am
content: Just configure the SPI in 16-bit mode.Play with the four combinations of CPHA and CPOL.Play with the clock idle level setting.I'm 87% sure it will just work no problem whatsoever. And it's really easiest this way, just a few lines of code initializing the SPI peripheral and no CPU time wasted. Bitbanging is last resort, it wastes both CPU and development time.

author: robzy
author_rank: Regular Contributor
timestamp: July 29, 2021, 12:55:20 pm
content: Quote from: Renate on July 29, 2021, 10:47:44 amThat's wishful thinkingAMS are well aware that this is not SPI, they have similar ICs which they say has SPI and have totally different CLK characteristics.It wouldn't surprise me if I could capture the whole thing in 3 8-bit SPI words, but I'd just prefer to bitbang at that point.

author: Renate
author_rank: Super Contributor
timestamp: July 29, 2021, 01:07:12 pm
content: Quote from: robzy on July 29, 2021, 12:55:20 pmOk. Well, I just use an Infineon TLV493D-A1B6 which is an I²C, 3 axis and 12 bit for my propane gauge sensor.(I don't use Z. Except for sleeping: Zzzz...)

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2021, 02:20:53 pm
content: Quote from: robzy on July 29, 2021, 12:55:20 pmSo have you tried already, or not? You would have tried in the time it took to write all the posts.Preferring bitbang for SPI before you even know you have a problem requiring that sounds pretty strange.ItisSPI, as much as most other SPI devices. The only oddity here really is that this protocol might be 17-bit. But try it with different clock phase and polarity settings in 16-bit mode first, it's easy to see if it works or not.SPI doesn't have any widely followed formal standardization, and I think the name isn't even a registered trademark, but vendors still like to avoid the name sometimes for reasons unknown to me.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2021, 02:29:01 pm
content: Oh and nevermind, the parity bit is almost useless for error detection anyway, and even the example waveform clearly shows there is neither falling nor rising clock edge to read out that parity bit so with that example transaction, whatever master device generated the waveform likely does not read it (unless it uses clock gating for SCK but generates internal read clock cycle for the last bit, but this is unlikely).Without the parity bit, it's 15 bits of payload so 16-bit mode should be able to easily generate that one excess leading clock cycle, if you really need it.SPI devices usually do not have any kind of error detection. Off-by-one by clock glitch is one of the most usual culprits and has 50% chances of being undetected by parity bit. Single bit MISO/MOSI corruption, which would be detected by parity bit, is much more rare. If you need extra reliability, do multiple reads, add a median filter and sanity check of values, and finally, SPI must be used on-board with proper design and measurement for signal integrity.