Error: Wrong number of parameters specified for call to "Assign"

[Aruna]

I am trying to get serial communication working from the IDE to a Arduino Nano. I am getting this error:

Code: Pascal  [Select][+][-]

1. unit1.pas(46,30) Error: Wrong number of parameters specified for call to "Assign"

The code is below:

Code: Pascal  [Select][+][-]

1. procedure TForm1.btnTurnOnLedClick(Sender: TObject);
2. var
3.   f: TextFile;
4.   data: string;
5. begin
6.  // Correct way to associate a file with the serial port ??
7.  // Step 1: Associate the file variable with the serial device
8.  
9.     Assign(f, '/dev/ttyUSB0');  // Or 'COM3' on Windows
10.     Rewrite(f);                 // Step 2: Open the device for writing
11.     WriteLn(f, 'on');           // Step 3: Write data to the serial port
12.     CloseFile(f);               // Step 4: Close the device
13.  
14.     WriteLn('Data sent to /dev/ttyUSB0');
15. end;                                      

I have searched the documentation and Googled with no success. What am I doing wrong? Attached screenshot shows the error message. I do not wish to use synaser at this moment in time (maybe later but not right now) I want to get writing directly to the serial port working on the nano.

[Wallaby]

Use AssignFile, otherwise it thinks you're calling the Assign method of the form.

[Aruna]

Use AssignFile, otherwise it thinks you're calling the Assign method of the form.

Thank you @Wallaby, your fix works. I see the RX led flicker on the nano but the led on pin 13 does not stay on. It flickers though. When I test my code in the Arduino sketch using the serial monitor everything works as expected. Any ideas?

[Thaddy]

Assignfile is a fallacy. Use system.assign instead, so prefix assign with the unit. It does not matter too much in this case, but it is a non-solution that proves hard to get rid of. It is just there to prevent scoping issues, which are better solved by providing the scope - unit name - you mean explicitly. That is much cleaner.

All that AssignFile does is calling system.Assign anyway, which makes it imho code rot.
It is also not available in all modes, because it is defined in the objpas unit, as opposed to system.assign which is available in all modes.

[rvk]

All that AssignFile does is calling system.Assign anyway, which makes it imho code rot.

They could have better made the AssignFile an inline function then 

[MarkMLl]

Use AssignFile, otherwise it thinks you're calling the Assign method of the form.

Thank you @Wallaby, your fix works. I see the RX led flicker on the nano but the led on pin 13 does not stay on. It flickers though. When I test my code in the Arduino sketch using the serial monitor everything works as expected. Any ideas?

You're inflicting several problems upon us here.

First, this partly duplicates your earlier thread at https://forum.lazarus.freepascal.org/index.php/topic,68606.msg530579.html which you abandoned.

Second, you've not given the community a testable project for this one. Now as it is Wallaby et al. have given you the correct answer, but I think it will be useful for you to consider the actual cause.

If you'd posted a proper project, it would be apparent that in the file causing the error you had imported other units which (we can reliably speculate) bring in implementations of Assign() other than System.Assign(), and that these are for some reason "closer" to the point of failure in a way that prevents polymorphism from telling the compiler which one to use.

And what is actually preventing the usual polymorphism from working? This:

Code: Pascal  [Select][+][-]

1. procedure TForm1.btnTurnOnLedClick(Sender: TObject);
2. ...
3.     Assign(f, '/dev/ttyUSB0');  // Or 'COM3' on Windows
4.  

You're calling Assign() in the context of a class TForm1. That descends from TForm... and up at the top of the unit is would be apparent that you've imported Forms.

The compiler could, possibly, have made sense of that. But it hasn't (and frankly I don't blame it), because TForm.Assign() is hiding all other declarations of Assign().

And /that/ is why you have to use either AssignFile() or System.Assign().

MarkMLl

[MarkMLl]

They could have better made the AssignFile an inline function then 

Look on the bright side: most of the time that would have resulted in a compiler warning that inlines were being ignored.

MarkMLl

[Thaddy]

All that AssignFile does is calling system.Assign anyway, which makes it imho code rot.

They could have better made the AssignFile an inline function then 

Yes. full code from objpas is this:

Code: Pascal  [Select][+][-]

1. Procedure AssignFile(out f:TypedFile;p:PAnsiChar);
2. begin
3.   System.Assign (F,p);
4. end;

and a couple of overloads with the same body but different string types...(code rot)
But it is neigh impossible to let people forget that there is such an atrocity as AssignFile.
I would have less trouble with it if it was a simple alias in system, not objpas.
That would also solve any ambiguities. it is also nitpicking from my side...

[MarkMLl]

I would have less trouble with it if it was a simple alias in system, not objpas.
That would also solve any ambiguities. it is also nitpicking from my side...

Is the ability to use a dot i.e. System.something dependent on the mode of the compiler, or has there ever been a time when it was? I'm very much used to the module.entrypoint notation from Modula-2, but I don't know how long Pascal's supported it and there are no doubt some who conflate it with much newer namespace facilities.

MarkMLl

p.s /nits/ please Thaddy. English for lice, i.e. bugs.

[marcov]

Is the ability to use a dot i.e. System.something dependent on the mode of the compiler, or has there ever been a time when it was? I'm very much used to the module.entrypoint notation from Modula-2, but I don't know how long Pascal's supported it and there are no doubt some who conflate it with much newer namespace facilities.

Afaik TP already had it.

p.s /nits/ please Thaddy. English for lice, i.e. bugs.

Nits are afaik the lice's eggs, not the (mature) lice themselves. But they are often confused, also in Dutch (neten/Luizen)

[Aruna]

Assignfile is a fallacy. Use system.assign instead, so prefix assign with the unit. It does not matter too much in this case, but it is a non-solution that proves hard to get rid of. It is just there to prevent scoping issues, which are better solved by providing the scope - unit name - you mean explicitly. That is much cleaner.

All that AssignFile does is calling system.Assign anyway, which makes it imho code rot.
It is also not available in all modes, because it is defined in the objpas unit, as opposed to system.assign which is available in all modes.

Thanks @Thaddy I will use system.assign ( I did not know until you mentioned it ) do you have any thoughts on why I am unable to get the nano led to light up?

[Aruna]

you've not given the community a testable project for this one

Even after compressing my zip is over the 500kb limit of the forum. Here is the source for anyone interested.

If you'd posted a proper project, it would be apparent that in the file causing the error you had imported other units which (we can reliably speculate) bring in implementations of Assign() other than System.Assign(), and that these are for some reason "closer" to the point of failure in a way that prevents polymorphism from telling the compiler which one to use.

Single unit no other imports :-)

[MarkMLl]

you've not given the community a testable project for this one

Even after compressing my zip is over the 500kb limit of the forum. Here is the source for anyone interested.

If you'd posted a proper project, it would be apparent that in the file causing the error you had imported other units which (we can reliably speculate) bring in implementations of Assign() other than System.Assign(), and that these are for some reason "closer" to the point of failure in a way that prevents polymorphism from telling the compiler which one to use.

Single unit no other imports :-)

OK, but at that point I have to ask: why are you trying to use ordinary file operations with a serial port? Did you read (mark, learn and inwardly digest) the examples I gave you in the other thread?

MarkMLl

[Bart]

Can you please move the discussion about LED's to another thread.
This thread is supposed to be about Assign().

Bart

[Aruna]

OK, but at that point I have to ask: why are you trying to use ordinary file operations with a serial port?

Everything is a *file* in linux, is why :-)