Is it possible to make the pst faster than spin?

turbosupra

After some reading, it appears that the best one can expect from spin is a code execution every 350 to 400 clk cycles.

It is possible to get the pst to run faster than spin could run a simple method in a dedicated cog, to update global variables so you could have a dedicated pst cog that read longs and sent them to the terminal faster than another cog could update them through spin ... even in a simple spin repeat loop with 1 action? The loop below should run at ~ 200000hz to 250000hz on an 80mhz program, correct?

Spin dedicated cog loop

VAR

  long  l_a

Pub spinLoop
repeat

  l_a++

To keep up, it would have to send up to (12*9) ( bits at the same frequency to catch every single number, correct? If my math is correct, this isn't happening. pst is also theoretically limited by the clkspeed (as well as other factors) of the processor/machine it is running on, correct?

repeat
  pst.dec(l_a)
  pst.char(13)

Thoughts?

Duane Degn

I think the Spin interface methods (str, dec, etc.) slows down PST a lot.

If you want the fasted speed possible from a serial connection, you'd probably want to have a PASM loop reading the values to transmit directly.

One of my modified four port drivers transmits an acknowledgement character when a wireless transmission is received. The acknowledgement never passes through the Spin interface so it happens much faster than it normally would.

The Spin interface is what make the objects easy to use though, so trying to bypass them will likely take a bit of work.

Phil Pilgrim (PhiPi)

Duane Degn wrote:

I think the Spin interface methods (str, dec, etc.) slows down PST a lot.

I think that depends on the transmit baud rate. At 9600 baud, for example, I'm sure that those routines enqueue characters in the buffer faster than the driver can send them out. So, whether the conversions are done in Spin or PASM, they will still get stalled if the buffer fills up.

-Phil

Mike G

It sounds like you need to debug something??? If so, there might be a better way. First, you'll have to describe what you're trying to do.

turbosupra

Here is why I ask,

The other day I was trying to trace something that counted from 1 to ~167.

I would have liked to have printed out every single counted value via a com cog to try and debug, but I did not attempt this because I didn't want the pst buffer to fill up because it is slow compared to spin, even at 115_200. I then tried to speed both of them up to the 921_600 setting and got gibberish.

Duane Degn

If it's not a whole lot of data, you could just increase PST's buffer.

Mike G

How much data?

Can you buffer up the data in RAM?

Maybe use a producer-consumer model, then shoot the data out the serial port when ready.

turbosupra

Since I'm chasing an issue, I just don't know. I was going to overbuild, rather than under build.

Mike G

Since I'm chasing an issue, I just don't know. I was going to overbuild, rather than under build.

I'm missing the point...

Anyway, sometimes ya just need to know what the heck was going on at some point in a process. I once spent 2 weeks trying to find a buffer overrun error in PASM. I did not know the buffer was smashing other memory. It took me a while to build tools and narrow down the culprit.

Point being, I had to come up with a systematic plan then execute the plan.

From your description, it sounds like you want to see 128 iterations of something. If so, you might consider writing all 128 values to some memory location. Then print the reading to the PST when the process has completed.

turbosupra

It's actually ~ 167, but that's a good idea. I could write them to an array and print them out when an event occurred, all the while pausing another piece of code so everything was in sync.

Thank you.

Cluso99

Do you have a spare pin?
If so, with a single resistor and a tv, and a cog, you could output to a tv screen. See my debug_1pin tv object in OBEX.