How to generate a pulse under 1uS ?

Go To Last Post
70 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
How about a sequence that shows the last two bits and the two microseconds after that?
The manufacturer didn't provide one.  The image in included in my previous post is a screencap from the datasheet (with colour added by me).

 

Quote:
If T0L and T1L apply to the last bit, then the signal has to remain high for some time after the last bit.
It does not.

 

You've been misled by the poor documentation.  As had I.  The right-hand edge of the sequence chart:

 

 

... suggests that the end of a bit must always result in a low-to-high transition.  It does not.  As you say, when there is a bit to follow, it does.  After the last bit of the last LED the line may be left in whichever state you wish i.e. you may keep it low and reset the comm line right away (after 50 us), or you can bring it high.  Since there are no LEDs after the last one to be confused by a high-idling line, and since all previous LEDs have already decoded and latched their RGB payloads and are now merely mirroring DI on DO while they wait for a reset, this should be fine but is by no means necessary.  This is one of the scenarios (idling high after the very last bit) which I did not completely test before moving on to another project.

 

Neither kk6gm's code, nor cpldcpu's library, nor the Adafruit library return the line high at the end of the last bit.  The line is merely kept low (its final state at the end of the last [well, any] bit) for at least 50 us before the next data stream is begun.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
At the end of the packet the line can stay LOW indefinitely (50us minimum to latch data) or until the start of the next packet.
Are you saying that the last TxL should be stretched indefinitely?

That is not at all obvious from the spec sheet.

 

If the other low pulses can also be stretched, that would alleviate a lot of timing problems.

It would also mean that the spec sheet is wrong about the TxL's.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

Are you saying that the last TxL should be stretched indefinitely?

That is not at all obvious from the spec sheet.

 

If the other low pulses can also be stretched, that would alleviate a lot of timing problems.

It would also mean that the spec sheet is wrong about the TxL's.

Yes, on all counts.
The library by cpldcpu states that "The only critical timing parameter is the minimum pulse length of the '0'" in reference to T0H. This is not mentioned in the datasheet. At 4 MHz his library is out-of-spec for all parameters >>except<< T0H.
While this may 'work', and indeed the other three parameters (T0L, T1H, T1L) may be very stretchable, I am still of the opinion that writing code which drives a device outside of the datasheet specs is a bad idea. Even if the datasheet is inaccurate. If later the manufacturer makes a revision to the device which breaks out-of-spec code, there is nowhere to turn and no-one to blame.
Still, I was curious when I was playing with them a year ago. Like I said, I'll get back to them when I can and report what I find (unless someone else does first ;-) ).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Jul 26, 2015 - 03:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The last TxL CAN be stretched but no other, 50 us low latches the data and reset the counters so anything after that you will be addressing the 1st LED.

 

At least that's the way my code works and the code of one of my client who has a project with 14,000 LEDs.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
The last TxL CAN be stretched but no other, 50 us low latches the data and reset the counters so anything after that you will be addressing the 1st LED.

 

At least that's the way my code works and the code of one of my client who has a project with 14,000 LEDs.

I take experience seriously.

'Twould be nice to take the spec sheet seriously.

The spec sheet implies idle high.

If that does not work and idle low does, one must bow to reality.

 

'Tis strange to me that no other TxL's can be stretched at all.

Even at 4 MHz, 40 us would be enough for nearly 160 cycles of ISRs.

As is, one needs to keep interrupts off for a rather long time.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One simple way for you to find out smiley buy a WS2812 LEDs string from ADA fruit and play with it...oh and let us know the results. wink

 

http://www.adafruit.com/category...

 

Can't see the 5m 150 (or 160??)  LEDs string anymore but they have 144 LEDs 1m strings http://www.adafruit.com/products...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know that the data sheet is not that great, but it's wrong if idle isn't high! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
I know that the data sheet is not that great, but it's wrong if idle isn't high!
+1

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed the data sheet isn't too great.

 

But the trailing vertical line is just to show the High and Low time intervals, it isn't meant to reference edges.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
But the trailing vertical line is just to show the High and Low time intervals, it isn't meant to reference edges.
-1

How does one end a low interval without a rising edge?

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One doesn't end the low interval when that interval isn't required to end (yet)
 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-1

 

How does one end a low interval without a rising edge?

I think you are missing the entire encoding concept, (albeit from a poorly written data sheet).

 

This is essentially Pulse Width Modulation.

Within each Bit Time the High interval is either short for a "O", or long for a "1".

The duration for the High Level, and for the entire Bit Time is spec'd.

(Hence the Low bit time is also spec'd, but this duration is redundant given the other info.)

Each Bit's data packet is defined by a high pulse, followed by a low segment.

 

One can view the series of 8 bits / color, 3 colors / LED, x N LEDs as a Time Division Multiplexed bit stream.

The initial High leading edge, occurring after a reset pause, initiates the timing, (conceptually).

(Agreed, the internal hardware might resynch on each bit or byte or LED).

Theoretically, one can know exactly which bit of which byte of which LED is being transmitted at any time after the initial bit's leading edge.

 

The protocol does not spec an intra-bit, intra-byte, or intra-LED time gap.

The only latitude, within spec, is the latitude given for the individual high and low durations of a given bit.

 

One sends the LED a series of Bits.

Each bit is PWM, with a leading high and a trailing low.

 

A trailing edge doesn't define the low interval.  <-- That is the key point.

The bit interval is spec'd, as in TDM, and the trailing edge on the last bit's low time isn't needed or expected or required.

 

The ending edge of the low part of the bit transmission only has a leading edge because the NEXT bit's information starts with the High portion of the PWM bit signal.

 

It is a crummy data sheet, but the system works.

 

JC

 

Edit: Typo

  

Last Edited: Mon. Jul 27, 2015 - 08:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

-1

 

How does one end a low interval without a rising edge?

I think you are missing the entire encoding concept, (albeit from a poorly written data sheet).

Being poorly written doesn't make it right.

The spec sheet authors seem to have missed it also.

 

I accept, from the results of others experiments that the device works as you describe.

The spec sheet says that it should work in a way that it does not.

The spec sheet is therefore wrong.

Not just vague.  Not just poorly written. Wrong.

 

That the device accepts pulse width modulation and the spec in the sheet somewhat resembles pulse width modulation does not make the spec sheet right.

It makes the spec sheet wrong.

Someone who fed the device only signals endorsed by the spec sheet would never get the device to work.

Quote:

 

This is essentially Pulse Width Modulation.

Within each Bit Time the High interval is either short for a "O", or long for a "1".

The duration for the High Level, and for the entire Bit Time is spec'd.

(Hence the Low bit time is also spec'd, but this duration is redundant given the other info.)

'Tain't.

The low time cannot be determined from the other given data.

 

Clearly the device works.

Clearly the spec sheet is wrong.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Not just vague.  Not just poorly written. Wrong.
Vague and poorly written, oh my goodness yes.

 

Wrong?:

DocJC wrote:
the trailing edge on the last bit's low time isn't needed or expected or required.

joeymorin wrote:
... suggests that the end of a bit must always result in a low-to-high transition.  It does not.  As you say, when there is a bit to follow, it does.  After the last bit of the last LED the line may be left in whichever state you wish i.e. you may keep it low and reset the comm line right away (after 50 us), or you can bring it high.  Since there are no LEDs after the last one to be confused by a high-idling line, and since all previous LEDs have already decoded and latched their RGB payloads and are now merely mirroring DI on DO while they wait for a reset, this should be fine but is by no means necessary.

js wrote:
The last TxL CAN be stretched but no other, 50 us low latches the data and reset the counters so anything after that you will be addressing the 1st LED.

 

I can find nothing in the datasheet which refutes this.

 

As previously mentioned, I will run some tests when I can.

 

BTW, no need to buy 5m of these things:

https://www.adafruit.com/products/1426

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'Tain't.

 

The low time cannot be determined from the other given data.

 ?

 

The Bit Time, (Data transfer time), is defined as 1.25 uS +/- 600 nS right in the data sheet.

The "0" High Time, T0H is defined as 0.4 uS, (in the data sheet).

The "1" High Time, T1H is defined as 0.8 uS, (in the data sheet).

 

It is a simple PWM data bit stream, and the inclusion of the low time is redundant.

 

Nobody is arguing it is not a great data sheet.

But it isn't the worst I've ever seen, and it is certainly sufficient to light up the LEDs.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got my assembler code working from the datasheet info but my brain works in mysterious ways if it does at all..... devil

 

It does say

 

RES  Low voltage time ABOVE 50us
 

 Which means (to me at least) that the last low transition can be 50us or longer including infinity.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
I will run some tests when I can.

 

So I did a bit of fiddling with some WS2812 (not the 'B' variant).  Here's what I found.

 

As posited by cpldcpu, parameters T0L, T1H, and T1L can be stretched quite a bit.  I don't have access to a DSO or an LA so I can't show any pictures or give authoritative figures, but it seems that each of these can be stretched such that the total bit time can be as much as 7125 ns i.e. (T0H + T0L) <= 7125 ns and (T1H + T1L) <= 7125 ns.  Note that 7125 ns is far longer than the max 1850 ns spec'd (which should probably have been spec'd as max 1550 ns, based on the specs for TxH/TxL).

 

Beyond 7125 ns and the behaviour of the LEDs becomes erratic.

 

A T0L or T1L stretched beyond 8625 ns triggered a reset.  Note that this is far short of the 50 us spec'd in the datasheet. 

 

In addition, I tested the use of an idle high condition, and got a curious result.  There are no seriously ill effects to doing so, however it did in fact confirm what js said in post #55:

 

js wrote:

The last TxL CAN be stretched but no other, 50 us low latches the data and reset the counters so anything after that you will be addressing the 1st LED.

In other words, an LED will not update the PWM drive of its R, G, and B elements until a reset condition is seen.  Keeping DI high will postpone that update.

 

The curious part is what happens to DO under these conditions.  While keeping high the DI pin on the first LED in a string will postpone the latching and PWM update of that first LED, the 'idle-high' condition is not replicated on DO.  An LED who's DI is kept high for too long will nevertheless bring its DO pin low.  How long is too long is unknown to me.  A DSO or LA would be helpful in this regard, but the lesson is still clear:  Keeping DI high or low beyond a threshold will reset and latch all down-string LEDs.  Only the first LED (directly driven by the mcu) can be forced to postpone a PWM update by keeping DI high after a transfer.  All down-string LEDs will update almost immediately, as they will see a reset condition almost immediately.

 

This doesn't resemble a feature so much as it does a design flaw.  Or at least an oversight.  It's hard to guess at the designers' intent from such a poorly written datasheet, but it seems clear enough to me that an idle-high condition is not handled well, whereas an idle low condition is.  There is some support from the datasheet in this regard:

 

 

The figure shows that the reset comes immediately after the last RGB word.  Had a high idle condition been intended, I would expect the figure would have looked something like this:

 

 

Of course the datasheet has already proven to be lacking, so that is perhaps not a reasonable expectation ;-)

 

@skeeve has pointed out that interrupts need to be disabled 'for a rather long time'.  Based on the apparent max bit time of 7125 ns and a nominal bit time of 1250 ns, there appear to be about 5875 ns available to service interrupts between bits.  At 8 MHz, that's only 47 cycles.  Opening a window for a pending interrupt would take 3 cycles (sei/nop/cli or out/nop/cli).  Vectoring and returning would take 4 cycles each, leaving 36 cycles for a hand-assembled ISR in the vector table.  If the ISR is outside the vector table, lose another 2 or 3 cycles for a jmp or rjmp, down to 33 cycles.  If the ISR is written in C, lose another 15 cycles for just the minimal prologue and epilogue.  That leaves 18 cycles for a C ISR before you've even touched a single bit or preserved any other state.  Not much, but perhaps enough for a very short, very time critical ISR.  Running at 16 MHz improves this somewhat (83/80/65 cycles).

 

While this may seem promising, there are two problems.  One is that you must guarantee the worst-case execution time of all enabled ISRs, or the WS2812 data stream will be corrupted.  Second, and more importantly IMHO, is that regardless of the quality of the datasheet, you would be driving the WS2812s out of spec.  Fine for a one-off.  Bad for production.  A change by the manufacturer could break later production runs of your product.

 

I did not explore the minimum/maximum times for T0H, nor the minimum time for T1H.  I also did not explore whether bit times could be stretched more or less on byte boundaries or RGB word boundaries.  I based my testing on kk6gm's code mentioned in post #14 running at 8 MHz, where T0H is 375 ns (3 cycles) and T1H is 875 ns (7 cycles).  Testing was done by modifying the code to extend T0L/T1L, and T1H with a granularity of 125 ns (1 cycle).

 

Only WS2812 were tested.  WS2812B were not.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Jul 30, 2015 - 04:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

parameters T0L, T1H, and T1L can be stretched quite a bit. 

If the WS2812 keeps backward compatibility with it's predecessor WS2811 (low speed mode) then it should accept a lower clock of 400KHz instead of 800KHz, so pretty much twice as long.

Don't really know as everyone always want FASTER>>>>>>>>>>

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If the WS2812 keeps backward compatibility with it's predecessor WS2811 (low speed mode) then it should accept a lower clock of 400KHz instead of 800KHz,
To my knowledge they are not backwards compatible per se.

 

The WS2811 has a pin called SET used to select the mode (400 kHz or 800 kHz).  The WS2812 has no such pin.  It operates at 800 kHz exclusively.  However as discussed, the only critical timing parameter is T0H.  Whereas the WS2812 specs that as 200-500 ns, the WS2811 @ 400 kHz specs it at 350-650 ns, so there is some overlap.  Code could be written to drive both using a value for T0H within the overlapping range.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Jul 30, 2015 - 09:51 PM

Pages