We will be closed on November 25, 2021 and November 26, 2021 in observance of the Thanksgiving holiday. We will resume normal operations on November 29, 2021. Wishing you a safe and happy holiday from all your friends at SparkFun!


Receive a free SparkFun USB Thumb Drive with every order this weekend. Details.


Member Since: March 28, 2008

Country: United Kingdom

  • It will run at 80+MHz as it has a PLL, and it is very accurate from a 12MHz xtal, certainly not +/- 10%. Read the datasheet.

  • Forget it. The SAM3 has no MMU, so no Linux. uClinux would even be a really tight squeeze.

  • You can fuse the data off-chip:



    It isn't as hard as you would imagine.

  • Eric,
    This does not look so hard to do; if you have the MPL sources then there are a couple of places that you need to start to hack to get the ADXL345 integrated. I have this board, but then I also have an MPU-6050 breakout too as I have ordered a lot of MPU-6050s from the UK distributor. But I also have an interest in getting this board supported.
    This breaks down into a couple of things you need to do:

    1. Write an ADXL345 driver for the accelerometer. This will be the meat of the project, but there are examples for the Kyonix and Mantis (6050) accelerometers.

    2. Set the accelerometer and gyro orientation relative to the frame. This is done through MLSetAccelCalibration and MLSetGyroCalibration. The documentation isn't of much use because it's not up to date. You are probably better off reading the sources which have better Doxygen comments and poke about in the code. Of course, it would help if you had the reference board to start with to gain confidence in any port.

  • ...after a bit more looking and expeimentation, ok, it is indeed 8 intensities as Bandtank says...

  • ...here's what bitrev is, minus loops:
    static int
    bitrev(int x)
    unsigned y = 0;
    if (x & 0x01) y |= 0x80;
    if (x & 0x02) y |= 0x40;
    if (x & 0x04) y |= 0x20;
    if (x & 0x08) y |= 0x10;
    if (x & 0x10) y |= 0x08;
    if (x & 0x20) y |= 0x04;
    if (x & 0x40) y |= 0x02;
    if (x & 0x80) y |= 0x01;
    return y;

  • This may well help some of you. Leading spaces are removed on the post by facist software and I can't post long, so more follows...
    static void
    // Get shield's SPI driver.
    CTL_SPI_DRIVER_t d = nb_shield_spi_driver();
    // CS is output.
    // Configure SSP0.
    // Configure 8-bit SPI, 50kHz as required by stock firmware.
    lm3s_ssi0_init_polled(8, PL022_OPTION_SPI_MODE0);
    for (;;)
    // Firmware is quite lame.
    // Random 4-bit color for each component. Unfortunately,
    // Button Pad expects data LSB first, so bit-reverse at this
    // level as the SPI driver can't do it!
    for (int i = 0; i < 16
    3; ++i)
    buttonpad[i] = bitrev(rand() & 15);
    // Send LED RGB data and force through status information.
    ctl_spi_write(d, buttonpad, 16*3);
    ctl_spi_write(d, 0, 16);
    // Firmware is quite lame.

  • I took a look at the firmware and the schematic. And as far as I can tell, you have four bits for each of the RGB components, i.e. 12 bit color or 4096 colours. That's sort of OK, but contrary to the marketing blurb. I mean, mixing the LEDs isn't exactly great.
    Perhaps SparkFun don't really know much about this thing now.
    I'm tempted to rewrite the firmware so it's faster, cleaner, and much, much nicer. There's a lot I don't really like about the firmware:
    1. CS is active high!
    2. When clocking using hardware SPI, the Button Pad expects data in the opposite bit order to standard SPI!
    I did get a single board running the stock firmware nicely. You wouldn't know how to get the thing working unless you looked at the firmware.
    What I did was bit-reverse all my colour data and constrain it to 4 bits. So, 0-F for the 15 intensities get mapped to 0, 0x80, 0x40, 0xc0, ... You just bit-reverse the byte and shove it out hardware SPI.
    Sorry, my code runs on a SolderCore (www.soldercore.com) so it's not much use to you stuck in AVR land.
    And I would have thought you'd like n LEDs when configured for n boards, not 'figure out where the LED is'. Count them, not place them!

  • It's a shame that the shield uses A0 and A1 as these are the default I2C pins for other shields (such as the Jee Labs Plug Sield and your own WiiChuck Adapter). Perhaps for a "V2" you might consider a configuration option to move them off the I2C pins?
    And yes, putting all the bits in a single kit would be the ideal.

No public wish lists :(