Smart VR Debug Output vs GPIO Serial

Help & Support Robot Parts
1

My Smart VR project is working great thanks in part to this forum. I have one more issue I must address and that involves the need for two separate Asynchronous Serial Outputs.

I currently have the Smart VR’s TX pin sending sound commands to an external MP3 player- I have the Baud configured for the player. I am using: _SerialSend(SERIAL_RXTX_PIN, ‘(value here)’); and it works perfectly.

I now need to send bytes out a second port to a 3.3V Arduino’s Serial RXI pin. This raises a few questions I need answered in order to feel comfortable that I am not going to damage the Smart VR Board:

I recognize that I can configure any of the Smart VR’s GPIO pins as a serial output, but, I also understand that the output cannot be directly connected to a high impedance external MCU pin; the manual describes that the signal must be driven through a transistor, resulting in an inverted output.

My first question is whether or not the Arduino RXI pin is in fact a high impedance connection. Would the Smart VR see a large load here, or can I connect a wire straight from the Smart VR’s GPIO pin to the Arduino’s RXI pin?

If such a connection is high impedance, requiring a transistor buffer, could I instead possibly use the Smart VR’s DBG pin as a second serial output, and if so, could that then be directly connected just as the TX pin is to the MP3 player I have working, without the need for a buffer or additional components?

I understand that the DBG output has its own set of data output functions which would then be used instead of _SerialSend, but I should be able to work around that in programming if it is possible to make the physical connection work.

Finally, the manual describes both the Diagnostic Ouput and the Debug Output as normally being enabled when the board is reset with the DBG Enable pin held low. Does using _DebugOn or _DiagOn avoid the need for the DBG Enable pin to be held low on bootup, or does that need to happen regardless? I see no Debug Enable pin broken out on the Smart VR board, yet there is a DBG pin. Can I assume that the Debug Enable pin is already held low internally to the board?

My goals here are twofold: first I hope to avoid the inverted signal using a buffered output would create, second I wish to reduce the number of discrete components on the finished product.

Any help is much appreciated.

Rob

2

Hi Rob,

Here are some responses we received from Tigal, the company that owns the VeeaR brand:

Response from Tigal:
[INDENT]Not exactly. The user manual provides a few examples of interface circuits for connecting the SmartVR pins to a system using a different supply, such as a 5V system. In that case the circuit is using a single transistor in a simple inverter configuration with a pull-up resistor. If the load is not high-impedance, the pull-up resistor might not be able to drive a valid high level to the target system.[/INDENT]

Response from Tigal:
[INDENT]Since your target system is 3.3V, you can run the SmartVR from the same power supply so that there is no voltage translation involved. If the power supply voltage of the two systems is the same, but it is not switched on at the same time, you might still need some kind of interface circuit to avoid latch-up issues. A series resistor may or may not be enough, depending on its value and the systems involved.

If the power supply voltage is the same and it is provided to the two systems at the same time, you can connect them straight together, without any particular interface circuit, you just need to check that input and output levels are compatible (highly likely).[/INDENT]

Response from Tigal:
[INDENT]Either you pull DBG low at reset or power on, or you call _DiagOn() at run-time. The effect is the same. Please note the DBG pin is meant for diagnostic purposes and it is used for programming the SmartVR module, so it is not recommended for general use. Anyway, the electrical characteristics are the same as the other GPIO pins, so using that pin instead of a GPIO would not solve interfacing problems.[/INDENT]

We hope this helps and let us know if you need clarifications,

3

Hi Rob,

These are very good questions, but they are a little more technical than RobotShop’s first-level support usually provides. We’ve contacted the manufacturer and asked them to answer these questions. They will either respond directly, or we will provide their responses for you.

We hope this helps,

4

I think that covers what I needed to know. Thanks for following up on this. I will post back with the outcome once I have a chance to try it.

Rob

5

Thanks Jeffrey-

I did send an inquiry to Veear, but not to Sensory. I am not sure who might better be able to give me the answers I need, but I figured I would give it a shot here as well since the Forum represents such a large knowledge base. Thanks for helping me with this.

Rob