Serial Com

[Ioannis]

Hi list.
I have a device that communicates with a PIC running @ 20MHz

When program asks:

SerOut rs232t,t2400,["&*AZ=?",13]

an answer is expected with:

Serin rs232t,t2400,1000,noresp1,["AZ=",byte1]

Unfortunately the answer comes too quickly for the
controller to catch. Is there a "cure" for this?

Note that commands are one after the other.

Ioannis

[Melanie]

Tricky one this...

1. Is it that you've got the SERIN syntax slightly screwed... You wrote...

Serin rs232t,t2400,1000,noresp1,["AZ=",byte1]

should it not be...

Serin rs232t,t2400,1000,noresp1,["AZ="],byte1

otherwise byte1 becomes part of your qualifier... and therefore you're not missing your reply, it's just not qualifying.

2. Or is it "just too late", or "seriously" too late?

If it's the former, you might get away with trimming your qualifying condition and dumping the first character like so...

Serin rs232t,t2400,1000,noresp1,["Z="],byte1

3. The best thing to do is to capture and dump the entire reply from the device and work out how much of the expected reply is missing before determining the best course of action to deal with it.

Melanie

[Ioannis]

Thanks Melanie.

Well you are right, that was a typo.

Anyway the compiler tries to check for the "AZ=" too late.

Meanwhile I tried debugin command which works much better. It seems that is faster in response from Serin. Also dumping "A" is a good idea.

Ioannis

[Melanie]

Just remember that DEBUGIN is not as good as SERIN at resolving comms. I did an experiment the other day where I varied the PIC's oscillator away from 4MHz to discover how far I could skew it at 2400 baud before serial async comms gave up. I discovered that SERIN was still resolving good data long after DEBUGIN had given up.

[Ioannis]

Hmm, that is really serious one. Ok, I'll try on Serin one and how it goes.

Just out of curiosity, how far did debug went (regarding the Osc. freq)?

Ioannis