Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2010-01

Challenging port of Borland Pascal program to FPC

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

John Youngquist

Hi: I have been using FPC for some time now and think it is a great system.

I am facing a challenging port of a Borland Pascal 7 program to FPC. It is about
8000 lines long. While most of it is ordinary and will compile easily it uses some
features and extensions which I don't know how to handle in FPC.

1) It does direct I/O to port addresses via the Borland Port[xxx] feature.
2) It uses a buffered interrupt driven RS-232 facility to receive and direct access for transmit.
3) It uses the RS-232 control lines separately to to additional unrelated I/O while normal serial I/O is in progress.
4) It reads/writes the LPT port.
5) It uses interrupts on the LPT port. About 35K ints/sec are used to drive stepper motors.
6) it writes to a 48 I/O line card on the ISA bus. (hard to find ISA bus slots)
7) it uses an excellent multitasking library written by Dieter Pawelczak from Germany.
This allows execution to be interrupted and other tasks run based on time scheduling.
A simple example would be to set a port bit in the main program and then schedule
a task to run say 10 msec later which turns it off. The main program would run normally
until the 10 msec time limit is reached at which time the main is suspended briefly while
the scheduled task is run. Of course there are various restrictions and pitfalls because of
rentrancy issues. But it works well when used properly. The source code is provided for
this library including a bunch of 16 bit oriented ASM code.
8) To avoid OS intervention on I/O port access Windows98 is used.

I would like to port the program as is, but eventually get a PCI 48 I/O line card to escape
the ISA bus and also talk USB as well. Getting it to run on later versions of Windows might
be useful. This program controls a machine on a single purpose computer. Windows is used
to handle files, networks, and little else. Most of the time only this program is run. A port to
Linux might be acceptable if that would solve some problems.

Are these insurmountable obstacles?

Thanks

John Youngquist

Reply by email

Jeff Wormsley
to John Youngquist
John Youngquist wrote 11 lines
I would like to port the program as is, but eventually get a PCI 48 I/O line card to escape the ISA bus and also talk USB as well. Getting it to run on later versions of Windows might be useful. This program controls a machine on a single purpose computer. Windows is used to handle files, networks, and little else. Most of the time only this program is run. A port to Linux might be acceptable if that would solve some problems. Are these insurmountable obstacles?

Probably not if you're willing to spend a ton of time and money, but you might be better off moving the bulk of this system off of a PC and on to a dedicated micro controller board, and just using a PC to handle UI and files/network and things that don't have any real time requirements. The STM-32 Cortex chips in the 144 pin package should probably have enough I/O and speed to do what you want, with built in ram/rom. Coupled with FreeRTOS, you can have a quite capable system for not a lot of money (you should be able to build a board to replace the PC hardware for a couple of hundred dollars, depending on how sophisticated the 48 port I/O board is).

I'm surprised the current system ran properly on a Win98 DOS box, considering how badly Windows messes up real time (those 10ms breaks should have probably been much longer on occasion when the Windows kernel was busy doing stuff with interrupts disabled). Until I found out how to use the multimedia timers, I couldn't get better than 55ms response out of Windows, even from a DOS box.

Jeff.

Reply by email

Mehmet Erol Sanliturk
to John Youngquist: Interesting response. I routinely implement large systems on the 8051 chip in assembly…
John Youngquist wrote 42 lines
Interesting response. I routinely implement large systems on the 8051 chip in assembly language which I can write faster than Pascal. Assembly is a minimum of 500% faster than C on the 8051. I hate C anyway. The machine is a pick & place machine designed to assemble SMT circuit boards. It was originally controlled by a Borland Basic program written in Japan without any useful comments. With 5 or 6 statements per line without even a single space it looked like Japanese to me. Initially I needed to fix a few bugs and add a few features so I studied the code for while - all 100K statements of it. I decided rewriting it from scratch would be faster that figuring it out. In exactly 2 weeks I had replicated and enhanced the original functionality with 3K lines of Pascal. I still had to study the code to figure out how drive their special hardware, but over the years all of it has been replaced with simpler stuff. Numerous enhancements have swelled the code to 8K lines using less than 2 64K blocks of memory. The before/after size ratio shows how poorly the basic was done. As implemented in BP it works very well. The multi-tasking part handles functions that are not time critical, operating air cylinders that don't know what a mSec is. The fast motion is handled independently by Animatics Smart motors. I have never explored the multimedia timers. I drive the LPT int to get my own periodic interrupt because the multi-task code already uses the timer. As you know there are 3 timers in the timer chip but only one will generate an interrupt. One problem I have yet to solve is the BP IDE when it hits a breakpoint kills my LPT interrupt. Nothing but an IDE restart will restore it. It sure cramps your debugging style.

You may think

http://www.freedos.org/

in a simple PC with Free Pascal

http://www.freedos.org/cgi-bin/lsm.cgi?mode=dir&dir=devel

I think , you may directly use your Pascal program in DOS mode : Port I/O , Interrupts , etc.

Thank you very much .

Mehmet Erol Sanliturk

Reply by email

John Youngquist
to Jeff Wormsley: Probably not if you're willing to spend a ton of time and money, but you might be better…

Interesting response.

I routinely implement large systems on the 8051 chip in assembly language which I can write faster than Pascal. Assembly is a minimum of 500% faster than
C on the 8051. I hate C anyway.

The machine is a pick & place machine designed to assemble SMT circuit boards. It was originally controlled by a Borland Basic program written in
Japan without any useful comments. With 5 or 6 statements per line without even
a single space it looked like Japanese to me. Initially I needed to fix a few bugs
and add a few features so I studied the code for while - all 100K statements of it.
I decided rewriting it from scratch would be faster that figuring it out. In exactly 2 weeks
I had replicated and enhanced the original functionality with 3K lines of Pascal. I still
had to study the code to figure out how drive their special hardware, but over the years
all of it has been replaced with simpler stuff. Numerous enhancements have swelled the code to 8K lines using less than 2 64K blocks of memory. The before/after size ratio shows how poorly the basic was done. As implemented in BP it works very well. The multi-tasking part handles functions that are not time critical, operating air cylinders that don't know what a mSec
is. The fast motion is handled independently by Animatics Smart motors.

I have never explored the multimedia timers. I drive the LPT int to get my own periodic
interrupt because the multi-task code already uses the timer. As you know there are 3
timers in the timer chip but only one will generate an interrupt.

One problem I have yet to solve is the BP IDE when it hits a breakpoint kills my LPT interrupt.
Nothing but an IDE restart will restore it. It sure cramps your debugging style.

Thanks for your ideas.

JY

Jeff Wormsley wrote 37 lines
John Youngquist wrote: > I would like to port the program as is, but eventually get a PCI 48 > I/O line card to escape > the ISA bus and also talk USB as well. Getting it to run on later > versions of Windows might > be useful. This program controls a machine on a single purpose > computer. Windows is used > to handle files, networks, and little else. Most of the time only > this program is run. A port to > Linux might be acceptable if that would solve some problems. > > Are these insurmountable obstacles? Probably not if you're willing to spend a ton of time and money, but you might be better off moving the bulk of this system off of a PC and on to a dedicated micro controller board, and just using a PC to handle UI and files/network and things that don't have any real time requirements. The STM-32 Cortex chips in the 144 pin package should probably have enough I/O and speed to do what you want, with built in ram/rom. Coupled with FreeRTOS, you can have a quite capable system for not a lot of money (you should be able to build a board to replace the PC hardware for a couple of hundred dollars, depending on how sophisticated the 48 port I/O board is). I'm surprised the current system ran properly on a Win98 DOS box, considering how badly Windows messes up real time (those 10ms breaks should have probably been much longer on occasion when the Windows kernel was busy doing stuff with interrupts disabled). Until I found out how to use the multimedia timers, I couldn't get better than 55ms response out of Windows, even from a DOS box. Jeff. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal .

Reply by email

Florian Klaempfl
to John Youngquist
Show quoted text 7 lines
Interesting response. I routinely implement large systems on the 8051 chip in assembly language which I can write faster than Pascal. Assembly is a minimum of 500% faster than C on the 8051. I hate C anyway.

FPC runs also on embedded arm systems so this might be a real possibility and probably allows code reusage.

Reply by email