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

[Aruna]

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

If you look at my initial post again you will see it says:

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

1. procedure TForm1.btn[b]TurnOnLed[/b]Click(Sender: TObject);

The led is related and part of my problem. I can move things to another thread but then I think it is only fair and reasonable we also open new threads about polymorhism, nits, lice, dot systems? It is sad and disappointing when people with your kind of experience and expertise fail to see the obvious and proceed to assume and speculate where I work on evidence based facts. NO offence meant to anyone and hopefully what I said will be taken in the spirit it was meant in. It would be much more helpful if you are unable to contribute meaningfully, not to do so at all?

[MarkMLl]

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 :-)

Everything IS NOT a file in unix.

Most things appear in the filesystem namespace: except network interfaces, open sockets, internal firewall rules endpoints, arbitrary USB devices... I could go /way/ on.

What's more, something like /dev/ttyUSB0 might be a file in unix, but that doesn't mean you can manipulate it like a file from Pascal: you can't. And that's (a) why things like serial.pp, SynAser and so on exist, and (b) why serial libraries/components (and network protocol ditto etc.) aren't applicable to ordinary files.

If you don't believe me, then follow through what your code is doing all the way to the kernel syscalls, and find out where it's not behaving like you expected.

MarkMLl

[Aruna]

Everything IS NOT a file in unix.

I said linux not unix :-) and your veering off-topic ( ...again)

What's more, something like /dev/ttyUSB0 might be a file in unix, but that doesn't mean you can manipulate it like a file from Pascal: you can't. And that's (a) why things like serial.pp, SynAser and so on exist, and (b) why serial libraries/components (and network protocol ditto etc.) aren't applicable to ordinary files.

You may want to reconsider that after watching this

[MarkMLl]

You may want to reconsider that

I've got much more important things to do with my time.

MarkMLl

[Thaddy]

Marcov is right, the assignfile/closefile procedures first appear in the OO versions of TurboPascal. (5.5, 6 and 7)
But that does not mean it is standard pascal and both are dependent on either {$mode objfpc} or one of the Delphi modes, actually any mode that draws in the objpas unit.
I have updated the wiki to reflect that: Assign and Close are independent from the mode. AssignFile and CloseFile are dependent on mode. That alone may be enough to never use them again: they are not portable, although many seem to think they are.

[Aruna]

You may want to reconsider that

I've got much more important things to do with my time.

Denial can be harmful because it prevents individuals from addressing reality and dealing with problems in a constructive manner. By refusing to acknowledge harmful behaviors or negative situations, denial perpetuates cycles of harm. This could involve repeating destructive habits, remaining in toxic environments, or enabling others' unhealthy behavior.

In essence, denial might offer temporary emotional relief, but it often comes at the cost of long-term well-being. Recognising and confronting reality, though difficult, is a crucial step toward growth and problem-solving. Just so you know that link I sent is a kid doing exactly what you said is not doable using pascal. Sadly when I tried to replicate his code I hit brick walls which am yet trying to get around.

The reason I asked you to watch is because I firmly believe 'your' very much more experienced and technically savvy than me so might see what am not seeing? And my turn to tell myself stop deviating from the subject at hand :-)

[Thaddy]

Read my remark about portability: using the convenience functions is not portable.

[MarkMLl]

The reason I asked you to watch is because I firmly believe 'your' very much more experienced and technically savvy than me so might see what am not seeing? And my turn to tell myself stop deviating from the subject at hand :-)

Flattery. Look, I /really/ have more important stuff to do and I'm sure you can understand the fact that I'm somewhat pissed off that you're ignoring the points I've made. Now this might sound like a fallacious "appeal to authority" but the fact is that I've got 40 years experience writing comms software and that by and large my stuff works.

Now you've just sent me a Google link (which required that the browser I pasted it into is now polluted by an acceptance of Google USA's T&Cs) but /which/ video am I supposed to be looking at: the 9:40 one?

To emphasise my point from another thread: if you write to /sys/.../backlight you aren't talking to a device directly, but to a kernel module which believe it can support that device and has created the backlight endpoint in the /sys tree of pseudofiles. Same applies to stuff in /proc... the device itself might not actually be expecting to transfer any data via a normal handle, but if the driver thinks there is state which can be usefully controlled then it might create something that /looks/ like a file.

Nearer home, if you look at my example code you'll see that there's some which goes out of its way to identify a (serial) device type: e.g. FTDI, WCH and so on (typically, so that it can find the instrument in which the chip is embedded). But that's not info that the device itself is exposing, rather it's the driver: /and/ there's a pseudofile which identifes the kernel module implementing the driver.

Now, what video did you want me to watch, or (even better) can you tell me the problems you're having interpreting things? Because right now I think that you're stuff because you're not making a distinction between "file" as defined by Pascal, and "file" as defined by the kernel... which in the case of unix (and I say unix advisedly, since I'm including SunOS etc.) has additional calls to set Baud rate, DTR state and so on which you're blithely ignoring.

MarkMLl

[Aruna]

/which/ video am I supposed to be looking at: the 9:40 one?

Yes please. Pay attention at 3:40 then again at 7:50 please and thank you. His code works as we can see in that video but when I try and type in the exact same code it chokes on me?

To emphasise my point from another thread: if you write to /sys/.../backlight you aren't talking to a device directly, ...

Oh dear sorry I totally forgot. My lap-toppie under /sys/class/backlight has acpi_video0 and intel_backlight

Nearer home, if you look at my example code you'll see that there's some which goes out of its way to identify a (serial) device type: e.g. FTDI, WCH and so on (typically, so that it can find the instrument in which the chip is embedded). But that's not info that the device itself is exposing, rather it's the driver: /and/ there's a pseudofile which identifes the kernel module implementing the driver.

Mark your code is impressive and a lot of thought has gone into it but it does not do the one thing I wouldl  like it t show me how to do? Which is send a string from pascal to the arduino and have the nano recognise that string then do the needful.

Now, what video did you want me to watch, or (even better) can you tell me the problems you're having interpreting things? Because right now I think that you're stuff because you're not making a distinction between "file" as defined by Pascal, and "file" as defined by the kernel... which in the case of unix (and I say unix advisedly, since I'm including SunOS etc.) has additional calls to set Baud rate, DTR state and so on which you're blithely ignoring.

I never ignored anything you sent 'blithely' or otherwise. I went through your code, was highly impressed at what you had done. Went through another couple of times looking for what I want to do and zilch. So saved your code for my own personal set of tools thinking this will come in handy someday.

So your pissed, so what else is new? Does not @Joanna  upset and piss your off much more? ( What is a friend for ?) and flattery I save for the fairer sex like our Joanna. I called it the way I saw it. That code was something else, but not what I was looking for is all.

[MarkMLl]

I'll try to come back to this in more detail later, but you could use the little terminal emulator program I gave you https://github.com/MarkMLl/serialcomms/blob/main/Term.pas as a starting point. Note the settings at the top for sped etc.

Looking specifically at (the source of) SerOpen(), I see that it sets one specific option that generic code won't use. In general you'd then set the line speed and put DTR/RTS in the correct state (neither of which you can do using generic file-handling code). also normal fpFlush() isn't appropriate so don't even try. You /could/ intercept the lower-level handlers so that WriteLn() etc. would talk to a serial port but trust me: you don't want to fiddle with that stuff.

MarkMLl

[Thaddy]

I adapted the wiki in a way that is possibly acceptable to all:
https://wiki.freepascal.org/typed_files

[Aruna]

Read my remark about portability: using the convenience functions is not portable.

Will do @Thaddy thanks.

[rvk]

You may want to reconsider that after watching this

Did you try the exact example mentioned in that video (but then with the USB port)?

You have TextFile and are sending complete strings while in that example just one letter is sent via a File of char.

Another possible problem... You close the /dev/ttyUSB0 port/file. This could reset things back. So you should not open and close it at the same place but keep a connection open. The downside of that could be that there could be done some buffering before flushing the data to that file/port so you might need to flush the data (or set the buffer to 0 or 1 before opening it as file).

[Aruna]

You may want to reconsider that after watching this

Did you try the exact example mentioned in that video (but then with the USB port)?

Hello @rvk, yes I followed his steps to the letter. I am going to do it over again from scratch and will post a video so anyone interested can see.

You have TextFile and are sending complete strings while in that example just one letter is sent via a File of char.

Another possible problem... You close the /dev/ttyUSB0 port/file. This could reset things back. So you should not open and close it at the same place but keep a connection open. The downside of that could be that there could be done some buffering before flushing the data to that file/port so you might need to flush the data (or set the buffer to 0 or 1 before opening it as file).

Yes I was trying to send 'more' than a single character like on/off. I have no idea how to keep a connection open :-( Thank you for the guidance.

[MarkMLl]

Yes please. Pay attention at 3:40 then again at 7:50 please and thank you. His code works as we can see in that video but when I try and type in the exact same code it chokes on me?

As RVK says, the demo code (7:42 in the video) runs forever without terminating and in particular without closing the connection. It also makes lots of assumptions about the speed that the port is set to by default, the state of (in particular) DTR and so on.

Your code similarly makes assumptions about speed and so on: but on a different OS where those assumptions are not at all safe. You send multiple characters and assume that they have all been transmitted before the file is closed, but even if the program or OS used flush() at the handle level (i.e. fpFlush() in the RTL) that call is ineffective on a serial port: it's one of the reasons why I got involved with maintenance of the serial unit in the first place and I direct you to

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

1. { Flushes the data queues of the given serial device. DO NOT USE THIS:
2.   use either SerSync (non-blocking) or SerDrain (blocking). }
3. procedure SerFlush(Handle: TSerialHandle); deprecated;
4.  

And so on.

Now, you've been spinning your wheels on this one since before the weekend: stop wasting your time and everybody else's and look at the example that I sent you. Or use SynAsync or whatever, noting that that's explicitly been written to be "further from the metal" than serial.pp.

MarkMLl