I am using "static". Now try to change the beginning level of that pin. If it is "HIGH" your output will be inverted and you decode will be incorrect. I have the pin setup as strong drive and pulled up from a previous use. Now try to go change that? I need that pin to be strong drive initial state is low and no pullup.
I tried your code and setup on a CY8C5888LTI-LP097. P1 is connected to a PC running RealTerm at your specified parameters. Here is the output straight from P1 in RealTerm I had to manually copy the Hex since I could not copy from RealTerm. "00 54 4D 92 27 48 49 4D 73 24 C9 93 etc" not the intended results. With an inverter added the output was "Welcome to community[cr][lf]" or in hex "57 65 6C 63 6F 6D 65 20 etc" . It appears the output of the software component is inverted.
On a scope the direct output starts out as low, then goes high for 1.5ms puts out the data (transitions starting from HIGH to LOW). at the end of the data the output is high and stays high.
Since the output does not show up on the component in TopDesign.cysch you have to consume two more pins to add the invert function.
I downloaded your project. I reassigned Tx output to P12.7 for my 059-Kit board. Works. No Issue.
Output to my term program = "Welcome to community" as expected.
When I switched the Tx output pin back to your assignment of P1.6 I get the following waveform:
Although I have not confirmed proper Tx output WITH THIS PIN, it should be the exact same as when using P12.7.
The waveform conforms to UART output standards which are
- inactive HIGH,
- LOW for a start bit (one bit-time),
- the remaining 8 bits are LOW for 0s and HIGH for 1s each for one bit-time. The least-significant bit sent first.
- HIGH for one bit-time.
- Since there is no parity declared, go to next step.
- If the next byte is in the FIFO, then repeat 2 through 4.
- The next byte is not ready the output goes back to step 1
Is it possible that RealTerm has the option to invert the bit logic of the incoming Tx data set? (See pic below in Yellow). Make sure this option is not enabled.
First, let me Thank two very nice folks for trying to help me understand this issue. I failed to do that on my first reply and that was wrong on my part. Sooo Thank You Bragadeesh and Len !
I used, as I stated earlier Realterm software AND I forgot to mention a Tektronix MSO2024 scope with the communication package software to look at the signal. Realterm printed out a lot of special charaters and the MSO2024 had timing issues and decode failures until I inverted the signal. No, I did not have data "Invert" bit on in Realterm. The only thing I can suspect is that there might be a difference between the "TTL" version of the spec and the actual version of the spec addressing the +/- signaling. RS-232 has been a pain in my rear since I got my BSEE in 1972 and it still continues ;-) !
Thank You for all your efforts, I greatly appreciate your assistance !! Have a wonderful day and I consider this Question closed. I will try to indicate as such on the file.