[fpc-pascal] Access to RS232 ports with fpc

[Roberto Padovani]

There's nothing limited within the compiler! If you have the same
knowledge and expertise of Pascal and C,  IMHO with gcc you will only
be complicating your life.

About serial port, low level routine need some practice, but you can
go quickly to the point with this component for lazarus:

http://sourceforge.net/projects/cportlaz/

You get threaded data reception and even packet parsing with automatic
event fire on a specific packet pattern.
I am using it to develop hardware monitors which are running smoothly
also on old fashioned hardware, so there's no packet loss or packet
corruption.

R#


2009/11/2 Holger Bruns <holger.bruns at gmx.net>:
> Martin schrieb:
>>
>> Holger Bruns wrote:
>>>
>>> Jürgen Hestermann schrieb:
>>>>>
>>>>> function SerRead(Handle: TSerialHandle; var Buffer; Count: LongInt):
>>>>> LongInt;
>>>>>   begin
>>>>>   Result := fpRead(Handle, Buffer, Count);
>>>>>   end;
>>>>> i don't understand the declaration for "buffer" in the function below,
>>>>> because no type is declared for "buffer".
>>>>
>>>> I believe that the type is irrelevant, you can use whatever you want. I
>>>> think that it's just used by fpRead to buffer data. You only provide the
>>>> space for the buffer but you don't need to read it directly. It seems that
>>>> Count has to be the size of the buffer. But I am just guessing....
>>>
>>> My hope was to read more than guessing. As I pointed out, the "buffer"
>>> seems not to be filled with incoming data from the selected serial port.
>>> Hence I cannot read just this data, and serread seems to be faulty. For this
>>> reason I ask for an advice. I need to look on working sample code to use
>>> this function in a working manner. In my example, serread replies only, what
>>> has been written with serwrite right before. Not even serflush, executed
>>> right after serwrite, can solve this problem to me.
>>
>> var foo;
>> const foo;
>>
>> are hidden pointer types.
>> That is foo would contain a pointer, but you never see this. You never
>> have to get the address of something, and you never have to dereference it.
>>
>> As for using this:
>>
>> SerRead(Handle, Buffer, 0)
>>
>> Buffer must be the first byte of a block of memory
>>
>> you can do:
>> var buffer: Array of byte;
>>
>> SetLength(Buffer, 1000);
>> SerRead(Handle, Buffer[0], 1000);
>>
>
> Hi Martin,
>
> I checked this out. It works not reliable. Sometimes I get real data,
> sometimes the data are corrupted. I have no idea to rule out corrupted data.
> I also tried to use the synaser unit, which can be found on the internet.
> The demo code "sertest" crashes instantly.
>
> The only way to get rid of this problem is a direct port access. But direct
> port access is only possible for the first 200 port addresses. A "port"
> array is not yet implemented, and the required higher port addresses are
> strictly ruled out from every use through compiled fpc programs. I do not
> understand this harsh policy. And I have no idea to rule this policy out. If
> there is any possibility to get access to all ports on the system without
> access error messages, please let me know. If I need to alter the compiler,
> is there a patch available? Or should I use gcc rather than fpc to match my
> ideas?
>
> The real sad thing is, that one cannot produce software for Linux, based on
> the restricted free pascal compiler. I am really disappointed.
>
> Best regards, Holger
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>