I have a little snippet (below) that drives a WS2812 its from a PIC16F1827
running at 32Mhz. Its 1 instruction cycle long (in assembler) its reasonabl=
y
easy to follow but it will give you a start... You need to set up the base
address for the data table and enter with the number of leds in 'w' it exit=
s
after sending the whole string and latching it...

Steve

;***************************************************************
;***************************************************************   =20

RGB_OUT		; Drive for WS2812 differential time for 0/1
			; initial setup is the data table of w*3 bytes with
the output information
	movwf		RGB_Bit_Count		; contains number of leds
	clrf		RGB_Byte_Count	; counter is empty
	movlw		.3			; number elements per led
	addwf		RGB_Byte_Count,f	; total number of bytes
	decfsz		RGB_Bit_Count,f	;=20
	goto		$-2			; and again

	clrf		FSR0H			; that's pointing to data
	movlw		RGB_BASE		; lowest ram location
	addwf		RGB_Byte_Count,w	; number of leds
	movwf		FSR0L			; pointer set
	movlw		.8
	movwf		RGB_Bit_Count		; preload counter
=09
RGB_Byte_loop 				;outer loop tight code from here.

	movfw	INDF0				; grab led data
1.875=09
	movwf	RGB_Temp			; and store
2uS

RGB_Bit_Loop	; inner loop must be 1.25uS		=20

	bsf		PORTB,0		; start of data out 		0us
	lasf		RGB_Temp,f		; rotate through carry
..125
	btfss		STATUS,C		;
..25
	bcf		RGB_DQ		; zero	clear output or nop	.375
	nop					;
..5
	nop					;
..625=09
	bcf		RGB_DQ		;				.75
	movlw		.8			; bit count val
..875				=09
	decfsz		RGB_Bit_Count,f	;				1.00
	goto		RGB_Bit_Loop		;
1.25

	movwf		RGB_Bit_Count		; reload bit counter
1.375
	decf		FSR0L,f			; new led byte
1.5
	decfsz		RGB_Byte_Count,f	; next byte
1.625=09
	goto		RGB_Byte_loop	;				1.75

RGB_OUT_Exit
	movlw		.135			; latch pulse 51.2uS
	goto		Short			; do it auto returns from
here....
=09


;***************************************************************
;***************************************************************
Short		; blocking short timer
		movwf	US_Timer			; period
		decfsz	US_Timer,F			; do time
		goto    $-1				; more
		return

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Josh Koffman
Sent: 22 April 2014 18:50
To: Microcontroller discussion list - Public.
Subject: [PIC] Animation Sequence Storage

Hi all,

I'm currently on a flight, which leaves me with time to think.
Dangerous! I'm writing this on my phone, so please excuse any typos.

As I've mentioned a couple of times, I'm hoping to start playing with the
WS2812 LEDs soon. For those that don't know, they are a 5050 sized RGB LED
with a build in driver, so you talk to them via one wire. And they chain
together.

Once I get code working to actually drive them, it occurs to me that I migh=
t
want to play back a small sequence of cues. Most of the stuff I make is
controlled by an external data source, so this isn't something I have dealt
with much. Actually, I did it only once before, and the method I used was t=
o
store a bunch of values in various tables. I then read them back (I think 4
per second), and used the stored values for PWMing some LEDs. Not elegant,
but it worked.

For a larger project, this method could be expanded to read the data off of
an SD card. The data rate should be high enough to read enough updates to
refresh the LEDs at say, 30Hz, and a 2GB card would have enough space for a
ridiculous amount of data.

I'm wondering if there's a better way to do this. Conceivably I could
implement some sort of dimming engine, so that each saved state would also
have a time value associated with it. The engine would take the cue,
calculate the difference from the present state, divide it up over the time
value, and execute the fade.

That might be nice for data storage and manipulation, as then I don't need
to have 20 cues if I'm doing a simple 5 second fade (assuming my old 4Hz
update rate). However, the engine might be tricky to write.

So, am I missing something?

Looking forward to watching where this discussion leads!

Josh
--
A common mistake that people make when trying to design something completel=
y
foolproof is to underestimate the ingenuity of complete fools.
        -Douglas Adams
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang=
e
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.