I need to make two legs robot with five motor and control way sensor using either Pascal or Delphi. I want to know how to write the order to get an output or input from the standard parallel port.
1. PASCAL is way, way too slow. Use C instead.
(The best introduction to C is a book by
Kernighan and Ritchie. Easiest C compiler, for a beginner, is TurboC. You can also try a book on parallel ports titled, CONTROLLING THE WORLD THROUGH YOUR PC.)
(The best introduction to C is a book by
Kernighan and Ritchie. Easiest C compiler, for a beginner, is TurboC. You can also try a book on parallel ports titled, CONTROLLING THE WORLD THROUGH YOUR PC.)
I assume you are talking 32 bit delphi. If the Operating System is NT based (NT, Win2K or XP), you will need a device driver, since Port IO is
prohibited in User Mode.
The following will work for Win 95/98
procedure SetDigitalOutputByte(BaseAddr: Word; nValue: byte);
begin
asm
Mov AL,nValue {get data value into AL (bytes only)}
Mov DX,BaseAddr {get port value into DX}
Out DX,AL {output the byte}
end;
end;
function GetDigitalInputByte(BaseAddr: Word): byte;
begin
{ get the current settings }
asm
Mov DX,BaseAddr {load DX with port to check out}
In AL,DX {input a byte}
Xor AH,AH {clear high byte for return in AX}
Mov @Result, AL
end;
end;
There is a device driver available, which will allow direct Port I/O under NT, although it opens a Plethora of security and stability problems, since you can poke bytes anywhere you like. It would definately not be recommended for production systems.
As for the "way, way too slow" comment. I would be interested to see some substantiation.
Pascal may be verbose (and therefore slower to write the code), but slow to execute???, I don't believe so. Also, try writing a windows GUI app in C. As usual, it's horses for courses.
John
prohibited in User Mode.
The following will work for Win 95/98
procedure SetDigitalOutputByte(BaseAddr: Word; nValue: byte);
begin
asm
Mov AL,nValue {get data value into AL (bytes only)}
Mov DX,BaseAddr {get port value into DX}
Out DX,AL {output the byte}
end;
end;
function GetDigitalInputByte(BaseAddr: Word): byte;
begin
{ get the current settings }
asm
Mov DX,BaseAddr {load DX with port to check out}
In AL,DX {input a byte}
Xor AH,AH {clear high byte for return in AX}
Mov @Result, AL
end;
end;
There is a device driver available, which will allow direct Port I/O under NT, although it opens a Plethora of security and stability problems, since you can poke bytes anywhere you like. It would definately not be recommended for production systems.
As for the "way, way too slow" comment. I would be interested to see some substantiation.
Pascal may be verbose (and therefore slower to write the code), but slow to execute???, I don't believe so. Also, try writing a windows GUI app in C. As usual, it's horses for courses.
John
Pascal is very, very slow? I don't see why you would say that. There is nothing "magic" about the 'C' language that would make the machine
instructions run faster when compiled by a 'C' compiler.
If you want to argue that one particular compiler implementation produces more efficient object code (in terms of execution speed) than another, then that is a different matter. However, that applies equally whether you are
comparing compilers for different langauges or for the same language, so this is not a language issue.
I haven't followed the reports on these things for some years now, but the fastest PC compiler on the market used to be one for Pascal (I forget the brand), which regularly beat all 'C' compilers on most benchmarks. That
particular company simply wrote a very good compiler, at least when measured in terms of benchmarks.
I would not discourage our robot pioneer from using Pascal or Delphi for his project since no one has enough information about his system to make a valid judgement or recommendation. In favour of using Pascal or Delphi is that he
appears to be comfortable with it, which means he can concentrate on writing a good program with good algorithms. This sounds like it is supposed to be an exercise in robotics, not in learning a new computer language.
What I would have to wonder though, is if this robot is of a type which has to dynamically balance on two legs, or whether it is naturally stable (i.e. it has big feet). If it has to dynamically balance, then the hardware interface and operating system effects are likely to matter much more than the choice of compiler.
************************
Michael Griffin
London, Ont. Canada
************************
instructions run faster when compiled by a 'C' compiler.
If you want to argue that one particular compiler implementation produces more efficient object code (in terms of execution speed) than another, then that is a different matter. However, that applies equally whether you are
comparing compilers for different langauges or for the same language, so this is not a language issue.
I haven't followed the reports on these things for some years now, but the fastest PC compiler on the market used to be one for Pascal (I forget the brand), which regularly beat all 'C' compilers on most benchmarks. That
particular company simply wrote a very good compiler, at least when measured in terms of benchmarks.
I would not discourage our robot pioneer from using Pascal or Delphi for his project since no one has enough information about his system to make a valid judgement or recommendation. In favour of using Pascal or Delphi is that he
appears to be comfortable with it, which means he can concentrate on writing a good program with good algorithms. This sounds like it is supposed to be an exercise in robotics, not in learning a new computer language.
What I would have to wonder though, is if this robot is of a type which has to dynamically balance on two legs, or whether it is naturally stable (i.e. it has big feet). If it has to dynamically balance, then the hardware interface and operating system effects are likely to matter much more than the choice of compiler.
************************
Michael Griffin
London, Ont. Canada
************************
I know a guy who writes all kinds of realtime machine control programs in Pascal, and they seem to work just fine. They are used for custom machine control in a manufacturing plant. The most sophisticated one cuts turbine rotors from a single block of material. Works great.
Walt Boyes
---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"
www.spitzerandboyes.com
walt@waltboyes.com
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------
Walt Boyes
---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"
www.spitzerandboyes.com
walt@waltboyes.com
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------
That's a rather rash statement. Especially considering that Karel is very close to Pascal and Karel is the language for GEF robotics.
Pascal or Delphi might be slow on Windows. And I'm not sure Delphi is ported to anything else, but a good Pascal implementation on a good OS should be more than fast enough. And the P2C converter on Linux used with the standard gcc compiler will produce very good object code for a variety of platforms. For that matter, I'm sure
that the earlier, efficient, Turbo Pascal on today's platforms would be competitive with all but optimized C or assembler and a lot easier to read. Turbo Pascal was fast on an 8088 of Z80,
even if it didn't take advantage of 32 bit procs, I doubt it could be described as slow on a thunderbird or pentium. The Windows RAD's add an incredible amount of bloat being visual. That shouldn't reflect on the underlying language. A good compiled BASIC would be several orders of magnitude faster than VB, and even that, done right, should be fast enough for anything where you can see it move. If it's slow on a 400 MIPS processor, fire the programmer or get better tools.
Regards
cww
Pascal or Delphi might be slow on Windows. And I'm not sure Delphi is ported to anything else, but a good Pascal implementation on a good OS should be more than fast enough. And the P2C converter on Linux used with the standard gcc compiler will produce very good object code for a variety of platforms. For that matter, I'm sure
that the earlier, efficient, Turbo Pascal on today's platforms would be competitive with all but optimized C or assembler and a lot easier to read. Turbo Pascal was fast on an 8088 of Z80,
even if it didn't take advantage of 32 bit procs, I doubt it could be described as slow on a thunderbird or pentium. The Windows RAD's add an incredible amount of bloat being visual. That shouldn't reflect on the underlying language. A good compiled BASIC would be several orders of magnitude faster than VB, and even that, done right, should be fast enough for anything where you can see it move. If it's slow on a 400 MIPS processor, fire the programmer or get better tools.
Regards
cww
On September 4, 2002 10:41 am, Curt Wuollet wrote:
<clip>
> Pascal or Delphi might be slow on Windows. And I'm not sure Delphi is
> ported to anything else, but a good Pascal implementation on a
> good OS should be more than fast enough.
<clip>
As a point of interest, Delphi is available from Borland on Linux as "Kylix". Delphi/Kylix has been designed as a cross-platform development tool for Linux and WIndows.
This sounds like a good way to hedge your bets if you are not sure which operating system you want to target, or if you want to be able to target both, without a lot of extra work. I have a copy, but I haven't tried it out yet, so I can't vouch for it (although Delphi has quite a good reputation).
************************
Michael Griffin
London, Ont. Canada
************************
<clip>
> Pascal or Delphi might be slow on Windows. And I'm not sure Delphi is
> ported to anything else, but a good Pascal implementation on a
> good OS should be more than fast enough.
<clip>
As a point of interest, Delphi is available from Borland on Linux as "Kylix". Delphi/Kylix has been designed as a cross-platform development tool for Linux and WIndows.
This sounds like a good way to hedge your bets if you are not sure which operating system you want to target, or if you want to be able to target both, without a lot of extra work. I have a copy, but I haven't tried it out yet, so I can't vouch for it (although Delphi has quite a good reputation).
************************
Michael Griffin
London, Ont. Canada
************************
I'm curious - why do you say that Pascal is too slow for realtime control of a robot? In my experience (though it has been many years since I had to use Pascal for anything - VC++ these days) code written in Pascal is as fast as the compiler and processor and application code allow it to be. If you can come up with a compiler which allows optimized code on a modern processor then it should be as fast as the processor and application code allow for. If you are using an older processor then you should find that the
Pascal is as fast as the Delphi under the same
conditions - maybe faster as Delphi may not allow
optimizations for older processors. So what it
actually comes down to IMNSHO is the speed of the
processor, the operating system, and the ability of the coder. If you are running this under Windows of any flavor you should make sure that you don't end up crashing your robot because the system hangs for many ms waiting for input from a mouse or ethernet card.
Davis Gentry
Delta Tau Data Systems
Pascal is as fast as the Delphi under the same
conditions - maybe faster as Delphi may not allow
optimizations for older processors. So what it
actually comes down to IMNSHO is the speed of the
processor, the operating system, and the ability of the coder. If you are running this under Windows of any flavor you should make sure that you don't end up crashing your robot because the system hangs for many ms waiting for input from a mouse or ethernet card.
Davis Gentry
Delta Tau Data Systems
PASCAL is way, way too slow for realtime control of a robot. Delphi, I don't know
about.
about.
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2010 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
"I shot an arrow into the air, and it stuck."
-- Graffito in Los Angeles







