Different working speeds at the same baud rate

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

First - Sorry about the rather vague title, I didn't know how to word this issue.

I've been working on the new tinyAVR (404 and 817) devices. I've been playing around with a UART bootloader, using Microchip's own design (AN2634 - https://www.microchip.com/wwwApp...). It's a pretty simple bootloader which I could get running without much hassle. The bootloader always receives and then echoes the full flash size number of bytes (8192 for the 817, 4096 for the 404). I'm using an 817 Xplained Mini board for experimenting with and my actual project is on a tinyavr 404 on my custom PCB. 

 

My issue: When I use the Xplained mini board with the mEDBG as the virtual com port at baud 115200, the 8192 byte transfer takes only 4-5 seconds. For my own board which does not have a USB-UART inbuilt, I'm using an Arduino Mega's USB-UART RX and TX pins (having connected the mega's reset pin to ground) since i lost my CH340 converter and am waiting for more to arrive. The mega has an atmega16u2 handling the usb-uart stuff. With this setup, the 4096 byte transfer to the tinyavr 404 at 115200 baud takes 17 seconds. I'm running both the 817 and the 404 at the same clock speed (20E6/6). 

 

I was under the impression that the same baud rate of 115200 should mean the same speed, so the 404 with half the size of flash would have taken hardly 2-3 seconds to complete. If anyone has an idea of why this could be happening, i'd love to know.

Thanks.

-Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For sure 115200 baud is 115200 baud, but that is only the speed it send a byte with, nothing about delay between bytes, between packets.

 

Full speed 115200 baud in this case 8N1 format should be about 0.7 sec for 8K. 

 

Perhaps double if there also is a verify, so there are more to it! 

 

edit typo

Last Edited: Thu. Apr 18, 2019 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samay wrote:
I was under the impression that the same baud rate of 115200 should mean the same speed,

You are confusing speed with throughput!  As sparrow2 noted, it does not take into account everything else that is going on in the transfer!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, jim and sparrow2.

Isn't the delay between bytes/packets controlled by the program sending the bytes, in this case, the python app sending the bytes form the hex file? since it is the same program in both cases, i'd have thought it shouldn't have mattered.

To rephrase my question - can the usb-uart controller have an effect on the throughput with the same program sending the data at the same speed?

-Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samay wrote:
can the usb-uart controller have an effect on the throughput

 

Yes it can!

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Jim. Hopefully the new converters will be faster. 

-Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doubt the converter has anything to do with throughput.

 

Throughput depends on the processing time at the source end (to format the data to be sent and to access individual bytes to be transmitted), the transmit time per byte, and delays at the target end. Since there is probably no byte-level feedback from the target to the source, the first two are probably dominant. Processing time through the USB driver at the source end certainly adds to the delay but that is effectively part of the transmit byte time. So, if you have unexpected long loading times, check your python program.

 

Jim 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Doubt the converter has anything to do with throughput.
the AVR is the long pole in the tent; otherwise, bottom of https://www.avrfreaks.net/forum/ftdi-and-prolificonly-two-games-town#comment-1753446

edit : USB UARTs - MaxLinear

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Apr 18, 2019 - 05:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May I yet again recommend a simple logic analyser? (See my signature).

 

It shows if your baudrate is 0.1% off.

It shows the distance between bytes.

It changes guesswork into knowing.

And it is also very usefull for debugging uC firmware.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

 So, if you have unexpected long loading times, check your python program.

 

Thanks, ka7ehk. The very same python script goes MUCH faster when using the Xplained Mini board, so it shouldn't be the one causing delays. The only thing different is the USB-UART.

 

@paulvdh - The LA use described by you is pretty awesome. I've never used one, looks like it's time to get a $5 LA.

-Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Different USB-serial adaptors (eg. different manufacturers and different models from the same manufacturer) can have different throughputs. It depends strongly on how USB link is managed, whether it supports USB 2.x vs USB 3.x, and such. For example, there is a variety of bit rates over the USB cable which is independent of the UART baud rate.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Apr 18, 2019 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure of the precise setup.

If your python program is writing to a virtual serial port,

then different devices might be using different drivers.

That could be the difference.

If your python program sends a byte at a time,

one driver might do useful buffering and

the other not.

That could be the speed difference.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

For example, one driver may send one character per USB packet (32 bytes?) while another driver may accumulate bytes in a buffer and pack them so that most of the USB packet is filled with data.

 

That can make a huge difference.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A logic analyzer on the RX/TX lines would show the difference very clearly as delays between characters or groups of characters.

 

Sounds like you have learned an important lesson on "speed'!

 

Have fun.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Typical operating system drivers are efficient; it's the application that affects throughput with the exception of atypical drivers.

https://www.pjrc.com/teensy/serial_read.c

...

	char buf[16384];

...

via

C code for Teensy: USB Serial

(bottom)
Transmit Bandwidth Benchmark

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Typical operating system drivers are efficient; it's the application that affects throughput with the exception of atypical drivers.
Yup.

At previous job, I had a python program sending data to a teensy at almost a megabit/second.

IIRC I gave pyserial about a Kbyte at a time.

Loops that sent data a byte at a time were not nearly so fast.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

115kbps is the speed the chip is serializing the data out, it doesn't mean "all the time".   Even the USB-UART may talk to the chip at that speed, but the speed it really communicate though USB will be different, it will hold the traffic until the package is complete.  In some cases even exist echo back to ensure the data reach the destination, it by itself doubles the traffic time.   The only way you could make sure of that, is writing a transmission/reception code in assembly, without any delays, and measure on both chips.  When you have other things in the middle that you can not comprehend how it works or measure it correctly, you will never have certainty. 

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0



that is only the speed it send a byte with, nothing about delay between bytes,

 

Maybe to confuse OR clarify things, some or most?? terminal programs give you the choice of delay BETWEEN characters, this one shows a 2ms delay but you could make it 10ms or longer.

 

I used this delay to advantage when older AVRs would take a "long" time to program EEPROM bytes, so I could send the data directly to the EEPROM from a terminal program without having a buffer.

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

USB data is packetized, and generally an USB node is serviced only once every ms.

That may mean that if your RS232 device sends a byte and then waits for a response such a transfer may take 2ms and this is independent of the baudrate selected. With a Logic Analyser you will probably see short burst of data coming out of the USB dongle in multiples of 1ms.

 

Logic Analysers seem to be very much under rated.

For uC stuff I find my EUR 7 LA often more usefull than my EUR 350 Rigol scope, I get lots of reactions of people never having used one and being amazed what you can do with them.

Combine that with the extremely low price and they shold be bundled with each "arduino" beginners kit in my opinion.

 

[Rant]

But don't buy "real" arduino's. I find the pricing of those boards completely appaling. an "official" arduino costs more than a Raspi, which is redicilous. They earn so much money with those overpriced boards that they can even afford to go to court and hire lawyers and have lawsuits over wo gets away with the most money.

And after 10 years or so they still use the horrible java contraption which some even dare to call an "ide". Yuck!

</Rant]

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Apr 19, 2019 - 10:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
I had a python program sending data to a teensy at almost a megabit/second.

Really squeezed it through the ol' pipe, eh?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
skeeve wrote:
I had a python program sending data to a teensy at almost a megabit/second.

Really squeezed it through the ol' pipe, eh?

Yup.

Packet size mattered.  A byte at a time would have been a disaster.

As it was, the teensy had time for almost nothing else.

Fortunately we were just using it as a USB interface for a board that wanted SPI (the almost nothing).

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for putting in your two cents, everybody. I've learned quite a bit from this thread, have ordered a logic analyzer, and will test it out with the new CH340 converters that i should receive any day now.

Cheers.

-Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One common way used many years ago, even on mechanical machines, when no packet CRC was used, was to echo back the received character.  The sender would only transmit the next char upon receiving and confirming the integrity of the previous sent one.   In a pure sense of integrity nothing better than that.  But with high time cost.  Using USB converters you can expect all sort of unexpected things.  There are several "other people work" involved, starting with the converter microchip code, the USB driver at the PC, the Windows layer, your application layer, the BIOS layer, etc.  You can be surprising how little you can really interfere on such vast Babylonia world of code.  Even if using a logic analyzer (I would use a protocol analyzer) you can find the time wasted between bytes or packets, but would still very difficult to find our where it is being generated.  One thing for sure you will understand is the reason why you can not communicate at full speed, but little you would be able to do to make it better. 

 

When those USB-Serial converters appeared, along with motherboards with less or no DE-9 port for COMx: serial communication, people still have lots of devices that need to communicate via serial port (RS232C), and they could not hold using the decrepit old computer or windows version, so they need to rely on those USB-Serial adapters.   At first, if their application want to see a serial port, well, windows and driver will lie to the application "here is your serial COMx: port", it will in fact use USB, and at the other side of the converter a nice and beautiful DE-9 connector, nice, but in great part of the applications this will not work.  The reason is on the old motherboards and windows, where you can control directly the hardware, the application sometimes use the RTS/DTR pins to tell something to the external device, other than the defined by the RS232C standard for those pins, and the external device will also use the pins CTS/DSR to tell something to the PC application, also different from the RS232C standards.  The USB-Serial converter not always will follow this strictly as the user wants, making RTS valid with DTR down is against the RS232C standards, for example, the virtual part of windows and the converter will get lost or will not propagate the application crazy use of such circuits.   Then people start to complain that the converter is not working, in real they don't understood what was happening.   Also, sometimes even when virtual port windows may obey your application, the RTS will not be changed at the end of the converted as soon as you command in the application, sometimes the virtual port windows just send it along with the data your application send few milliseconds later, but it will arrive at the same time at the DE-9 connector, making everything crazy.

 

Sometimes you design and plan everything at the smallest detail, but when you don't control everything, there is always something unexpected in the middle.   We are living in a world where we created a monster called technology, and we made it very complicated.  Soon we will need large programs and computers to understand themselves because we would not be able to do so.   I believe sooner than 2 decades we will need some technical professions we don't even have name for that, one for example is some kind of Artificial Inteligente Psychologist, a human person that would interact with A.I. and find its flaws and defects, since it will be no more possible to do it with a software trace, breakpoints, or registers contents, it will be a machine behavioral new world, like a child learning and making innocent mistakes, and we will not know where is this failing node or how to fix it.

 

Hope you have luck with the analyzer.

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samay wrote:

...The very same python script goes MUCH faster when using the Xplained Mini board, so it shouldn't be the one causing delays. The only thing different is the USB-UART.

 

..have ordered a logic analyzer, and will test it out with the new CH340 converters that i should receive any day now.

115200 is quite slow, and you can so some basic self-tests by sending a couple of seconds worth of data, (eg 20k or 32k bytes) and timing how long that takes.

You could also check the CP2102N, as that can manage 3MBd sustained data rates.

 

USB has 1ms frames (125us for HS-USB), so your code, and any drivers, do need to send blocks of data, rather than one-byte-at-a-time loops.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Yup.

 

Packet size mattered. 

Python.  Squeezed.  Apparently not good enough Dad-joke to make my daughter's eyes roll.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
skeeve wrote:
Yup.

 

Packet size mattered. 

Python.  Squeezed.  Apparently not good enough Dad-joke to make my daughter's eyes roll.

Arrrg.

I shoulda got it.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

just a quick update - as you guys said, changing the USB-UART device made a ton of difference. My CH340 converters seem to be taking forever to arrive, so I made my own converter using a PIC16F1454. The bootloading time came down from 17 seconds to just over 2.5 seconds. Amazing lesson learnt! 

However, to be quite honest, i'm still not too clear on why this happened. I understand the part about the device doing useful buffering, however, my current python code sends data a byte at a time, then waits for an echo before sending the next one, so I guess this essentially requires 2 USB frames to be transferred for each byte of transfer with not much possibility of data being buffered (since each byte MUST be transmitted and then received before the next is sent) - am I right about this? 

Your help and insights on this are much appreciated, thanks!

 

Edit: incorrect chip no.

-Sam

Last Edited: Tue. May 14, 2019 - 12:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From your description, useful buffering is not really an option.

Your previous device might be trying too hard to do so.

 

If one has bytes available at 10 per millisecond,

then one only needs to send the packet when it is full.

Whether the timeout is a millisecond or a full second

does not matter.

 

OTOH if getting the second byte depends on sending the first,

the timeout matters.

You will be sending a byte once per timeout.

If that is a second, you will be sending at a byte per second.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller