1
\$\begingroup\$

I'm using an 8051 series microcontroller, and documentation states that if I use serial mode 0, then its RXD pin can function as a bi-directional pin (both input and output) while TXD is strictly a clock.

I have an IC which have MOSI, MISO and clock pins. and I also use multiplexer/demultiplexer IC's as well.

I want to take advantage of the microcontroller RXD pin so I don't have to do alot of CPU time-wasting bit-banging routines for each device I want to control.

So is it acceptable to connect MOSI, MISO, and RXD pins together or should there be a resistor somewhere?

And Is it safe to connect an output of a demultiplexer (Example: 74hc151) to the 8051's RXD pin and to an input of a decoder (Example: 74HC138) or should I use resistors?

If resistors are required, what values would you suggest and why?

\$\endgroup\$
  • \$\begingroup\$ I read a couple of times the question but I do not understand, sorry. I am confused by the fact that you talk about RXD and TXD and then you talk about SPI's MOSI and MISO. I guess you are saying that RXD and TXD are some pins on the uC that can be used as SPI ports, is this correct? Maybe you can provide a schematics showing what you want to do? Regardless of the configuration, it does not make sense to me why you would short MOSI and MISO together ? \$\endgroup\$ – Almendrico Jan 10 '18 at 2:40
  • \$\begingroup\$ I read that on an 8051 chip (example: AT89C2051) that setting serial port to mode zero will cause TXD to be a clock and RXD to be data I/O and for each bit processed, TXD will clock it out. Page 11 of this paper explains it: libvolume6.xyz/medicalelectronics/btech/semester4/… , and I want to short them together so that I can receive data on the 8051's serial port in shift register mode. \$\endgroup\$ – user152879 Jan 10 '18 at 3:00
  • 1
    \$\begingroup\$ maximintegrated.com/en/app-notes/index.mvp/id/600 \$\endgroup\$ – Bruce Abbott Jan 10 '18 at 5:43
  • \$\begingroup\$ Ok, I'll continue with this idea taking your link into consideration but I think for safety, I'll look into 1K resistors. \$\endgroup\$ – user152879 Jan 10 '18 at 6:28
2
\$\begingroup\$

The answer is "it depends".

If your SPI slave tri-states its MISO pin when it isn't transmitting then there is no harm in connecting MISO and MOSI to an MCU that supports this feature. Whether the SPI slave does this or not should be spelled out in the device's datasheet but if it isn't, you can figure it out on your own:

  • leave the MISO line disconnected from the MCU
  • connect the MISO line to two resistors, one to +V and one to GND
  • the actual value of the resistors doesn't matter. They should have the same value, and any value between 1k and 10k would be fine for this experiment.
  • connect one channel of an oscilloscope to the MISO line, and another channel to the MOSI or CS# line.

Now have your MCU perform a normal SPI transaction with the device, one that the device would respond to. What you are looking for is the MISO signal level while the MCU is transmitting to the device. Due to the resistor bias network the MISO line should be sitting at approximately 1/2 the supply level. It may be slightly more or less depending on the device and the tolerance of your resistors, but you should see something not +V and not GND if the device is tri-stating its MISO line.

If the MISO line is at one of the rails and then starts toggling when the device responds then the device is not a good candidate for combining MISO and MOSI lines. This is because the device is actively driving the MISO line when it's not talking. This isn't wrong because SPI is a full-duplex communications system and each direction has it's own physical signal. The device expects to be the only driving element on that net so it's doing the right thing by maintaining a signal level.

If, however, the MISO line more or less sits halfway between the rails and then only toggles to the rails when it's sending its response then this device is capable of having its MISO and MOSI lines tied together. The datasheet may mention that a pull-up or pull-down resistor should be used on the MISO line, which is another hint that this is a device capable of tying the MISO and MOSI lines together.

Now to address something you've said:

I want to take advantage of the microcontroller RXD pin so I don't have to do alot of CPU time-wasting bit-banging routines for each device I want to control.

I recognize that you're using an 8051 but even then it's difficult to believe that your MCU will be doing much while the SPI transaction is active. Unless you're transmitting massive blocks of data, your SPI peripheral is dog-slow or your particular 8051 has an amazing serial port then you will likely have very little time between bytes to do anything. Even the fastest 8051s clock at about 50MHz, which is right around the maximum SPI clock frequency for most SPI slaves as well. Even if your specific 8051 is able of executing an instruction per clock you won't be getting more than 8-48 instructions per byte transferred over SPI (assuming your SPI port is operating at 6-50MHz). You are unlikely to save a lot of time or power by using the peripheral.

\$\endgroup\$
  • \$\begingroup\$ What do you mean by "amazing" serial port? one that transmits at high speed? Well I could also configure the serial port in manual mode where I can write a program to toggle the bit at a super slow speed and read the bit back at slow speed, but if I can actually get away with reading it by setting it up through serial (mode 0), I'd rather do that. \$\endgroup\$ – user152879 Jan 10 '18 at 6:27
  • \$\begingroup\$ What I mean by that is if you have a simple SPI peripheral, you are going to get interrupted after every byte so you can feed the next byte to the peripheral. If, however, you have the capability to specify an entire buffer or use DMA, these are more "amazing" SPI peripheral implementations which will let you do some other work while the data buffer is being clocked out for you. \$\endgroup\$ – akohlsmith Jan 11 '18 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy