Resetting/Changing the Serial Interface (ASCO) | Telit Cinterion IoT Developer Community
April 27, 2017 - 6:37pm, 2350 views
I am using an aplicom board which has integrated EHS5 with only one serial interface. Since I wanted to use the stdout so I enabled it by using AT^SCFG="Userware/Stdout","ASC0". Previously, it didn't work because of fact that we can't switch on the system output on the same interface which you are using to send the AT^SCFG command. But later it worked, but it always show System.OUT Started ( I can't use AT commands because there is only one serial interface ). Is there any way to disable it and revert back to the original settings in which I can use AT commands ? Thanks.
Generally it is not possible to use AT interface together with system out on one interface. It's interesting how you managed to do it.
If you have no other interface (for instance USB or another serial) you could still try to deactivate the system out on the ASC0 interface but you need to send the command very fast after booting, you need to prepare the command in the terminal and just press enter when the module boots or you may use some script if that would not be fast enough.
Alternatively you could use OTAP to load and run another MIDlet that will send the command.
Thanks for your reply. I know it sounds a bit weird because I also read that I can't use it in that way, but it did work. I contacted the company from which we bought the hardware and they sent me a script which did exactly as u mentioned.
My scenario briefly :
Read data from a GPS receiver ( Position ) using serial interface and send it to a server. Server replies me with some data and then I write that data back to the serial interface. So, this involves reading and writing on serial. Can I use the System.out Serial interface to do this or I need another seperate interface ? What I want to achieve is reading from and writing to serial , able to perform System.out and should also send AT commands at the same time.
You could use multiplexer as Antero has advised to have more virtual interfaces.
If you have System.out activated on the interface then you can't send AT commands on it. I'm not sure from your description which functionality is realized by MIDlet. The MIDlet application on the module reads data from a GPS receiver on serial and sends some data from server to the GPS receiver on the same serial? And how about AT commands? Generally it is possible to open a serial interface in Java MIDlet and it is possible to redirect System.out to the same interface. However it is not a recommended solution. But it will work. You will then not be able to send any command on the interface but only send data to the MIDlet while it's working. You could then also implement the AT commands interpretation inside the MIDlet and send the commands by AtCommand instance.
Yes you are right the MIDlet application running on the module will read the position data from the serial interface and writing the received data from the server on the same serial interface.
So your recommendation would be to use 3 interfaces:
-one for reading and writing from/to the serial interface
- one for System.out
- one for sending AT commands
Not recommended but it will work :
But one common serial interface can also using for reading/ writing from to Serial interface as well as performing System.out , but we can't use it for AT commands ( one more interface is needed ).
Am I right on both recommended and non-recommended approaches?
The separate interfaces would probably be the most convenient solution.
Your understanding is correct. While System.out is mixed with Java application there is System.out mixed with the data sent by the MIDlet on the interface and your device that is connected to the interface also receives that data. So it is better to have a separate interface for application debug. If your device that contains GPS can also send AT commands you need another interface for that or the Java MIDlet would need to read the commands that the device sends and would need to execute these commands with the provided Java API and send the replies back on serial.
It would be the best way to do some tests before taking a final decision.
One way to try to recover is to install the Multiplex Driver on Windows.
Then you will get three virtual channels where probably only one is designated as standard out.
The two other channels can be used for AT commands.
I am not sure if this works but is worth to try.
Communication and Mechatronics
Enkom Active Oy – www.enkom-active.fi
Upseerinkatu 3 A, 02600 Espoo, Finland
Mobile: +358 400 411368
Office: +358 10 204 0000
Fax: +358 10 204 0010