Forgot your password?
No account? Register one!
May 7, 2011
News - New Product Friday: Flex … |
about 2 months ago
You don’t see many 3D armadillo’s here in Texas..
Product WRL-09582 |
about 3 months ago
Product DEV-10306 |
about 6 months ago
Getting ready for Christmas - $.$
Sometimes the lights appear to have latency but it is purely cell-phone-camera related.
Product BOB-11611 |
about 7 months ago
I thoroughly read the datasheet and saw the obvious intent with the board to provide daisy-chaining, but didn’t notice the entirely alternate wiring shown in the schematic. Per the datasheet, this board could have had a single 5x2 header in, and a single 5x2 header out, with no extra one-wires. It will work, but the daisy-chaining could be greatly simplified by conforming to the datasheet.
:( (first-ever frowny face @ sparkfun)
From AutoDriverSupport.cpp -
// SPIXfer()…A very important
// note regarding chip select- holding the CS line low results in data being
// shifted THROUGH the chip, not into it. To latch data, CS must be released
// after each byte. I can’t find a reference to this in the datasheet, which
// is AWESOME, and I’ve personally discovered it at least twice."
This was intentional and expected behavior per the datasheet:
Page 37: CS lines should all be tied together; MISO should return to CPU from last driver in chain
Page 54: NOP = 0x00
To command the n-th driver in the chain:
1) Hold CS
2) Transmit (CommandForNthModule + (NOP * (n - 1)))
3) Release CS
These appear to be daisy-chainable, except that CS is not connected per the datasheet example.
Please recommend a method for addressing modules in the chain after the first.
Product COM-10982 |
I am having the same issue. If/when rotation is detected, it is immediately cancelled by an opposing rotation detected at the same time. Turning the encoder one detent at a time, will not increment a counter. This is already soldered into the RingCoder breakout and I doubt it’s going to come back out easily.
No public wish lists :(