@JonnyMac said:
This code is the equivalent of pinwrite() after the signals from each stream have been moved into a parallel group.
wr_outs testb outs, #5 wc ' lsb pin in outa or outb?
if_nc setq outsmask ' mux pixouts into outa using outsmask
if_nc muxq outa, pixouts
if_c setq outsmask ' mux pixouts into outb using outsmask
if_c muxq outb, pixouts
SETQ does not have to be immediately before MUXQ, unlike most instances of SETQ. It can be a few or many instructions earlier, as long as Q is not changed in the interim. (Another SETQ is not required before the next MUXQ if the mask is the same and nothing else modifies Q.) Therefore the following code is possible:
wr_outs setq outsmask '
testb outs, #5 wc ' lsb pin in outa or outb?
if_nc muxq outa, pixouts ' mux pixouts into outa using outsmask
if_c muxq outb, pixouts ' mux pixouts into outb using outsmask
I wondered about that, Tony, but ended up duplicating what Chip does in the interpreter. The docs on setq are a little confusing; I interpreted them as saying that q gets reset after the next instruction.
From the latest interpreter:
' PINWRITE(pins,val)
'
pinwrite_ mov w,x 'w=val
setq #2-1 'pop pins and new top of stack
rdlong x,--ptra 'y=pins
ror y,#6 wc 'get outa/outb flag into c
bmask v,y 'make mask
rol y,#6
rol v,y 'justify mask
rol w,y 'justify val
if_nc setq v 'mux val into outa using mask
if_nc muxq outa,w
if_c setq v 'mux val into outb using mask
if_c muxq outb,w
_ret_ dirh y 'enable outputs
Took a peek at the @JonnyMac gamma function today and can now see how this WS2812C version with 5 mA max is much better here (for most cases) than the WS2812B version at 12 mA max.
First of all, you probably don't want full power, even with the C version, so probably limiting max to some value like 25 % or so. I mean, maybe there is a case for blinding brightness, but that is probably unusual...
Anyway, when a limited max gets factored in with gamma, looks like the range of possible levels would be very limited with the B version...
As Ray was kind enough to send me a board, I did! -- throw Jinx at it. Thanks for mentioning it, Terry. The only lighting controller I'd ever used before was version 2 of Vixen.
I kind of muddled my way through Jinx, but did get it working. Now that it works I should probably read the Jinx docs!
The first three elements of the Setup menu will get you there.
Step 1: Define the matrix size. The only thing I did was change the dimensions.
Step 2: Add an output device -- in this case we use serial via the Gledinator protocol.
Step 3: Patch the matrix to the serial device.
Click on Fast Patch and then select Linewise starting Bottom Left if your board is oriented connector left, pixels right like mine is (see video). Funny, I modified my driver this morning because I expected lighting control software would want to start in the upper left. There are other reasons to use the latest driver (in the archive), but we don't need to use the vertical flip feature I added when using Jinx.
Since the code using the programming port, download the project first, then you can run data to it.
IMPORTANT: Set the master level very low before clicking on Start Output to prevent drawing too much current from the USB port.
See post #41 for the latest version of the Jinx player code.
@JonnyMac Thanks for figuring that all out! Downloaded Jinx and can see being fun to play around with.
Scrolling text needs some work though. Need to somehow get a font that actually works in there...
Also, why can't text be black? Don't see any way to do that.. Maybe that's just a bad idea or something...
Got Jinx working! I guess it is neat even at 8x8.
The one thing that took me a minute to figure out is that the "Start Output" on the menu is also a toggle button.
Start Output needs to be turned off and then back on for changes to take effect, seemed like.
The need to turn down the master (brightness) is a bit not so nice as it makes the preview window too dark to see.
Maybe need to do this in the driver instead...
Start Output needs to be turned off and then back on for changes to take effect, seemed like.
That isn't my experience -- I can select something different from the Channel 1 drop-down menu an it will immediately take effect.
The need to turn down the master (brightness) is a bit not so nice as it makes the preview window too dark to see.
Maybe need to do this in the driver instead...
Easy-peasy lemon squeezy. There is a scaling method in the driver -- change your main code to this. I just tried it with the master level on Jinx set to 100% (fully right).
pub main() | p_buf, b, color
setup()
repeat
p_buf := @pixbuf0 ' point to pixel buffer
repeat
wait_sync()
b := jinx.rx()
if (b == $01) ' header/sync?
quit ' yes, exit to process stream
repeat N_PIXELS ' process pixel stream
color.byte[3] := jinx.rx() ' red
color.byte[2] := jinx.rx() ' green
color.byte[1] := jinx.rx() ' blue
color := rgb.scale_rgb(color, 13) ' limit to ~5%
long[p_buf] := color ' write adjusted color to buffer
p_buf += 4 ' point to next pixel
This is for testing. I will update the Jinx player code so the scale is set as a constant above the code.
A few minutes later... Here's a code update that incorporates what I show above using a constant called PIX_LVL instead of a literal value.
Comments
Hmm... Ok, guess overkill... Still if can strobe at 40*900/8 = 4.5 kHz... Maybe good as a flash for high speed camera...
SETQ does not have to be immediately before MUXQ, unlike most instances of SETQ. It can be a few or many instructions earlier, as long as Q is not changed in the interim. (Another SETQ is not required before the next MUXQ if the mask is the same and nothing else modifies Q.) Therefore the following code is possible:
wr_outs setq outsmask ' testb outs, #5 wc ' lsb pin in outa or outb? if_nc muxq outa, pixouts ' mux pixouts into outa using outsmask if_c muxq outb, pixouts ' mux pixouts into outb using outsmaskI wondered about that, Tony, but ended up duplicating what Chip does in the interpreter. The docs on setq are a little confusing; I interpreted them as saying that q gets reset after the next instruction.
From the latest interpreter:
' PINWRITE(pins,val) ' pinwrite_ mov w,x 'w=val setq #2-1 'pop pins and new top of stack rdlong x,--ptra 'y=pins ror y,#6 wc 'get outa/outb flag into c bmask v,y 'make mask rol y,#6 rol v,y 'justify mask rol w,y 'justify val if_nc setq v 'mux val into outa using mask if_nc muxq outa,w if_c setq v 'mux val into outb using mask if_c muxq outb,w _ret_ dirh y 'enable outputsMoments later....
Okay, that works. Thanks for the feedback.
Took a peek at the @JonnyMac gamma function today and can now see how this WS2812C version with 5 mA max is much better here (for most cases) than the WS2812B version at 12 mA max.
First of all, you probably don't want full power, even with the C version, so probably limiting max to some value like 25 % or so. I mean, maybe there is a case for blinding brightness, but that is probably unusual...
Anyway, when a limited max gets factored in with gamma, looks like the range of possible levels would be very limited with the B version...
You should load the latest version of of Blitzen 24 for this. It would be neat to throw Jinx at it.
Jinx looks neat but probably overkill for 8x8... Do have a 64x32 that would be more interesting for that though...
As Ray was kind enough to send me a board, I did! -- throw Jinx at it. Thanks for mentioning it, Terry. The only lighting controller I'd ever used before was version 2 of Vixen.
I kind of muddled my way through Jinx, but did get it working. Now that it works I should probably read the Jinx docs!
The first three elements of the Setup menu will get you there.
Step 1: Define the matrix size. The only thing I did was change the dimensions.
Step 2: Add an output device -- in this case we use serial via the Gledinator protocol.
Step 3: Patch the matrix to the serial device.
Click on Fast Patch and then select Linewise starting Bottom Left if your board is oriented connector left, pixels right like mine is (see video). Funny, I modified my driver this morning because I expected lighting control software would want to start in the upper left. There are other reasons to use the latest driver (in the archive), but we don't need to use the vertical flip feature I added when using Jinx.
Since the code using the programming port, download the project first, then you can run data to it.
IMPORTANT: Set the master level very low before clicking on Start Output to prevent drawing too much current from the USB port.
See post #41 for the latest version of the Jinx player code.
@JonnyMac Thanks for figuring that all out! Downloaded Jinx and can see being fun to play around with.
Scrolling text needs some work though. Need to somehow get a font that actually works in there...
Also, why can't text be black? Don't see any way to do that.. Maybe that's just a bad idea or something...
Got Jinx working! I guess it is neat even at 8x8.
The one thing that took me a minute to figure out is that the "Start Output" on the menu is also a toggle button.
Start Output needs to be turned off and then back on for changes to take effect, seemed like.
The need to turn down the master (brightness) is a bit not so nice as it makes the preview window too dark to see.
Maybe need to do this in the driver instead...
Cool.
That isn't my experience -- I can select something different from the Channel 1 drop-down menu an it will immediately take effect.
Easy-peasy lemon squeezy. There is a scaling method in the driver -- change your main code to this. I just tried it with the master level on Jinx set to 100% (fully right).
pub main() | p_buf, b, color setup() repeat p_buf := @pixbuf0 ' point to pixel buffer repeat wait_sync() b := jinx.rx() if (b == $01) ' header/sync? quit ' yes, exit to process stream repeat N_PIXELS ' process pixel stream color.byte[3] := jinx.rx() ' red color.byte[2] := jinx.rx() ' green color.byte[1] := jinx.rx() ' blue color := rgb.scale_rgb(color, 13) ' limit to ~5% long[p_buf] := color ' write adjusted color to buffer p_buf += 4 ' point to next pixelThis is for testing. I will update the Jinx player code so the scale is set as a constant above the code.
A few minutes later... Here's a code update that incorporates what I show above using a constant called PIX_LVL instead of a literal value.