I wrote a program in SXB and want to know then benefits of converting it over to Assembly language.

If I have an SXB statement such as: OE = 1 and its Assembly equivalent is  / SETB OE, do I gain anything here?

Am I taking the wrong approach in using Run ->View List in the SX Key program menu to copy over the assembly listings line by line into my SX/B program?

Just a newbie to assembly wanting to know how to begin.

Thanks.

No you wouldn't gain anything by replacing "OE=1" with "\ SETB OE". Usually you want to convert to assembly where you will get the biggest bang (speed improvement) for the buck (time spend). So that means anything that is repeated many times. Like inside a FOR...NEXT loop.

Copying in section of the SX/B generated assembly is a great way to "play around" with assembly.

Bean.

Thanks Bean. I am just starting to look at PWM (if you haven't read my postings already). I look at my SPI SXB code and don't see any significant reason to convert it to assembly language. Is there any resource to look at to differentiate between using the SXB "PWM" command (analog? with adding an RC network) and using the SX48 Timer command mode for PWM (squarewave?). I don't know where to begin with PWM and SPI based on what I have found here and another PIC forum.

All I want to do is add PWM (RGB LED fading for eventual video input) to an /OE line on an SPI based LED driver similar to an 74HC595. Is ASM the answer or can I do this with SXB and either the PWM command on an SX28 OR do I use the SX48 Timer command mode ofr PWM?

Thanks for listening.

If you are using Interrupts in your program then you could have the ISR routine control the PWM of your display.  Just have it keep a count and toggle on/off the pin for the display.  That might be the easiest way to go.

The hardware timers of the SX48 are also another option.  They work great but there are a couple of issues to watch out for when using them.  The one that got me was that they can also generate Interrupts upon certain timer events.  If you have ISR based serial code that doesn't expect this to happen it will trash your communication.  I ran into this for a project (BOB in SERVO magazine) where I used the timer to generate the PWM to control a motor.  I just had to mask off any interrupts from the timers (since I didn't care about them) so that the only interrupts being generated were ones that I expected and had code to handle in the ISR.  Once that was done the communication issue was fixed.

Another issue to watch out for is how often you update the timers.  If you do it too often you can actually reset the count each time and never let the timer count up to toggle the state.

RobotWorkshop,
The PIC users told me that I should insert PWM is on the /OE pin, do you know how that would allow me to have 256 shades of red, green or blue LEDs. I can't quite grasp how using PWM is going to allow you to change something so specific like that over an SPI LED driver.

I only have these inputs to the display: R1A, R2A, R1B, R2B, G1, G2, B1, B2, CLK, Latch, /OE and GND.

Thanks.

I guess it depends upon a couple factors.  I've used a couple displays where the /OE would turn the entire display on/off.  If you use PWM on that line you can control the intensity of the entire display by varying the duty cycle of the PWM signal.  That should be relatively easy to implement with an existing ISR using a counter for the duty cycle or via one of the built-in hardware timers.

With the inputs on your panel I'm not sure how you would go about varying each individual color since it looks like the /OE will affect the whole display and not an individual LED or color.

I've done (toggled the enable pin with a PWM signal) that with another type of display and it works just fine.  Since you don't need super high-speed PWM for brightness control you could do it in the ISR of an SX28.  As Robert points out, though, there was just one enable pin for the entire display and everything dimmed/brightened together.

I very much appreciate all of your inputs on this.

What I don't understand is that this display is supposed to be capable of 25 bit color according to the datasheet. I don't see how getting 8 bits (256 shades) of ALL LEDS can be converted into 36 bits (I'd be happy with 24 or maybe 16 bits). These modules are daisy chained together (out to in) dozens or hunderds of times over for huge doublesided billboard size displays. Having 3 color RGB LEDS doesn't make sense to only have 256 shades of "all" LEDs.

I appologize if I am sounding demanding (but not sure if that is the word I am thinking of), but I just want to understand how it is possible to get 36 bits of color with PWM with just those RGB color data signals, clock, latch and /OE signals. Even adding additional hardware still means only connecting this to one (or more) of those input jack signals.  
No one seems to know this answer on the PIC forum either, short of adding additional hardware on the LED anodes (which are all hardwired on the PCB to VCC).

Where does someone get the experience or understanding on this technology. I certainly did not learn this in college.

I have however, learned alot about LED displays over the last 2-3 years with the forum members help especially from BEAN and JONNYMAC.

I thank everyone for the support they offer to assist Parallax users like me.

You'd probably save yourself a bunch of stressful guessing by just purchasing a module and experimenting with it -- that's really the best way to learn something new.

I have (2) 16x8 pixel RGB modules already. http://forums.parallax.com/forums/default.aspx?f=7&m=301606

I am testing this to see the possibility in controlling these modules (possibly dozens or a hundred or so) from an SX micro-controller(s) and some additional hardware. I have already sent out SPI data very much like you would for a 74HC595 to (2) cascaded displays. Now I want to understand how PWM can work with these to eventually send video RGB into these modules. These are high end display modules so it has to be possible to individually control Red, Red2, Green and Blue LEDs (256 shades each) or somehow 36 bits (as per the datasheet) with the current PCB boards attached to the LED modules.

[Quoting: ""]The only signals on each module are as follows:

R1A, R1B, R2A, R2B, G1, G2, B1, B2, CLK, LATCH, /OE, GND.

Somehow from these connections, PWM has to be possible.

My question us why are there two signals for each color?  The data sheets aren't too clear.  Well, perhaps they might have the explanation buI can't read all the text on them...

Could the second signal for each color be for the intensity of that particular color?  If so, how smart is the chip used on the display?  Since they are self refreshing I suspect that the chip must hold the intensity for each LED.  That second pin may be how you pass that information.  If they published the timing diagrams that should clearly show the relationship of all the signals but without that we'll just have to take our best guess and try some things to figure it out.

I'll take two swags at how it might be done:

Assuming the second pin for each color is for the intensity of the LED then perhaps it takes a look a the frequency present on that pin at the time the data is clocked in for that particular LED.  In that case you may have to vary that for each LED.  Another method that comes to mind is that it may not be the frequency but more like the time that second signal is clocked high/low in relation to the clock signal.  If the edges are closer or further from the edge of the clock signal than that would alter the intensity of that LED.  Without a panel here to test myself I can only make an educated guess on this.

Hopefully this will help.

RobotWorkshop,
To your question: Why are there signals for each color?

Each 16x8 RGB module has 2 datastreams of 64 bits each. So 4 of the 8 RGB data inputs are for the top datastream (e.g. R1A, R2A, G1, B1) and 4 are for the lower datastream (e.g. R1B, R2B, G2, B2). The bottom of the 2nd page of the 16x8 RGB module shows the 2 data streams in a figure. I have attached both the Module datasheet and the LED driver datasheet.

From what I have found out from a PIC user using logic - It could be related to the CLOCK.

From the LED driver datasheet on the MBI5024GF:

tw(CLK) = 20 nS on time and 20 nS off time = 40 nS total CLOCK pulse time
However, if the CLOCK should be on for 20 ns and off for 20 ns, it should be possible. I could do something like this in SXB for the SX28 chip:

CLOCK = 1
PAUSEUS 0.02 'a 20 ns pause
CLOCK = 0
PAUSEUS 0.02 'another 20 ns pause
40 nS total CLOCK * 64 bits (or 8 bytes) per RGB input (which is 8 RGB inputs to cover both upper and lower data streams) = 40 nS * 64 * 8 = 20.48 uS
Add to this total CLOCK time (20.48 uS) the 40 nS for the single Latch (20.48 uS + 40 nS) = 20.52 uS to clock through data for (1) 16x8 RGB LED module.

In the US, TV scanning is at 60 Hz so Time = 1/Freq = 1/60 Hz = 16.67 mS refresh rate.

16.67 mS refresh / 20.52 uS = 812 chances to turn on each LED on / off per refresh.

So by dividing the brightness of each pixel by 812, and sending an 'on' for that pixel for that many cycles you have 812 levels of brightness for each LED.

A sensible number of shades is 256 so the LED on or off period would be:
16.67 mS / 256 shades = 65.104 uS.

For 50% brightness this would be 65uS * 127 (1/2 of the 256 shades) = 8.268 mS.

So this gives us 8.268 mS available from the 16.67 mS for 50% brightness.

We have 256 shades of say red = 256 ^ 1 = 256 Colors possible = 256
and 256 shades of red2 = 256 ^ 1 = 256 Colors possible = 256 * 256
and 256 shades of green = 256 ^ 1 = 256 Colors possible = 256 * 256 * 256
and 256 shades of blue = 256 ^ ` = 256 Colors possible = 256 * 256 * 256 * 256 or 256 ^ 4
So 256 ^ 4 = 4,294,967,296 possible colors = 32 bit color
That is unless both reds need to be on simultainiously, in which case it would just be 256 ^ 3 or 16,777,216 colors which is 24bit color - more than enough for a video based LED display.

-------
So now we know how it may be possible to get 32 bit color ON A "SINGLE" 16x8 RGB LED DISPLAY MODULE (even though it is possible somehow to get 36 bits - but I'm more than happy with 24 or 32 bit), How do I apply this?
I stated before to add in delays or pause statements of 20 nS for the Clock on and 20 nS for Clock off. And probably want to do this also for the Latch.

How can this be information be applied (to the /OE to get the 256 shades per LED??)  or to one or more of the 8 inputs (R1A, R2A, G1, B1 <<-- UPPER DATA   R1B, R2B, G2, B2 <<-- LOWER DATA) - OR CLK, LATCH, /OE, and GND is all that is available.

Thanks.