Re: [fpc-pascal] Serial connection via TCP/IP sockets on RPi?
On Fri, 03 Nov 2023 19:47:01 +0100, Bo Berglund via fpc-pascal wrote: >I have now found that there is a Linux utility named socat, which apparently is >able to map a serial port to a network socket server: > >https://www.acmesystems.it/socat > >Here they actually use ser2net as the remote server point and socat to connect >to it > >Seems like a possible path to go down. > UPDATE: I solved the problem using ser2net on the remote site's RPi3 to publish a connection to the RPi serial0 device, which is hardwired to the measuring equipment. This implements a server on port 2001 (my choice) to the serial connection. Back at home I have this other RPi4 device on which I have an exposed connector to the serial0 port, to which I can connect a serial/usb cable from my Windows10 development machine. After installing socat on the RPi4 I can start it with the remote RPi3 address:2001 as connection parameter for the port and destination. And this RPi4 has already a VPN connection to the remote network. So after I opened the VPN connection and started socat I could run the control program on my Win10 laptop against the equipment across the ocean! Worked amazingly well! And no development required on my part. Just get socat and ser2net via apt on the RPi devices... -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Compiler probem?
Hi, I have a question about some code. The following code segment generated a compiler error when I compiled it with... fpc Sample -Se -gl -al but not when it's compiled with... fpc Sample -Se -gl ... Asm LdRH R0, [ R1, R2, LSL #1 ]End [ 'R0', 'R1' ];... Any idea why? Its driving me crazy. Thanks, Paul. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Creating capturers
> On Nov 4, 2023, at 4:22 PM, Sven Barth wrote: > > Then don't assign them every "frame". If you just keep them around then they > aren't more expensive than a virtual method call. > And any other mechanism would involve the heap as well, because that's how > anonymous functions that capture variables work and thus anything that wants > to store them must play by the same rules. There won't be any changes there. > The need for a universal function pointer type really isn't about the function references even though they work for that, albeit with unneeded overhead. Lets say you have a sort function which takes a compare callback parameter. You can make the callback type "is nested" which works on global and nested/anonymous functions but not methods. What if the user wants to provide the compare function as a method because they're calling it in a class which shares the code elsewhere? As the writer of the function you'd need to make 2 versions of the function, one "is nested" and "of object". The writer of the sort function shouldn't need to know what kind of function it will be passed, just that a comparison callback is provided, right? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Creating capturers
Hairy Pixels schrieb am Sa., 4. Nov. 2023, 01:42: > > > > On Nov 3, 2023, at 8:31 PM, Sven Barth > wrote: > > > > If you need a catch all type, then you should use function references. > There is no need to invent yet another type. > > The only thing it can not handle is the assignment of nested function > pointers (in contrast to nested functions directly), because they can only > ever be used in a function that is below the one where the nested function > was assigned which is not a guaranteed property for function references. > > > > not always because it creates a heap allocated interfaces for every > function they're used in, even if it doesn't escape the scope. Maybe this > was fine for Delphi but they can't be used for anything real time outside > of GUI apps. > Then don't assign them every "frame". If you just keep them around then they aren't more expensive than a virtual method call. And any other mechanism would involve the heap as well, because that's how anonymous functions that capture variables work and thus anything that wants to store them must play by the same rules. There won't be any changes there. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
