Shop OBEX P1 Docs P2 Docs Learn Events
Solved: Problem with the parallax serial terminal - wasn't about PST at all — Parallax Forums

Solved: Problem with the parallax serial terminal - wasn't about PST at all

varnonvarnon Posts: 184
edited 2012-07-19 22:51 in Propeller 1
EDIT:
It seems I posted the thread a few minutes prematurely. I realized the problem is that the new cog launched cannot use the sensirion object correctly. Everything works when the sensirion object is initialized inside the new cog. I only ended up blaming PST because of some order of cog launching issues I have had before. The cog ID reports are still interesting. A mod can delete the thread if desired. I didn't see a delete button. Otherwise, I'm going to leave the content of the message as is, in case it helps someone else that runs into the same issues.

I am having a problem with the parallax serial terminal (PST) object interfering with the activity of other cogs. This is not the first time I have had this happen. Before, I have notice that if PST is started before other cogs are started there may be problems, changing the order of object initialization usually solved this problem. I believe I had some similar issues with the fsrw SD-card object.

I am in the initial phase of adding a new feature to my project, and I was testing some of this using the sensirion humidity/temperature sensor. I encountered this error again, but it seems that the order of launching cogs does not matter. I have reduced my code to isolate the problem.
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

OBJ
  Sensirion     : "sensirion_full"
  CF           : "common_functions"
  pst           : "Parallax Serial Terminal"

VAR
  long temperature
  long humidity

  long sensorstack[50]
  byte sensorcog

PUB Main
  sensirion.start(14,13)
  sensirion.config(33,sensirion#off,sensirion#yes,sensirion#hires)

  sensorcog:=cognew(sensor(5000), @sensorstack)
  pst.start(115_200)

  pst.str(string(13,13,"Terminal cog: "))
  pst.dec(pst.getcog)
  pst.char(13)
  pst.str(string("Sensor cog:   "))
  pst.dec(sensorcog)
  pst.char(13)

   'sensor(5000)

PUB Sensor(interval) | rawtemperature
  {{ Collects temperature and humidity data every interval. }}

  CF.pause(5000)
  CF.startsync
  repeat
    rawtemperature:=sensirion.readtemperature                                   ' Reads temperature
    temperature:=(-39350+(18*rawtemperature))                                   ' Adjusts reading

    pst.dec((temperature/1000))
    pst.char(46)
    pst.dec((temperature//1000))
    pst.char(13)
    CF.syncpause(interval)

Here is the basic code.
First, a cog is launched to report the temperature every 5 seconds. Before it starts, I pause that cog for 5 seconds to give a chance for some other diagnostic information to print. The CF object is irrelevant at the moment. The methods referenced are familiar pausing codes.
Second, the PST object is initialized. This ultimately launches some code on a new cog. I added a method to return the cog ID.
Once both the sensor cog and the PST cog are launched, the cog IDs are printed, then the temperature readings begin.

If the cogs are launched in this order, the PST cog is 3 and the sensor cog is 1. I'm not sure why PST would not launch on cog 2. The temperature value reported is 1140.280.

If the cogs are launched in reverse order, that is PST first then the sensor cog, both cogs are listed as cog 2.
Again the temperature value reported is 1140.280.

If the PST cog is launched, then the sensor code is launched on cog 0 (No new cogs are launched, I just comment out the code that launches the sensor cog, and remove the comment at the end of Main to start the sensor method), then the PST cog is reported as 2. Again I am not sure why the terminal launches on cog 2. What is cog 1 doing? (The sensor cog is reported as 0, but this is because no value was ever given.) The temperature now accurately reports about 81.3 - 81.4 degrees Fahrenheit. (I keep my house warm during the summer.)

It doesn't seem to be a problem of stack length. It doesn't matter if I give 20 longs or 2000. Also note that no other objects launch any cogs. If I use an LCD screen (serial_LCD object launches no cogs) in place of the serial terminal I have no problems. (Edit: actually, now I am getting the same problem with the LCD screen.)

This isn't too difficult to work around. I don't use the serial terminal for any final products, but it is useful when writing code, and sometimes more convenient than and LCD display. Does anyone have any thoughts on this matter? From what I understand cognew launches code only in an unused cog, and returns -1 if no cogs are available. However, PST launches assembly code and I haven't learned enough about assembly to understand what it is doing.
(Hopefully somebody can tell me I'm just missing a comma or a bracket somehow.)

Comments

  • varnonvarnon Posts: 184
    edited 2012-07-19 22:51
    Hey Varnon, why don't you try initializing the sensirion object inside the sensor cog.
Sign In or Register to comment.