ANT Forum

Hi Folks,

As a new adopter I'm weighing up the benefits of UART vs SPI comms with the AP2. UARTS are getting scarce in my design and since I already have a couple of devices functioning on the NXP's SPI ports it makes sense to add the ANT+ device here as well, and run it in byte sync mode as a synchronous SPI slave.

However, after reading various posts on this forum and relevant docs such as D00000794 I'm not 100% confident that this going to work out as expected, so I'm wondering if anyone out there has achieved this with LPC2xxx processors.

From what I can gather the MOSI(SOUT)/MISO(SIN)/SCLK signaling matches up with motorolas SPI standard and the AP2 docs claim that it can be used with generic hardware SPI implementations where the host MCU supports being a synchronous SPI slave. So far so good as the LPC2xxx range does this.

However I see a few posts on the forums mentioning problems with data/clock phase, and saying that the SPI standard SS (slave select) is not equivalent to the SEN# output on the AP2 (I see the SEN# does not stay low for the entire transaction in sync byte mode). Also the demo wiring in D00000794 is with an EPSON MCU USART. A USART is not equivalent to SPI, so I can't help but feel the term SPI is being used very loosely here.

Another complication is that I share the same SPI bus with other peripherals, so I will need to jump through some hoops changing mode between master/slave on the MCU SPI port when I switch talking between the AP2 and my other SPI devices on the same bus. Not a deal breaker I think - but AP2 SOUT and SCLK will need to go tri-state until SRDY# is active. All the same I'm wondering whether I might be better served by adding some extra UARTS in to my design and using async serial instead.

So, to summarise with a couple of questions;

1) has anyone successfully used NXP LPC2xxx SPI ports in sync byte mode with the AP2,
2) and if "Yes",
a) has the SPI port been shared with other peripherals?
b) would you have any diagrams code that you would be prepared to share?

Thanks in advance for any advice,

Brent.      

Hi folks,
We’ve now had success getting NXP SPI hardware working with the ANT. I was a little surprised nobody had any feedback on this thread so far. Perhaps this just means nobody is doing what I’m doing (!) –regardless I thought I’d post some pointers on the hardware integration of ANT hardware with SPI ports to help anyone else doing a forum search. Specifically this relates to using the AP2 and NXP ARM7 processors, although I believe this information would be relevant to any ANT module in byte synchronous mode communicating with a true hardware SPI port.

First up, the AP2 does not speak native SPI. SPI is a de-facto standard, introduced by Motorola in the 68HC11. Implementations by other manufacturers have various extra features or variations, but ultimately two SPI devices can typically find common ground to communicate with just by hooking up the 4x SPI lines.

ANT byte synchronous mode shares the SPI concept of master/slave communications, a source clock, and separate lines for bi-directional data. It also shares mode 3 (CPHA=CPOL=1) of timing for the clock and serial lines.

Where it deviates from the norm is that the SEN line cannot be used for SPI’s SSEL as it is released at the beginning of the last byte in a transaction rather than one clock cycle after the last bit. By the SPI standard, the slave receiving this signal should immediately abandon the transaction and tri-state the MISO line. In practice this means that SPI hardware will not be able to send or receive the ANT protocol checksum byte with this configuration.

ANT also has some extra control signals that are needed for MCU and wake power wake states. These aren’t of any particular relevance to the SPI transactions other than providing a bit of control and handshaking that the MCU needs to deal with.

So, if it’s not fully SPI compatible, why did I want to make it work with an SPI port? Saving a UART was one thing, but also operating the ANT in Byte Synchronous mode provides the lowest MCU overhead interfacing mechanism because the driver can be completely interrupt driven, make use of the SPI bit shifting hardware engine, and free up clock cycles for other things (or sleeping!). While not important to me in my current application, the MCU only needs to be awake for the shortest possible times = low power in this mode. Bit Synchronous mode requires software bit-banging, which is really a last resort option.

Anyway, at the end of the day to make the ANT work with NXP’s SPI implementation means dealing with the SEN line. In my case I just connected SEN to a GPIO (rather than SSEL) and then used another GPIO to drive the SSEL line with the correct timing (i.e. de-asserting it when I read a byte from the shift register if SEN has already been de-asserted). This means now 8x lines are needed to implement the interface to the ANT. This would be 9x if you use the H/W reset line, although you don’t need this when using the synchronous Interface since you can achieve the same result with the SRDY and SMSGRDY lines.

To get full benefit of power saving states or saving CPU cycles with the NXP hardware I’d recommend connecting the SEN line to a GPIO (or other input such as a CAP, EINT etc) that generates interrupts that can wake the MCU from deep sleep.

Also the SRDY line needs to operate as “software controlled IO” (see page 29 of the nRFAP2 spec) which means a pulse of min 2.5us. You can save a few more cycles here by using a timer output pin for this.

One last point about the NXP SPI ports. These come in a couple of flavours that support different extensions. Of particular note, SPI[0]supports LSB ordering where SSP/SPI[1] or higher do not. So using SPI[0] means you can save some cycles doing bit reversal in software. The other differences aren’t of any particular note for ANT interfacing.

OK, hopefully that helps out anyone starting out with SPI.
For the ANT team, could I suggest that SPI nomenclature be cleaned up in the product specification and D00000794? I found this misleading and it would be better to say that the clock and data timing is consistent with SPI mode 3, but that extra control signaling for SSEL will need to be added by the integrator.

As a suggestion for future specifications, could a method for switching to compliant SPI signaling be added? Looking at how SRDY is being used, perhaps if SRDY is held low at the end of the first byte from the ANT master(rather than pulsed) then this could signal that the rest of transaction will be made SPI compliant? In practice I think this means that the ANT module would keep clocking bytes without waiting for SRDY, and release SEN after the last byte was clocked out. In addition to making the transmission SPI compliant, for MCU’s implementing SPI with a ring buffer this means they could sleep after the control byte and wake when SSEL is released at the end of the complete transaction, so more power/cycle savings.

Thanks and regards,

Brent.      

Hello Brent,
thank you really; really much for the last post! It helped me alot, especially regarding the 4-Wire-SPI and the missing Checksum as well as the strange behavoir of the SEN# line.