File / port cconventions and use

[Parkland]

Hello folks,
I've been struggling for a few days on this. I'm trying to use 2 LoRa modules on 2 orange pi boards with qb64pe programs on them.
So far, i enabled UART 5, and wired the devices to the correct pins, and 'cutecom' (terminal program) can chat back and forth.
Now in QB64pe, i open the port like this:

Shell "stty -F /dev/ttyS5 9600 raw -echo -icanon -iexten -opost -ixon -ixoff -crtscts cs8 -parenb -cstopb min 1 time 0"
Open "/dev/ttyS5" For Binary As #1

Here's my issue, is have 'a' dimensioned as _unsigned _byte, and whenever i use 'get #1,, a', it will hang until it can receive data from the buffer. (but it does recieve the bytes one by one).
also, EOF(1) always equals zero, so i'm unable to use it to see if data should be read.

if i use GET #1 ,, d$ (d$ being just a random undefined string), it won't read anything.
if i use GET #1 ,, d ( d being just a random undefined variable ) , i get something crazy like 4.09884E+22

so the only way I can seem to read correctly is using a _byte variable, but i haven't figured out how to tell if theres data to read, and it hangs if there isn't.

If anyone has ideas thanks in advance!

[SMcNeill]

Can LOF(1) be used in this case?

Store what the previous LOF was, check against it, and if the current LOF is longer then read the info.

Code: (Select All)

'only a pseudo-type concept of code flow I'm thinking of

L = LOF(1)
DO
   LF1 = LOF(1) 'to store lof once per read and see if there's new data
   IF LF1 > L THEN  'there's new data
      a$ = SPACE$(LF1 - L +1)  'set a string to the size of the new data
      GET #1, , a$  'this should be the whole data read in one pass.  
      L = LF1 'L is now the new LOF(1)
   END IF
   'do whatever with a$
LOOP

---

(+1 may not be needed above when sizing for a$)

[Parkland]

When i read LOF(1) it causes an error when running, 'path / file access error'.
I'm running it with 'sudo' and it can read data so I don't *think* it's a permission issue.

[Pete]

What is 'd' defined as? QB64 displays values in SN when the value exceeds the limits of the variable type. You assigned a as an unassigned byte, so I would think you need to do the same with d, although I don't see why you are not just using 'a' here. I know, we're experimenting to find an answer. All I can think of is a time-out routine so if the packet of bytes is no longer growing in size, then force an exit to the next routine.

Dim d As _Unsigned _Byte ' Put at top of routine.

GET #1 ,, d

Pete

[Parkland]

What is 'd' defined as? QB64 displays values in SN when the value exceeds the limits of the variable type. You assigned a as an unassigned byte, so I would think you need to do the same with d, although I don't see why you are not just using 'a' here. I know, we're experimenting to find an answer. All I can think of is a time-out routine so if the packet of bytes is no longer growing in size, then force an exit to the next routine.

Dim d As _Unsigned _Byte ' Put at top of routine.

GET #1 ,, d

Pete

Sorry, I was blabbering. When the variable is defined as '_unsigned _byte' it returns the corresponding ascii number for the character.
The problem is I have no way to see when to read data and if I read it when the buffer is empty the program sits and waits.

[DSMan195276]

The short answer is that you're probably not going to get this to work on Linux for a variety of reasons. On Windows `Open` has special support for serial devices via `OPEN COM`, but similar functionality is not implemented on Linux and Mac OS and the regular file logic is not designed for streams.

Your best bet would be writing a little bit of C code to read/write from the stream using `open()`, `read()`, `write()`, etc. and then call that code from QB64 using `DECLARE LIBRARY`. In theory you could do it all via pure QB64 and directly calling `open()`, `read()`, `write()`, etc. (via `DECLARE LIBRARY`) but you wouldn't be able to use the C constants for `open()` so there would be more potential for mistakes.

I'm also pretty sure the `stty` shell call won't work as intended, I don't think those settings will persist after the `Shell` call. If I'm right on that then you'll have to set the tty settings using the C APIs (`tcgetattr()` and `tcsetattr()`). Those functions pass a `struct termios` structure back and forth so you really don't want to bother trying to do that with QB64, writing C code for that would be a lot simpler.

[Parkland]

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.

[Pete]

What if you added something to the message being sent?

message = "Four score and seven years ago." or in qb... msg$ = "Four score and seven years ago."

31-characters.

Now if I use QB64 to count the characters len(msg$), assign that to a variable, use some divider like chr$(3), and combine it, I get... msg$ = "31 Four score and seven years ago." When the receiver gets the bytes, it recognizes chr$(3) (heart symbol) and converts the bytes received in front of it as the total characters to receive in the transmission before exiting the routine.

Could this type of logic be applied in your set of circumstances?

Pete

[Parkland]

What if you added something to the message being sent?

message = "Four score and seven years ago." or in qb... msg$ = "Four score and seven years ago."

31-characters.

Now if I use QB64 to count the characters len(msg$), assign that to a variable, use some divider like chr$(3), and combine it, I get... msg$ = "31 Four score and seven years ago." When the receiver gets the bytes, it recognizes chr$(3) (heart symbol) and converts the bytes received in front of it as the total characters to receive in the transmission before exiting the routine.

Could this type of logic be applied in your set of circumstances?

Pete

I think I understand what you mean, but the problem is still when the program is running and to check for more serial data.
A 'GET' statement hangs until more data comes.
Even if I know where the end of the data is, the program would still freeze checking for more data again.

If I remember correctly I used this for a networking program before and 'GET' would just return nothing if there was no new data, but obviously the way I'm accessing the file (serial port) isn't behaving the same.

[tantalus]

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.