varunme said:On compiling, gives
volatile unsigned char port_C = PORTC; //save PORTC
err: constant expression expected.
I am using mikroC
volatile unsigned char port_C;
port_C = PORTC; //save PORTC
unsigned char i;
volatile unsigned char port_C;
volatile unsigned char port_D = 0;
void main() {
trisc=0xff;
trisd=0x00;
port_C = PORTC; //save PORTC
for(i = 0; i < 8; i++)
{
if (port_C&(1<<i))
{
port_D |= (1<<i);
if (i)
port_D |= (1<<(i-1));
}
}
PORTD = port_D; //update PORTD
}
Can you please be more specific? In my simulation it works all right.varunme said:compiling , but in simulation , not works
I meant in proteus, when connected with switches as below , when i press switches the lights wont glow ,
View attachment 67204
Then you could add a main loop and see what happens.varunme said:Not working with resistor added too
unsigned char i;
volatile unsigned char port_C;
volatile unsigned char port_D = 0;
void main()
{
trisc=0xff;
trisd=0x00;
while (1)
{
port_C = PORTC; //save PORTC
for(i = 0; i < 8; i++)
{
if (port_C&(1<<i))
{
port_D |= (1<<i);
if (i)
port_D |= (1<<(i-1));
}
}
PORTD = port_D; //update PORTD
}
}
not. havnt solvedHai varun.. i thought the problem of glowing the adjacent lights, is solved.
.
can u give further example ?hai varun...
i am not sure how much clear about this idea. But i think you can develop this for further level. The idea is " 1. Feed the sensor output to a flip flop, which will hold the status when some vehicle passes. 2.reduce the adjacent light intensity gradually even if the sensor output is down."
Here you may find another problem like, when first interrupt comes, the flip flop will hold high and when u get another interrupt u get low. So i recommend you not to check high or low but you can check the changes of previous and present state of the port pins. So when one vehicle crosses you will find the new status is high and another vechicle crosses you can confirm the state again changed so you have to lit the adjacent lights.
This may solve the problem of holding the state and also gives you some logical problems but i hope those can be resolved.
Thanks...
varunme said:Now we have to apply the PWM
and a method for making the off ones 50%
Yes it does. In my opinion it is not a good idea to do so.varunme said:The third option to produce pwm by setting and clearing pin needs external circuitry ?
The design we are using, suits software one, and for prototyping , we use 16F877a , have only two PWMsYes it does. In my opinion it is not a good idea to do so.
I don't know how many pwm pins you have available. Could you confirm this?
You must be sure what kind of pwm you need. Software or hardware?
If you lack PWM pins, then software implementation is the only way.
Then the soft pwm is the option. In what frequency? Because soft pwm cannot go to really high frequencies. It is not "fire and forget" like hard pwm. You need to run code inside timer interrupt. If the frequency is very high, then the interrupt will be coming all the time and the rest of the code will run slow. But again this may not be a problem in some applications. So what frequency do you need?The design we are using, suits software one, and for prototyping , we use 16F877a , have only two PWMs
Its to control LEDs so, is the frequency really accounts ?Then the soft pwm is the option. In what frequency? Because soft pwm cannot go to really high frequencies. It is not "fire and forget" like hard pwm. You need to run code inside timer interrupt. If the frequency is very high, then the interrupt will be coming all the time and the rest of the code will run slow. But again this may not be a problem in some applications. So what frequency do you need?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?