Encoder Interface

[nickross4444]

Documentation for the board: MAX14890E.pdf MAX14890EEVKIT.pdf Encoder: amt10.pdf

Trying to figure out how to wire the encoder and Arduino to the board.

[nickross4444]

A maxim agent this is the closest they have to application documentation:

https://www.maximintegrated.com/en/design/reference-design-center/system-board/6330.html/tb_tab0 https://www.maximintegrated.com/en/design/reference-design-center/system-board/6782.html/tb_tab0

[DeepFriedDerp]

@nickross4444 I'm assuming you are planning to use HTL since the nominal supply voltage (VDD) of the AMT is 5VDC, and the minimum output high level is VDD-0.8. Feel free to correct me on this.

@gbacelli feel free to correct me, because I honestly do not have a lot of experience with various encoders/decoders. It appears that the encoder operates in a single-ended HTL mode, which means that A,B, and X on the encoder should be connected to A, B, and Z on the decoder, respectively.

From the EEVKIT datasheet, all of the switches on the S1 switch panel should be set to the ON position (flipped to the right) for SPI mode. It looks like you'll automatically set everything up for SE-HTL operation when you pull the SPI pin high.

From here, it looks like you'll need:

• The decoder SPI pin asserted high (so either connected to 5V or to an arduino DIO pin asserted high)
• The decoder HITH/CS pin connected to an arduino DIO pin set to output Pinmode
• The decoder TTL/SDI pin connected to the arduino MOSI pin
• The decoder D3Fault/SDO pin connected to the arduino MISO pin
• The decoder SNGL/CLK pin connected to the arduino SPI CLK or SCK pin
• (Optional) The decoder D2Fault/IRQ pin connected to an arduino DIO pin in input mode, maybe to one of the interrupt-capable pins. This pin will indicate if any of the encoder receiver channels has a fault detected, and a fault pin has been set in the decoder registers.

I've included a crappy visio diagram with the suggested connections (its like my 2nd time using visio, sorry about that).

Let me know if you have questions about the SPI interface, I've done a little work doing direct register reads/writes like this on an xbee before.

Suggested_Encoder_Decoder_Connections.pdf

[gbacelli]

I think we are using the wrong board. I'm sorry, it's my fault.

We should be using this one:

https://www.superdroidrobots.com/shop/item.aspx/single-ls7366r-quadrature-encoder-buffer/2397/

The website includes schematics and examples on how to connect it to arduino and encoders

😞

[nickross4444]

Gerrit and I are on a call right now, came to the same conclusion. We also talked about using Arduino nanos, either should do the job.

[gbacelli]

I'd say we go for this board if we can buy it in a reasonable amount of time. Simpler and more robust.

[nickross4444]

Sounds good

[ryancoe]

Yes, I support the getting the dedicated board; @DeepFriedDerp - can you look into ordering (probably a P-CARD thing). Please order a few extras.

[DeepFriedDerp]

@ryancoe @nickross4444 Do we want to add the encoder hookup kit or arduino headers to the order?

Also based on the recommendations on the website provided by @gbacelli, it looks like if we are going to run this on a 3.3V level system like the Due, the recommended configuration is to power the buffer board with 5VDC and bi-directionally level shift down to the 3.3V logic on the Due.

I know we can build the level-shifters if necessary, but I've used these 4-channel I2C-safe bidirectional level shift breakouts before on I2C, Serial, and SPI with no issues, and would probably be cheaper than what we could build ourselves. https://www.digikey.com/products/en?mpart=757&v=1528

[ryancoe]

Without trying to understand the details of what you guys are working through, I emphatically suggest you buy whatever components you think might be helpful.

[nickross4444]

@DeepFriedDerp I think all three are a good idea and will be useful

[DeepFriedDerp]

As a potentially unrelated side note, the Due's SAM3x8e processor has built-in quadrature decoder functionality, but I'm not entirely sure that we could use it, as the TC blocks and channels involved might be used for millis() and micros() functions, like it is in the MEGA for timer0.

I think using a dedicated decoder/buffer breakout board like we are currently doing is probably the most reliable option for right now, but thought it might be of interest for reducing the cost and complexity of the required hardware in the future. ATMEL SAM3x8e Datasheet, page 871 of 1459, Section 36.6.14 - Quadrature Decoder