Semaphore with push button for pedestrians

olimathus · Joined: 13 Jul 2014 Posts: 2

Hello everyone. I have a school project where the objective is to make semaphore. The semaphore is working ok, however I've been having problems with the interrupts that I'm using for the push buttons, which are needed for the pedestrians. Here is the code:

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

Two things:

Debounce.

Delays in the ISR.

Now the first problem is that switches don't produce nice clean 'on/off' pulses. They will often make several times. You don't want to accepts a single 'I am on' edge. This could be caused by somebody holding the button a long time, then releasing it and generating another set of these edges....

Then you have massive delays in the ISR.

Rethink.

Have a single 'tick' interrupt. A timer running out at perhaps 50* per second.
Then just test the buttons in this.
If a button is seen to be 'on', record this fact and exit.
If a timer is seen 'on', and has already been recorded as on, then accept it.
Cancel the recording whenever a button is off.

This way the button has to be 'on' and stable for two successive interrupts.

Then don't do your pedestrian sequences in the ISR. Instead use a 'state machine' in the main code - I suggest using an enum for the names of the states, and using a switch...case with this, so you have states like 'pedestrian_stop' etc..
Do the timings, by using a counter updated in the same tick. Have the tick code use:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You appear to have buttons on pins B0 and B4. I assume 'BOT' means
a button ? You didn't tell us.

olimathus · Joined: 13 Jul 2014 Posts: 2

Mike Walne · Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK

A few comments.

Please don't edit code after you've had replies.
The replies no longer make sense, the rest of us can't then follow the thread.

You've got a #use delay AFTER you've tried to use it.
Can't be good news, will probably confuse the compiler or produce strange results.

Indent your code to make it more readable.
As a guide, position each closing } below its opening {.

Mike

temtronic · Posted: Sun Jul 13, 2014 4:13 pm

just a comment...
I find it easier to have 'same length ' variables if possible.
Using GRN for green and YEL for yellow makes them the same as RED for ,well red !
It's just a bit easier on my aging eyes and looks 'neater'.

also
you may have to read the entire PORTB inside the ISR to clear it.I can't be sure, not near the 'testPC' to confirm/deny but it sticks in my head that it's needed.

others will KNOW for sure !!

also when I did 'traffic light' programs(30 years ago !, when Motorola had a 1bit processor) we used NS for the 'north-south' lights, EW for the 'east-west' lights. It might have been a 'traffic standard' back then.It did make it easier to understand when we got into the 'real world'.

hth
jay

Mike Walne · Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

This is where a 'what has to happen' list comes in.

What seems to be attempted to be done, is far too simple for anything even approaching 'real'. Normally car lights have to go 'stop', and then a little later the pedestrian lights go green. As it stands the lights all change together, which given that cars take time to stop, would be pretty certain to lead to accidents.
Real sequence would have to be something like:

Car green
Wait for button pressed.
Car lights go red
Wait two seconds
Pedestrian lights go green
Beeper starts
Wait eight seconds
Pedestrian lights go off
Beeper stops
Wait two seconds
Pedestrian lights go red
Car lights go amber
Wait two seconds
Car lights go green

This is the sort of sequence used in the UK (times are very wrong), where there is an 'allowance' time, with cars allowed to progress under 'amber', if there is nobody on the crossing, and pedestrians are not allowed to start crossing.

In the real world there is more to it, with the button not simply starting the sequence, but measurements on the traffic, and how recently the button was last pushed, also being taken into account.

So start with such a list. The actual sequence wanted, and how it progresses.

As I've already said, this sequence should really be coded in the main. This way you can't have a situation where you are halfway through going to the car green state, and a button push immediately intercepts it. Instead the state has to be in the 'car green' mode, before a button is accepted.
Then the key debounce has to be handled, before a button is accepted.
It's worth realising that the keys on your keyboard have a debounce like this, which is why they actually work the way you expect. Without this 'oddities' will be the norm....