Usleep call in yield causes degraded performance about epoxyduino HOT 6 CLOSED

Thanks, glad you found it.
I think the problem is that if you remove usleep(), the CPU goes to 100% because unixhostdino_main() is just a tight loop around a read(). Try using a smaller value for the usleep() and let me know what you discover. Maybe we can make that number configurable.

There's probably a way to make Unix wait for a keypress without using a busy-loop, but I'm not a Unix programming expert, and I didn't want to spend a lot of time on this part of the code. The usleep(1000) works fine for my needs, which is to run unit tests on a desktop machine. If you have another way of doing this, I'd be curious to know what that is.

from epoxyduino.

I didn't notice that because my tcp socket wrapper is currently blocking indefinitely on accepting new clients and the cpu runs idle because of this. Lets see if I can figure out something. This is nothing that important. I have been developing a HTTP server library for Arduino and got curious what the performance would be on a computer.

from epoxyduino.

I have some ideas how this could be done with select but now I started to wonder is there a reason why the reading is done in the unixhostduino_main function rather than in the read function of the StdioSerial class? This change would solve my problem already because the sleep could be then removed but I think there are even bigger problems with the current implementation. The Stream class provides a bunch of functions that try to read data until a timeout. Basically they are while loops that call the Stream read() until enough data is received or the timeout is met. With the current implementation it's impossible for those functions to return any data if the buffer of StdioSerial does not contain it already when the call is made but they will wait anyway.

from epoxyduino.

I don't think the Unix/POSIX read() call can be moved into StdioSerial.read() because the normal programming pattern on the Arduino is to check Stream.available() on the serial port, before calling Stream.read(), so StdioSerial.read() would never get called. You are correct that the current implementation does not support Stream.readString() and readStringUntil(). I rarely use them, so I did not give them any attention. Recall that the primary reason this was created was to allow AUnit unit tests to compile and run on a desktop computer.

The intent of StdioSerial.insertChar() was that I might have to use a separate thread to read the keyboard, then inject that character into the ring-buffer. That would emulate the parallel processing that occurs on an Arduino chip, where the serial port triggers an interrupt that causes the character to be processed.

from epoxyduino.

Isn't stdin buffered by default already? Is there a reason to "emulate" this? I think the available() function could just use the ioctl function with the FIONREAD command. If the buffering on the application side is really needed It could be also done so that that if the buffer is empty both StdioSerial read and available would trigger a call to read from stdin.

from epoxyduino.

I'm not using the buffered FILE pointers and <stdio.h> functions because those are blocking calls. I'm using integer file descriptors and the lowest-level read() function from the C-library because it's non-blocking. There's no buffering at that level that I'm aware of.

With regards to your "just use the ioctl and FIONREAD", I am not familiar with those. I'd be happy to look at your code if you get it working.

from epoxyduino.