Serial Comms and _xinfreq

pgbpsu

I have an application where I'd like to use a 5.12Mhz input signal. This application requires some high speed assembly routines so I'd like to run it with the PLL set to 16x. This application also requires several serial port of differing speeds. I've been doing my testing (before getting the 5.12Mhz boards built) using the Demo board and proto board running at 5Mhz. Reading the manual (pg 131-133) it seems like declaring the _XINFREQ to be 5.12Mhz will allow FullDuplexSerial to compensate for this increased clock speed. What I've been running at 9600bps with a 5Mhz clock will STILL run at 9600bps using the higher clock speed.

Do I understand this correctly?

Looking over FullDuplexSerial I see bit_ticks, bitticks, and a wait assembly routine, but I don't understand the jmpret setup. I assume this is the portion that waits the correct amount of time (regardless of the clock speed). I was expecting a waitcnt in there....

Is this all I should need to change to get my serial routines written for 5Mhz clock to run when clocked at 5.12Mhz?

  ' System clock settings - 80 MHz
  _clkmode = xtal1 + pll16x                      ' Low speed external crystal 16x PLL
  _xinfreq = 5_000_000                           ' Crystal input frequency is 5 MHz

  ' System clock settings - 81.92 MHz
  _clkmode = xtal1 + pll16x                      ' Low speed external crystal 16x PLL
  _xinfreq = 5_120_000                           ' Crystal input frequency is 5.12 MHz

Thanks,
pgb

hippy

I have not used FullDuplexSerial but assuming it is well written that should be all you need to do. Likewise with any other well written objects, they should adjust themselves to what you have selected. It all comes down to how the object is written rather than anything else.

Paul Baker

Yes FullDuplexSerial adjusts it's timing according to the specified clock frequency.

The JMPRET is the duplex portion of the code, it swaps between two process (transmit and receive) to achieve the bi-directional serial.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Praxis

If what you are saying is this;

You use one clock setting and the speed is 9600, then you change the clock setting to a higher speed and the serial speed is stil 9600.

If that is correct then make sure the call to start full duplex serial has the baud rate that you want set.

pgbpsu

Thanks all for your responses.

@Paul- where then does the waiting take place? i.e. if the baud rate is set to 9600 where does it pause between sending/receiving bits?

@Praxis- I'm not sure I follow.... My desired serial port speed is 9600. My system clock speed for developing these routines has been 80Mhz. When I actually build the boards, the system clock speed will be 81.92Mhz (~2.5% faster). My question (which Paul answered) is will FullDuplexSerial properly adjust to this slightly faster system speed to maintain serial comms at 9600 if I declare my xinfreq to be 5.12Mhz. At no point do I reset the system clock speed, which is what I think you were getting at????

Thanks all.
pgb

Paul Baker

The waiting is done between :wait and the if_nc jmp #:wait. The waiting occurs by dedicating the waiting cycles to the other process, then when control is returned to it, check if the bit period has elapsed, process the next bit if it's time, or kick back to the other the process if it isn't time yet. This ping ponging is what delays the time between the bit samples.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

pgbpsu

@Paul-

Thank you for clearing that up. I could (and should) have worked through it, but I was pretty sure from the manual that setting _xinfreq would work given the way it was written. Once I started reading it I didn't see what I expected so I posted.

Thanks for your time.

Still working on our geoPebble. We're having 6 boards printed right now and hope to have them populated next week by a local shop. Now if I only had the code working....

I'll let you know how we get on.
p

Paul Baker

Great to hear of your progress, definitely keep us informed of your further progress.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

newmi

i ve a prog with:
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 16_000_000

to set up an 2400 conection, i have to start the fullduplexobject with
sio.start(0,1,3,7800)

BradC

If you have _XINFREQ of 16 MHZ and you have a multiplier of 16x then you are running the propeller at 256 MHZ.. *OR* you've set a define very badly wrong.
What is your crystal speed?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!