Best approach to check sms while doing other work(GSM modem+atmega328p))

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear freaks

 

I am designing a remote sensing platform(multiple door sensor+multiple dc-current+multiple ds18b20 temparature sensor+dc voltage sensing) using atmega328p & gsm modem.The unit should alert the user if door opens/high temparature occurs/dc voltage falls below a certain point.In addition,the unit should also respond to user queries sent via sms(manual current sensing/door state sensing/temp sensing & voltage sensing).

Now,I would like to know,while the cpu is doing a work(for say,communicating with ds18b20) and a sms apperas,what would be the best way to read the sms?

Should i use uart interrupt(that would ruin the ds18b20 reading in this case) or should I manually read the sms after completing the said task(disabling uart interrupt while doing other work and enabling it after any particular task got finished)?

 

Rgds//Sharanya

Last Edited: Mon. Dec 11, 2017 - 04:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a similar challenge 20 years ago - doing 1wire comms whilst doing uart. My solution was to disable interrupts whilst doing a 1wire bit. The uart can interrupt between 1wire bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you should a buffer that catch uart interrupt for sms... put things in some buffer... check that buffer at end of while(true) { } block.... also disable interrupts while doing 1 wire comms... but it comes at risk of losing sms... the best thing is to check frequency by which u receive sms.. so keeping interrupt ON so it would be least likely you have to flush 1 wire comms if that frequency is less...

Show's ON....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SHARANYADAS wrote:

...while the cpu is doing a work(for say,communicating with ds18b20) and a sms apperas,what would be the best way to read the sms?

 

Wait until you have finished what you are doing and then retrieve the SMS. There is no need to respond immediately.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Setup RXC interrupt and feed the received characters into a decent sized ring buffer then just pull out and process complete "sentences" as and when you have time. Only "danger" is possible buffer Overflow. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SHARANYADAS wrote:
 uart interrupt(that would ruin the ds18b20 reading in this case)

There is no reason why UART interrupts should ruin 1-Wire comms!

 

The critical timings for 1-Wire are only a few microseconds at a time - it won't hurt to disable the UART interrupt for that long.

 

And besides, as others have said, you can just poll the modem at times when you are not doing 1-Wire comms - thus avoiding the issue altogether!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok....But i would like to know one thing!

For say,while reading from the ds18b20,a long strings appears via RXC interrupt,then the cpu must service the uart ISR.So the ds18b20 read function/time critical actions will be delayed.So there is a possibility that I read incomplete/wrong data from the ds18b20 due to timing delay...Am I right??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SHARANYADAS wrote:
while reading from the ds18b20

Again, the critical timings for 1-Wire are only a few microseconds at a time - it won't hurt to disable the UART interrupt for that long. See #7

 

long strings appears via RXC interrupt,

No, it doesn't.

 

Only one single character appears per RXC interrupt. All the handler needs to do is to take that one single character and put it into a ring buffer. See #4 and #6

 

And, apart from all that, you could disable all unsolicited responses from the modem - so that it only speaks when spoken to.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that this is entirely general - nothing specifically to do with AVR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the best approach is to manually check the sms(via RXC interrupt) after all the time critical task is finished!!....

Last Edited: Sun. Dec 10, 2017 - 08:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, "best" is endlessly debatable - but it is certainly a perfectly good solution.

 

Now you can mark the thread as solved: http://www.avrfreaks.net/comment...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure I understand the problem.

 

I would think that the remote modem comm's would be a higher priority than reading the various sensors, and that that would occur rather infrequently.

 

If the modem receives a request, then typically you send the array of most recently obtained data values.

 

Or, you spend the time to re-poll every device and then send that data array.

 

In either case, interrupting the reading cycle of a bunch of sensors shouldn't matter.

Your system should be robust enough to recover / re-initialize a DS sensor to handle noise on the line, power glitches, or interrupts to handle higher priority tasks.

 

JC

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doc, the problem is you don’t know when the uart data is going to arrive. With one wire, you need to time each bit with microsecond resolution - so if a char arrives whilst timing a one wire bit, then that upsets the timing. With one wire, the timing between the bits is not critical, so disabling ints for around 100us whilst doing a one wire bit is one way around the problem. The other is detect the one wire comms error caused by ints and retry later. It has a CRC for this. Temperature really doesn’t change too quickly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, agreed.  Perhaps not well stated by me, but if one assumes USART comm's is the higher priority, then go process its interrupt.

Understood, that might well trash the comm's to the DS temp sensor, but so what.

Either you already have an array full of recent data, or you go capture new data, while the data requester is standing by awaiting the remote unit's response.

 

Trashing the link to any DS sensor on the bus shouldn't matter.

You reset the bus and query the desired temp sensor.

I'd think the OP needs the ability to re-set (re-initialize) the DS sensor bus no matter what, whether it is interrupted by the USART, or a power glitch, etc.

If the overall sampling rate was once per minute, for example, then just reset the bus before one queries the sensors.

Its a digital chip.  It doesn't care how many times you reset it.

 

I'd have to go look at the DS data sheet to see the tolerance on the sending and receiving bit patterns, to see if merely grabbing an incoming USART byte and stuffing it in a ring buffer takes too much time.

I guess on would have to calculate the maximum rate of data arrival at a given baud rate, to see how many times one would need, at max, to process the RxData ISR, within one bit time, to calculate the maximum error.

But, as above, if one is willing to trash the DS comm's and then reset the bus for the next reading, this becomes immaterial.

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
 if one assumes USART comm's is the higher priority

But, in this case, I do not think that is a good assumption!

 

A GSM module - any GSM module - can handle receiving & storing SMS messages entirely autonomously; so there is no need at all to give its comms high priority.

 

You simply query the GSM module at a convenient time - when you are not doing 1-Wire comms.

 

(some GSM modules can indicate incoming SMS on a pin - eg, RI - so you could just check the state of that pin without having to use the UART at all).

 

see if merely grabbing an incoming USART byte and stuffing it in a ring buffer takes too much time

Look at it the other way: as noted in #7, #9, and #14, disabling the UART interrupt while doing 1 bit of a 1-Wire transaction - which is the only part where the timing is critical - is not going to disrupt the UART comms.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
With one wire, the timing between the bits is not critical

Absolutely

 

disabling ints for around 100us whilst doing a one wire bit

I forget the details now, but pretty sure that the actual critical part is significantly less than that?

 

Just the 15us ?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again, nothing specifically to do with AVR.

 

Exactly the same advice here: http://www.8052.com/forum/read/1...

 

This had 2 separate 1-Wire busses, and three interrupt-driven UARTS (one of which was managing a TCP/IP link over a GPRS module) - not to mention a load of other stuff - and there no problems just disabling interrupts during the critical part of the 1-Wire transactions:

 

BT redcare VIU

 

and that was an 8052.

 

 

Last Edited: Mon. Dec 11, 2017 - 10:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get it now.

 

If the GSM Modem has its own internal Data Received Buffer, then one can easily make it a low priority device and not worry about it.

 

Either way, it sounds like the OP needs to spend some time thinking about the high level program design and how best to integrate the various subsystems, (which is, no doubt, what lead to the post in the first place!).

 

JC