Announcement

Collapse
No announcement yet.

uOLED 128 G1 --- FIRST TIME AT IT : Sending serial HEX ??

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

  • uOLED 128 G1 --- FIRST TIME AT IT : Sending serial HEX ??

    The first time using.
    I bought 2 128uOLED's a couple of months ago from a local vendor - It bothers me that, according to forum, new generation G2 will require new coding for future...maybe that is part of the problem I am having....


    The boot screen booted up color and stayed put. Looked like other pics found in Forum.

    I could not get any serial connection in Visi : dot was red. Clicked comm dot: turned yellow-> back to red. ' would not connect.

    Tried in Designer and Serial, but would not connect.

    I uploaded PmmC 128G1 and upload SPE, boot screen now rolls from bottom right corner to top left corner, but can connect now.
    If upload PmmC 128 G1h and then SPE , the boot splash rolls directly vertical ... and connects also.

    In serial commander I can draw forms, but if no communications for 2 seconds the screen rolls: Either straight up, or diagonal.
    Example : ( gfx_CircleFilled[FFCC 0028 0046 0014 58CC] 0.030 (ACK) from Graphics Commander works.


    Is the screen supposed to roll when communication is delayed?

    I intend to communicate directly from a Propeller based voltage reading board that will directly attach to back : So, need to talk serial to it.
    When I go to serial,9600 terminal, and at the "send Hex" box, send bytes.. I get nothing.
    If I enter them one byte or one word at a time same...nothing. If I enter the whole string I get nothing. If I put in spaces...says invalid.... I tried using the for-mentioned same hex ...same set of Hex sent from Serial Commander...nothing... not a Ack or anything else.

    So, can anyone tell me what is going on here. Maybe I am not understanding the functional architecture. LOST?

    Any suggestions appreciated.
    /Chuck

  • #2


    That is normal, to stop burn in on the oleds, you can change the 'default' and also change the settings on the fly.

    Do a find on 'screen saver' in the manual.

    As for sending bytes, check what you are sending again. Compare it to what worked in Serial Commander.
    Mark

    Comment


    • #3


      Thanks for that on preventing burn in. Just wondering if it is normal.

      But...
      On writing in serial. I tried every way I could to copy the hex stream.
      So, in the "send Hex" box:
      are there any other characters beside the hex ?
      are there any spaces or delimiters?
      Does it need the checksum? (is that blind to me in the Serial Commander): I did not see it used in SerialCommander, so I did not use.

      If I put cursor in left box and type when first open, I get lots of odd replies. So, it starts to send something. Then I click on Hex box and when I go back to put type in left box...nothing happens. LIke something is hanging.

      I assume put in the entire string of hex... one after the other ... no spaces.
      any other ideas?

      Comment


      • #4


        It's just hex without spaces, eg.

        gfx_CircleFilled[FFCC 0028 0046 0014 58CC] 0.030 (ACK)

        would be

        FFCC00280046001458CC

        or doesn't that work?
        Mark

        Comment


        • #5


          Haaa! I tried that yesterday...10 times...but this morning it works!
          I see that If I load the PmmC G1 it rolls diagonally.... when I re-send hex, the object prints to
          NOT the proper location, but If I load the G1h... and the screen only rolls directly vertical, then
          the following updates of hex are placed in the proper location
          .

          Thank you ...

          So, one more explanation please: I see the SPE to be the ...what ..Serial operational program,..maybe, ...
          What is the PmmC?
          Why is there more than one version?

          Comment


          • #6


            The displays have a different driver, yours is obviously a G1h (due to the way it scrolls).

            If you had your display in a state where it was expecting 'data' anything you were sending as hex would have been treated as part of that data, if there's a chance you've been accidentaly sending something 'odd' it might be best to reset the display before you try again
            Mark

            Comment


            • #7


              Thank so much...
              It all is working now

              It looks like I may have sent and FF0D instead of an FFD0... and hung up the processor. So, I did the reset and it worked fine.
              This is important... Are these serial commands the same for the G2 ??? When I produce this product with new module will I need to do any mods to code If just sending serial commands???

              Is there a way to send a "blank" char to the display... or do I need to resend a complete string over ?
              What is name of command to move cursor location ???
              Is there a "Compact" command set cheat sheet somewhere out there ??? so all on one page ?

              It is probably right in front of me... Pretty close to "figured out now"

              Thanks for help !

              Comment


              • #8


                All commands for Goldelox processors are the same.

                Drawing a blank sends a blank character, or are you meaning the difference between TRANSPARENT and OPAQUE text. You can always draw a rectangle over the top of a character.

                gfx_MoveTo() positions the cursor at the pixel level
                txt_MoveCursor() positions it at the character level

                The index seems to be a quick cheet sheet
                Mark

                Comment


                • #9


                  Great Idea.. the index!

                  Thanks folks for the help. Is working now.

                  I found the problem that was hanging me up. I feel it is a querk that should be addressed by 4D:

                  As mentioned in the previous thread, the display can become "confused"... so, if you send it a command that it does not know...it locks up. That should not be. If it does not know a command then, it should disregard. While I was trying to work initially with the display ( i am a little dyslexic ) I flipped an xFFD0 with xFF0D.. so it locked ... and did not give any response...if it had returned 6 then I would have known that something was wrong.
                  This gives a little problem while booting...but solved most the time with a repeat command unitl == x6 return.

                  I am driving directly from Propeller and works beautifully now! This is a wonderful display.
                  This display will hopefully be in 150 radio stations within a few years.

                  Thanks for all your help.

                  Comment


                  • #10
                    Err, it should have sent a NAK

                    If you want to here's how to fix that.

                    1. Edit C:\Users\Public\Documents\4D Labs\4DUpdates\Utils\SPE2GV10.INC
                    2. Change line 19 "maxcmds 292" to "maxcmds 155"
                    3. Change line 315 "if (funcArgs[cmd] == 0xff)" to "if (funcArgs[cmd] == 0xffff)"
                    4. Save changes
                    5. reload SPE
                    Mark

                    Comment


                    • #11


                      OK. I will. /But this begs the question:
                      Why is this not fixed in the current version.

                      Thanks for the info very much.

                      Comment


                      • #12


                        Because you were the first one to report it
                        Mark

                        Comment


                        • #13


                          Thanks,
                          /Chuck

                          Comment

                          Working...
                          X