In the shifting project ISR should be set to rising edge -
You ISR in Shifting project calls another f(), readserial(). Generally speaking its best
to set a flag and service it in main. Heavy stack push would be avoided. Also variables
in an ISR should be declared volatile. Principal also applies to MainBoard project.
If you are driving a solenoid you generate large L based transients. You need to clamp
the coil as well as clamp the output of PSOC to insure you get no charge injection into
the substrate, which will do crazy unpredictable things in any CMOS part. Make sure for
solenoid diode it is a fast recovery diode, not a grunge power rectifier diode.
This circuit is pretty good example, but there should be diode clamps at the pin side
of the 1K connected to MOSFET gate to insure no miller coupling and parasitic C couples
transient back into PSOC output pin.
There are two things I woud change in your program: I have learnt to never ever wait within an interrupt handler, be it directly or indirectly. Since you write out data to UART in your handler and that is a blocking call you will be waiting for all bytes stored away in the UART's FIFO. This cannot be accepted and will lead to some unpredictable behavour.
The second issue I see is: In your main-loop you write out 10 messages per second. Your interrupt will fire at any time, even within one of these messages and spoiling the sequence of the bytes to transmit.
I would suggest:
As you already defined, use a (volatile! as Dana suggested) variable that gets the actual state of the shift changed in your interrupt handler
In your main-loop:When you find it not being no_signal, setup the message, send it and reset the state back to no_signal, indicating the process has been finished.
Thanks for the replies!
I tried switching the isr in the shiftig project to rising edge but that didn't make much of a difference. I haven't tried declaring anything volatile yet but that's next. I'm also driving the solenoids just as you mentioned.
How would you recommend writing UART on an interrut then? Just a flag? I can try that next. As mentioned above I'll also start using volatile.
I tried both of your suggestions and neither of them worked. I also added LED's (Pin_1 to Pin_3) for testing and scoped the signal at the input. The signal looks perfect but the LED's are intermittent. Additionally, the shifting board hardly ever registers a shift when the LED's are lit. I have my revisions attached.
MainBoardPrototype.zip 2.3 MB
A new Creator update is out. I suggest you to do that update, there were some issues with components corrected.
I took the liberty to order and comment your program a bit.
You did not mention how the three switches are connected to the port, you are using a pull-up, so are the switches connected to GND permanently and open only when acted?
Am I right in: one switch for cludge
One switch for shift
one for the direction of the shift
Three for the elven-kings.... ah, no, wrong forum...
Haha, thanks for taking another look Bob. I'll check out your project once I finish updating. As far as the input goes, there are three input: up shift, down shift, and clutch. When you hit the clutch, it's just supposed to toggle the clutch solenoid. When you hit up shift or down shift, it is supposed to engage the clutch solenoid, wait for it to fully engage, engage either the up shift or down shift solenoid, wait, release the up or down shift solenoid, wait, then release the clutch solenoid. The waits are hardcoded as you can see in the shifting project. For testing purposes now, you can see I just have each button turn one of the solenoids on for 100ms then turn it back off.