USB Virtual ComPort Example

[atobindustries]

Posted on October 03, 2011 at 20:38

Hello, I have been searching without success to find an example of the STM32 Virtual Comport that shows how to receive data from the PC.

I am coming from an 8051 background so the use of the legacy COM port will help in porting my programs to the Cortex-M3 environment.  There are plenty of examples of how to transmit and it is very simple.  Why are there no receive examples?

Is there a way, similar to the 8051 where you can use the <intrins> testbit function ie,

_testbit(RI) for reading when a character is available and then decode the command?

Thanks

#virtual-comport-stm32 #virtual-comport-stm32 #usb-to-uart

[atobindustries]

Posted on October 05, 2011 at 16:56

Well, after doing more reading than I wanted to...

The Virtual ComPort example in simple terms is performing the function of an FTDI or Serial to USB cable, and nothing more.

My misunderstanding was because I thought that the Virtual ComPort performed the same function on the MCU side as it does on the PC side.  On the PC, the Virtual ComPort makes your program oblivious to the fact that it is using USB.  The code example is not suppose to be used as a single MCU(STM32) to PC.

I did make changes to the example to allow it to act as a STM32 to PC interface.  You can't get around using, reading, and understanding how USB works on the MCU side.  So for those in a similar situation, the _testbit(RI) simplicity isn't available.

[Andrew Neil]

Posted on October 06, 2011 at 09:54

''You can't get around using, reading, and understanding how USB works''

 

That is correct - you can't.

If that's what you want, then you need something external that does it all for you - like this, for example:

http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm

You just connect the USB end to the PC, and the other end to the microcontroller's UART (taking care to select the appropriate logic voltage option).

[atobindustries]

Posted on October 06, 2011 at 17:45

I did manage to add some lines of code to the Virtual ComPort firmware that allows for a MCU to PC connection.  It really defeats the purpose though, since you have to use USB in your code.

Your solution would actually be a double redundancy.  The Virtual ComPort program does exactly what the cable you recommeded does.  All I would need is another MCU running the firmware and connect the USB and USART lines.

The demo code I wrote is for the Raisonance EvoPrimer, but will work on any Eval if you uncomment the sections for your board.  This will allow you to test your PC side code and software without having to rewrite it, but as I stated, you will have to make changes to your firmware.

[Andrew Neil]

Posted on October 06, 2011 at 22:06

''It really defeats the purpose though, since you have to use USB in your code''

Eh??

If you use the STM32's USB peripheral, then you are obviously going to have to write code to deal with that!

''The Virtual ComPort program does exactly what the cable you recommeded does''

 

Yes it does, but it requires you to deal with USB; which is what you were complaining about - weren't you?

By using the cable, you entirely avoid having to deal with USB at all. It becomes just a ''normal'' UART connection - which is what you wanted - wasn't it?

[atobindustries]

Posted on October 07, 2011 at 19:45

Let me clarify.  If you use the Virtual ComPort program to act as an MCU to PC interface then the PC side of your code remains the same, you can use the regular serial com protocals.  On the MCU side, you will have to change your code and incorporate USB functions.  This is when you try to use the Virtual Comport as a MCU-PC interface.

If you use the Virtual Comport program as it was originally written, then it would be a USB to Serial converter.  You would then connect the USART of the first MCU to another MCUs USART and your code on the second MCU would not have to use USB, just the USART functions.  Just like in the diagram.

As I sated in the previous post I misunderstood the function of the Virtual ComPort program.  I thought the software and firmware performed the same function, making the USB transparent for the first MCU so that a simple MCU to PC interface could be made, not a MCU to Virtual Comport(MCU) to PC interface.

I think we are talking about the same Oranges here.  Semantics my be getting in the way.

Cheers.

[Andrew Neil]

Posted on October 08, 2011 at 12:11

''I thought the software and firmware performed the same function, making the USB transparent for the first MCU''

My point was that cannot be so.

But now I see what you mean.