You are confused about the noise getting through because your active filtering elements should not let it.
But there's no power yet, so how will any active element filter the noise?
When you have a ringing supply rail that noise can be propagated and even amplified quite easily throughout the electronics and properly predicting or modelling that is hard enough that most professionals also just prevent the supply ringing.
To do that, I would prefer having a Zero-Crossing switch on the primary side to begin with (whichever fits your circumstances best). That because it also prevents ringing noise being emitted at switch-on to the rest of the world.
Then, I might prefer also adding a low Rds-on pass MOSFET that turns on a few ms after the main power rail's capacitors are and stay above a certain minimum voltage. Maybe add a 1/10th the capacitance capacitor behind the MOSFET so that in its Turn On curve the electronics still see a "slow turn on", if you feel that might be beneficial.
Do also test turning on another original one, while your new one is in regulation and see if that ever (give it a dozen tries) causes noise as well, maybe your feedback filter will prevent that, or maybe you'll need some more filtering if you want to use it in a Lab with sensitive loads.
A cheap Lab supply at a customer had huge ringing spikes on the output when someone else turned on the soldering iron. Very annoying with $5000 a piece prototypes.
It's not going to work without some basic debouncing which if you don't want to use interrupts means a basic wait function unless you debounce in hardware.
The intended functionality of your code seems to be to call the set LED functions constantly while the button is pressed, going by your description there is no need to do this, you can call them once and then wait for the button to be released. They will remain lit until a different LED setting function is called.
Finally if you are ANDing the IO register with 0x02 then the result is either 2 or 0. Rather than checking for a specific value you can use the c convention that 0 is false and all other values are true, this makes the code a lot cleaner looking. Moving that into a function makes it even nicer to read.
int SW1Pressed (void) {
return !(IO0PIN & 0x00000002) //switch connected on P0.1. Low when pressed.
}
....
count = 0;
while (1){
if (SW1Pressed()) { //when pressed
wait_ms(100); // wait 100 ms
if (SW1Pressed()) { // still pressed.
if (count==0) // turn on correct led
function1();
else
function2();
if (++count == 2) // update count
count = 0;
while(SW1Pressed()) // do nothing until the button is released
;
}
}
}
Best Answer
Most SPST switch or pushbutton will bounce, because there are only two states: contact closed (for instance low level) and contact open (high level through a pull-up resistor). This may seem obvious, but it's that hesitation when opening/closing that causes the bounce; just once is enough to make a toggle not work.
You can debounce the switch with a capacitor, but since you're using it with a microcontroller it's cheaper to do it in software. I usually have a 32 ms (software) timer for keypad scans, and only accept a state change if it persists during two consecutive scans. That means you'll have a delay of maximum 64 ms, but since the button will be manually operated you won't notice such a short delay.
You mention a SPDT button, and that's the best solution if you want to do it in hardware.
But frankly, I see no reason for not doing it in software, and you'll have much more choice in SPST buttons than in SPDT buttons.
If you want a button which hardly bounces then I can recommend the Alps SKQG tact switch
which with the devices I tested had an initial bounce of less than 10 ns.