[SOLVED] How can we change the state of 3 adjescent

[varunme]

There will be some problems that will come if i set porte as input

so i am using portb as input and outputting to port A and E

 

[alexxx]

so i am using portb as input and outputting to port A and E

In what manner? Please elaborate in the same way as post #56.

 

[varunme]

yes,
Collect full input from portb (8bits),
and

output into porta [6bits (0 to 5)] and porte (2bits) -> but porte has three bits(0 to 3)

 

[alexxx]

Collect full input from portb (8bits),
and

output into porta [6bits (0 to 5)] and porte (2bits) -> but porte has three bits(0 to 3)

I assume that your PORTA and PORTC did not change. About PORTE you didn't mention which pins, so I am assuming pin0 and pin1. The edited code would be:

volatile unsigned char count = 0;
void TimerISR (void) 
{
  volatile unsigned char port_A = 0;
  volatile unsigned char port_E = 0;
  volatile unsigned char port_B;
  unsigned char i;

  //............................ the rest of the code remains as is.

  PORTD = port_D;  //update PORTD

  port_B = PORTB; //save PORTB
  for(i = 0; i < 6; i++)
  {
    if ((port_B&(1<<i)) || (count >= 1))  //pin will be set in any case if count > 0
    {
      port_A |= (1<<i);
      if (i)
        port_A |= (1<<(i-1));
    }
  }

  for(i = 0; i < 2; i++)
  {
    if ((port_B&(1<<(i+6))) || (count >= 1))  //pin will be set in any case if count > 0
    {
      port_E |= (1<<i);
      if (i)
        port_E |= (1<<(i-1));
      else
        port_A |= (1<<(i+5));
    }
  }

  PORTA |= port_A;  //update PORTA
  PORTE |= port_E;  //update PORTE
}

Try with this code and post back the results.

 

[varunme]

All the outputs stays at 100% , not blinking ...

 

[alexxx]

All the outputs stays at 100% , not blinking ...

That's funny because the code is the same with the PORTC and PORTD part which as you said is working OK.
Did you configured PORTB as input and PORTA and PORTE as outputs?

 

[varunme]

yes, configured as output

i have attached my code

is it because, the two for loops togather ?

 

[alexxx]

is it because, the two for loops togather ?

No. You are declaring count variable twice. Remove the second declaration and keep the first only. This will solve the problem.

 

[varunme]

hi,
Now with same code PORTD, its working perfectly, but with port A,E B its not, lot of peripherals are residing there, i am tweaking using datasheet.

 

[alexxx]

hi,
Now with same code PORTD, its working perfectly, but with port A,E B its not, lot of peripherals are residing there, i am tweaking using datasheet.

Sorry Varun, I can't help you on that. I am not a PIC expert and furthermore this issue is far from this thread's topic. I suggest you open a new thread for this. The code is working OK, I tested it yesterday in simulator. There is a very small bug, but unless you solve your peripheral problems on those ports, there is no point to further discuss it. When you are ready with the other issue you raised in your previous post about ports, you can come back here to finish this thread. It is almost solved anyway. :wink:

Cheers!

---------- Post added at 14:34 ---------- Previous post was at 14:27 ----------

PS: I don't find it a good idea to have lots of peripherals on a pin and change it from input to output and vice verca during runtime. Maybe it is better to search for a more suitable MCU with more pins, or use multiplexers for inputs and shift registers for outputs to expand the total number of IOs.

 

[varunme]

yes,
i will use shift register for real world.
But for prototyping as now, isnt it difficult to code for mux and shift register ?

 

[alexxx]

But for prototyping as now, isnt it difficult to code for mux and shift register ?

As I said I don't use PIC, but even if it was in AVR, I would cut all the other ways of those IOs on the board and leave only lights and sensors related tracks. When you test the code succesfully for the bits algorithm, you can again bring in the parts you cut and write the code for them as well. You can use a cutter to scratch and eventually cut tracks and then resolder them when you're done. I wouldn't waste time on debugging and fixing bugs for code I will not make use of in the real world. When time comes in the final sample, write the code for shift register at once. If you are using any simulator then spare your time for cutting, measuring and soldering and finish the bits code in Proteus.

 

[varunme]

Can i use inside RTC , so that I can use like a timer ,
if a time condition is satisfied then this program has to be executed.

 

[alexxx]

Can i use inside RTC , so that I can use like a timer ,
if a time condition is satisfied then this program has to be executed.

I think that all combinations could be made. I mentioned it at an earlier post that this could be done inside timer interrupt. This is why the function originally acquired the name "TimerISR()". It was supposed to be a timer interrupt service routine. You don't have to instantly change the lights state (I mean none will complain if lights go off a few ms after they supposed to), so you can run this from main(). Inside timer ISR only count variable will be updated and its value will be processed from main(). So this has to be a global variable.
As for the RTC, it is up to you to choose where it will run from. If you are using hardware I2C, then it will be inside I2C interrupt. If you 're bit banging I2C, then it will be from main(). I think you are using an I2C clock right?
If you ask my opinion, lights drive with this method is fine just the way it is from main().

Alexandros

 

[varunme]

yes,
I am using hardware i2c , clock

 

[alexxx]

Can i use inside RTC , so that I can use like a timer ,
if a time condition is satisfied then this program has to be executed.

yes,
I am using hardware i2c , clock

Since you need a time condition to be satisfied, I see no reason to drive lights from I2C interrupt. Update count variable inside timer interrupt, and process it from main(). Or entirely do it inside timer interrupt if you don't want to mess with flags. As I said in my previous post, I believe it's fine in the way it is now. But in any case I would avoid lights driving from I2C interrupt.

Alexandros

 

[varunme]

But i am doing the clock and

sensors and lights

in different pics , due to lack of number of pins,

if a certain time condition is satisfied, a pin goes high and its a condition for the lights to lightup in a certain way in the second pic which controls the lights, if another time is satisfied, then another pin goes high and does another lighting condition.

 

[alexxx]

But i am doing the clock and

sensors and lights

in different pics , due to lack of number of pins,

if a certain time condition is satisfied, a pin goes high and its a condition for the lights to lightup in a certain way in the second pic which controls the lights, if another time is satisfied, then another pin goes high and does another lighting condition.

So you are saying that one pic measures time and depending on the timing condition it drives pins of the other pic to command him to do something with the lights?
If this is the case, then things are much more simpler. When you read the inputs from the lights pic, if the time pic commanded something, then lights pic will follow it. Thus you can drive lights from the inputs read function. Or even better, read the inputs, update your flags, and from another function drive lights according to the values of those flags, this is much more structured.
If I misunderstood, please explain the scenario in details.

 

[varunme]

yes,
this is the one i want

 

[varunme]

The code in post #53 , keeps all lights in portd "on" always