Announcement

Collapse
No announcement yet.

serial communication issue - getting a "0x75" response on every two byte command

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • serial communication issue - getting a "0x75" response on every two byte command

    Hello everybody,

    I have obtained an uOLED-128-G2, which I want to connect to a PC. The target system has a "real" RS232-Port, but currently I have connected it to my laptop using a USB-to-RS232-converter. It is wired as such:

    PC-RX <-> display-TX
    PC-TX <-> display-RX
    PC-GND <-> display-GND
    5V (from PC-5V-rail) <-> display-5V

    I have all of the other display pins floating (I do have some switches which I plan to use connected to IO1, but I do not think that this matters for now).

    The device has power and shows the scrolling splash screen.

    I only ever want to use the serial command interface (SPE2) with the device, which is in its factory loaded state (display says SPE2 rev1.1, PmmC 2.4, Comm 9600).

    For testing, I am talking to the device via a simple serial terminal program. I am on Linux and using gtkterm, port settings are 9600 baud, parity none, bits 8, stopbits 1, flowcontrol none.

    If I send some of the example commands from the SPE manual (e.g. 0xFF 0xD7 to clear the screen), I never get the expected result. The only things that happens is that the splash screen stops scrolling for a few seconds, and I get a "0x75" (ascii: 'u') returned from the device. This seems to happen with every two-byte command that I send. Occasionally, by randomly sending commands to the device, an error message "Missing internal fi[le]" is showing up on the display.

    Is anything obviously wrong with my setup? Is 0x75 a defined error message, or is it just some scrambled bits that indicate a problem with my communication?

    Any help appreciated, thanks!
    Julius



  • #2
    The splash stopping scrolling indicates that 'something' was received by the display.

    The 0x75 coming back and the lack of a proper 'action' by the display would seem to indicate that the baud rates are mismatched, or some of the parameters are wrong.

    Then there's the bits you haven't mentioned, check that 'start bits' is 1 and that 'invert' is no (or Yes, maybe your converter is inverting it for you!?)
    Mark

    Comment


    • #3
      Hi Mark,

      thanks for your response. I did a bit of homework and now I am afraid that connecting straight to rs232 was a bad idea. This https://www.sparkfun.com/tutorials/215 suggests that firstly my RS232 signal levels are totally wrong (I just measered them and found them to swing btw -7 and 7 V), and that secondly they are inverted. I am now afraid that I already broke the device with the wrong signal levels. I have an FTDI cable lying around, but it is one with 3.3V-level. I connected that straight to the display, but no reaction. Is the display capable of communication on 3.3V-levels? The "invert"-setting that you mention, is that one that I can adjust on the display side (on the host side, i.e. in my terminal program, I do not see such a setting).

      Thanks!
      Julius

      Comment


      • #4
        The display will love 3.3v levels.

        I hope it hasn't been damaged by +-7, we have heard of worse being applied without damage, so I hope you are ok too.

        Make sure you have the TX/RX swapped and give it another go.

        See if you still get the display scrolling pausing when you send something.

        What diagnostic equipment do you have available?
        Mark

        Comment


        • #5
          Hi Mark,

          thanks for your quick response. Meanwhile, I got it to work with the FTDI cable, the problem was that the FTDI cable supplied 3.3 V voltage (which is probably too little as a _supply_ voltage). I got some regulated 5V elsewhere, and now it works). I also think that I understand now how to make it work on RS232 (I have some MAX-something level converters lying around). Just one thing: Is there such a setting on the display that allows to invert the comm-levels? Or do I have to take care of that myself in hardware?

          Thanks!
          Julius

          Comment


          • #6
            I think you will find that when you use a converter it will work.
            Mark

            Comment


            • #7
              Ok, I'll try that, thanks!

              Comment

              Working...
              X