Recent

Author Topic: Linux serial comms: a heads-up  (Read 8127 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Linux serial comms: a heads-up
« Reply #15 on: October 20, 2021, 04:04:32 pm »
Yes, I agree with that. We're just looking at it from a different perspective.

In C++, reading through the header-tree in Linux and comparing that to OS-X and Windows, the bottom of the stack is roughly the same, with some small changes in the Apple headers, all the way back to Palo Alto. Higher up, they start to diverge more and more.

The only *NIX-es I've worked with for the last 10 years or so are Linux and OS-X. Together with Windows, they all share a POSIX parent, although the implementations are quite different. For things like sockets and threads, it's best to stick to it anyway, but the implementations of the more modern stuff varies wildly.

The serial and block model are as old as computing, where they all differ is the "everything is a file" view, as you said. And that also changes over time. But even in Windows, at the core you see the same model, where most (but not everything) is a file-like entity in the (virtual) directory tree. But that is only really used by the kernel and hidden as much as possible from users and programmers.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Linux serial comms: a heads-up
« Reply #16 on: October 21, 2021, 08:59:59 am »
But even in Windows, at the core you see the same model, where most (but not everything) is a file-like entity in the (virtual) directory tree. But that is only really used by the kernel and hidden as much as possible from users and programmers.

It's not file-like, but everything in NT is an object. Including inheritance. Somewhat.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Linux serial comms: a heads-up
« Reply #17 on: October 21, 2021, 02:11:11 pm »
I once wrote a program (in Delphi or FPC/Laz) to communicate with a serial USB device in Windows, and at that level it works. It wasn't even all that complex, but almost completely undocumented. If you manage to find the object in that virtual tree, it behaves like a COM port. So it's mostly obfuscation.

I'll see if I can find that project.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Linux serial comms: a heads-up
« Reply #18 on: October 21, 2021, 02:36:14 pm »
I was the last person to do any maintenance on serial.pp, and when I put it on Mantis it included test programs which had run successfully on Linux, Solaris and Windows (but not Mac, which in my case I have not got). It definitely works using USB on Linux- I use it almost continually- and while I can't speak for USB on the other platforms I have no reason to think there would be a problem: it's just the standard serial comms API subject to Windows's strange naming conventions for ports numbered above 9.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Linux serial comms: a heads-up
« Reply #19 on: November 01, 2021, 09:04:22 pm »
Code: Pascal  [Select][+][-]
  1. function SerAvailable(handle: TSerialHandle): integer;
  2. ...
  3.     if fpIoctl(handle, FIONREAD, @result) <> 0 then
  4.  

That code is problematic since it makes no explicit check that the amount of data returned by the ioctl() matches the function return type.

I've changed the return type to longint and verified that it's filled by the ioctl(), but doing so has no effect on the underlying problem.

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

 

TinyPortal © 2005-2018