Getting string on virtual com port.

Erenburg.Evgeny · ‎2018-02-26

Posted on February 26, 2018 at 12:04

I'm getting a string from a terminal.

int main(void)

{

Set_System();

Set_USBClock();

USB_Interrupts_Config();

USB_Init();

while (1)

{

if (bDeviceState == CONFIGURED)

{

CDC_Receive_DATA();

/*Check to see if we have data yet */

if (Receive_length != 0)

{

if (packet_sent == 1)

CDC_Send_DATA ((unsigned char*)Receive_Buffer,Receive_length);

Receive_length = 0;

}

And I see in Receive_Buffer my string. But I want to evaluate every char and to format a string as I need. For example I want to trim all '\n' and '\r' on reception level.

I didn't find a function I get chars from terminal. Where should it be?

AvaTar · ‎2018-02-26

Posted on February 26, 2018 at 12:24

I didn't find a function I get chars from terminal. Where should it be?

...

CDC_Receive_DATA();

CDC_Send_DATA ((unsigned char*)Receive_Buffer,Receive_length);

Obviously from the USB device.

I suggest you need to read the USB spec. then, especially the sections about the CDC device profile.

The air gets a bit thinner there - less people are really familiar with it.

Andrew Neil · ‎2018-02-26

Posted on February 26, 2018 at 12:48

I'm a bit confused:

I see in Receive_Buffer my string

If you can see it in the Receive_Buffer, why can't you just process it from there?

I didn't find a function I get chars from terminal

But you said you have all the characters - in the

Receive_Buffer

Erenburg.Evgeny · ‎2018-02-26

Posted on February 27, 2018 at 07:49

AvaTar wrote:

The air gets a bit thinner there - less people are really familiar with it.

Thinner? Anorexic!

AvaTar · ‎2018-02-27

Posted on February 27, 2018 at 08:05

At least you have not lost your senso of humour ... 😉

You intend to use the VCP functionality for debugging / instrumentation, right ?

I would have trouble to justify coding effort, code size impact and performance requirements which a target USB implementation requires.

Except you see it as a kind of apprentice piece.

Erenburg.Evgeny · ‎2018-02-27

Posted on February 27, 2018 at 08:26

Yep. I gave up on the idea. It was additional nice-to-have feature to a user.

AvaTar · ‎2018-02-27

Posted on February 27, 2018 at 08:59

A cheap USB-to-Serial converter, with the serial side (TTL) directly connected to TX/RX of the target, are useful where there is no ST-Link V2.1 with VCP.

I mostly use a level shifter that 'boosts' the target TTL levels to RS232 levels - useful if you have a PC with a legacy RS232 interface.

Andrew Neil · ‎2018-02-27

Posted on February 27, 2018 at 09:24

This was pointed out repeatedly in the other thread - but you insisted on going the USB/CDC route.

Now you see why we tried so hard to get you to consider the 'external' VCP options ?

(ie, using the ST-Link or an external USB-to-UART).

But, anyhow, it seems that you do have it working - you say you do have a buffer with all the received characters in it.

So why can you not simply process those characters directly from that buffer (or a copy of it)?

Erenburg.Evgeny · ‎2018-02-27

Posted on February 27, 2018 at 11:20

OK. I format the received string and pass it to a parser.

Now I have another problem. When I process the received string I reply to a user (terminal).

CDC_Send_DATA((uint8_t *)string, strlen(string));

The problem - if I set a break point on the line CDC_Send_DATA and then Step Over - I see the reply on a terminal.

If the code runs free without break point - I see nothing on the terminal. Some synchronization issue I can't bit.

Actually I have a workaround to the problem - to use USB-UART converter or to place FTDI chip on the board.

Andrew Neil · ‎2018-02-27

Posted on February 27, 2018 at 11:30

erenburg.evgeny.002 wrote:

Some synchronization issue I can't bit.

Yes, I think so; I think the USB transmissions are probably 'scheduled' somewhere - so you're not (quite) hitting the correct point in the schedule.

Actually I have a workaround to the problem - to use USB-UART converter or to place FTDI chip on the board.

The ST-Link still remains a potential option, too.

If your board doesn't have a suitable ST-Link, and you can't get hold of one that does, the simplest approach is a cable like this:

http://www.ftdichip.com/Images/TTL232RRPI%201_a.jpg

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

The USB end just plugs into your PC, and the UART end just plugs onto the headers on your Discovery board.

Simples!