Recent

Author Topic: Serial seems to be slow  (Read 1566 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Serial seems to be slow
« Reply #15 on: June 10, 2022, 09:16:34 am »
I agree. Except for things like AVR and simple PICs, most microcontrollers today have a DMA channel you can use to fetch the new bytes if the UART buffer is empty, and an interrupt that is executed when the receive buffer is full (the one in main memory, where another DMA channel transported it to). So, the best option is probably an AVR. Cheap, and easy to program. Everything else is overkill.

y.ivanov

  • Sr. Member
  • ****
  • Posts: 445
Re: Serial seems to be slow
« Reply #16 on: June 10, 2022, 06:04:35 pm »
This sounds like it will be easier to handle in a microcontroller, where one works close to the hardware latency. If the inspection logic is not too heavy a humble AVR should suffice. Else an ARM or ESP if more computational power is required for the logic. Of course one wants to avoid external hardware dependencies, but if your requirements conflicts with modern computer and OS design...
I doubt that will help. On a second thought, If:
*snip*
The sending of the next byte depends on the receiving of a byte.
*snip*

Then the big trouble is actually the protocol itself. Implementing a dedicated communication processor in a micro will help only if the protocol can be "layered" and the PC<->micro can communicate at higher (logic) protocol level. The micro must do some work to translate between the layers. Otherwise it will be just another bottleneck between.

The same thing will be a dedicated thread in the PC with no artificial delays (as Mark noted), which logs the whole transfer to memory for whom may be interested, eventually for the main thread.

But we still don't have protocol details from kensmith ... just "The sending of the next byte depends on the receiving of a byte", which is, I'd say, insane.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

winni

  • Hero Member
  • *****
  • Posts: 3125
Re: Serial seems to be slow
« Reply #17 on: June 10, 2022, 09:07:08 pm »

But we still don't have protocol details from kensmith ... just "The sending of the next byte depends on the receiving of a byte", which is, I'd say, insane.

Hi!

I told you that the name of the protocol is Kermit.

http://www.columbia.edu/kermit/archive.html

Not only source for Turbo Pascal but for y.ivanov there are UCSD sources

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 4763
Re: Serial seems to be slow
« Reply #18 on: June 10, 2022, 10:17:53 pm »
I told you that the name of the protocol is Kermit.

http://www.columbia.edu/kermit/archive.html

Not only source for Turbo Pascal but for y.ivanov there are UCSD sources

Winni, you're talking absolute rubbish. Sorry, but it had to be said.

Kermit is a block-oriented protocol with extensive escapes, a million miles removed from what's being discussed here.

I knew Bertil Schou when I was working at Lowbrow, he was one of the main European conduits so I both used and supported it on various kit (Multics down to micros) and was fairly familiar with its capabilities and operation.

OP here is talking about some sort of weird state machine. Again, NOTHING WHATSOEVER LIKE KERMIT.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

avra

  • Hero Member
  • *****
  • Posts: 2355
    • Additional info
Re: Serial seems to be slow
« Reply #19 on: June 14, 2022, 01:01:02 pm »
Basically I want to:
1) put one character into the output buffer of the UART
2) detect if an received character is waiting in the input buffer.
3) Get that character.
All of my code works one byte at a time and has to do logic on every received byte.
Right now something that should take about 10 Minutes at 115200 baud takes about 1.5 hours.
Without knowing the USB CDC implementation details, no wonder you face such slow downs when using USB to SERIAL convertors.
You can find all the answers you need here: https://forum.lazarus.freepascal.org/index.php/topic,51948.msg382188.html#msg382188

Spoiler: Reason for such a slowdown is that you use byte for byte half duplex protocol, each byte is treated as USB message, and there is a very limited number of USB interrupt messages you can send/receive each second. To achieve higher speeds you need to make messages longer then 1 byte, or avoid using USB CDC at all.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

 

TinyPortal © 2005-2018