fastrack go command duplexing


Hi, another annoying question:

I have hardware setup needing asynch UART between a pic processor for data gathering, PC COM for configuration and a Fastrack GO RS232 for transmission. To avoid increasing circuit space I am using the same max232 converter to translate CMOS voltages for both the PC and Fastrack. Handshaking is dealt with by tying both CTS & RTS lines to the Fastrack high, and when the PIC is not running a program the connection is quite capable of sending messages originated in hyperterminal.
However when the PIC starts sending strings, communication is totally lost, and if I attach just the Fastrack and the PIC no messages are being sent and am unable to see Fastrack error output for debugging.

Is there anybody out there who has solved an issue like this before? I would be very greatful for ANY suggestions, I’m stuck in a rut of inserting ever increasing delays into the transmission program in the hope that the processor is outrunning the Fastrack, but without hyperterminal feedback I am blind to the problem.

Thanks for reading!

Will Goodman


What you really need is a PIC with (at least) 2 serial ports, isn’t it?
Anything else is doomed to be plagued by issues such as this!

Surely, such PICs must exist? If not, there are plenty of other architectures available with multiple serial ports…

No, that’s not really “dealing with” handshaking, is it?
That’s really just overriding the handshaking!

You could try properly managing the handshaking, so that the Fastrack is blocked while you’re talking to the PC, and vice-versa…

RS232 is not a bus - it is not designed to be shared by multiple devices!

A single output may drive multiple inputs, but you cannot connect multiple outputs together to drive a single input!

#3 … ilType=Top


excellent, thanks for the link! its a prototype for a uni project so i’m averse to changing the architecture, the pc connection is only for maintenance purposes, once the program executes everything is meant to be autonomous.

the handshake is something that i think i will have to take a closer look at as the cts seems to be distorted when i take rts high, i tied it off because i thought i read in the AT manual that if there is no change on the rts line the modem assumes it is not in use and operates asynch. a few more pokes with the scope and then i think i’m going to have to get me a data tap type thingumy!

thanks guys,
will :mrgreen:


But, surely, you don’t need to change architecture?
Although I’ve never used a PIC, I really can’t beleive that there aren’t any PICs with >1 UART?!!

So why not just have a switch that puts it into either “Operating” mode or “Maintenance” mode?

  • “Operating” mode talks only to the fastrack;
  • “Maintenance” mode talks only to the PC.


switched operation is what I’m looking for really, i was just hoping to see what sort of error was being generated by the fastrack. tying off the handshake lines and sending commands from the pc works ok, so i imagine it’s something to do with the pic sending data faster than me typing, but i can’t be sure until i spy what is going on between PIC/fastrack, or like i said i can keep on bumping up the delay between transmissions… hyperterminal transmits one character at a time now i think about it, i’ll try placing consecutive characters into the ftrack rather than strings, see if that gets results :unamused:


You’re missing the point there: Hyperterminal (or any other terminal program) doesn’t send anything at all of its own volition - if you pasted complete AT commands into Hypoterminal, it would send the characters back-to-back at full speed.

More likely is that you yourself - the user at the console - are applying inteligence that you have omitted from your PIC code.

The commonest beginner’s mistake is not to wait for the modem’s response to one command before sending the next…

Remember: the “OK” response does not just mean that the command was accepted - it also indicates when the module is ready for the next command…

And, of course, if you get an ERROR response - then you need to consider how to recover from that error…

Extremely unlikely - far more likely is that you’re not observing the strict command-response sequence…


Right, I just realised that the setup which allows controller to pc comm does not allow controller to modem - the PIC’s tx is attached to modem tx… So I will need another max 232 with the reversed setup.

When the correct setup for controller to modem is in place, the modem’s tx line is quite noisy on the CRO, and when a response signal occurs it’s peak is around -1v rather than the full swing from - to +, not enough for the max232 chip to give a cmos output. Maybe I need some damping to reduce the noise on the modem tx?


Remember that the Fastrack is a DCE (a modem) so its “TX” is an input.



Yes, only just unravelled that one, the problem now is I am getting noisy -5v at rx when the modem is idle, and between -5v and -2.5v when the controller has just sent data :imp:

Have just spoken with embedded prof. and he has suggested that I make 100% sure the 232 converter is working correctly, will let you know what happens…