 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Duinomite and MODGSM, incoming SMS
Page 1 of 2   |
|||||
| Author | Message | ||||
| Eloclegin Newbie  Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Hi, Can anyone offer advice on the following.I have no reply from Olimex support. I searched past posts on this forum but most posts on this topic focus on handshaking issue, not MMBASIC code. I am using DuinoMite (running MMBASIC) with MOD-GSM. Want to send and receive SMS messages. I have used code samples from this old app note (below) and all runs fine for sending SMS messages. (I have cut cable to the minimum wires to avoid the handshake issue). I simply OPEN a com port and PRINT#1 per the note below and Outgoing SMS and outgoing ringing works fine. http://olimex.wordpress.com/2012/02/01/duinomite-project-imp lementing-gms-remote-control-in-basic-with-few-lines-of-code / My problem is when trying to write some lines of MMBASIC to read incoming SMS from the MODGSM buffer. The Commands provided in the app note above seem to be invalid syntax? For example. INKEY$(1,1). I know only INKEY$ which is keyboard buffer Ditto for INPUT$(1,#1). I never saw two dimensional input Commands. When I try this olimex example code, with MMBASIC (loaded using MMEDIT) it just flags those Commands as Invalid basic commands. Were these commands unique to old DMBASIC? Anyway, CAN ANYONE PROVIDE A FEW LINES OF MMBASIC THAT WILL READ MODGSM buffer incoming sms messages? In principle I understand that I will need to keep polling the buffer, then once I see something I will keep adding on the chars to make up the incoming string, then finally when I see EOF or similar, it ends. Problem is, how do I read the char from incoming buffer??! Thank you in advance to anyone who can offer help. Nigel |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Once you open the port, MMBASIC will asign a 256 byte buffer for both outgoing and incoming data. All you have to do, is read that data from the buffer. You may then need to filter the data, to extract the message you need. Assuming that you have opened COM1 to the device, you can find out if there is data waiting in the serial buffer with the following line of code: IF LOC(#1)<>0 THEN... You will need to add the bit on the end of that line, depending on what you want to do. If you just want the data from the buffer, any time some is there, then you can suck the data from the buffer and store in a string(or an array - up to you) thus: [Code] IF LOC(#1)<>0 THEN DO BYTE$=INPUT$(1,#1) D$=D$+BYTE$ LOOP UNTIL BYTE$=CHR$(13) OR LOC(#1)=0 ENDIF This code will suck any bytes waiting in the serial buffer, and stick them into D$. Your SMS messages need to end with a CR(decimal 13) byte. If they end with another character, then you need to change that line to the appropriate value. Technically, you don't need to detect the CR - you could just change that last line of code to: LOOP UNTIL LOC(#1)=0 - that will keep reading bytes out of the receive buffer until the buffer is empty, then D$ will hold the contents of the serial buffer. The loop above assumes that no more data arrives in the serial buffer while it is reading it out into D$, but if more data DOES arrive, it will just be tacked onto the end of D$ till the buffer IS empty. Using the first example of detecting the CR as an end-of-message marker, means the loop can finish once it sees one complete message. You deal with that message, then you can read the rest of the buffer for the next message. All that assumes you don't overflow the buffer, which is why many on the forums would suggest you read the entire buffer in one go, rather then jumping in and out. Once you have cleared the buffer by reading it into D$, then you can dissect D$ for the data you want, leaving the serial buffer to grab any new data that may arrive in the meantime. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Grogster, Many thanks for taking the time to provide such a detailed reply. Much appreciated. I thought my MMBASIC3.2 was not recognising the INPUT$(1,#1) command and I could not find any reference to this bracketed use of INPUT$ in the MMBASIC language manual, but i guess I must have missed something. I will give it a try tomorrow. Thanks again |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
You are welcome - please let us know how you get on. 
See page 50 of the manual for the INPUT$ function. If you just want all the buffer as quick as possible, then you could setup an interrupt: SETTICK 1,XXX,BYTES Where XXX is how often you want to check the serial buffer in ms. Then the interrupt called would be along the lines of: [code] BYTES: IF LOC(#1)<>0 THEN D$=INPUT$(LOC(#1),#1) IRETURN [/code] That is about as simple as it gets, and there is no checking AT ALL for what is in the buffer, CR or otherwise, it just sucks everything waiting in the buffer and rams it into D$ then exits. I actually prefer the interrupt(settick) method myself, cos then you don't have to know there is data there, to have the interrupt check periodically for you. In the case of the above example, you would then need to check D$ periodically to see if it has been updated with any data from the serial buffer. This can be done easily with a line in your normal code such as: IF LEN(D$)<>0 THEN... That code will check to see if D$ has anything stored in it, then it can process it if it is greater then zero in length. In your code that processes D$, before that code finishes, you need to clear D$ with the likes of D$="". If you don't do that, your loop will go around forever in the same message. 
Note that this interrupt example does not allow for any new data arriving in the buffer during the time you are processing D$. If that happens, and the interrupt is called at the same time, the "Old" D$ you are processing, will suddenly become the "New" D$, which will completely corrupt your code's ability to process it, as the message data will have magically changed in the middle of processing it. 
There is an easy-ish way around that, but I did not want to confuse you too much at this point. The above is not likely to happen, so long as you are not getting a constant stream of text messages from the network. If you ARE getting lots of messages at once, then the code examples will need to be changed so that the corruption of D$ does not happen. Let me know if you expect to receive multiple messages such that a new message could arrive while processing the last one, and I will show you a new code to get around that. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I don't think MMBasic V3.2 can do it that way. If you are getting a newline at the end of the string, have a look at LINE INPUT Is there any reason why you can't update to a later version of MMBasic? Jim VK7JH MMedit  MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
That's a point - perhaps you need a more recent version of MMBASIC before you can do what I was writing about. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
So i gave it a try (upgraded to MMBASIC4.3 beforehand). This is what I get.. Using your code, I can read the buffer. I get various response back from The module. However I cannot get hold of the actual message text. When it receives an incoming message, I read the following from the buffer.. +CMTI: "SM",25 I believe this is simply indicating that an SMS message has arrived and is available to read, but I dont know how to get to the chars of the actual,message!! (By the way, the 25 simply indicates the number of incoming sms and it just counts upward, with each new incoming message, until I send a command to delete all) Other actions also seem to produce sensible responses from the buffer. Eg. If I call the number of the GSM module, then buffer reads RING If I PRINT#1 the AT command to enable caller ID, then I also see the incoming number, when it rings If I drop the call, the the buffer reads NO CARRIER So my question is once I have incoming sms, ie when i see +CMTI: how do I get to the actual text of the message.???? At first i thought I was perhaps not reading the full buffer but I am LOOPING UNTIL LOC(#1)=0 using exactly your suggested code. If I look at the Olimex rough app note for the MODGSM they show some code which apparently works for many people. once the string "+CMTI:" is detected ie.then they PRINT#1, "AT+CMGR=1" and then read again, but when I try this it does not yield any extra characters. BTW. The actual olimex code uses the command INKEY(1,1) instead of your INPUT$(1,#1) to read buffer, which seems odd. Is that a command unique to DMBASIC? I am curious to understand this, because apart from this oddity, it appears to run fine for many who tried it and they read the text of the message. Also, surprisingly, I am not able to find SIM340 data sheet on the net. I am 99% there!! Just need to read the text of the message. Any thoughts? Thank you again Nigel PS. Here is the olimex code, reproduced from their web note 5 PHONE$ = “+359897286123″ ‘this is the phone number which SMS we will process 6 CMD$ = “LED=ON” ‘ this is the command which to trigger my action 7 ACTION = 0 ‘ listen 10 OPEN “COM3:9600″ AS #1 15 PRINT #1,”AT+CMGF=1″ : PAUSE 250 ‘ set TEXT SMS mode 20 MSG$=”” 30 IF EOF(1) THEN 20 ‘wait MOD-GSM to tell us something 40 M$ = INKEY$(1,1) ‘read one character 50 IF M$ = CHR$(13) THEN 100 ‘process incoming message 60 IF M$<> CHR$(10) THEN MSG$ = MSG$ + M$ 70 GOTO 30 ‘wait for new message 100 IF INSTR(MSG$,”+CMTI:”) <> 0 THEN 200 ‘ new SMS arrived 105 IF INSTR(MSG$,PHONE$) <> 0 THEN 230 ‘ the SMS is from secure number 106 IF INSTR(MSG$,CMD$) <> 0 THEN 250 ‘ we recognized command 110 GOTO 20 200 ACTION=1 ‘ SMS is ready to be read 210 PRINT #1, “AT+CMGR=1″ : PAUSE 200 ‘ read the SMS in memory 220 GOTO 20 230 ACTION=2 ‘ SMS comes from secure phone 240 GOTO 20 250 IF ACTION = 2 THEN PRINT “COMMAND RECEIVED AND EXECUTING…” 260 ACTION = 0: PRINT #1, “AT+CMGD=1″ ‘delete the SMS 270 GOTO 20 |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Ahhhhhhh - the cell module is saving the SMS internally, and only telling you that it has one in it's memory - just as you think is going on. You have to instruct the cell module to forward any incoming SMS directly to the serial port(it's serial port), so that the SMS is squirted out of the module as soon as it receives it. It will THEN be waiting in the uM serial buffer for you to read. Now, without reading through the manual for your module I can't be 100% sure, but it certainly looks like this module makes use of standard AT commands. Redirecting the SMS output was something I had to do with my ElecFreaks cell phone modules for exactly the same reasons. I will have a hunt for the command you need to issue to the module, to have it automatically send SMS messages to it's serial port - I have it here somewhere. EDIT: Found it. I will also have a look for the 340 datasheet, but it sounds like an early model going by the 900 number on my ElecFreaks cell module. AT+CNMI=2,2,0,0,0 Set module to auto-route incoming text to serial port You need to enter this command either using the likes of TeraTerm, or you could write a simple BASIC code to send this command to the module. THIS WILL ONLY WORK, if your cell module supports AT commands, and this command specifically. This works for me on the ElecFreaks module, which uses the SIM900 cell module - might not be supported on the 340. Assuming your module accepts this command, the settings are saved. Cycling power will not alter this command, it will remember what you told it. As to the syntax of the commands, there is/was a long-standing "Issue" between your chosen supplier, and Geoff when it came to MMBASIC, so it may not be possible to upgrade your chosen board to more recent MMBASIC versions, because Geoff changed his license such that your chosen supplier has to update their port of MMBASIC themselves now and not just use Geoff's version. Your chosen supplier also elected to use a different I/O pin arrangement over the bog-standard CMM, which also can potentially cause issues with pin assignments etc. All I can do, is show you what works for me with a genuine CMM unit, as I have none of your units here. Here is an example of making the change, then receiving a text message via TeraTerm: [code] AT OK AT+CNMI=? +CNMI: (0-3),(0-3),(0,2),(0-1),(0-1) OK AT+CNMI? +CNMI: 2,1,0,0,0 OK AT+CNMI=2,2,0,0,0 'Set module to auto-route incoming text to serial port OK +CMT: "+64000000000","","14/10/16,17:09:35+52" Hello module. [/code] I have replaced the cell-phone number with zeroes for privacy. Once CNMI is correctly set, any SMS that arrives will be squirted out of the module. In the example above, the message starts with "+CMT:" followed by the number, date and time. Note my example is copied from a TeraTerm log-file, hence the 16/10/14 datestamp.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
I added an extra line ..PRINT#1,"AT+CNMI=2,2,0,0,0" When I run the buffer seems to accept this command. It returns "OK" When I send an sms message to the module, it now shows +CMT: ,25 .............(Previously it was. +CMTI: "SM",25) I then get a string of chars that look like Hex? I tried Hex to Ascii conversion but results are garbage. I tried shifting one char and converting. Still garbage. However there is some correlation between what I sent in the sms message and what is read from buffer. Including the length of message read. I just cannot decode it. Here are 3 examples of what I send and what I read from buffer from the module. Any ideas? A Testy ATesty MSG$= 07913396050066F1040B913356215344F00000411130807030400141 MSG$= 07913396050066F1040B913356215344F000004111307055754005D4F29C 9E07 MSG$= 07913396050066F1040B913356215344F000004111308080654006416A79 4ECF03 BTW. The sending number is +33651235xxx. (I don't give my last 3 digits). I mention in case caller ID is embedded there. Still not found SIM340 datasheet. The link on the simcom.us website doesnt work Yes, I am aware of history and have too watched efforts to commercially exploit Geoff's good work, as well as the pin I/O mess. I have several Maximites but wanted a tiny form factor quickly for this test, hence using a DuinoMINI. I am already awaiting delivery of a GSM module which uses SIM900 and have ordered a couple of micromites to try next. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Yeah, that's an odd output alright. Does kinda look like hex, but might not be. Who knows. I will see if I can find the datasheet for the 340. Once you get your 900 series module, you should find that everything then works. I am speculating that the 340 module just does not quite support the same output, otherwise you would be seeing what I posted above. 
EDIT: The output could be "ASCII HEX" instead of true hex. Two bytes to make one, so to speak. "F" and "F" for FFh, "0" and "7" for 07h for example. In that case, you would have to run the bytes through a filter to combine the MSB and LSB into ONE true data byte by combining the ASCII hex two byte codes. I'm not sure if this is the case, and if it is, WHY the 340 would want to be difficult by outputting data like this, but I will have a hunt for the 340 manual now. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Yes, i had similar thoughts. But lots of other users have in the past reported fine results using that code stub from Olimex app note, without this degree of hassle, so I would expect it to be straightforward. I will spend a few hours "code breaking" but my guess it that it will be quicker to fire up a proper MM with a SIM900 module and try that. Currently, all my MMs are integrated into "projects" so not readily available on the bench at the moment. Thank you again for your kind assistance. Very much appreciated. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Don't lose too much hair over it, and do let us know how you get on. No idea why the code stub from Olimex won't work. As I don't have either an Olimex module or the 340 GSM module, I can't really test any of that side of things for you, unfortunately. I was unable to download the 340 datasheet either. Sim.com kept asking me to login or register, in order to download the datasheet. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
i sent a few test messages and recorded the string read from buffer each time. This is what I see. The first char is the content of the sms message (eg "A") and the long hex type string is what I get from buffer in response. (I mention in case there is a retired WW2 codebreaker out there!!) A=07913396050066F1040B913356215344F00000411130111065400141 B=07913396050066F1040B913356215344F00000411130110094400142 C=07913396050066F1040B913356215344F00000411130112034400143 ABC=07913396050066F1040B913356215344F00000411130114055400341 E110 a=07913396050066F1040B913356215344F00000411130119055400161 b=07913396050066F1040B913356215344F00000411130110172400162 c =07913396050066F1040B913356215344F00000411130111175400163 abc=07913396050066F1040B913356215344F00000411130112153400361 F118 1=07913396050066F1040B913356215344F00000411130113134400131 2=07913396050066F1040B913356215344F00000411130113134400132 3=07913396050066F1040B913356215344F00000411130114195400133 123=07913396050066F1040B913356215344F00000411130115174400331 D90C Btw. If I ring the module during this process I get a sensible response from buffer showing RING and incoming number etc. Outgoing SMS also works fine |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
...very strange output.... I have no real idea what the module is trying to tell you or any of us by that. We kinda need the 340 manual at this point, don't we? (rhetorical)  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Read the manual????? That would be a bit radical ! :-) Seriously, I will still try to track down the 340 at command set. If not, then wait for a sim900 with a proper MM. Cheers. |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
CRACKED IT!!!!!! I studied the AT command set for SIM900 for SMS messages. There is one for incoming message "type". CMGF It defaults to "pdu" and must be changed to "text" type. So I sent. AT+CMGF=1 Suddenly the messages appear as normal text!!! Wonderful !!! So in summary.. 1. DuinoMiteMINI can run MMBASIC4.3 talking to a MOD-GSM rev A. (provided you cut the UEXT cable down to 4 wires only). 2. MOD-GSM module uses old SIM340 which is now EOL and datasheet hard to obtain. It seems however to respond to most AT command set. 3. For incoming sms messages the default state is "PDU" and requires -+CMGF=1 to set incoming message format to text type. 4. It always pays to read the manual !! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
What I CAN tell you at this point, is that the SIM900 based module I have does output the text messages as plain text as you would have seen in my examples I posted on page 1. That means much less brain-strain trying to decode ASCII-hex or whatever the hell that actually is!
...just remember to execute that CNMI code on your SIM900 before you try, as factory-default is to NOT auto-forward received text messages to the module's serial port... In any event, I'll be watching to see how you get on.
EDIT: I see you cracked it!  Well done you. It's 1:57AM here in Kiwiland, so I now need to rest my little grey cells. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Closing note. the SIM340 does not store the CNMI command that sets autoforward. At least it loses it on my MOD-GSM module when I power off. So it needs to be rewritten again, at power on. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Eloclegin, here is some code for you to play with. I have it running on a sim900 module, so you may need to change some things, but for the most part, it works fine on a uMite. It will give you an idea on sending and receiving sms and controlling stuff. You can see that I just have it controlling pin 3 on the umite and sending back info if it did it or not. You can add a whole bunch of stuff in the checkcmd subroutine. This code has been running on a umite for about 3 months now without fail. Not the best code but a start... Text "aon" to set pin 3 high Text "aoff" to set pin 3 low option autorun on
GOODNUM$ = "2223334444" 'GOOD NUMBER HERE - AREA CODE AND NUMBER NO SPACES SETPIN 3, DOUT PIN(3) = 0 OPEN "COM1:9600" AS #1 RESTART: FLUSHBUF PAUSE 400 PRINT "INITIALIZING SYSTEM.... PLEASE WAIT." PRINT #1,"AT" PAUSE 200 PRINT #1,"AT" PAUSE 200 PRINT #1,"ATE0" 'TURN ECHO OFF PAUSE 200 FLUSHBUF PRINT #1,"AT" 'DO QUICK MODEM RESPONSE CHECK PAUSE 200 GETSTRING CHECKOK PRINT #1,"AT+CMGF=1" 'TURN ON TEXT MODE PAUSE 200 GETSTRING CHECKOK PRINT #1,"AT+CLIP=1" 'TURN ON CALLER ID PAUSE 200 GETSTRING CHECKOK PRINT #1,"AT+CNMI=2,2,0,0,0" 'SEND SMS DIRECT TO SERIAL PORT PAUSE 200 GETSTRING CHECKOK 'PRINT #1,"AT+CMGD=1,4" 'CLEAR SMS 'PAUSE 200 'GETSTRING 'CHECKOK '********************** MAIN ************************* MAIN: DO FLUSHBUF ERASESMS PRINT "WAITING FOR SMS TO COME..." DO WHILE LOC(#1)=0:LOOP CHECKIFSMS IF ISSMS = 0 THEN REPLY$ = "SOME DING DONG TRIED TO CALL ME... I ONLY TEXT, DUH!!!" REPLYSMS REPLY$ PAUSE 200 GOTO MAIN ENDIF CHECKNUM PRINT "SMS COMING IN FROM ";CHECKNUM$ IF GOODNUM = 0 THEN PRINT "NOT A GOOD NUMBER...":PRINT REPLY$ = "YOUR NUMBER IS NO GOOD HERE BUSTER!" 'SENT BACK TO BAD NUMBER REPLYSMS REPLY$ GOTO MAIN ENDIF CHECKCMD LOOP '********************************************* SUB ERASESMS print #1, "AT+CMGDA = " + CHR$(34) + "DEL ALL" + CHR$(34) PAUSE 200 GETSTRING CHECKOK END SUB '********************************************** sub FLUSHBUF PAUSE 100 DO:A$=INPUT$(1,#1):LOOP WHILE LOC(#1) <> 0 END SUB '*********************************************** SUB CHECKIFSMS PAUSE 200 GETSTRING ISSMS = 0 IF INSTR(SMS$,"+CMT")<>0 THEN PRINT "INCOMING IS VALID SMS" ISSMS = 1 EXIT SUB ENDIF IF INSTR(SMS$,"RING")<>0 THEN PAUSE 400 PRINT #1, "ATH" PAUSE 500 GETSTRING PAUSE 200 CHECKOK PRINT "RING DETECTED, AND I HUNG UP!!!" EXIT SUB ENDIF END SUB '********************************************** SUB GETSTRING SMS$="" PAUSE 200 DO S$=INPUT$(1,#1) SMS$=SMS$ + S$ LOOP WHILE LOC(#1) > 0 PRINT "GETSTRING = ";SMS$ IF INSTR(SMS$,"ERROR")<>0 THEN GOTO RESTART END SUB '*********************************************** SUB CHECKOK IF INSTR(SMS$,"OK")<>0 THEN EXIT SUB PAUSE 500 GOTO RESTART END SUB '*********************************************** SUB CHECKNUM GOODNUM = 0 B = INSTR(SMS$,"+1")+2 CHECKNUM$ = MID$(SMS$,B,10) IF CHECKNUM$ = GOODNUM$ THEN GOODNUM = 1 END SUB '************************************************ SUB CHECKCMD IF INSTR(SMS$,"aon")<> 0 THEN PIN(3)=1 PRINT "A IS NOW ON" REPLY$ = "HELLO MASTER... A IS NOW ON" REPLYSMS REPLY$ EXIT SUB ENDIF IF INSTR(SMS$,"aoff")<> 0 then PIN(3)=0 PRINT "A IS NOW OFF" REPLY$ = "HELLO MASTER... A IS NOW OFF" REPLYSMS REPLY$ EXIT SUB END SUB '************************************************ SUB REPLYSMS REPLY$ print #1, "AT+CMGS=" + chr$(34) + CHECKNUM$ + chr$(34) pause 200 GETSTRING DO IF INSTR(SMS$,CHR$(62))<>0 THEN EXIT DO 'RECEIVED ">" LOOP print #1, REPLY$ PRINT "SENDING SMS = ";REPLY$ pause 200 GETSTRING DO IF INSTR(SMS$,CHR$(62))<>0 THEN EXIT DO 'RECEIVED ">" LOOP print #1, chr$(26) 'SEND CNTL Z TO SEND TEXT SMS pause 5000 'WAIT FOR MODEM RESPONSE 5 SECONDS!!! WORKING ON THIS... GETSTRING DO IF INSTR(SMS$,"+CMGS")<>0 THEN EXIT DO 'FINISHED SEND LOOP end SUB |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Thanks ViscomJim, I appreciate you sharing your code. Will look through it. It is all helping my experience with GSM modules. One area that I could do with advice is the following..... I want the MM to be simultaneously looking at both the GSM module for an incoming message and also the I2c bus for an incoming message. Messages can come in on either every few minutes. In either case, if it receives something from one then it must go off and handle the message via actions for about 3 seconds, then come back and NOT have missed anything on the other. (There is no issue of missing anything on the one already being handled, since events on the SAME one cannot occur that frequently). Any ideas on how best to structure this at top level, since it will dictate the structure of my prog. Would it be best to give priority to the I2C (process this via I2C interupt, which I have done many times before) and just assume that (if an SMS arrives while I am dealing with I2C received data) then the GSM buffer will just hold any incoming sms, without loss, UNTIL i go back and read it. Does this make sense? But then, What happens if I should get an I2C receive interupt when I am part way through reading GSM buffer? I welcome any advice from you gurus. Much appreciate all your help. |
||||
| Page 1 of 2 |
|||||
 Print this page |
