Some one check my thinking! Serial port content

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

Could someone check my thinking and see if they can see any flaws in the plan, so to speak!

 

 

I have a device, with an ATmega128, and  UART0 will be connected to two TTL level serial "streams", although only one stream will ever be active at any moment  (sorry UART1 is already used talking to a separate peripheral).

 

Those "streams" are both external diagnostics style interfaces, one is hardwired (and requires the device to be physically opened and a plug inserted to a connector on the pcb) and won't be used much (EOL programming via bootloader, and high speed flight recorder data dumping from the on-board memory) but it's set up for 1Mbaud, and full duplex. It's connected to some pc software via an FTDI Virtual serial port device (FT232 etc), and is the "secure" door into the system.

The second stream is slow speed IRDA link (half duplex due to the IR echoing) at around 56kbaud, used to change settings and trigger customer test modes.  It uses some light pipes passing through the device enclosure to transmit the data, and includes a magnetic hall switch that senses some magnets in the mating half of the diagnostic "plug". Therefore, when the IR diagnostics are plugged in, the system drops it's baud rate, ignores the echo'd TX data, and allows a more limited range of actions (the ones we let the customer do..... ;-) )

 

So far, so good, i hope.  I will repeat that it's a pure "OR" situation between those streams, and they are not going to be connected simultaneously.

 

So, for the TX line from the embedded micro to the outgoing data stream, that line, being an output, and being driven by a (relatively) low impedance AVR port pin can just be Tee'd off to the two streams i think?  I might put in some current limiting resistors to perhaps prevent any silly errors from blowing things up, and perhaps a high value pull down (pullup ?) on this data line to make sure it sits at some known value during reset / power up etc

 

The RX (streams returning data back into the embedded micro in the device) is more complex, because the IRDA transciever (a Vishay part:  TFBS4711 ) has a tri-state output, with a weak pull up to vcc, which normally, when the hardwired stream is not plugged in, will have complete domination over the RX pin on the embedded micro.  As this is a pretty slow stream, my though was to connect the data returned line on the IRDA transciever to the 128's RX pin through a relatively high value resistor (say ~ 10k or similar).  As long as there isn't too much capacitance on that line (and hence cause a loss of signal edges), then the IRDA should be able to drive the RX pin ok.  Because the "default" mode will be the slow speed, half duplex IRDA stream, this must have a permanent connection to the embedded micro. 

 

The second stream, the high speed hardwired one, can then be connected through a much lower value resistor (say 330 ohm) and so it will "win" any arbitration for the RX line (i need to check the strength of the driver in the FTDI part!!) when it is plugged in.  Ie the IRDA will be idling (idle high i guess when it's not sending any data), but the FTDI can still pull the pin low through it's OR'd series resistor?  I could also use the "shutdown" pin on the IRDA device to tri-state it's output when it's not being used, but that can't be set permanently because the unit must respond to data on that stream normally,

 

 

Because the IRDA necessarily includes TX echoing, there operating modes will have to be different to take advantage of the true ful duplex coms from the hardwired stream (ftdi).  As i use an interupt driven RX function, i can just disable that function when operating in IRDA mode (as well as drop the baud rate etc)

 

 

 

So, can anyone see any problems with this approach?

 

 

 

 

 

 

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

Seems like a good plan, as serial lines idle high, a pull up on TXD / RXD would hold the lines in idle mode while reset or mode changes.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

OK i think i spotted my own "gotcha" which is the lack of an IR endec between the UART and the Irda transceiver!

 

The datasheet for the transceiver ( https://www.vishay.com/docs/82633/tfbs4711.pdf  ) includes the phrase " Serial Infrared Transceiver" and the following line: " The transceiver module consists of a PIN photodiode, an infrared emitter (IRED), and a low-power CMOS control IC to provide a total front-end solution in a single package " which fooled me into thinking that you could just send it TTL UART and all would be good!  Er, nope!  I need and IR Encoder / Decoder in front of the transceiver.  Currently looking at the MCP2122, which looks good, but i need to find a suitable clock source to drive it.  One option is to take the EXT CLOCK from the ATmega (which is already driving some other peripherals) at 16Mhz, and divide that by 10, to get a 1.6Mhz clock for the endec, that gives me a 100k baud link, and because the AVR is providing the clock, the UART shouldn't have any jitter or clock drift issues??

 

Whats the best way to do a divide by 10 on the clock signal?

 

 

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

What bit patterns do you want to send & rcv via IR?  It is up to you to define some pattern/code...just make a set of software routines...of course the rcvr is more complex, but will be similar to a software uart.    So now they can use completely separate pins.  Yuo also get to pick the bitrate, so simply use a divider (such as a timer IRQ) that works nicely.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

For the cost of your ir stuff, you could get a bluetooth module methinks.

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

max_torque_2008 wrote:
Whats the best way to do a divide by 10 on the clock signal?

Use a decade counter, perhaps 74hc4017 or similar.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

max_torque_2008 wrote:

Whats the best way to do a divide by 10 on the clock signal?

 

Another way is if you have a spare timer and free

output compare pin.  Run the timer full speed, set

the output to toggle on compare match, set the

mode to CTC and the TOP value to four so that it

toggles every five clocks.

 

--Mike

 

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

Bluetooth is out because the end application precludes RF emissions!

 

Looking at the options, i might ditch the IR stuff and make up a basic 1 wire bus to use the single spare pin that exists in the devices main I/O connector......       I could use something like a LIN transceiver straight into the UART that way!