help - write to file in interrupt problems 
Author Message
 help - write to file in interrupt problems

I am developing Network interface cards and PC level software for a LAN
project that will be able to FTP files from one computer to another.  This is
accomplished by breaking up the files into as many 64-byte packets as needed.

We are using Borland 5.0 to create a DOS executable.  It's a project with
where Target type = Application( .exe ), Platform = DOS( Standard), Target
model = Large, and node = .cpp.

We are in the final stage of this design and are having a major problem in the
PC level code.  When we write data to a file inside an interrupt, the system
crashes.  Previously, I have verified the program works while specifically in
the receive mode( and the files are rebuilt outside the interrupt ) and I have
verified that all the receive code works correctly when executed inside the
interrupt providing these 4 lines are commented out:

w_access =  ( O_RDWR|O_CREAT|O_APPEND|O_BINARY|S_IREAD|S_IWRITE);
f_handler = open( ( char* )filepath, w_access );
write( ( int )f_handler, ( uchar *)&pkt_r[proto_size], data_size );
close( ( int )f_handler );

So I've got the data where I want it, yet I can't write it to the file.  I
also tried these 2 methods to no avail:

( I created the empty file before using this code )
1)
_dos_open( ( char* )filepath, O_RDWR, ( int* )&f_handler );
_dos_write(f_handler,(uchar*)&pkt_r[proto_size],(uint)data_size,
                (uint*)&nbytes );
_dos_close( f_handler );

2)
 fstream write_file;
write_file.open(( char* )filepath, ios::out | ios::app | ios::binary );
for ( l = 0; l < data_size; l++ )
{
        write_file << pkt_r[ST_PR_SIZE + l];

Quote:
}

write_file.close( );

Like I said, I get the data where I want to when I want to, yet I can't write
it to a file.  I thank anyone willing to offer help now.  I will forever be in
you debt.

Paul A. Lohr

phone number:   ( 320 ) 253-3810



Mon, 17 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems



Quote:
>I am developing Network interface cards and PC level software for a LAN
>project that will be able to FTP files from one computer to another.  This is
>accomplished by breaking up the files into as many 64-byte packets as needed.

>We are using Borland 5.0 to create a DOS executable.  It's a project with
>where Target type = Application( .exe ), Platform = DOS( Standard), Target
>model = Large, and node = .cpp.

>We are in the final stage of this design and are having a major problem in the
>PC level code.  When we write data to a file inside an interrupt, the system
>crashes.  Previously, I have verified the program works while specifically in

You should probably break your network drivers into the traditional upper half
and lower half. The lower half responds to interrupts and buffers data, and
signals the upper half of its availability. The upper half dequeues the data
and makes it available to the application.

Have a look at some teaching operating system such as Xinu/386.

It sounds like you are trying to reinvent the wheel, very badly.

In any case, this has nothing to do with the C language, so ask on some OS
programming, or PC hardware newsgroup.
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton



Mon, 17 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems

Quote:

> I am developing Network interface cards and PC level software for a
> LAN
> project that will be able to FTP files from one computer to another.
> This is
> accomplished by breaking up the files into as many 64-byte packets as
> needed.

> We are using Borland 5.0 to create a DOS executable.  It's a project
> with
> where Target type = Application( .exe ), Platform = DOS( Standard),
> Target
> model = Large, and node = .cpp.

> We are in the final stage of this design and are having a major
> problem in the
> PC level code.  When we write data to a file inside an interrupt, the
> system
> crashes.  Previously, I have verified the program works while
> specifically in
> the receive mode( and the files are rebuilt outside the interrupt )
> and I have
> verified that all the receive code works correctly when executed
> inside the
> interrupt providing these 4 lines are commented out:

> w_access =  ( O_RDWR|O_CREAT|O_APPEND|O_BINARY|S_IREAD|S_IWRITE);
> f_handler = open( ( char* )filepath, w_access );
> write( ( int )f_handler, ( uchar *)&pkt_r[proto_size], data_size );
> close( ( int )f_handler );

> So I've got the data where I want it, yet I can't write it to the
> file.  I
> also tried these 2 methods to no avail:

> ( I created the empty file before using this code )
> 1)
> _dos_open( ( char* )filepath, O_RDWR, ( int* )&f_handler );
> _dos_write(f_handler,(uchar*)&pkt_r[proto_size],(uint)data_size,
>                 (uint*)&nbytes );
> _dos_close( f_handler );

> 2)
>  fstream write_file;
> write_file.open(( char* )filepath, ios::out | ios::app | ios::binary
> );
> for ( l = 0; l < data_size; l++ )
> {
>         write_file << pkt_r[ST_PR_SIZE + l];
> }
> write_file.close( );

> Like I said, I get the data where I want to when I want to, yet I
> can't write
> it to a file.  I thank anyone willing to offer help now.  I will
> forever be in
> you debt.

> Paul A. Lohr

> phone number:   ( 320 ) 253-3810

   It is not a good way to write from a interrupt in to a file, since
you don't know how long it will take. So you will probably lose
interrupts . I normally do it from a procedure outside of interrupt.
Generally it is possible to do that. You have to examine the InDosFlag (
interrupt 21h Func 34h ) and Critical Section Counter ( Int 21h Func
5d06 ). But I suggest you rewrite the code.

Damian



Tue, 18 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems

<david says>
I agree with damian, writing to a file in an interrupt is *bad* coding
since the disks can delay for long and possibily indeterminate times
(seeks, errors, head settling, all these things take *loads* of time from
the standpoint of the CPU).

Generally speaking, in this type of app you cache the data in memory
and use multitasking to have another routine write out the data to the
file at a non-interrupt level.  However, this can be a bit
tricky if you have a lot of data coming in fast... and it is going to
be even more tricky given that you have chosen a 16-bit compiler on
an operating system that does not support multitasking.  Still, it CAN
be done, you might want to jet over to comp.arch.embedded if you need basic
info on the techniques for rolling this kind of stuff yourself.  Do
tell them things like what your data rate is though... that will play a big
role in deciding how much of the present design you are able to keep as-is.

David

Quote:

> > I am developing Network interface cards and PC level software for a
> > LAN
> > project that will be able to FTP files from one computer to another.
> > This is
> > accomplished by breaking up the files into as many 64-byte packets as
> > needed.

> > We are using Borland 5.0 to create a DOS executable.  It's a project
> > with
> > where Target type = Application( .exe ), Platform = DOS( Standard),
> > Target
> > model = Large, and node = .cpp.

> > We are in the final stage of this design and are having a major
> > problem in the
> > PC level code.  When we write data to a file inside an interrupt, the
> > system
> > crashes.  Previously, I have verified the program works while
> > specifically in
> > the receive mode( and the files are rebuilt outside the interrupt )
> > and I have
> > verified that all the receive code works correctly when executed
> > inside the
> > interrupt providing these 4 lines are commented out:

> > w_access =  ( O_RDWR|O_CREAT|O_APPEND|O_BINARY|S_IREAD|S_IWRITE);
> > f_handler = open( ( char* )filepath, w_access );
> > write( ( int )f_handler, ( uchar *)&pkt_r[proto_size], data_size );
> > close( ( int )f_handler );

> > So I've got the data where I want it, yet I can't write it to the
> > file.  I
> > also tried these 2 methods to no avail:

> > ( I created the empty file before using this code )
> > 1)
> > _dos_open( ( char* )filepath, O_RDWR, ( int* )&f_handler );
> > _dos_write(f_handler,(uchar*)&pkt_r[proto_size],(uint)data_size,
> >                 (uint*)&nbytes );
> > _dos_close( f_handler );

> > 2)
> >  fstream write_file;
> > write_file.open(( char* )filepath, ios::out | ios::app | ios::binary
> > );
> > for ( l = 0; l < data_size; l++ )
> > {
> >         write_file << pkt_r[ST_PR_SIZE + l];
> > }
> > write_file.close( );

> > Like I said, I get the data where I want to when I want to, yet I
> > can't write
> > it to a file.  I thank anyone willing to offer help now.  I will
> > forever be in
> > you debt.

> > Paul A. Lohr

> > phone number:   ( 320 ) 253-3810
>    It is not a good way to write from a interrupt in to a file, since
> you don't know how long it will take. So you will probably lose
> interrupts . I normally do it from a procedure outside of interrupt.
> Generally it is possible to do that. You have to examine the InDosFlag (
> interrupt 21h Func 34h ) and Critical Section Counter ( Int 21h Func
> 5d06 ). But I suggest you rewrite the code.
> Damian



Tue, 18 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems



Quote:
>Generally speaking, in this type of app you cache the data in memory
>and use multitasking to have another routine write out the data to the
>file at a non-interrupt level.  However, this can be a bit
>tricky if you have a lot of data coming in fast...

The usual solution is to maintain double buffers, switching the
buffer pointer (handle) when a buffer fills and notifying the
"top end" that there is a buffer ready for it to dispose of.
Meanwhile the "bottom end" keeps storing data into the other buffer.


Thu, 20 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems

Quote:



> > I agree with damian, writing to a file in an interrupt is *bad* coding
> > since the disks can delay for long and possibily indeterminate times
> > (seeks, errors, head settling, all these things take *loads* of time
> from
> > the standpoint of the CPU).
> Everything depends on what you mean by "in an interrupt". In a narrow
> sense you are in an interrupt until the End Of Interrupt command has been
> sent to the PIC and the CPU's interrupt flag has been set. The obligation
> on programmers during that time is to be as quick as possible. Certainly,
> it would be stupid to attempt file operations while in an interrupt in
> this narrow sense (even if DOS is known to be ready).
> In a broad sense however, you are in an interrupt until you return to the
> interrupted code. If you receive a hardware interrupt and call through to
> the original handler (via a PUSHF, CLI, CALL DWORD PTR sequence), then
> when the original handler returns, you can arguably take as long as you
> like over any operations that you can be sure will not disturb a state
> that the interrupted code expects to see. Most notably, if the interrupted
> code is not in the middle of a file operation, you should be able to
> perform file operations.

of course.  But if you do such a thing you need to allow for the problem
where the interrupt gets re-triggered while you are still doing file I/O...
you don't want two file I/O operations going on at once.  I assumed he was
doing time-dependent data aquisition when I responded, and didn't want to
cover *all* the possibilities given how little information he presented us
with.  I could have gone on for a long time...

Quote:
> I don't say that this is necessarily the best way to implement TSR
> features, just that fear of losing interrupts is a red herring. The real
> concern about implementing TSR popups as preemptive multi-tasking (which
> is essentially what you are implementing when performing DOS file
> operations from a hardware interrupt handler) is that you can't be certain
> that the interrupted code wasn't programming peripherals by direct I/O.
> You should really have full hardware virtualisation of the capacity to
> save and restore the complete hardware state of any peripheral that your
> popup code may use. Otherwise, the TSR popup may disturb some hardware
> state that the interrupted code was in the middle of preparing.

of course.  You *CAN* do a lot of things but he was a novice both in
terms of the application and in terms of what he was telling us about it...
so it was just as well to keep it simple.

David

- Show quoted text -

Quote:
> --
> Geoff Chappell
> Software Analyst
> For email address change host to ozemail.com.au
> Web site in directory ~geoffch at www.ozemail.com.au



Thu, 20 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems



Quote:
> I agree with damian, writing to a file in an interrupt is *bad* coding
> since the disks can delay for long and possibily indeterminate times
> (seeks, errors, head settling, all these things take *loads* of time
from
> the standpoint of the CPU).

Everything depends on what you mean by "in an interrupt". In a narrow
sense you are in an interrupt until the End Of Interrupt command has been
sent to the PIC and the CPU's interrupt flag has been set. The obligation
on programmers during that time is to be as quick as possible. Certainly,
it would be stupid to attempt file operations while in an interrupt in
this narrow sense (even if DOS is known to be ready).

In a broad sense however, you are in an interrupt until you return to the
interrupted code. If you receive a hardware interrupt and call through to
the original handler (via a PUSHF, CLI, CALL DWORD PTR sequence), then
when the original handler returns, you can arguably take as long as you
like over any operations that you can be sure will not disturb a state
that the interrupted code expects to see. Most notably, if the interrupted
code is not in the middle of a file operation, you should be able to
perform file operations.

I don't say that this is necessarily the best way to implement TSR
features, just that fear of losing interrupts is a red herring. The real
concern about implementing TSR popups as preemptive multi-tasking (which
is essentially what you are implementing when performing DOS file
operations from a hardware interrupt handler) is that you can't be certain
that the interrupted code wasn't programming peripherals by direct I/O.
You should really have full hardware virtualisation of the capacity to
save and restore the complete hardware state of any peripheral that your
popup code may use. Otherwise, the TSR popup may disturb some hardware
state that the interrupted code was in the middle of preparing.

--
Geoff Chappell
Software Analyst

For email address change host to ozemail.com.au
Web site in directory ~geoffch at www.ozemail.com.au



Thu, 20 Apr 2000 03:00:00 GMT  
 help - write to file in interrupt problems



Quote:
> of course.  You *CAN* do a lot of things but he was a novice both in
> terms of the application and in terms of what he was telling us about
it...
> so it was just as well to keep it simple.

Well, my newsreader - the fabulous Microsoft Internet News - has just gone
through my message file removing supposedly expired messages but leaving
me with what it reports as 4192400KB of message bodies. I incline to call
this spontaneous corruption rather than a clean up, but who am I to argue
with Microsoft. Anyway, it means I can't easily refer now to the earlier
items in this thread.

I do appreciate the desire to keep things simple for novices. I also
appreciate the number of times I have had to disabuse even expert
programmers of beliefs that they have carried with them since their days
as novices. I say disabuse because sometimes people hold so tenaciously to
simplifications that they end up being almost unable to un-learn the point
later.

To say one should not attempt file operations in an interrupt handler
seems to me like too great a simplification. I recall that someone else in
the thread even went as far as suggesting that it can't be done because
interrupts would get lost. Yet Windows enhanced mode and any number of
(earlier) preemptive multitaskers for DOS depend on performing file
operations - and anything else that the incoming task wants to do - in
interrupt handlers. A simplification that complicates a novice's eventual
understanding of preemptive multitasking seems like a simplification that
goes too far.

With my post on the matter, I didn't mean to criticise the contributors,
just to amplify.

--
Geoff Chappell
Software Analyst

For email address change host to ozemail.com.au
Web site in directory ~geoffch at www.ozemail.com.au



Tue, 25 Apr 2000 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. problem reading from and writing to file - please help

2. how to write software interrupt subroutine

3. How do I write an interrupt driven routine ?

4. Interrupt driven socket -read and write

5. How to Write an Interrupt routine in C for PC IRQ

6. how can i write an ISR(Interrupt service routine)

7. Problem opening a file for read while it is open for write

8. File Read/Write Problem

9. problems writing to binary files

10. Problems with writing to a file

11. Q: problem: CGI-programming with C (writing files and sending picyures)

12. problem writing to file

 

 
Powered by phpBB® Forum Software