I totally agree - if you know it that is. With compiling higher level code - there usually is some problems with that; too many to list. With machine level - 'you know' exactly what you want to do and what it should be doing. But with higher level code, the compiler is the one that decides what is going on. In theory it works excellently, but as we all know in the real world, that isn't always the case.
__________________
Bla - de - bla - de - BLA!!! "That's Me!!!"
I would suggest assembly language given that machine language is almost never taught any longer or even used pervasively. Failing that then the C-paradigm is the next option as it is the cleanest of the higher languages, although I would suggest using the GNU compiler for the compilation step because of its compilation of C-codes into intermediate assembly code that could be examined for efficiency or development insight.
__________________
EditorGBAnalysts - Give a boy fish and he will eat may be for a day, but teach him how to fish and he will eat everyday.
Yes, machine code is the fastest to run, but maybe 10X slower to write, so you will want to use it very sparingly. (Assembly code is just a human readable representation of machine code; its execution speed is identical.)
However, only a fraction of port I/O routines MAY need to be coded in machine language. A higher level language is so much easier to write in. You may get all the speed you need from carefully written C code which will run within a factor of 2 of the speed of machine code. If and only if the C code is not fast enough, you can rewrite only the critical part in hand coded assembly code in-line with the C code. Still, most of your code will not be in that critical path, and so can remain in a higher level language, such as C.
If you have GUI code or complex algorithms to write, you will want a higher level language than C, such as Python (currently my favorite language). Python and C can be mixed easily. In fact, I'd recommend starting out writing in Python, and switch to calling C routines only for the low level code close to the hardware or any other time critical routine.
What system and CPU are you using and what is on the other side of the port?
I am also in favour of Assembler / machine level programming but using a higher level language also have advantages. Ports are accessed by name, it may do better error handling and handle protocol correctly without you having to know much about it.
Also note that high level languages includes inline assembler programming in any case.
__________________
Never do today what you can put of until tomorrow - Student motto
Worth noting is the type of port, RS-232 is pretty easy to reach for, USB or TCP are layered protocols which I *think* might argue for a higher level language for ease.
__________________
"If you want to get somewhere else, you must run at least twice as fast as that!"
There's no correct answer, it depends on what you want to do and what you're doing it on.
But note that modern PC's and programming methods don't let you access the ports directly (like you could in the good old DOS days) and most users want a pretty GUI. You could look a something like Visual Basic, it's pretty and, once you understand the classes, quite powerful.
As an old C/assembler programming elec engineer, I never thought I'd ever say that.
__________________
If there's something you don't understand...Then a wizard did it. As heard on "The Simpsons".
Very true the answer is hardware and application specific. I can't say yet for Linux but it is very hard to do with M$ OSs now. It can be done but it is made difficult by M$ design. They want you to pay for Visual Basic.
Also is just a connection being made for communicating (like a tunnel) or is the control root level at all parts (like CNC)?
A command line control is doable but a GUI brings its own issues.
Brad
__________________
(Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.
Good Answers: