Pins as variables?

[SwingeyP]

I want to define the controller pins as variables. Is this possible?

The project is to switch a random output on for a random period of time.

So far I have this ...

Dim seed As Long
Dim random As Word

seed = %11000111
start:

random = rand(9)

PORTA.random = 1 'This doesn't work is it possible to address each pin as a variable?

Goto start
End                                              


Function rand(range As Byte) As Word
Dim i As Byte
Dim feed As Bit
Dim temp As Long
For i = 0 To 7
    feed = seed.7 Xor seed.2
    seed = ShiftLeft(seed, 1)
    seed.0 = feed
Next i
temp = seed And 255
temp = temp * range
rand = temp / 256  'To 0 - range
End Function

I think you'll get the idea. I want to be able to say Pin.random = on blah blah blah ....

Regards - Paul

 

[BioniC187]

create a case where the random number corresponds to the pin number
Like this:

random = rand(9)

switch random

case 1: pin1 = HIGH

case 2:  pin2 = HIGH
etc...

 

[NorthGuy]

You can do

Dim i As Byte
Dim Bits(0 to 9) As Word
Bits(0) = 1
For i = 1 to 9
  Bits(i) = Bits(i-1)*2
Next i

Then, instead of

PORTA.random = 1

you do

PORTA = PORTA Or Bits(random)

If you use PIC, you need LATA, not PORTA.

 

[SwingeyP]

I thought about the case but wondered if there was a better way. The more I think about it the case solution is best. It will allow me to do other things depending on the random number.

Thanks for the help - Paul

 

[3v0]

The case solution is also more portable.

 

[misterT]

Instead of calling rand you could just say:
random = random+1

And when the user hits the button, just take a remainder
random % 7
(or whatever range you need)

That is much better random than the library rand-function.

Also, switch-case is really a bad programming structure. Use if and else -statements instead.

 

[3v0]

Also, switch-case is really a bad programming structure. Use if and else -statements instead.

Why?

 

[misterT]

Why?

There is just too many things that can go wrong. And compilers do equally good job with if-else statements. This is more of a personal philosophy than a truth, but I do avoid using switch-case.

 

[NorthGuy]

There is just too many things that can go wrong. And compilers do equally good job with if-else statements. This is more of a personal philosophy than a truth, but I do avoid using switch-case.

I can guess why. Because in C you need a break after every case. If you forget it then things can go very wrong.

 

[misterT]

I can guess why. Because in C you need a break after every case. If you forget it then things can go very wrong.

Exactly. When you go and edit switch-case structure you need to be very careful. Too many traps.

 

[3v0]

Not to argue but why is it any harder to ensure you use a break where needed then it is to match {}'s. It is not. Just a matter of what you are used to I expect.

I recall more then on if else nightmare.

 

[NorthGuy]

Not to argue but why is it any harder to ensure you use a break where needed then it is to match {}'s. It is not. Just a matter of what you are used to I expect.

If you forget to close {}, you'll get a compiler error. If you forget the "break", your program is just doing wrong things and, in this particular case, it might be hard to figure out why.

 

[misterT]

Not to argue but why is it any harder to ensure you use a break where needed then it is to match {}'s. It is not. Just a matter of what you are used to I expect.

I recall more then on if else nightmare.

It is good to argue
I don't think there is any advantage using switch-case over if-else. Like I and NorthGuy said there are only disadvantages when using switch-case. Not really a big deal if you want to use it. Sometimes there is a reason to use switch-case, but I do not have a good real-life example.

 

[3v0]

I make the case that although you get the compiler error you do not always have a good indication where it is. At times the compiler only points it out at the end of the program. Switch case is intended to simplify this sort of logic.

Would be nice if compilers would warn about missing breaks. (just looked and there is a lot of questions on how to do that) That would be a dead easy thing to detect. I expect lint would catch it but few use it.

Heck how hard would it be to write a parser to do just that. Call it from your make file.

Use what works for you.

 

[be80be]

What basic is the op using? And case statements don't always work as planed. I think there lazy way of writing a " if else" statement.

 

[3v0]

What basic is the op using? And case statements don't always work as planed. I think there lazy way of writing a " if else" statement.

LOL 'code' never works as planned.

Yeah they are a 'lazy way' but so is using c instead of ASM. It is just another tool in you box.

We were warned about missing breaks the first time I seen a switch. In decades of programming I have not been bitten any worse then if else.

 

[nsaspook]

The 'Case' statement is pure C magic if used with a little imagination.

https://groups.google.com/forum/#!msg/net.lang.c/3KFq-67DzdQ/TKl64DiBAGYJ

 

[BioniC187]

I've never had an issue with case. I write out the skeleton of the code, and its easy to keep track of breaks etc that way

 

[3v0]

I found switch/case to useful with cooperative multitasking. This is the taskBeep example from NAOS (Not An OS). Task states are identified by the nature of switch/case.

Not that it matters for the point I am making but kTimer[] is an array of counter variables that are decremented each time a free running timer passes zero.

# define state case
...
void taskBeep(void)
{
  static byte seq=0;   // current state of task
  switch (seq)   
  {
    state 0: // INIT
      kTimer[DUR]=750; //  duration of beep
      seq=1;
      break;
    state 1: // ON
      SPEAKER_BIT_HI;
      kTimer[BEEP]=2; // 1000 Hz
      seq=2;
      break;
    state 2: // OFF
      SPEAKER_BIT_LO;;
      if(kTimer[DUR]) // another pulse
      {
        kTimer[BEEP]=2;
        seq=1;
      }
      else // generate a rest
      {
        kTimer[BEEP]=750;   // sleep for 750 counts
        seq=0;
      }
  }
}

It is 6AM so there is a good chance I made some goof in this post.

 

[misterT]

3v0: If you add a state 3 in that code and forget to add the break in state 2, you are in trouble. Those are the traps that switch-case structure has. You could achieve exactly same behavior using if-else if and the code would be shorter and more readable.