Ok, someone in Germany has already done it with a 12F629. This is his
website: www.wrankl.de/*SMS*T/*SMS*T.html<http://www.wrankl.de/SMST/SMST.html>
He has just used a 629 with a max232 as his main hardware components. But
he's got a few extra features on it which makes it that bit harder
to understand his code (for me).

The following is extracted from his notes:

example for typical communication between SMST4PIC and Mobile Phone:
;          1. SMST4PIC -> Mobile Phone: "AT+CMGS=21"  = AT command send
message and
;                                                       length of data (=
PDU) in bytes in step 4
;          2. SMST4PIC -> Mobile Phone: 0x0D          = CR (carriage return)

;          3. Mobile Phone -> SMST4PIC: "> "          = 2 characters
;          4. SMST4PIC -> Mobile Phone:
"0011000B8110570xxxxxF30000AA08D3E6944A832687"  = PDU [A]
;          5. SMST4PIC -> Mobile Phone: 0x1A          =ctrl-Z = indicates
end of PDU

Please note the following:

AT command is specific to the phone used.

Another example below of how the comms is done using a Ericcson T10, from
www.riccibitti.com (but this guy uses Atmel and I don't feel comfortable
going there)

-------------------------------------------------------------------------------

*AT*         And the cell phone answered: *
OK*        (note: cell phone responses are green)
A good start! Using this technique, I selected the commands relevant to the
application [3], simulating manually the intended algorithm.
I save you the pain going straight to the conclusion.



First, tell the phone which memory to use for successive commands:

*AT+CPMS="ME","ME" +CPMS: 7,15,7,15,7,15
OK*

This instructs the mobile to use internal memory "ME" in place of the "SM"
memory from the SIM (Subscriber Identity Module) as default memory. Next, a
message can be read from that memory specifying its number:

*AT+CMGR=4
+CMGR: 1,,27
0791934329005000040C9193433728501400001060314104350809D02A735A043DAB54
OK *

This is the fourth message, 1= received and read, 27 bytes long text, in PDU
(Protocol Description Unit) format.
The *PDU format* is quite complex, as it contains many subfields packed
together using different encodings. Among other things, it holds also
service centre numbers, origin numbers, nation codes, a time stamp, and a
descriptor of the character set used.
For more detailed information see the sidebar "SMS Data
Dissected"<http://www.riccibitti.com/tinyplanet/tiny_sidebar.htm>:
for our purposes, it is sufficient to know that the text bytes are on
the *rightmost
*position.
Storing a "*signature*" from the last 6 byte of the message, the device will
be able to *recognize* incoming messages. Right now, we are able to download
messages from the phone.
The next command frees precious mobile memory *deleting* the seventh
message:

*AT+CMGD=7
OK *

The last step is to *send *an SMS message. This proved to be the more
difficult part, as I had to find a workaround in order to avoid building a
PDU *from scratch*.
The *trick* is to ask the user to send the message manually, during the
first setup. In this way, the mobile will complete the PDU with all required
fields, it will pack the text and numbers, and it will store it in the sent
messages memory. At a *later time*, a simple command is all that is required
to *resend* the message from memory:

*AT+CMSS=1
+CMSS :96
OK*

------------------------------------------------------------------------------

So why not stick to 629 unless there really is some other obvious advantage
with some other microcontroller.

And yes this will be my first program and MC. A seriously think my ''LED
lighting days'' have been long over.

What do you all think? Thanks for all inputs.





On 3/6/08, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
>
> Jinx wrote:
>
> > However, what you propose could be done with a 12F. The
> > meagre 64 bytes of RAM...
>
> Double that in the 12F683, which is a nice chip in other ways also.
>
> But, as you say, we realy know to little yet to be too specific
> about the "best" chip.
>
> Jan-Erik.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist