Shop OBEX P1 Docs P2 Docs Learn Events
Problem with Full Duplex Serial and uOLED-128 GMD1... — Parallax Forums

Problem with Full Duplex Serial and uOLED-128 GMD1...

Dal BrandonDal Brandon Posts: 6
edited 2008-02-27 16:29 in Propeller 1
I am using a prop chip with FullDuplexSerial.spin to communicate with a uOLED-128 GMD1 device.

It mostly works. I can reset it, send a "U" for auto baud, and display various strings, change colors and backgrounds.

My code is written to receive the acknowledge byte after each command before continuing. I have verified that the
bytes received are all acknowledge bytes, and I don't get any other (unaccounted for) bytes on reception.

When I put my test code into a loop, the system fails intermittently. It only takes about a minute of operation before
a failure occurs. The failure is alway accompanied by a time-out waiting for the acknowledge byte.

I have check for issues such as fault power supply. Power is good and stable.

Since communication is realiably established, but not susstained, I am lead to believe that the uOLED is not realiably
receiving what I am sending from the prop chip. My theory is that is receives a bad bad, and then it waits for the
completion of a command that I did not intend to send. This in turn leads
me to think there is a problem with the serial comm.

So my question to whoever might know: Has anyone else had a similar problem with unreliable Serial comm? Does
someone have a working system where a prop chip is driving an uOLED?

Thanks for any help/advice you might have,
Dal




To really exerice

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-02-25 20:30
    I built a sound sequencer using a Propeller Protoboard, a uOLED-128-GMD1, two VMusic2s and some other stuff. It ran fine for weeks at a time. I posted a description of the project in the Completed Projects forum. It was posted late in 9/2007.
  • Dal BrandonDal Brandon Posts: 6
    edited 2008-02-25 21:57
    Mike,

    Thanks much. Your relpy was exactly what I was looking for: a verification that the problem is mine, and not in either the OLED or FullDuplexSerial.

    I noticed that with your project that you modified FullDuplexSerial to have a TX flush and larger buffers. Was this in response to a problem you found,
    or did your design need this modification from the beginning? (Also, was it done for driving the OLED, or for the VMuxic2 devices?)

    Dal
  • Mike GreenMike Green Posts: 23,101
    edited 2008-02-25 22:04
    As I recall, the TX flush (waiting for the transmit buffer to be sent) was helpful for debugging. The larger buffers allowed the VMusic2 responses to be buffered completely and simplified some of the logic in handling two separate command streams.
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2008-02-27 05:34
    Dal Brandon said...
    FullDuplexSerial.spin to communicate with a uOLED-128 GMD1 device mostly works.

    I can reset it, send a "U" for auto baud, and display various strings, change colors and backgrounds.

    My code is written to receive the acknowledge byte after each command before continuing. I have verified that the
    bytes received are all acknowledge bytes, and I don't get any other (unaccounted for) bytes on reception.

    When I put my test code into a loop, the system fails intermittently. It only takes about a minute of operation before
    a failure occurs. The failure is always accompanied by a time-out waiting for the acknowledge byte.


    Dal
    Dal, does your system fail because your program stops after a timeout or because the -128 stops accepting instructions?
    What happens if you timeout to a -128 reset routine or downshift the baud rate and try again?
  • Gerry KeelyGerry Keely Posts: 75
    edited 2008-02-27 09:17
    Dal

    Check that you have an up to date copy of the PmmC firmware on your display and that you are using latest copy of manual.This is available from 4D Systems.I think there has been· changes with some of the commands so oled is probably hanging up.

    I had this problem recently where I was using some· old commands.Display would appear to work o/k and then lock up.

    Regards



    Gerry
  • Dal BrandonDal Brandon Posts: 6
    edited 2008-02-27 16:29
    Guys,

    Thanks for the help... I solved the problem. My wait loop was written like:

    tdone := cnt + clkfreq * 4 ' 4 seconds from now..

    repeat
    b := SS.rxcheck
    if (b < 0)
    if (cnt > tdone)
    ' Record a timeout, and return
    else
    ' check for Ack, Nak or garbage, and try again if necessary

    My problem was that the greater than check on cnt is signed, not unsigned. Due to the wrap around of the cnt counter, the loop was
    exiting with an early timeout indication, and then leading me and my code completely astray.

    My fix was to replace "(cnt > tdone)" with "(cnt - tdone > 0)".

    Anyway, again, thanks for the ideas and quick responses. (I did try changing baud rates, and firmware versions before finding my bug.)
Sign In or Register to comment.