Forum > Beginners
Serial seems to be slow
SymbolicFrank:
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.
alpine:
--- Quote from: ccrause on June 10, 2022, 07:31:40 am ---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...
--- End quote ---
I doubt that will help. On a second thought, If:
--- Quote from: kensmith on June 09, 2022, 08:04:49 pm ---*snip*
The sending of the next byte depends on the receiving of a byte.
*snip*
--- End quote ---
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.
winni:
--- Quote from: y.ivanov on June 10, 2022, 06:04:35 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.
--- End quote ---
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:
--- Quote from: winni on June 10, 2022, 09:07:08 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
--- End quote ---
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
avra:
--- Quote from: kensmith on June 07, 2022, 08:09:19 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.
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page