Objective Development Forums

is transfering some data from microcontroler to computer using v-usb faster than rs232 at maximum baudrate

No, I do not think so.

Most of the advantages of V-USB is cheaper and (since RS232 dies as a default interface on common computers) better supported (thanks to USB) of interconnection with computers.
Since V-USB just supports low-speed USB (1.1 Mbps) and since it is very CPU-intensive on the micro (means you won't be able to utilze full 1.1 Mbps), RS232 should be faster.
You will need external components like 5 capacitors and an MAX232 but (tanks to hardware UART support) I think you may be able to transmit with over 2Mbps.

Best regards

vouvoume wrote:No, I do not think so.

Most of the advantages of V-USB is cheaper and (since RS232 dies as a default interface on common computers) better supported (thanks to USB) of interconnection with computers.
Since V-USB just supports low-speed USB (1.1 Mbps) and since it is very CPU-intensive on the micro (means you won't be able to utilze full 1.1 Mbps), RS232 should be faster.
You will need external components like 5 capacitors and an MAX232 but (tanks to hardware UART support) I think you may be able to transmit with over 2Mbps.

Best regards

and what maximum baudrate is possible to achieve with v-usb? max rs232 baudrate is 115200bps and i would be happy if v-usb can be faster than this

No I thing you are wrong.

For example the popular ATmega8 says in its datasheet "http://matrixstorm.com/avr/files/doc2486.pdf" (overclocked) at 20MHz it could do even 2.5 Mbps (attantion: bits per second)! See table on page 156.

My incomple VUSBOscilloscope project shoulbe be a good benchmark. It nearly utilized completly the CPU speed just for sending data to the host via multibuffer approach.

gameuser@thinkrat /tmp/delme.gameuser/VUSBOscilloscope/software/linux $ time ./main start > sizetest.bin
decoded mcubuffersize=56
........*.*.*..*.*.*.*.*..*..
[...]
**.*.*.*..*..**.*.*.*..*.*..
^C

real 2m8.457s
user 0m0.238s
sys 0m1.607s
gameuser@thinkrat /tmp/delme.gameuser/VUSBOscilloscope/software/linux $ ls -lsa
total 1444
4 drwxr-xr-x 2 gameuser gameuser 4096 May 4 12:11 .
4 drwxr-xr-x 5 gameuser gameuser 4096 Feb 10 13:35 ..
[...]
1176 -rw-r--r-- 1 gameuser gameuser 1203180 May 4 12:13 sizetest.bin
[...]

So it took about 128.457 seconds to transmit 1203180 byte - makes an average of 9366 bytes per sec (74.931 kbps)...

and how about this topic

viewtopic.php?f=8&t=3059


where people states that they got 24kB/s


and is avr309 better than v-usb

I think over 10k is very unlikely....
(Esp. since my 9.3kBps are achieved by doing nothing else in the micro. and activating the large-code VUSB with faster code: "USB_USE_FAST_CRC")
There might be some extreme low latency USB controllers within some special computers, but this will not be the general case.

App. note 309 is based on Igor Češko's USB implementation. This implementation should be even slower, since it does not
calculate checksums "on the fly".
See "http://www.obdev.at/products/vusb/benefits-de.html" for details. (Advantages over other Firmware-Only Implementations)

Best regards

One more question. You say that you are working on osciloscope project. What is the max frequency of measured signal which you can show correct graphically?

This project should become an example on and for tinyUSBboard ("http://matrixstorm.com/avr/tinyusbboard/").

Because this board provides 16 MHz the "oscilloscope" samples in "running mode" with maximum rate (100ksps?) and 8bit resolution.
ADC is implemented as interrupt, but always stores the current ADC uninterruptable, while multibuffer stuff is interruptable to not block V-USB.
Some of the samples inbetween one buffer period are dropped, but this should keep jitter to a minimal level.

The number of buffers and their size can be configured within the source code of the firmware. The host application always supports any parameter, since it is handshaked during enumeration.
At the moment I use 16 buffers 56bytes each (there the 9.3kBps came from), since this provides good latency with very very rare buffer underruns. For communication with host there is a special protocol for first checking,
if a new buffer is available...

If latency is no problem, it would be possible to reduce the number of buffers down to two and therefore increase their size to 450 bytes each. Because of less overhead you then could transmit about 10 ksps.

Based on 9kSps and sampling theorem the maximum frequency displayable should be 4,5kHz.
But lets say about 3kHz to 4kHz? since we also have a little bit of jitter within each sample.
But anyway it is just a demonstration example, if you want an oscillocope - use your soundcard

Best regards

vouvoume wrote:This project should become an example on and for tinyUSBboard ("http://matrixstorm.com/avr/tinyusbboard/").

Because this board provides 16 MHz the "oscilloscope" samples in "running mode" with maximum rate (100ksps?) and 8bit resolution.
ADC is implemented as interrupt, but always stores the current ADC uninterruptable, while multibuffer stuff is interruptable to not block V-USB.
Some of the samples inbetween one buffer period are dropped, but this should keep jitter to a minimal level.

The number of buffers and their size can be configured within the source code of the firmware. The host application always supports any parameter, since it is handshaked during enumeration.
At the moment I use 16 buffers 56bytes each (there the 9.3kBps came from), since this provides good latency with very very rare buffer underruns. For communication with host there is a special protocol for first checking,
if a new buffer is available...

If latency is no problem, it would be possible to reduce the number of buffers down to two and therefore increase their size to 450 bytes each. Because of less overhead you then could transmit about 10 ksps.

Based on 9kSps and sampling theorem the maximum frequency displayable should be 4,5kHz.
But lets say about 3kHz to 4kHz? since we also have a little bit of jitter within each sample.
But anyway it is just a demonstration example, if you want an oscillocope - use your soundcard

Best regards

and how do you intiate sending buffer from microcontroller to computer. do you constantly send signals from computer to device or there is some other method?

A special command sends the bufferstate from micro to host.
Then the host can estimate waittimes to poll the micro.

Basically there is no other way. Even interrupt endpoints are polled by the host.

Best regards

and other question. if i use circular buffer to store adc samples. would i lose some samples while transfering for example buffer of 254B to PC

I use an indicator flag, which will be set if adc is ready but value can not be written to the buffer.
(Not because of buffer overflow, but because of pending USB interrupts).

And yes, you will definitly loose samples - even with maximum prescaler.

Best regards

vouvoume wrote:I use an indicator flag, which will be set if adc is ready but value can not be written to the buffer.
(Not because of buffer overflow, but because of pending USB interrupts).

And yes, you will definitly loose samples - even with maximum prescaler.

Best regards

And for example. If i have 100ksps sampling rate and transfering buffer which has size of 254B with speed 9kBps. How many samples will I lose while sending data to PC

Because there are no buffer overruns in the normal operation, you can calculate it yourself.
91% loss. Since you get only 9kS out of 100kS in one epoch.

Best regards