Hi, Mahesh

Use AT commands is not a compiler problem.
The soft problem is to be able to transmit (and maybe to receive) on a
serial port.

If you use CodeWarrior, you can ask the compiler to do that, but I can't say
anymore, because I don't use it (too expensive).

In other case, you have to write your own serial port driver, that means
write "putchar" function depending on what serial port you use...
When you have done this, you just have to send commands to your putchar or
puts function.
I've posted a couple of months (years ?) ago a serial driver on this site.

So, for me, under ImageCraft ICC12, I wrote
- my own "putchar" function
- so, printf, puts automatically use MY putchar

I think in fact the main difficult is WHERE to connect the serial port
(Transmit, Receive, GND) to the cell phone, and to know the speed of the
transmission. The remaining is easy.

Hope this helps.
Joel

-----Message d'origine-----
De: 6... [mailto:6...] De la part de
mahesh suddhala
Envoy mercredi 30 dembre 2009 09:08
: 6...
Objet: Re: [68HC12] Can we connect a cell phone to hc12

Hi Ruben,
Thanks for your reposne.

I never used AT commands in the HC 12 compiler. I wonder if I can use AT
commands in C program. Would you know any website or book which can help me
enhance my knowledge on At commands and help me use it with HC 12.

I am searching in google and trying to learn more about AT commands.

Thanks!

--- On Wed, 12/30/09, Ruben Jsson wrote:
From: Ruben Jsson
Subject: Re: [68HC12] Can we connect a cell phone to hc12
To: 6...
Date: Wednesday, December 30, 2009, 2:53 AM

You can connect the phone to a serial port (UART) and talk to it with AT
commands.

Google is your friend here.

/Ruben

> Hi Group,
> I have a couple ofquestions aboutthe HC12 controller.
>
> 1) Can we connect a cell phone to HC 12 controller
> 2) Then pass command back and forth between the cell phone and HC12
> 3) Has any one done a project in which you can pass a message to a cell
phone
> connected to the HC 12 controller and depending on the message or number
the
> output of the controller will be a 0 0r 1.
>
> Any information on the above related questing will be greatly appreciated.
>
> Thanks!
>
> Mahesh Suddhala
>
>
>
>
>
>
>
>
>
> ------------ --------- --------- ------
>
>

Hi Ruben,
Thanks for your reposne.

I never used AT commands in the HC 12 compiler. I wonder if I can use AT commands in C program. Would you know any website or book which can help me enhance my knowledge on At commands and help me use it with HC 12.

I am searching in google and trying to learn more about AT commands.

Thanks!

--- On Wed, 12/30/09, Ruben Jönsson wrote:
From: Ruben Jönsson
Subject: Re: [68HC12] Can we connect a cell phone to hc12
To: 6...
Date: Wednesday, December 30, 2009, 2:53 AM

You can connect the phone to a serial port (UART) and talk to it with AT
commands.

Google is your friend here.

/Ruben

> Hi Group,
> I have a couple of questions about the HC12 controller.
>
> 1) Can we connect a cell phone to HC 12 controller
> 2) Then pass command back and forth between the cell phone and HC12
> 3) Has any one done a project in which you can pass a message to a cell phone
> connected to the HC 12 controller and depending on the message or number the
> output of the controller will be a 0 0r 1.
>
> Any information on the above related questing will be greatly appreciated.
>
> Thanks!
>
> Mahesh Suddhala
>
>
>
>
>
>
>
>
>
> ------------ --------- --------- ------
>
>

You can connect the phone to a serial port (UART) and talk to it with AT
commands.

Google is your friend here.

/Ruben

> Hi Group,
> I have a couple ofquestions aboutthe HC12 controller.
>
> 1) Can we connect a cell phone to HC 12 controller
> 2) Then pass command back and forth between the cell phone and HC12
> 3) Has any one done a project in which you can pass a message to a cell phone
> connected to the HC 12 controller and depending on the message or number the
> output of the controller will be a 0 0r 1.
>
> Any information on the above related questing will be greatly appreciated.
>
> Thanks!
>
> Mahesh Suddhala
>
>
>
>
>
>

Hi Group,
I have a couple ofquestions aboutthe HC12 controller.

1) Can we connect a cell phone to HC 12 controller
2) Then pass command back and forth between the cell phone and HC12
3) Has any one done a project in which you can pass a message to a cell phone connected to the HC 12 controller and depending on the message or number the output of the controller will be a 0 0r 1.

Any information on the above related questing will be greatly appreciated.

Thanks!

Mahesh Suddhala

> Jerry Fields writes on 12:33 PM 12/18/2009
>Thanks Bill! I find all of that extremely interesting! I need to
>find a electrical engineering forum too!

You're welcome Jerry.

>When it comes to the loose coupled effects of the ESD (EMP), its the
>rising and falling edges that are damaging to the circuit. Correct?
>I imagine, that the over all frequencies of ESDs can vary, so the
>impedance of the protection devices would be designed to pass or
>block the frequencies of the rising and falling edges of the pulse.
>(i.e. several hundred Meg to around a gig.) Yes?

I'm not an expert on the electrical test damage or effects. Since I
had to sign the PO's for the outside testing done by my group, I had
to know what internal tests were done and if we were confident we
would pass on the first submission. We never got into IC failure
modes. Although through the several hundred zaps on 12 PC boards we
never saw any IC fail.

>Am I on track with that thought?

I can't say, except it sounds on track. If you find an expert on
this and can provide failure analysis and causes, please report back.

Happy New Year!
Bill

Thanks Bill! I find all of that extremely interesting! I need to find a electrical engineering forum too!

When it comes to the loose coupled effects of the ESD (EMP), its the rising and falling edges that are damaging to the circuit. Correct? I imagine, that the over all frequencies of ESDs can vary, so the impedance of the protection devices would be designed to pass or block the frequencies of the rising and falling edges of the pulse. (i.e. several hundred Meg to around a gig.) Yes?

Am I on track with that thought?

To: 6...
From: b...@softools.com
Date: Thu, 17 Dec 2009 23:04:09 -0500
Subject: RE: [68HC12] Hardware vs software interrupt vectors

Jerry,

> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?

Yes.

> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.

CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.

>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?

Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.

All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.

Bill

_________________________________________________________________
Hotmail: Trusted email with Microsofts powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/

Jerry,

> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?

Yes.

> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.

CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.

>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?

Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.

All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.
Bill

Hey! You two settle down, or we'll turn the car around right now! :)

All of you raise very good points, and listening to all this makes me want to go back to college, and surround myself with big brains like the people on this forum!

I work as an electronics technician, so my co-workers, many times, have no idea what I'm talking about when it comes to programming or engineering issues.

OK, help me out Bill, or somebody, by ESD, you must mean electro static discharge? What type of ESD testing do you put the product through? Surely, it must be a loose coupled test if it is electro static discharge.

ESD pulses of a certain kilovolt range are produced in close proximity to the product, and the accompanying EMP is what the product must have resistance to?

Jerry

To: 6...
From: g...@chichak.ca
Date: Tue, 15 Dec 2009 23:00:05 -0700
Subject: Re: [68HC12] Hardware vs software interrupt vectors

>
> Being professional is also a good practice. I corrected a post of
> yours that was dead-wrong - and asked you to back it up and you
> provided no substance to back up what you said. .
>
>
>

See Hatton, L. (1995), Safer C, McGraw-Hill. Section 2.8.3 "Arrays are not always synonymous with pointers"

Dead wrong? My products have gone through Health Canada and the FDA. If I'm dead wrong I get to take people's grandmothers with me.

_________________________________________________________________
Hotmail: Trusted email with Microsofts powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/

>
> Being professional is also a good practice. I corrected a post of
> yours that was dead-wrong - and asked you to back it up and you
> provided no substance to back up what you said. .
>
>
>

See Hatton, L. (1995), Safer C, McGraw-Hill. Section 2.8.3 "Arrays are not always synonymous with pointers"

Dead wrong? My products have gone through Health Canada and the FDA. If I'm dead wrong I get to take people's grandmothers with me.

> Andrei Chichak writes on 09:57 PM 12/15/2009
>Absolutely, but computing is equally about handling errors as it is
>normal processing. The software people have to be able to detect the
>errors so that the hardware people can harden the system against
>things like ESD. How do you know that you have an ESD problem, you
>don't turn off interrupts and throw diodes at the problem or how
>would you know when to stop? Diodes and capacitors won't detect
>division by zero, but putting in a trap will.

A divide by error isn't a spurious interrupt, it's a programming
problem. If you enable divide by 0 interrupts, your software should
be preventing the divide by 0, not using the trap to handle them.
What are you going to do in the handler? This is something that
should have been considered at the time of the divide.

>Nobody is saying that do "nothing vectors" harden the system, they
>help you identify unexpected behaviours. But not using the features
>that are given is just ignorant, literally. When you get an
>unexpected interrupt (since that is what we are talking about)
>wouldn't it make more sense to save the interrupt information and
>the stack and halt the system? If the interrupts never get used,
>they cost nothing.

What features did I say not to use? Filling vectors for peripherals
that are not used serves what purpose? And I didn't say not to use
them and I didn't say anyone said using them do harden it. Did you
read the email or have you been sitting back just waiting to snipe at
me because I corrected you in a post, umm, months ago? I mentioned
why releasing a product with them in isn't a bad thing, and also
mentioned, as another reader has confirmed, that they can be used to
better recover from an ESD event.

How do do-nothing vectors identify unexpected behavior? If they
do-nothing and return, they didn't detect anything.

>I think that Professor Redd's suggestion is exactly correct. It
>helps you detect the problems early, before your customers do. It is
>a small part of the known best practices and should not be ignored.

I didn't say he wasn't correct - you've adding that my post said that
which is incorrect. My suggestion was to detect problems - I don't
use the vectors when developing to know I'll catch a problem which
might just be an oversight in initializing. I don't enable
interrupts on peripherals I'm not using. Why is a vector for that
peripheral helpful? You mention divide by 0 - that's not a spurious
interrupt, it would be a programmer error to have allowed it. You're
just looking for something to fire back at me for. I didn't say not
using vectors wasn't correct, I asked why is it necessary, and also,
if you do use them, there may be a better way to handle them.

>To quote a member of this list:
>"please don't put your gloom and doom programming rules out on a
>public forum where beginners may be trying to learn correct
>programming practices."

Being professional is also a good practice. I corrected a post of
yours that was dead-wrong - and asked you to back it up and you
provided no substance to back up what you said. Here, I'm trying to
add information, which isn't wrong, based on extensive embedded
programming experiences in developing several high-reliable
products. Our products passed ESD 2-5 times CE requirements and
spurious interrupts on unused peripherals were never the
problem. Interrupts on used peripherals were if you're interested in
discussing real-world topics.

Bill