Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

SPI timing issues

SPI DLYBCT clockrate

  • Please log in to reply
11 replies to this topic

#1 Christopher Gilmore

Christopher Gilmore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationBurlington, MA

Posted 30 December 2013 - 08:04 PM

Hi All,

 

I am trying to hack some G-35 lights (similar to the Arduino project here: http://www.deepdarc....ristmas-lights/).

 

The lights need a 100KHz control signal that consists of high and low bits. I assumed that using the SPI port on the Netduino was the only way to achieve writing high and low bits this quickly (switching every 10us).

 

However, I have run into two issues using the Netduino Plus 1 SPI ports:

 

1) When I set the SPI clock rate to 100KHz, the SCLK port and MOSI ports do NOT seem to follow the 100KHz clock rate.  I need a 100KHz clock rate. (note: after some testing, it only seems to be stable when set to some value >= 200KHz). I define the port like below:

 

SPI.Configuration objSPIBus = new SPI.Configuration(Pins.GPIO_PIN_D10, // SS-pin
                false,             // SS-pin active state
                0,                 // The setup time for the SS port
                0,                 // The hold time for the SS port
                true,              // The idle state of the clock
                true,              // The sampling clock edge (this must be "true" for the 74HC595)
                100,              // The SPI clock rate in KHz
                SPI_Devices.SPI1   // The used SPI bus (refers to a MOSI MISO and SCLK pinset)
                );

 

2) Because I need to write ~80 bits to the SPI, I need to send a byte array to the port. When I do this however, I can see a small delay between bytes (using a logic analyzer). Some other post here describes the Delay between consecutive bytes being hardcoded to 0, but there still being a delay because of the way the driver is written. This delay is screwing up the way the lights are interpreting the bits. I need a way to remove this delay between bytes. How I write the bytes is below:

 

byte[] writebuffer = new byte[16];

 

//Some code to set all the byte values

//......

 

objSPIBus.Write(writebuffer);

 

So my questions are:

1. Is there a way to resolve these issues (either by some update/hack, using the Netduino Plus 2 instead, etc)?

 

2. If there is not a way to resolve the issue, is there any other approach for doing something like this on the Netduino Plus 1, without using SPI?

 

 

I am currently using:

Netduino Plus 1

.NET micro framework 4.2

Netduino firmware 4.2.0



#2 Paul Newton

Paul Newton

    Advanced Member

  • Members
  • PipPipPip
  • 724 posts
  • LocationBerkshire, UK

Posted 30 December 2013 - 08:34 PM

Hi Christopher,

 

Have you tried (could you try) increasing the clock rate to see if the delay between bytes becomes shorter?

 

(I am assuming the delay is caused by clocking the next byte into a shift register in the Nteduino hardware.)

 

If it does get shorter what you might try is seting the clock speed to 200 or 400 KHz, and adding a 74HC counter chip to divide the clock by 2 or 4 back down to 100KHz. The result should then be less gap.

The data you write out would need x2 or x4 bits, and each original bit would need to be repeated 2 or 4 times in the byte array.

 

Crazy idea - might just work.

 

Have fun - Paul



#3 Christopher Gilmore

Christopher Gilmore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationBurlington, MA

Posted 31 December 2013 - 03:22 AM

Thanks Paul.

 

Yes I did try that, and the delay seems to bottom out at 1.3us after increasing the clock. Unfortunately, even that 1.3us blip will interfere with the way it is interpreted by the lights (probably due to some edge triggering).

 

Is there any other way around it?



#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 December 2013 - 07:09 AM

Hi Christopher, Netduino Plus 2 is faster, so it may reduce the intra-byte transfer delay for you. We're also looking at the possibility of using DMA transfers in the future (which would eliminate the small intra-byte delay)--and if you're handy with C++ you could hack on that in the Netduino Plus 2 firmware today. Chris

#5 Juzzer

Juzzer

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts
  • LocationHertfordshire, UK

Posted 31 December 2013 - 10:22 AM

From a quick look at the link they appear to contain by the looks of it WS2811/12 LED's

 

The STM port for Netduino is obviously different to the one for the other lots FEZ's as you can happily drive 5m of WS2811/12 in managed code on them. Will be interesting to see what the difference is.... 



#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 December 2013 - 11:55 AM

Juzzer, Just FYI...I believe that Christopher is using a SAM7-based Netduino gen1 board. Chris

#7 Juzzer

Juzzer

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts
  • LocationHertfordshire, UK

Posted 31 December 2013 - 12:27 PM

Yeah i know, but there are timing issues on the stm boards as well... As a side note similar issue on the fez hydra bur not on the slower older fez boards. Hence my comment...

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 December 2013 - 01:02 PM

Juzzer -- interesting. Some SPI peripherals do "continuous SPI transfer" without any intra-byte pause while others have a bit of a wait. We're actually working with a similar issue on the GoBus 1.5 firmware for STM8S at the moment (where transmissions are typically constant--but the microcontroller issues a "not busy" flag pulse between received bytes). Perhaps an STM8S-based SPI driver module for RGB LED strips should be on our roadmap? That's one of the awesome things about GoBus: we can leverage the best MCU for any given application while running our NETMF app on the powerful main micro. Chris

#9 Juzzer

Juzzer

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts
  • LocationHertfordshire, UK

Posted 31 December 2013 - 01:10 PM

Chris, have a look at the other mobs codeshare for Ws2811, works really well on most devices from 72mhz to 168hz...

#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 December 2013 - 01:22 PM

Hi Juzzer, I haven't used WS2811s before, but from this article it looks like they're not actually SPI devices--but that they sample a combined clock/data line at a fixed rate. Is that accurate? The STM32 chips use a clock divisor for SPI that works at specific fractional portions of the master clock. So the divisors are 84MHz, 42MHz, 21MHz, 10.5MHZ, 5.25MHz, 2.625MHz, 1.3125MHz, 656.25KHz, 328.125KHz, 164.0625KHz, etc. When you select a SPI speed in the SPI.Configuration constructor, the board will pick the next-slower speed if the desired rate isn't an exact match. It is possible to tweak the firmware to change the master clock speed to a slower rate which is a closer or exact multiple of the desired target clock speed. Chris

#11 Juzzer

Juzzer

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts
  • LocationHertfordshire, UK

Posted 31 December 2013 - 01:30 PM

Correct. The Oberon port works well.

#12 Christopher Gilmore

Christopher Gilmore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationBurlington, MA

Posted 13 January 2014 - 05:47 AM

Hi Chris,

 

I purchased a Netduino 2 Plus and tested this again using the 4.3 beta firmware. It looks like the delay is essentially GONE between the bytes. w00t!

 

However, like you said above about the clock divisor, does that mean there is no way to get exactly 100KHz clock on the SPI bus without modifying the firmware to slow down the master clock on the device?

 

Thanks,

Chris







Also tagged with one or more of these keywords: SPI, DLYBCT, clockrate

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.