Best device for implementing a custom serial protocol

[Leonelf]

Last year I developed an inverter for a formula student car. The motors use an EnDat 2.2 absolute position encoder. Because of the time constraints I used an Altera MAX10 evaluation board with a transceiver daughterboard to implement the protocol and to act as an SSI slave to the inverter, but I don't find my solution to be very elegant so I want to re-design it properly.

I used an FPGA because I found the protocol to be very hard to implement with good performance by just bitbanging or (ab-)using SPI or DMA peripherals.

EnDat requires the master to clock out a command and then continue clocking. After a startbit appears, data-reception starts, the master continues to clock after the last bit + 1.

I looked into different microcontrollers with certain peripherals, especially the LPC43xx series seem interesting because of their SGPIO and STIM, but they're very expensive and large. FPGAs all seem more IOs than I need, leading to an unnecessarily big footprint. CPLDs seem too small for my VHDL design.

Do you have experience implementing "custom" protocols in hard- and software? Which microcontroller or FPGA can you recommend? Or are there special techniques or microcontrollers good for very fast (6MHz) bitbanging?

[CM800]

It may be possible to shrink it down further, if you were to 'ignore' the CRC and hope for the best.

Equally, maybe ask the motor to be supplied with a different encoder feedback? E.g. Halls & Incremental encoder (easy to feed back to an MCU without extra hardware) or SSI, which can be used with Serial easily.

What about the Lattice FPGAs like the ICEStorm Compatible ones.

[Leonelf]

Ordering the motors with more usable encoders is apparently impossible. Why especially the FPGAs compatible with IceStorm? Is the original Lattice software so bad?

[CM800]

Ordering the motors with more usable encoders is apparently impossible. Why especially the FPGAs compatible with IceStorm? Is the original Lattice software so bad?

Icestorm actually compiles a lot faster then Lattice.

Easy to use too.

plus, open source is always a nice bonus

[NorthGuy]

When you are on the master side, bit-banging is easy and doesn't need much. You just unroll the loop for the entire transmission and then you only need 2-4 instructions per bit. Which means you can easily do about 2 MHz with PIC16. If you want faster, you need something which can support a faster clock, but you don't want anything with cache or other timing impediments.

SPI modules will often work on 8/16/32 bit chunks, but you can always add few bit-banged bits at the beginning, or at the end. Usually, SPI will be 2-3 times faster than bit-banging on the same CPU. Probably easier too.

DMA will work just as well, however small MCUs usually don't have DMA so you'll have to go bigger. DMA is the easiest way if you want to communicate with both the encoder and the inverter at the same time.

Working as an SPI slave is harder for a CPU because it must adjust of the pace of the external clock. Thus bit-banging will be harder and slower. An SPI module with a buffer will work much better. An SPI module coupled with DMA will be the best.

[splin]

Whoever 'designed' that appallingly Endat protocol should be thoroughly ashamed of themselves; but you have to work with what you've got...

I think you should be fine with just about any ARM Cortex M0 or better with a USART and preferably DMA.

On the TX side you have to turn the transmit driver off at the end of the transmission which you could do in a counter interrupt from the timer generating the clock signal.

On the receive side you can deserialize/decode 32 bits at a time so not much load at 6Mb/s. Continuous Rx mode should be pretty simple but it is more problematic otherwise as you have to stop the clock when you Rx the last bit - so perhaps use an external interrupt to catch the rising edge of the start bit and modify the timer counter generating the I/f clock generator to stop on the last Rx bit. That assumes you know the length of the Rx block beforehand, otherwise you'll have to modify the counter as you decode the Rx data.

Things might be a bit more complicated if the receive block is not an integer multiple of the word lengths supported by the USART (usually 7,8 and 9 bits). If not you might have to bit bang a few bits at the start or end of the block. The latter has the advantage that you can easily stop the I/f clock at the right point.

Another complication is that for data rates above 2Mb/s you need to generate the Rx clock into the USART from a 2nd timer suitably phase offset from the I/f clock to deal with delay compensation. Ideally the delay compensation measuring clock will be at least 8 x data rate, so a 48MHz would be needed for a 6Mb/s data but you might get away with less depending on cable length and the amount of noise.

If a 48MHz MCU proves to be a bit of a struggle, 72 or 80MHz or more parts are still very cheap at less than $2 (eg. STM32F301). If you like a challenge and you are an assembler Ninja then maybe you could get away with a 20MHz 8-bitter but perhaps not something to get your company's future on!

[EEVblog]

There are now small pin count FPGA's, Lattice IIRC, have you looked into those?

[Mr. Scram]

Maybe you want to look at Cypress PSoC devices. Even though they provide a relativaly modest amount of FPGA type fabric they all come with one or two ARM processors alongside it. You might be able to cut the HDL down by using the processor for some parts. You can use predefined modules or write your own in Verilog. If I recall correctly DMA is available too. The footprints can be quite small. Various options are available and I think they come with various analogue features as well.

It could be the wrong tool for the job, but I thought I'd mention them.

[Leonelf]

There are now small pin count FPGA's, Lattice IIRC, have you looked into those?

I looked into them once and found the software to look quite frightening  I'll look into them again

EDIT: Going by LE-count, the Lattice iCE FPGAs seem pretty expensive to a simple MAX10, do they have special features I missed?

[Mr. Scram]

I looked into them once and found the software to look quite frightening  I'll look into them again

EDIT: Going by LE-count, the Lattice iCE FPGAs seem pretty expensive to a simple MAX10, do they have special features I missed?

I think LEs are hard to compare directly due to differences in design and comparisons therefore tend to be handwavy.

[ogden]

Things might be a bit more complicated if the receive block is not an integer multiple of the word lengths supported by the USART (usually 7,8 and 9 bits).

Indeed things are complicated when you use USART where you shall be using SPI. ENDAT is synchronous interface with separate clock line. Why would you even consider to suggest USART here 

Otherwise I agree - ARM microcontroller with SPI peripheral can do the job. DMA can be implemented as well - if needed. I would not even call it abusing of SPI because it is flexible I/O "standard" and seems to be ok for ENDAT protocol. I may stand corrected here, but seems like ENDAT was made with SPI peripherals in mind.

You can use either very small ARM microcontroller with CAN and SPI interface as "I/O helper" or try to find bigger one with as many SPI peripherals as needed. AFAIK STM32F302RE have 4xSPI. Have no info about other brands and ARM uCs'.

[NorthGuy]

There are now small pin count FPGA's, Lattice IIRC, have you looked into those?

I looked into them once and found the software to look quite frightening  I'll look into them again

EDIT: Going by LE-count, the Lattice iCE FPGAs seem pretty expensive to a simple MAX10, do they have special features I missed?

If you want FPGA, Xilinx's Spartan-7 is now out. They start from $15.

[Leonelf]

I've found the Lattice ICE5LP4K-SG48ITR to fit my design (the 2k aswell).
I'll use an external SPI-Flash (36cents are nothing compared to the OTP-NVCM of the FPGA)

Are there inexpensive ways to program this FPGA? The original Lattice programmer seems to be an FTDI based SPI translator so could I just use the FTDI ft232 cable with the integrated multi-protocol engine?

[AloyseTech]

Most of the Cortex M0+ have single cycle IO write. I’m able to toggle at 24MHz with an ultra cheap ATSAMD09 (available in tiny package). It is useful for bit banging. Maybe the cpu itself will not be sufficient for handling the whole protocol at that speed though.

[asmi]

Are there inexpensive ways to program this FPGA? The original Lattice programmer seems to be an FTDI based SPI translator so could I just use the FTDI ft232 cable with the integrated multi-protocol engine?

I used FTDI's 3.3 V MPSSE cable - just google connection diagram and make sure you actually use 3.3 V cable, or you're going to toast your FPGA.

[Bassman59]

There are now small pin count FPGA's, Lattice IIRC, have you looked into those?

I looked into them once and found the software to look quite frightening  I'll look into them again

EDIT: Going by LE-count, the Lattice iCE FPGAs seem pretty expensive to a simple MAX10, do they have special features I missed?

If you want FPGA, Xilinx's Spartan-7 is now out. They start from $15.

Lattice MachXO2 family has parts that are easily half that price. Of course, it all depends on what he actually needs.

[Bassman59]

Things might be a bit more complicated if the receive block is not an integer multiple of the word lengths supported by the USART (usually 7,8 and 9 bits).

Indeed things are complicated when you use USART where you shall be using SPI. ENDAT is synchronous interface with separate clock line. Why would you even consider to suggest USART here 

Some (most?) ARMs' USART module can be configured to do SPI. After all, the acronym is for Universal Synchronous/Asynchronous Receiver/Transmitter, and in synchronous mode it will generate the shift clock (if set up as master) or use an external shift clock (if a slave).

[splin]

Things might be a bit more complicated if the receive block is not an integer multiple of the word lengths supported by the USART (usually 7,8 and 9 bits).

Indeed things are complicated when you use USART where you shall be using SPI. ENDAT is synchronous interface with separate clock line. Why would you even consider to suggest USART here 

Some (most?) ARMs' USART module can be configured to do SPI. After all, the acronym is for Universal Synchronous/Asynchronous Receiver/Transmitter, and in synchronous mode it will generate the shift clock (if set up as master) or use an external shift clock (if a slave).

Precisely; you don't need or want to use SPI for this at all - just the synchronous part of a USART. SPI is just a particular protocol that runs on top of a USRT (the synchronous part of a USART) but is not a good fit with the ENDAT protocol.

[NorthGuy]

There are now small pin count FPGA's, Lattice IIRC, have you looked into those?

I looked into them once and found the software to look quite frightening  I'll look into them again

EDIT: Going by LE-count, the Lattice iCE FPGAs seem pretty expensive to a simple MAX10, do they have special features I missed?

If you want FPGA, Xilinx's Spartan-7 is now out. They start from $15.

Lattice MachXO2 family has parts that are easily half that price. Of course, it all depends on what he actually needs.

True, but the software is less frightening

You probably can do this with $3 PIC if money is a concern.

[ogden]

SPI is just a particular protocol that runs on top of a USRT (the synchronous part of a USART)

I bet you are talking about serial peripheral of AVR/Arduino Other microcontrollers are not like that. Also better improve your knowledge about SPI before you dare to say that (synchronous) USART is ok for ENDAT but SPI - not.

[guenthert]

Perhaps a solution has already been identified, just wanted to have mentioned (perhaps not suitable for the given use case, but I think generally for 'custom serial protocol'):
1. (for modest speeds, say up to around 1Mbaud): Parallax Propeller.  It has its drawbacks (one of them the need for an external I2C addressed (EEP)ROM), but it's probably the easiest to program.
2. (for considerably higher speeds, but at the cost of considerable complexity): TI Sitera ARM e.g. the AM3358 (as used in Beagle Bone Black, etc.) with its two PRUs which are explicitly made for this purpose.

[NivagSwerdna]

FYI http://www.ti.com/lit/ug/tidual5/tidual5.pdf is an interesting read Sitara™ AM437x.

[Bassman59]

SPI is just a particular protocol that runs on top of a USRT (the synchronous part of a USART)

I bet you are talking about serial peripheral of AVR/Arduino Other microcontrollers are not like that. Also better improve your knowledge about SPI before you dare to say that (synchronous) USART is ok for ENDAT but SPI - not.

We were talking specifically about ARM (see my post). The handful of ARMs I've looked at -- Cortex M3 parts from SiLabs, Atmel and NXP -- have a USART peripheral which can be configured as, among other things, SPI, either master or slave. (Some even have a simpler peripheral called SPI, just to make things more confusing.)

I've never used ENDAT, nor do I know what it is.

[ogden]

Atmel and NXP -- have a USART peripheral which can be configured as, among other things, SPI, either master or slave

Then blame them or initial poster, but not me:

I think you should be fine with just about any ARM Cortex M0 or better with a USART and preferably DMA.

Suggesting plain USART (Universal Synchronous/Asynchronous Receiver/Transmitter) when you mean either synchronous serial or SPI is much more confusing. In case you wonder why - check roots of USART abbreviation.