serial communication

Vladimir Andrejev

I am hoping to use the propeller chip to deal with the Parallax GPS reciever and Bluetooth.· However these both require serial ports.

can i do these on any pins?· or are there dedicated pins for serial communication.· I know p30 and p31 handle serial on boot, but can other pins handle serial during run-time?

I am a little worried that the popeller can't do both GPS and Bluetooth if only p30 and p31 can handle this?

Any suggestions?

Cheers guys.

mirror

The Propeller is capable of supporting 15 Full Duplex serial ports! 2 I/O pins per port, and 2 for the EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

StefanL38

Hello Vladimir,

Yes you can use any of the 32 IO-pins for serial connections.

The serial communication is completely organized by a softwaredriver
EVERYTHING buffer for sending data and buffer for incomming data is done by software
there is no hardware UART needed. And as it is done in software you are able to change the size of these buffers !

As with all other microcontrollers only voltage-level-shifting from 3.3V to TTL or V24 (+-12V) OUTSIDE the propellerchip
is needed.

You have 8 co-processors inside one propellerchip and each cog can handle 1-4 serial connections

all 32 IO-Pins are general purpose. AFTER Boot-up-procedure (takes about 2 seconds after Power on to the propeller)

Boot Up Procedure
Upon power-up (+ 100 ms), RESn low-to-high, or software reset:
1. The Propeller chip starts its internal clock in slow mode (≈ 20 KHz), delays for 50 ms
(reset delay), switches the internal clock to fast mode (≈ 12 MHz), and then loads and
runs the built-in Boot Loader program in the first processor (Cog 0).

2. The Boot Loader performs one or more of the following tasks, in order:
a. Detects communication from a host, such as a PC, on pins P30 and P31. If
communication from a host is detected, the Boot Loader converses with the
host to identify the Propeller chip and possibly download a program into
Main RAM and optionally into an external 32 KB EEPROM.
b. If no host communication was detected, the Boot Loader looks for an
external 32 KB EEPROM (24LC256) on pins P28 and P29. If an EEPROM
is detected, the entire 32 KB data image is loaded into the Propeller chip’s
Main RAM.

And for instance it will be much easier tp program a serial connection with the propeller
than with any other microcontroller
call a command "Start serialdriver" and then send and receive data. Thats all !

here is a little demo-program

'Use F11 to store program into the EEPROM.
'If you open the COM-Port with a terminalsoftware this may cause
'a reset of the propellerchip and then
'the content of RAM will be overwritten by the content of the EEPROM

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000


OBJ
  'give the serialdriver object wich is defined in the file "FullDuplexSerial.SPIN"
  'the name "SerialCon" 

  SerialCon : "FullDuplexSerial"  


PUB Main
  'the FIRST PUB-Method inside a spinfile is ALWAYS the startpoint where the program starts to run    

  SerialCon.start(31, 30, 0, 9600)                    ' start serialdriver in a new cog with parameters Rx-Pin is Pin 31 Tx-Pin is Pin 30, mode 0, 9600 baud


  repeat                                              ' repeat the indended commands below this line endlessly
    SerialCon.Str(string("Hello World"))              ' send a string
    SerialCon.tx(13)                                  ' send a carriage return
    WaitCnt(ClkFreq * 2 + cnt)                        ' wait for 2 seconds

best regards

Stefan

Timmoore

strictly the 2 eeprom pins do not need to be used for eeprom after boot, thats up to your app. During the boot loader 2 pins are for accessing eeprom and 2 pins are for talking to PC/other boot loader. After the prop is booted all pins are free, as long as you can live with whatever is connected to the boot loader/eeprom pins or you can disconnect them.
The standard fullduplex driver needs 1 cog to run it. There are low speed (19200 I think) drivers that run in spin and dont need a dedicated cog. There is also a fullduplex serial port driver that runs 4 ports with 1 cog upto 115200 baud. The most number of serial ports I have seen is 5 or 6 ports using the 4 port driver.

One of the demo program for the 4 port serial driver, runs 3 copies of the driver, with a total of 7 ports.

Post Edited (Timmoore) : 9/16/2008 8:22:48 AM GMT

CarlosFandango

If the boot pins are used for serial comms after bootup, is it possible that the propeller can become 'locked up' by this? In other words, because the boot pins are being used as a serial port, might it become impossible to reprogram the device? I can immediately see two possibile ways of avoiding this, 1) by working to RAM only whilst code is under development, and 2) incorporating a serial command to shut down the link - but I'm still worried about locking myself out accidentally. Should I be?

Ron Sutcliffe

No you should not be concerned.

Have a look at page 18 of the Prop manual, the boot process.

Ron

CarlosFandango

Ron, thanks for the reply. It is clearer now...

pems

Hi Stefan

Good post but I am not sure i am convinced on the following:

StefanL38 said...


And for instance it will be much easier tp program a serial connection with the propeller
than with any other microcontroller
call a command "Start serialdriver" and then send and receive data. Thats all !

from my experience using the serial object from ASM code in another cog, you have to make explicit effort to poll to empty or fill the ringbuffer frequently enough to maintain constant data rate. Polling = usually a lot of wasted cycles
on the other hand, i know another similarly priced mcu that can use interrupts or better yet on-chip deeply-integrated DMA to take care of these inconveniences. By no means i say lack of interrupts is necessarily a disadvantage - it's just prop has a different philosophy about it. And i think that asynchronous serial comm is not a strong point of this philosophy.