Can Simple_Serial Object do 9600 baud at 5Mhz clock?

william chan

My Propeller is running at 5Mhz PLL1x.
When I try to send any string using the simple serial object, the cog hangs.
Any ideas?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

CJ

I think that is too slow for 9600 as simple serial tops out at 19200 at 80Mhz

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

Aleks

can you up the PLL to somewhere around 8 or 16?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

tpw_man

I think that you would have to do at least 40MHz because 19200/2 = 9600. So half the clock rate at 80MHz(40MHz) would probably be the least you can do.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!


Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com

Rsadeika

Try not using, 5Mhz PLL1x, in other words, use the internal oscilator, and see what happens. That way you will have checked both conditions, if it hangs, then I would check the code.

Ray

Aleks

If you're actually communicating with an external object, which is the only assumption I can make given your use of the simple_serial.spin, I can advise you that communication is more efficient with the use of an external oscillator, simply due to the way the two are broken down. In the Prop Manual it suggests using an external oscillator for accurate timing due to the inaccuracy of the internal oscillator. Again, pick up your speed via the pll mode, and if you can't get it working check your code or switch to FullDuplexSerial.spin. Maybe you can give us a little more information about what you're communicating with?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Rsadeika

A few months ago I was experimenting with Extended_FDSerial.spin, and using the internal oscilator, I had no problems with 57600 BAUD. I could not go above that, so when I used the external oscilator, then I was able to get up to 240600 BAUD, with no problem. When using the internal oscilator, it did not occur to me to go the other way, like using, lets say 9600 BAUD. I was pretty impressed with the stability of the internal oscilator, maybe I was just lucky, anybody else try that.

Ray

Aleks

Or I could just have a bad oscillator. Either way, its only a line of code to change to check either one, so go for both. If it works, it works

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

william chan

My application is simple.
I just want to send some strings to my Serial LCD.
FullDuplex serial seems like an overkill and it takes up one extra cog.
Why is simple serial so slow?

Simple things are usually faster...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Aleks

If you're using the 2x16 Serial LCD offered on the Parallax website then you can download my Serial_Com object in the object exchange
obex.parallax.com/objects/356/
It has an LCD object I coded within that uses a slightly modified simple_serial.spin to run.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

william chan

That object requires 80Mhz clock. My propeller is only running 5Mhz clock......
If I set RxPin to -1, will FullDuplexSerial still start another cog?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Aleks

can't you just change pllx1 to pllx16 to compensate? that would explain why your program is running so slow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

william chan

I can't run faster than 5Mhz because the Propeller is powered by AAA batteries!

Looks like we need a "serial transmitting only bit bang assembly" object soon...
Would it be difficult to write such an object?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Mike Green

In the Object Exchange, you'll find a 4-port full duplex serial driver that should be able to run at 5MHz. It adjusts for the system clock speed. For transmitting, you should be able to handle 9600 Baud easily. You can disable the receive side by specifying -1 as the receive I/O pin.

william chan

But what I need is only half a port(transmit only), not 4 ports and preferably does not use a new cog.
I think Simple_Serial is slow because it uses spin.

Can it be easily converted to assembly?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Timmoore

To convert run pasm you need a new cog. I expect to get to 9600 at 5Mhz you need pasm, this means (5000000/9600)/4 instructions per bit. I wrote the 4 port driver and optimizes the standard fullduplexdriver. It also uses very little overhead if you dont run the ports, i.e. it runs 1 port with 1/4 CPU that it runs 4 ports. So it should need 1/8 cpu to run just tx on 1 port. I haven't done the calculation for min cpu speed for 1 tx at 9600 but the tx loop is about 112 instructions (for 8bits) which should be enough for 9600 at 5Mhz.

william chan

Tim,

Are you saying that the 4 port driver will use less battery current than the FullDuplex driver?
If yes, it would certainly help my batteries.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Timmoore

william, no they both would be the same. To handle tx they continously poll a memory location to see if there is anything to tx. The 4 port uses less instructions to send a byte so it can support 9600 at a lower clock speed, but once it sends a byte it then polls for the next byte.
If you wanted that cog to reduce power when there is nothing to send you would have to change something. They easiest way I can think of is to use a spare pin to signal the tx cog and have the cog wait on that rather than poll the memory location.

Ale

Or you can poll at regular intervals. If you send full 16 chars or 32 for 2 lines every time, you can make it poll every 10 ms or so and send all at the same time. Maybe you should retouch the code a bit to customize it for sending 16 or 32 chars (or whatever you need) at once from a HUB memory buffer every 10 or so ms. That way the program is waiting loads of time.

william chan

Can I use a pin in port B (unused port) to signal the Serial COG to start transmission?
Which line of the object code should I change?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Timmoore

Look in fullduplexserial.spin for this code

transmit                jmpret  txcode,rxcode         'run a chunk of receive code, then return

                        mov     t1,par                'check for head <> tail
                        add     t1,#2 << 2
                        rdlong  t2,t1
                        add     t1,#1 << 2
                        rdlong  t3,t1
                        cmp     t2,t3           wz
        if_z            jmp     #transmit

This code, reads the tx queue and checks that whether the head and tail of the queue are the same and if so jmps to transmit, i.e. if head and tail are the same then the tx queue is empty. So the pasm cog will spin here when there is nothing to transmit. You want to insert a waitpeq for a pin you pick. Then in the tx spin routine you want to set the pin to be an output pin and set it to 1 when you add something to the queue.
Then back in the transmit code you need to reset the pin when the tx queue is empty.
You need to be a bit careful in the order of setting/reseting the pin and adding/removing from tx queue since the spin and pasm cogs will be running in parallel.

william chan

Can I use INB[noparse][[/noparse]0] as the signaling pin?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Mike Green

The hardware for the "B" I/O doesn't exist on the current chip.
There's no "B" wiring from cog to cog. INB / OUTB / DIRB don't connect to anything.

hippy

It's very easy to write a PASM routine which takes a byte in PAR and bit bangs it out at 9600 baud the stops itself. That can easily be extended to looping, reading a character from hub and sending whenever there's something available.

I pulled this from the I2CMonitoring stuff I did ...

              mov       OUTA,pinMask
              mov       DIRA,pinMask

GetByte       rdbyte    getByt,PAR WZ
    IF_Z  jmp       #GetByte

SendByte      xor       getByt,#$100
              shl       getByt,#1

              mov       count,#10

              mov       timeout,bitTim
              add       timeout,CNT

SendBit       shr       getByt,#1 WC
              muxc      OUTA,pinMask

              waitcnt   timeout,bitTim

              djnz      count,#SendBit

              mov       getByte,#0
              wrbyte    getByt,PAR
        
              jmp       #GetByte