File / port cconventions and use

[Parkland]

Just a thought, may it be a handshake problem?

I see you're enabling both software and hardware handshaking "-ixon -ixoff -crtscts".
Have you tried disabling the hardware as I believe (correct me if I'm wrong), the hardware enabling will take precedence over software.

I'll have to think about this in morning. I've definately used com ports on linux before, for eg on another computer a program is communicating with rs485 devices so i'm doing input and output on that.

Maybe the 'stty' command is wrong, i have played with it a lot.

[Pete]

Okay, so you are saying if that after it counted '31' characters received, in the example, telling it to exit to loop would make no difference because when it cycled back, to monitor for the next message, it would forever hang until that message was sent, and if never sent, hang indefinitely.

Hopefully the handshake suggestion by tantalus makes a difference. If not, and you can get a C solution for that part going, as DSMan mentioned, and he does have a Linux system, you might still be able get it working, without any chewing gum and bailing wire.

Pete

[DSMan195276]

the stty shell command works, it is persistent.
everything works so far except way to see if more data is in buffer.
LOC(1) seems to just count up every time a character is read.

That's good news if that's the case with stty, that would save you the more complicated part.

The issue of seeing the number of characters pending to read and not blocking on the GET is unfixable though. To not block on the read you have to set the opened file to "non-blocking" mode, but you can't do that with QB64 (and QB64 can't do it with the regular std::fstream it normally uses to read files).

For getting the number of bytes ready to read, there's not exactly a standard way to do that but it can be done using the `FIONREAD` `ioctl()` call on the underlying file-descriptor. QB64 doesn't expose that to you though (and QB64 doesn't have it, it's buried in the std::fstream) so this isn't possible to do. `FIONREAD` isn't really the way to go anyway, it still doesn't _really_ guarantee you won't hang. Opening the file in non-blocking mode is the best way, then you don't need to know how many bytes are ready since all calls to `read()` will not hang and will tell you if there was nothing available.

[Parkland]

Alright, learning as I go here but this is what worked so far.

Shell "  stty -F /dev/ttyS5 9600 raw -ixon -ixoff -crtscts cs8 -echo -parenb -cstopb -icanon min 0 time 0"

And I'm able to send data from qb64pe out, and recieve raw characters, without a hang on 'GET' statement waiting for data.

It's amazing how many times I've used com ports for what I considered pretty advanced projects and never asked much questions.
For example i can 'PUT' whatever string i want without error, but can only 'GET' into a numerical byte array.


But, it does work, with this, I can use the orange pi UART serial from qb64 programs. 

I will probably arrange a subroutine where it checks several times a second for more data using 'GET', and if there is any just load the rest without delay. that way it's functional and not super CPU intensive.
I suppose theres probably a way to adjust buffer sizes so it needs less checking too, another days project.

Just adding that after the shell stty command, I open the serial device file, in my case /dev/ttyS5. then open as binary.