AT Commands and USB

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

Hi Freaks,

Newer model cellular phones are connected to USB and also my old Ericsson T68i could communicate via USB if the cable has built-in USB -> Serial converter.

How does this work?
Seem to me that all new phones still use AT Commands.

Is it as simple as connecting an FDTI232R chip in btw and feed it with the same AT Commands from AVR side and get the "normal" replies from the phone?
And that all "modern" cellular phones have cables with a built-in USB -> Serial converter?

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

That won't work - the phone would act as a USB device, which means you need a USB host to be able to enumerate it. In terms of AVR models, that limits you to either the AT90USB1287, or the AT90USB647.

The phones do not implement the same serial protocol as thr FTDI chips, which use custom drivers. Rather, the carry one or more CDC class serial interfaces, which you need to find by reading the device's descriptors and configuring the USB AVR's pipes accordintly. This can be done with relative ease using my LUFA library and one of the above AVRs.

Once enumerated by a USB host, you can exchange regular AT commands through the CDC data pipes.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Dean,

Grateful for your answer.
Even though it seem to involve some more work than I hoped for.
So far I've stayed away from the depths of USB, as it seemed far more complex than other standards.
I have though read a lot of forum posts over the years so I know you're the authority on this site when it comes to USB.

A short description of my project:
I've developed a system for control and overview of heating systems.
As part of this I want to give the customer ability to communicate with the system by connecting a cellular phone to the main board to use as a modem.

The software is written so that every task to be performed run as a subroutine from main. All code is in ASM.
There are no ISR's except RTC from Timer2 twice a second.
Communication with modem has a slice of those 500mS where nothing else need to be serviced.
As for now appx 150 mS is used.
Can be extended to appx 300mS since I have some "spare time" waiting for next RTC tick.

Deliberately I've kept the number of used AT Commands to a minimum(4)to work with as many brands and models of phones as possible.
99.999% of the time AVR ask every second if any SMS have arrived and get the answer no.
At rare occasions the user send an SMS to change a setting or AVR send an alarm to inform the user of certain events.

I've studied V-USB and similar software but the somewhat bloated code and lack of useful comments made me back off. I was hoping that an FTDI chip would solve this. I realize now that there's more to it...

I suppose high speed USB is not needed for this.
I can dedicate 16Kb FLASH/1Kb SRAM for the task.
Given my specs, is it realistic to implement USB Host in ASM in a "normal" m324 AVR and then use the FTDI chip?
I've studied USB647 during the day and it seem to have all features from m324 that I use.

Hopefully this will eventually be a consumer product.
As far as I understand there's some sort of unique HID/PID needed?
Will that be an obstacle or involve big costs?
Does USB647/LUFA differ from m324/FTDI in this respect?

Right now I'm leaning towards changing AVR model to USB647.
A bit painful that no PDIP's are available while prototyping.

Sorry for all the questions but this is new territory for me...

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

You're still going to have some problems. The AT90USB647 or AT90USB1287 is what you will need to use (no additional FTDI needed, since that is essentially rolled into the phone itself for the USB connection) however there will be quite a lot of coding involved. A USB stack is not something you can knock up in a day or two, although if you are willing to only support certain devices, you might be able to get away with a subset.

LUFA is entirely written in the C language, and needs the AVR-GCC compiler. While you can use the GNU Assembler (GAS) to link assembly code to C code, your application would have to have been written in the GAS dialect already, or you'll have a lengthy conversion step ahead of you.

Timing is not critical with USB Host, since the hardware USB controller takes most of the load off the CPU, and you are in charge of logical timeouts.

You cannot realistically implement USB Host in assembly - you *need* the special USB AVR variants. This is because the timing of USB is very strict, and even the best software USB device implementation can only manage "Low Speed" USB, which is out-of-spec for the CDC class used by the phones. You need a host controller capable of "Full Speed" or better, meaning the USB AVRs or a external USB Host IC.

You do not need a unique VID/PID combination for a USB Host, as this is only required in USB Devices. That means that while the phone you have attached will have one, you won't need one for your application.

You have a few possibilities:
1) Use an external USB Host IC like the MAX3421E - this means that you will need to implement the CDC class and USB stack yourself

2) Use a secondary USB AVR running LUFA for the USB comms - expensive, but minimal application impact and nearly a turn-key solution

3) Use a USB AVR instead, port your code to GAS, link in with LUFA - difficult, but ultimately cheap

4) Use a USB AVR instead, and write your own USB stack - as good as #1, *may* be cheaper overall

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi Dean,

Thanks for the crystal-clear explanation.
I will study your LUFA project to see what's involved.
Seems to me I have only two options.
Either

Quote:
4) Use a USB AVR instead, and write your own USB stack - as good as #1, *may* be cheaper overall
Or remove the option of using a phone. The application would still be useful enough to find customers. Adding remote control through SMS would definitely add value to the product so I will give #4 a serious try. I've already spent quite some time to get my head wrapped around PDU format and get that working, so I'm willing to invest more time to get it all the way.
Good to know that using mega324 wouldn't have worked to get Full Speed. Didn't know that the phones required that.
I'll probably get back to you with some stupid questions if I decide to do this.

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

@Lennart

I'we been using Siemens MC35 modules , wich have RS-232 IF.
http://www.mobiledata.com.au/Sie...

There are other suppliers of modules like this , but they cost more $$ than an old phone.

Another way was to use an "USB 3G stick" (ought to work with sms also) , and i even think Dean have some lufa code for that.

Edit: Add TC35
http://cgi.ebay.de/GSM-SIEMENS-T...

Edit2: Add this thread
https://www.avrfreaks.net/index.p...

/Bingo

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

Hi Bingo,

Thanks for your answer.
When I first wanted to add the ability to remotely control the system I looked at different modems such as the Siemens module and Sim300.

Reading some posts here made me realize that mobile phones are modems.
Since I want to keep the cost of the system low to attract customers I got the brilliant?? idea that a customer that have the need/desire to be in remote contact with his/her heating system could normally do that at zero cost, since most people at least in my country have 4 or more old phones stuffed away in a drawer somewhere. Might have a bad display or buttons that stopped working. Still would work for this purpose.

So I spent some time learning how to communicate btw AVR and phone. PDU format was a bit of a struggle but I seldom give up.
When I started to look for cables that could be connected to eg my Ericsson T68i and RS232 on my board I had to realize that those cables are history.

What I did found was cables with USB A at one end that claimed to work with 30 or so models of Ericsson phones, most obsolete as mine.
Bought two cables for the stunning prize of 13SEK each(including CD).
To make it work I had to crack open the case closest to phone, smash the board with a small blob hiding USB chip and solder the contacts to my own little board.

The whole process made me realize that the future of cell phones involve USB. And to have a realistic plan I need to have USB working on AVR side of that cable.
Still think this could attract customers.
As comparison one company in the business of controlling heating systems offers a separate module for $800 + VAT.
That's what I expect my complete system to cost.

Will look into 3G modems as you suggested, probably be some of those in same drawer as the phones in near future.

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

Hi Dean,

After seraching the internet for over a month, finally i seem to have find a ray of hope in you. Actually, I am trying to interface USB Mobile phone with AT90USBKEY Eval board (based on AT90USB1287). I am trying to use the Eval board in CDC Host mode so that it can enumerate the the mobile phone.
Of the options suggested to Lennart, I found Option 2 to be the most suitable for me. But I need your guidance in implementing the LUFA USB Stack in to my project.
How to go about it so that the USB based Mobile handset can be enumerated.

Thanks in advance.

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

Please start your own thread instead of hijacking mine...