Trouble parsing and reading serial strings with uOLED 96 Prop

Ron_W

I have a uOLED96 Prop.· I am trying to read data in from an external device.· The beginning of the incoming data begins with "$" and ends with a carriage return.· For whatever reason I cannot get the propeller to parse the incoming data stream off either of those characters.· I've attempted replacing the 'c == "$"·' under get sentence with every form of the two characters.·

My code will parse the incoming data stream if I trigger off other characters.· I had it trigger off of "I" and "D", but this does not meet my needs.· Why can't I get a true value when I compare c to the dollar sign or carriage return?

I also have another question about the serial communications.··When using·FullDuplex serial, or one of its evolutions, and sending a RX command should the received byte have been removed from the buffer?· The·documentation that I've read·leads·me to believe that should be the case, however when I issue the RX command the byte remains in the buffer, and I will continuously read in that byte until the buffer overwrites it with a new bite.

Please help out the new guy.· (btw:· I have changed the repeat j...·to bytefill)

Thanks!

PUB GetSentence : Okay | i, j, c
  i := 0
  c := 0
  repeat j from 0 to linelen-1
    sentence[noparse][[/noparse]j] := 0
  
  debugDisplay(string("Ready"), c, i)  
  repeat
    if (c := ser_device.rx)
      if (c == 13) and (i > 1)                       'Locate end of sentence
        debugDisplay(string("EoL found: "), c, i)     
        sentence[noparse][[/noparse]i] := 0
        sentencePtr := @sentence
        return
      elseif c == "$"            'Locate beginning of sentence
        debugDisplay(string("SoL found: "), c, i)
        bytefill(@sentence,0,linelen)
        i := 0
        sentence[noparse][[/noparse]i++] := c
      elseif (i > 1) and (i < linelen-1)
        debugDisplay(string("MoL found: "), c, i)
        sentence[noparse][[/noparse]i++] := c
      else
        debugDisplay(string("Buffer reject: "), c, i)
  Okay := True

Post Edited (Ron_W) : 5/27/2008 6:39:54 PM GMT

Coley

Hi Ron_W, welcome to the forum!!!

My guess is (and it is only a guess!) is the clock speed.
You have the Prop set to run at 8Mhz clock input with 16x PLL = 128 MHz, at this speed your Prop will be unstable.

Try lowering the PLL to 8x and see what happens...

Regards,

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite

Ron_W

That appears to have fixed the issue.

However things did not work immediately after the change I needed to go through and debug the code again. I'll probably spend a few hours making sure that everything else works correctly again.

Thanks for the recommendation!!

Rayman

The uOled-96-Prop really should come with a warning regarding this issue with the clock when using multiple cogs...

rjo_

Ron,

You probably already know this, but just in case and for others that might not:

Remember, the i/o pins are 3V... but the device requires 5 volts. So, if your signal is 5V you need to put a resistor on that line.

Rayman,

This is not meant as a criticism. Clocking is an old issue, which was beaten to death and put way off track. AND since we all would wish for more Prop-supported displays from 4D, I think we need to be "fair and balanced."

If there is going to be a warning, the warning probably belongs in the serial libraries.

As a manufacturer... there doesn't seem to be a right way for 4D to say... "there is a trivial issue having to do with Propeller clock settings and the available serial libraries, and we aren't going to fix this problem because frankly we don't have the time, and we are not in the business of writing serial libraries for the Propeller. Until this little problem is fixed, please use a reduced clock setting."

I just don't see how that would foster healthy relations between Parallax and 4D.

But just in case 4D would want to include such a disclaimer... I would like to see it etched on a titanium enclosure for the 96[noparse]:)[/noparse]

In my opinion, next to Parallax's demo board, the 96 is the sexiest Prop package in the world... except that it doesn't come with an enclosure and people complain about the physical specs... a tiny little titanium box, with an engraved disclaimer, could solve all three issues:O)



Rich

Post Edited (rjo_) : 6/3/2008 5:21:36 AM GMT

Paul Sr.

Sorry rjo_, but I feel you are completely off the mark on this one!

However "old" or "dead" the "overclock" issue of the uOLED-96 Prop is to YOU, it was in fact the precise cause of Ron's issue.

Although valid / useful information, nowhere was VOLTAGE discussed as a possible problem or solution.

Nor are the "serial libraries" in any way responsible for the issue - they work fine when you don't overclock.

There clearly IS an issue with uOLED-96-Prop IF you overclock (as 4D has done in their Demo) and attempt to use multiple COGS (something the Prop is clearly capable of and happy doing by design!).

I fully agree with Rayman - 4D SHOULD provide such a warning. I don't think it would hurt them on bit to say in some way that the DEMO used a higher clock speed which may or may not cause problems with other programs - and to initially develop using a lower (i.e. 8X) PLL, then test the higher speed when fully functional. To NOT say this has caused a few of us to spend an unusual amount of time unnecessarily "troubleshooting" our code because of an inferred acceptable clock speed, only to find that our code was fine.

Respectfully,
Paul

rjo_

Paul,

Thanks for the response.

I wish I could find the link... but before the uOLED-96 came out there was a discussion about serial bit banging and certain combinations of clocks...where the deep logic of the serial object failed. I'm not an expert, so I can always be wrong.

I agree that this is not a dead issue in the sense that it still impacts every new user of the 96. I ran into it myself when I was implementing a GPS tracker. What I meant to say is that I thought that the technical issue had been identified and was actually a software issue....but I could easily be wrong about this. The only way to find out is to state the opinion and hope that someone corrects the opinion. And you are correct, the solution is to move to 8X on the PLL.

To be complete, the fact that there WAS an issue in the serial object does not mean that the issue is still there or that it the issue necessarily related to the speed limits on the 96 pll.

I find this issue very interesting. I thought that the last discussion was somewhat biased and might unnecessarily prejudice people's interest in the 96, which I find to be an absolutely beautiful implementation. I

I would very much ike to hear from the serial experts...possibly in a new thread.

Does anyone have a reference to the link (about serial bit banging and clocking) that I absolutely remember seeing?

Rich

Post Edited (rjo_) : 6/6/2008 1:31:32 AM GMT

Duffer

All,

This may not be germain to the original subject of this post (it looks like it's taken a left turn allready), but I have learned that·all uOLED-96-PROP displays currently being manufactured by 4D Systems are being built with 10MHz crystals unlike the original design which used an 8MHz part. If you've forgotten, 4D said that the reason·they used the 8MHz part was that 10MHz parts were in short supply at the time of manufacture and 6MHz crystals were too large to fit on the tiny PCB of the 96-PROP·and that they relyed on the currently available data sheet for the Propeller chip to determine the maximum clock frequency, not antecdotal information found in forum posts regarding the maximum stable clock speed.

This change in design means that the PLL can be set to 8X and one can run the Propeller at its maximum published stable clock frequency of 80MHZ rather 64MHz when using the 8MHz crystal of the older design.·It was felt that this change would allow users of the uOLED-96-PROP to realize the full potential of the embedded Propeller chip. This design change·does NOT mean that 4D Systems recommends or suggests that anyone attempt to run the Propeller chip at 160MHz by setting the PLL to 16X when coding to the uOLED-96-PROP.

I don't have a date certain for delivery of the new design, but I think quantity deliveries by the end of June is a fairly safe bet. Check the Parallax store or your favorite 4D products distributor for availability.

Bye for now,

Duffer

And yes, a really nice little enclosure would be great, titamium or otherwise. If anyone comes across one, please let me know.

Rayman

I think this is a good move! Same freq crystal as Hydra now.

It is rather painful to run at 64 MHz when we know the Prop can handle 100 MHz fine...

That should really help anybody trying to do video or fast animation...

Clemens

Wow, that's great news. The 6MHz crystal is is the only reason, I didn't order a uOLED PROP yet.


·