- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All!
This is my first time posting so I'm not sure if my file project upload is correct. I'm also new to using PSoC's in general.
I'm designing paddle shifting in an automotive system with two PSoC 4's for and I'm having trouble with the communciation between the two. I have two boards, one that uses the PSoC 4 prototyping kit (www.cypress.com/) that we will call the "Main Board" and one that uses a PSoC 4200 on a custom PCB that we will call the "Shifting Board". The Main Board takes 3 digital inputs from the steering wheel (up shift, down shift, and clutch) and puts that data into a mesage that gets sent out UART. The Shifting Board reads UART and when it sees that it contains a message to shift, it performs a series of digital writes to actually complete the shift.
What I'm observing:
First of all only one of the solenoids are firing but I will get to that later. Anways, it will work fine anywhere from 10-50 shifts (slowly getting less responisve) and then stop working completely until the Main Board gets restarted. Restarting the Shifting Board does nothing.
My theory:
Since the message I'm sending is larger than the hardware buffer size (4 bytes?) I might be continuously buffer overflowing. However, I would imagine restarting the Shifting Board would get it start working again (temporarily). So maybe it's only a problem on the tx buffer of the Main Board?
Any suggestiions would be greatly appreciated! I attached both projects in Project.zip since it wouldn't let me upload two files.
Also: My tx is inverted because I'm switching 12V serial with an N-FET so don't mind that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword Volatile
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.
Regards, Dana
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Eric,
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.
Happy coding
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the replies!
Dana:
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.
Bob:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.