I think I figured out why my writeln's are causing an issue.. they are
introducing a delay between the SerWrite and SerRead...
and the device I am reading is timing out and sending it's response a second
time.
This seems to be the case because it's re-sending bytes that have already been
What I meant by 'Hex Data' is that I am reading data in the form of bytes but
they do not represent ASCII characters.
So if I read a $0D, it's just a byte $0D, it doesn't represent a carriage
return. There is no specific code for end of line,
the last two bytes are a checksum, but I won't
On Sun, 27 Dec 2020 10:47:59 -0500, James Richters via fpc-pascal
wrote:
>I'm trying to figure out how to read a packet of HEX Bytes of an unknown
>length that have no specific termination character over a serial port as
>efficiently as practical.
What exactly do you mean by HEX Bytes?
Hex
On Sun, 27 Dec 2020 21:15:03 +0100, Jean SUZINEAU via fpc-pascal
wrote:
>I think TBlockSerial can work in your console program context. May be
>TLazSerial can be more tricky to use in your context, you'll need to use
>events/callbacks and FCL.
I have struggled with LazSerial in a console
May be using TBlockSerial from unit synaser from Ararat Synapse ?
( doc: http://synapse.ararat.cz/doc/help/synaser.TBlockSerial.html ,
download: http://synapse.ararat.cz/doku.php/download ).
Given a variable (SynSer: TBlockSerial;), you can test if data is
available with SynSer.CanReadEx(0)
On 27/12/2020 18:36, Benito van der Zander via fpc-pascal wrote:
> this code:
>
> program Project1;
> {$mode objfpc}{$H+}
> var a,b, c: string;
> begin
> a := 'x';
> b := 'y';
> SetCodePage(RawByteString(b), CP_NONE, false);
> c := a+b;
> writeln(c);
> end.
>
> prints x without y on
Hello,
this code:
program Project1;
{$mode objfpc}{$H+}
var a,b, c: string;
begin
a := 'x';
b := 'y';
SetCodePage(RawByteString(b), CP_NONE, false);
c := a+b;
writeln(c);
end.
prints x without y on win32/wine.
Is that supposed to happen?
Bye,
Benito
On 27/12/2020 5:02 pm, Michael Van Canneyt via fpc-pascal wrote:
> Because on 32 bit platforms, this is the maximum size of available memory for
> a program, and we like things maximally portable. You can't read more than
> 2gb in memory on a 32-bit platform.
Ha yes, it's been so long since I
On Sun, 27 Dec 2020, Graeme Geldenhuys via fpc-pascal wrote:
Hi,
Is this a bug in FPC 3.2.0 where TCustomStream still uses LongInt in
the Read() method, where all other methods in in the class uses Int64
type?
Here is the FPC code:
TCustomMemoryStream = class(TStream)
private
FMemory:
On 27/12/2020 4:53 pm, Graeme Geldenhuys via fpc-pascal wrote:
>
> According to this HTML page:
>https://freepascal.org/docs-html/ref/refsu4.html
Oh wait, the table I was looking at is titled "Integer constant type mapping",
so it's how the compile maps constants to a data type. It's not the
According to this HTML page:
https://freepascal.org/docs-html/ref/refsu4.html
The data types Byte, Word and Cardinal (LongWord) has the following ranges:
128..255Byte
32768..65535Word
2147483648..4294967295 Cardinal (longword)
Those should be 0..
Regards,
Graeme
--
fpGUI
On 27/12/2020 4:00 pm, Jonas Maebe via fpc-pascal wrote:
> No. New and Dispose eventually result in calls to plain getmem/freemem
> anyway.
Thanks Jonas. I'll try and reproduce the original issue with a smaller
example. It the issue still persists (can't determine the method causing
the memory
Hi,
Is this a bug in FPC 3.2.0 where TCustomStream still uses LongInt in
the Read() method, where all other methods in in the class uses Int64
type?
Here is the FPC code:
TCustomMemoryStream = class(TStream)
private
FMemory: Pointer;
FSize, FPosition: PtrInt;
protected
On 13/12/2020 22:50, Graeme Geldenhuys via fpc-pascal wrote:
> Are there any known issues with heaptrc unit via compiler parameters
> -gl -gh, when using New() and Dispose() to manually allocate and free
> memory.
No. New and Dispose eventually result in calls to plain getmem/freemem
anyway.
I'm trying to figure out how to read a packet of HEX Bytes of an unknown
length that have no specific termination character over a serial port as
efficiently as practical.
The packet ends when there is just no more data to read.
I have something that is working that I wrote using SerRead from the
15 matches
Mail list logo
