Random number -> Corresponding LED lit (n00besque content contained)

[HankMcSpank]

Just had a sleep on this - I've never previously used case, and now I fresh look at it, to my eyes it's just a load of IFs?

For example....

HIGH_LED:
  SELECT CASE MyByte
    CASE 1 : HIGH LED1
    CASE 2 : HIGH LED2
    CASE 3 : HIGH LED3
    CASE 4 : HIGH LED4
    CASE 5 : HIGH LED5
    CASE 6 : HIGH LED6
  END SELECT
RETURN

could be written as...

IF MYBYTE = 1 THEN HIGH LED1
IF MYBYTE = 2 THEN HIGH LED2
IF MYBYTE = 3 THEN HIGH LED3
IF MYBYTE = 4 THEN HIGH LED4
IF MYBYTE = 5 THEN HIGH LED5
IF MYBYTE = 6 THEN HIGH LED6

So when to use case & when to use if?

Going back 20 years to when I used to write simple VMS DCL programs, I could construct code like thus...

HIGH "LED"+'MyByte'

the stuff inbetween " " was text & stuff in the ' ' was the value held in a variable

therefore the above would actually run as.....

HIGH LED1 (assuming MyByte held 1) ......presumably no similar ways of constucting in Picbasic?

[Darrel Taylor]

Select Case is a lot like a "Load of IF's" with a few differences.

1. It removes some of the (n00besque content contained) look and feel.
2. Only the first "CASE" that evaluates TRUE will execute, then it exits the SELECT block.
   In your list of IF's, if the first one is true, it still goes on and evaluates all the other IF's too.
   This allows more complex logic, where more than one test can be true, but only the first one is acted on.

The same functionality using IF statements would look like this ...

IF MYBYTE = 1 THEN
    HIGH LED1
ELSE
    IF MYBYTE = 2 THEN
        HIGH LED2
    ELSE
        IF MYBYTE = 3 THEN
            HIGH LED3
        ELSE
            IF MYBYTE = 4 THEN
                HIGH LED4
            ELSE
                IF MYBYTE = 5 THEN
                    HIGH LED5
                ELSE
                    IF MYBYTE = 6 THEN
                        HIGH LED6
                    ENDIF
                ENDIF
            ENDIF
        ENDIF
    ENDIF
ENDIF

OR, if you have PBP 2.60 you could do it like this ...

IF MYBYTE = 1 THEN 
    HIGH LED1
ELSEIF MYBYTE = 2 THEN 
    HIGH LED2
ELSEIF MYBYTE = 3 THEN 
    HIGH LED3
ELSEIF MYBYTE = 4 THEN 
    HIGH LED4
ELSEIF MYBYTE = 5 THEN 
    HIGH LED5
ELSEIF MYBYTE = 6 THEN 
    HIGH LED6
ENDIF

It may not seem like much difference with this simple example, but with large SELECT CASE blocks using more complex comparisons, it can save a boat load of execution time not having to evaluate every condition.

* SELECT CASE is also much easier to read. Especially when it's not your program.

PicBasic Pro, was written to generate the Smallest and Fastest code possible. As it is the HIGH/LOW statements only use a couple of instruction cycles. If you add in the abilities to use them like array's and access pins non-contiguously, it would make EVERY HIGH/LOW statement Bigger and Slower, breaking everyone's code, and causing more complaints than not having those abilities produces.

[HankMcSpank]

Many thanks Darrel....crystal clear now

[AvionicsMaster1]

I've tried to randomize 20 LEDs hooked up as shown in the attachment with the following code:
(Sorry, I've had to retype it. Long story.)

clear
define osc4
ansel=0
comcon0=7
adcon0=0
 
delay var word
myword var word
mybyte var byte
previous_random var byte
gpiostate var byte
tristate var byte
 
delay = 250
 
main:
random myword
mybyte = (myword//20)
if previous_random = mybyte then goto main
gosub high_led
pause delay
gpio = %000000
pause delay
previous_random= mybyte
goto main
 
high led:
lookup mybyte,[%000001, etc for 20 LEDs], gpiostate
gpio = gpiostate
lookup mybyte,[%111100, etc for 20 LEDs], tristate
trisio = tristate
return

The problem I'm having is two fold.

First, LED0 never lights. I've watched it for a about 3 minutes several times and that first LED never lights. Any ideas why?

Secondly, although I implement the previous_random scheme shown previously in the thread, I often get an LED that will light repeatedly before moving on. Any ideas why?

As always, most of your thoughts are appreciated.

[Archangel]

We really need to see the entire code esp. the lookup tables.

[HankMcSpank]

It worked perfectly for me ....any reason you have not copied the code verbatim?

Re LED1 never lighting, what happens if you comment out the random aspect & simple make mybyte = 1 (where 1 is the LED you're not seeing lighting up etc)...this should light the suspect LED up all the time & proves both the wiring/LED at least.

Re the same LED lighting in succession, I'd approach this by getting some debug/hserout info of 'mybyte' onscreen....else you're grasping in the dark. (no pun intended!)

[AvionicsMaster1]

I did run another program to ensure all the LEDs are hooked up and working. They all work using the cut and pasted look up tables provided.

Hank, when you say it worked perfectly did you use the schematic I provided? The last time I chased a problem with these LEDs, it turned out to be the circuit not the code. If you look here http://www.picbasic.co.uk/forum/show...ght=wood+chuck you'll see what I mean.

Here are the look up tables.

lookup mybyte,[%000001, %000010, %000001, %000100, %000001, %010000, %000001, %100000, %000010, %000100, %000010, %010000, %000010, %100000, %000100, %010000, %000100, %100000, %010000, %100000], gpiostate
gpio= gpiostate
lookup mybyte,[%111110, %111100, %111010, %111010, %101110, %101110, %011110, %011110, %111001, %111001, %101101, %101101, %011101, %011101, %101011, %101011, %011011, %011011, %001111, %001111],tristate
trisio= tristate

I don't currently have the knowledge to display my number on screen but if the LED is lit by another program, proving it does work, then looking at a number will only tell me that the LEDs number never comes up.