limitations to adl_atCmdSubscribe()on UART?

ADL, A&D memory, Flash objects, multi-tasking, file system, DOTA.

limitations to adl_atCmdSubscribe()on UART?

Postby CAA » Tue Jun 12, 2012 12:10 pm

Hello everyone.

My system is build of 2 modules. Module "a" (not a SiWi product) sends information via at commands on the uart to a SL6087 Modul.
An example AT command would be:
Code: Select all
AT+MY_TOAST=1

which i´ve subscribed to with the function:
Code: Select all
adl_atCmdSubscribe ( "AT+MY_TOAST", CmdHandler_MyToast, ADL_CMD_TYPE_PARA | 0x11 );

This way im having 15 commands which gets send by the other module in a loop, with about 200ms between each command. So i´m sending about 5 commands per second from the other module.
The longest commandString is about 60-80 charakters, the others are normaly < 20.

At the start, the all the CmdHandlers gets called whenever the module sends the particular command (or if you want to see it from the other side: when the SL6087 retrieves it^^)- or when i enter it manually in the remote shell (dev studio).

After (seemingly) random time durancys (which allways seems to be < 10 minutes) the SL6087 stops to handle the commands, which got send by the other module (if i believe the debugger of the other module^^). But when i enter an command manually into the console, it still gets handled.....
But as soon as i restart the SL6087 via
Code: Select all
at+cfun=1
it starts to handle the commands which got send from the other module again, without causing any "harm" (like a restart) to the other module.


So...Is there some sort of a limitation to sending AT commands via UART (to an SL6087) or is it more likely that something happens on the other module, which currently is just unnoticed or wrong interpreted by me?
CAA
 
Posts: 77
Joined: Tue Oct 04, 2011 4:09 am
Has thanked: 4 times
Have thanks: 4 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby awneil » Tue Jun 12, 2012 9:26 pm

Remember that AT commands work strictly on a command-response basis; ie, the "client" must not send a new command before it has received the final response to the previous one!

At the speeds you mention, I think you possibly ought to be looking to a different protocol between your modules...?
When I say "SiWi", that's short for "Sierra Wireless".
User avatar
awneil
 
Posts: 6641
Joined: Mon Dec 03, 2007 1:18 pm
Location: Basingstoke, UK
Has thanked: 54 times
Have thanks: 88 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby zafer » Wed Jun 13, 2012 5:10 am

i think you can have a look at what you get on uart. Maybe, you start getting wrong characters within your custom AT command and your module can not execute the command.
zafer
 
Posts: 257
Joined: Wed Oct 15, 2008 7:59 am
Has thanked: 7 times
Have thanks: 5 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby CAA » Wed Jun 13, 2012 8:26 am

since i don´t want to rebuild half the programm (which in most parts isn´t written by me), i´ll try to stay at at-commands.... but yes, it most likely is not the best protokoll to choice....

the connection is "hard wired", i can´t just put a pc between the two modules and forward the data, while monitoring them... how can i look into the transmition? Does the Dev Studio have some function in that direction?
CAA
 
Posts: 77
Joined: Tue Oct 04, 2011 4:09 am
Has thanked: 4 times
Have thanks: 4 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby tobias » Wed Jun 13, 2012 11:55 am

When you send commands manually from the console, is it on the same UART as the "other module" is sending AT commands on or a different?

I have observed that AT-command processing can stop at random when saving data to flash, and I have to use the +WMFM command (on virtual port or the other UART) to close and re-open the UART that I was receiving commands on in order to get it working again.
tobias
 
Posts: 435
Joined: Sun Dec 02, 2007 10:00 am
Has thanked: 3 times
Have thanks: 20 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby CAA » Wed Jun 13, 2012 12:44 pm

the module sends on UART1, while i´m on UART2

and i´m neither writing nor reading the flash... but to reopen the UART is an idea i´ll try.
CAA
 
Posts: 77
Joined: Tue Oct 04, 2011 4:09 am
Has thanked: 4 times
Have thanks: 4 times

Re: limitations to adl_atCmdSubscribe()on UART?

Postby CAA » Mon Jun 18, 2012 7:13 am

reOpening the UART works just fine, even if its just a workaround... :S
CAA
 
Posts: 77
Joined: Tue Oct 04, 2011 4:09 am
Has thanked: 4 times
Have thanks: 4 times


Topic Tags

UART, adl_atCmdSubscribe

Return to Operating system

Who is online

Users browsing this forum: No registered users and 1 guest