Propeller ASC+ and Seeedstudio GPRS Shield 1.0 Serial Communications

jrullan · 2014-04-26 04:40

Hi all,

I have been recently introduced to the Propeller by a friend and I am quite impressed with it so far. I purchased the Quickstart board from Radio Shack, spent a couple of weeks learning SPIN and very little PASM (enough to make blinking leds in the Quickstart using cores 2-7, turning them on and off by using the touchpads).
Now I decided to move a little ahead and port a working project from Arduino to Propeller. So I naturally purchased the ASC+.

The project uses a Seeedstudio GPRS Shield 1.0 and so far I have been able to somewhat establish serial communications with it (had to solder the bottom of Pins 7 and 8 to make it work). The problem is that I can't receive certain messages from the shield.

For example, using the Parallax Serial Terminal I send the following:

AT+CMGF=1

and the response is

AT+CMGF=1

OK

However, every time I issue this command:

AT+CMGL=?

I don't see the response and it stops working from then on.

But if I load the program into RAM again (Note: The shield is not affected by this, there is no reset involved), I can again send commands and see the responses until I issue that last command.

The behavior is consistent, but I can't pinpoint what is wrong with it.
My take is that some part of the response from the shield is causing a crash on the serial port used to read its responses.

I'm no expert so I am requesting help from the real propeller masters on this forums.

Mike G · 2014-04-26 05:25

Welcome to forum.

It's a good idea to post your problematic source code.

Also, soldering two pins together sounds a little iffy.

jrullan · 2014-04-26 05:43

Mike

Heres the Spin code

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000
   
OBJ
  GPRS: "Parallax Serial Terminal 128"
  pst : "Parallax Serial Terminal 128"
  
VAR  
  byte  bufferT[128]
  byte  bufferM[128]
  long  symbol


PUB main
  pst.start(19200)
  GPRS.StartRxTx(7,8,00,19_200)          'Use pins 7,8 for serial communication with Shield
  bytefill(@bufferT,0,128)
  bytefill(@bufferM,1,128)
  
  repeat
    'Read entry from terminal text input and send it to GPRS
    if(getTerminalRxBuffer(bufferT))
      GPRS.str(bufferT)
      GPRS.char(13)


    'Read from GPRS and send to terminal  
    if(getModemRxBuffer(bufferM))
      pst.str(bufferM)
      pst.newline




PRI getTerminalRxBuffer(buff): available
  available := false
  if pst.RxCount > 0
    pst.StrIn(buff)
    available := true
    
PRI getModemRxBuffer(buff): available
  available := false
  if GPRS.RxCount > 0
    GPRS.StrIn(buff)
    available := true

The Parallax Serial Terminal 128 is a modification to the standard version with these changes, Buffer is now 128 and

PUB StrInMax(stringptr, maxcount)
  repeat while (maxcount--)                                                      'While maxcount not reached
    byte[stringptr] := CharIn
    if (byte[stringptr] == NL) OR (byte[stringptr] == LF)
      quit
    stringptr++
  byte[stringptr+(byte[stringptr-1] == NL OR byte[stringptr-1] == LF)]~        'Zero terminate string; overwrite NL, LF or append 0 char

I added the LF condition, because otherwise it was crashing after the first message was received from the GPRS modem.

This version, at least, works in the consistent manner I specified before.

About the pins, just followed the instructions on the ASC+ wiki for faster communications. I did not solder 7 and 8 together, just the jumpers on the bottom of the board to bypass the 2k resistor.

Thanks for answering so quickly.

Mike G · 2014-04-26 06:27

The GPRS is set to inverted Rx is that what the device expects? Directly connecting two pins is not a great idea. If one pin is high and the other is low/input you have a short and maybe some smoke. Be careful...

The secondary buffer logic does not zero terminate (or have the concept) and therefore you may have garbage from the previous command.

jrullan · 2014-04-26 07:04

Mike,

I had not considered, and maybe dont understand, what you mention about the Rx being inverted in the GPRS. That said, does it affects the code?

About the pins, maybe I'm not expressing correctly what I did, so I'm including here a picture of the board and the jumpers. I think is is required for high speed communications, as suggested in the Wiki.

Pins:

Setup picture:

Again, thanks for your interest.

Mike G · 2014-04-26 07:40

You can have inverted and noninverted serial io. You'll need to read the device docs to verify.

The secondary buffer logic does not zero terminate and can cause unexpected results.

You Re right I do not understand the pin thing. All I can see from the code is pins 7 and 8 on the prop are connected to something.

jrullan · 2014-04-26 07:49

Mike,

By secondary logic, are you referring to the second code posted?

If so, I understand it is zero terminating whenever it performs the last line:

byte[stringptr+(byte[stringptr-1] == NL OR byte[stringptr-1] == LF)]~

It should make byte[#] equal to 0 it is just using the

byte[#]~

instead of

byte[#] := 0

Does this makes any sense?

jrullan · 2014-04-26 08:18

Mike,

I checked and it seems that it is not inverted. So I guess the initialization is correct:

GPRS.StartRxTx(7,8,00,19_200)

I'm running out of ideas.

PD: The third parameter should read % 0000, but the forum markup removes the first % 00 .

homosapien · 2014-04-26 08:18

I have used that shield successfully in the past, but it has been awhile...

I have not examined your code fully to understand what you are doing at the end of the commands, but here are some thoughts after taking a quick look at the code I used:

- After sending a command, it should be followed by <CR> <NL>.
- The zero terminator of the ASCII string should NOT be sent.
- However, the AT+CMGF=1 command is only followed by a <CR>, because it is immediately followed by another command.
- Some commands return WAY more data than you might expect, make sure you are not overflowing your buffer.

snippet of my code (that requests current time from module)

   SERIAL.str(string("AT+CMGF=1", CR))
                                                        'GPRS will ACK with {13, 10, OK, 13, 10}
  waitcnt(clkfreq/10 + cnt)
  
  SERIAL.str(string("AT+CCLK?", CR, NL))               'Send time command

jrullan · 2014-04-26 08:35

@Homosapien,

Well at this point in time the code just listens to the terminal entry then forwards the entry to the GPRS shield.
The other part of the code is listening to the GPRS shield and then relaying the received buffer back to the terminal.

Though I wonder if I need to add the delay? In Arduino I guess it was needed because it is the same code that handles both ports, but in Propeller each is running on a different Cog.
I will anyway try adding the delay just in case.

Thanks for your reply.

Mike G · 2014-04-26 09:02

By no means am I suggesting that a zero terminator should be sent to the device.

Closer examination, getTerminalRxBuffer(bufferT) should be getTerminalRxBuffer(@bufferT). Since you are using SPIN string functions, you NEED to zero terminate the command strings in the secondary buffers, bufferT[128], bufferM[128], if you plan to use the buffers more than once.

PST has been around a long time. I'm not sure you need to update the object...

homosapien · 2014-04-26 09:05

Are you following the command with <13> <10> ?

Nate

Mike G · 2014-04-26 09:27

jrullan wrote: »

Mike,

By secondary logic, are you referring to the second code posted?

If so, I understand it is zero terminating whenever it performs the last line:

It should make byte[#] equal to 0 it is just using the instead of

Does this makes any sense?

Got it... I am wrong about the zero term but (byte[stringptr-1] == NL OR byte[stringptr-1] == LF) will overwrite the ending CR or LF with a zero? True = -1, false = 0

I would do as homosapien suggests and simplify the command by sending the AT commands directly without going through the terminal. Once you get that working then sort out the terminal logic.

Martin Hodge · 2014-04-26 10:52

It looks as if the GPRS shield is a 5V device and as such you should NOT be bypassing the current limiting resistors. You may in fact have damaged (definitely will damage eventually) the ASC+. Unfortunately this is the price we pay for Arduino choosing to stick with the arcane 5v TTL. You'll have to lower your serial rates with the ASC, or somehow convert the shield to operate at 3.3v if possible.

homosapien · 2014-04-27 07:14

Martin is 100% correct, there needs to be a current limiting resistor at minimum in the RX line (p7). I have never used the ASC+, so I was not really sure what the talk of modifying it was about. In my build (Propeller Project Board USB), I used a 2.2k current limiting resistor and communications work fine. Remove solder blob ASAP!

The good news is that if you are getting a response to the AT+CMGF=1 command (and you are), the hardware is probably fine. I would further investigate how you are terminating your commands.

kwinn · 2014-04-27 08:52

Print the contents of each buffer to pst between steps to help diagnose the problem. Print bufferT after reading from the terminal, and in the two PRI modules as each character is received.

Ariba · 2014-04-27 15:08

jrullan

You need to pass the address of your buffers to the methodes "getTerminalRxBuffer" and "getModemRxBuffer" when you call them.
For example:

if(getTerminalRxBuffer(@bufferT))
      GPRS.str(@bufferT)
      GPRS.char(13)

As you have it now, you pass the undefined content of the first byte in bufferT as an address. So the PST object writes into an unknown position in hub-memory, and may overwrite some Spin code, thats why it stops working.

I only found a schematic for the V2 GPRS shield, but if the the V1 has the same level translater as the V2, you don't need the current limiting resistors, the interface works with a FET for Low and a 4k7 resistor for High, so the current is limited already.

Andy

Propeller ASC+ and Seeedstudio GPRS Shield 1.0 Serial Communications

Comments