And if you use it only for sending SMS, why would you want to use it in the first place. You can easily write an AT command yourself to the serial port of the SMS module and send the message...
Maybe you could you use interrupts to do the detection and counting of incoming rising edges if they are not disabled by the sendSMS() function.
The shield is using (software???) the pins 2 and 3.
I didn't succeeded to compile GSM.cpp with a change to pins 4 and 5.
Am i deluding myself thinking that interrupts are used to execute a function in a very small amount of time, and coming back to counting edges very quickly ? What if the function takes too long ?
Is there a big/long protocol beside SMS, or do i use a bad library ?
Which SMS library are you using?
And if you use it only for sending SMS, why would you want to use it in the first place. You can easily write an AT command yourself to the serial port of the SMS module and send the message...
It takes a single AT command to send an SMS - AT+CMGS - and if you download the command reference for your GSM device then you'll find all the information you're likely to need!
the delays are needed to await a response from the shield via the AT command.
100ms to 1s following command sent and waiting for an answer, and more than 5s to acquire an IP if you use http request.
I would not wait for a response. Rather just issue the AT+CMGS command, delay some millisecs so the command gets printed to the software serial and then continue with my code.
I'm not sure how exactly delay works but to be on the safe side If I want to delay something in my projects I just use a while loop. That way, I'm sure everything that goes on in the background, continue to execute are they are supposed to...
I think interrupts are the way to go for you though. I'm not sure I understand exactly what you are counting, but if its pulse-like signal, then you can connect it to one of the INT-enable pins and write a small (REALLY small, ie, just increment a variable) ISR routine.
When the interrupt gets triggered everything else stops for the ISR to complete. That way you are sure you are not loosing pulses.
Have a look at the examples here and in Nick Gammon's excellent (as always) tutorials.
Confirm what? That SoftwareSerial uses interrupts? It does.
the delays are needed to await a response from the shield via the AT command.
Nonsense. You need to understand how asynchronous communication works, and how to NOT coerce asynchronous communications to be synchronous.
It's like posting here, and sitting and staring at you computer, waiting for a reply. No one does that. You post. You go away. You come back later, and see of a reply, or none, or twelve came in.
PaulS:
Confirm what? That SoftwareSerial uses interrupts? It does.
So, here it is. Confirmed then.
PaulS:
Nonsense. You need to understand how asynchronous communication works, and how to NOT coerce asynchronous communications to be synchronous.
It's like posting here, and sitting and staring at you computer, waiting for a reply. No one does that. You post. You go away. You come back later, and see of a reply, or none, or twelve came in.
I doubt it his code that uses the delays though. Must be the library that does. Why would he need to wait for responses if he uses a library for his SMS communication?
3mmanu3l:
Sorry about word "front" which is the french name of a pulse edge.
Thank you for fixing this. I edited the first post so "fronts" dont appear anymore.
I think I've seen it called that in English too, but the context made it clear that it was pulses that were being discussed.