SparkFun Electronics will be closed in observance of memorial day on Monday, May 29th. We will resume normal business hours on Tuesday, May 30th. Any orders placed after 2pm Mountain Time on Friday, May 26th will process and ship out on Tuesday, May 30th.

Member #428370

Member Since: April 12, 2013

Country: United States

  • Nothing is more fun that product quirks! (ST’s product, not sparkfun’s :) So buyer beware! The L6470 has an internal 8-bit data latch that it uses for all SPI communications (that’s why it’s so easy to daisy chain them on the same CS). However, it does not ignore CK (serial clock) when CS is deasserted! Thus, if you’re SPI master happens to have a quirk of toggling the clock line in between messages, say like the MCP2210 does, then you’ll end up with responses where each byte is shifted left a bit, LSB always zero, MSB missing.

    In case you happen to run into this, you can work-around the problem with an inverter on the clock line and configuring the MCP2210 to use CPOL = 0 (so SPI mode 2), since it doesn’t have this hiccup when CPOL = 0, and the inverter will put the clock back in the correct polarity.

    sparkfun, on your next revision of this, can you please use the POWERSO-36 package? :) :)

  • OK sparkfun, it’s complaint time:

    • You’re schematic refers to JP1, JP2, etc. They aren’t printed on the board.
    • You’re schematic refers to VS, but the board only has a V+ printed on it.

    Less confusing are these inconsistencies between the board & schematic:

    • BUSYN != BSYN
    • FLAGN != FLGN
    • OUT{1,2}{A,B} != O{1,2}{A,B}

    Can guys pretty please either:

    • update your schematic
    • provide a picture that shows which JP is which with either a photo of the board or a diagram (my copy if geda isn’t reading the eagle file for some reason).
    • At the very least, make a tiny text file that clarifies these items, eg.:

    Errata: V+ on the board is VS in the schematic The jumper with the pins V+ and GND is labelled J5 in the schematic

    etc. Thank you!

  • Oh, this is cool. It would be nice however to be able to stick in some 0.1" or 2mm headers on the sides, maybe just line two edges of this thing with little round pads w/holes in them to we can easily connect/disconnect whatever we make to something else?

  • Hello. While I don’t have this board yet (or any dSPIN to play with at all) I can tell you that your problem is a platform problem. Note that the C standard does not offer any guarantees as to the number of bits of each type. In fact, even the “byte” that we take for granted today, used to be anywhere from 5 to 12 bits!! While I don’t think you’ll run into that anymore, you have to throw out your assumptions about data size of C types and determine what your compiler is specifically doing for each C type on a specific platform. Otherwise, best case, you’re code will not work and you’ll be frustrated in trying to solve it and in the worst case, you’re code will work fine until one day when you do something over that bit threshold, when your robot arm slaps you in the head. (OK, so that was probably a very weak attempt at a “cautionary tale” :)

    So I suggest that you consider type-sniffed types from the posix library (i.e., your libc) implementation instead of the standard types “long”, “int”, etc.

    EDIT: it’s not letting me use angle brackets in the code example :( but the stdint.h, should be <stdint.h>

    #include stdint.h
    int main(void) {
        int8_t   myint8;
        int16_t  myint16;
        int32_t  myint32;
        uint8_t  myuint8;
        uint16_t myuint16;
        uint32_t myuint32;

    See also: <stdint.h>

No public wish lists :(