This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Disk I/O -> scheduling problems]




Paul D. DeRocco írta:
From: Szentirmai Gergely

I have an SD card with FAT filesystem, handled throught an MCI
interface. eCos did not have support for this interface (target
AT91SAM7A3), and I have written an extension - based on Atmel's library
- for the MMC driver to support it.
I have a sensor connected with SPI, and this sensor has an interrupt,
which is handled this way isr -> dsr (flag set) -> thread (flag wait) ->
spi_read. This reader thread has a high pritority.

When I write the card with a low priority thread, it blocks reading the
sensor. Sensor reading should be done in about every 5 ms.

This is because dsr-s are locked by io/src/disk.c. So the question is,
what should I do to prevent losing samples? Writing a blocks of data
(512Byte) to the card can take some time (approx. 10 ms). Are these
really concurent request, so this locking mechanism is needed?

<snip>
So what is the recommened solution for handling lengthy operations in a
  driver?

This is a code part from the Atmel AT91 SPI driver:
             // Wait for its completion
             cyg_drv_dsr_lock();
             {
                 while (!spi_bus->transfer_end)
                     cyg_drv_cond_wait(&spi_bus->transfer_cond);
             }
             cyg_drv_dsr_unlock();

Assuming that you're using the SPI bus that doesn't share pins with the MCI interface, it ought to be possible.

Of course.


Does the existing MCI driver do the
entire sector transfer without using any interrupts?

No, but it polls for the result. This is what could be modified to the code here, I have posted.

If that's how it works,
then, yes, the scheduler will remain locked for the duration, which is a Bad
Idea.

Agreed with the Bad Idea.


Here comes the thing which is not clear. Examine this code (perhaps an
eCos-recommended solution, is it?):
             cyg_drv_dsr_lock();
             {
                 while (!spi_bus->transfer_end)
                     cyg_drv_cond_wait(&spi_bus->transfer_cond);
             }
             cyg_drv_dsr_unlock();

spi_bus->transfer_cond is set by an interrupt. Until the operation is not finished, dsr-s are locked. Basicly the same with this solution, except CPU usage.

cyg_drv_dsr_lock();
...
while (!IsTxCompleted);	//polling
...
cyg_drv_dsr_unlock();

Note, that dsr lock and unlock is in disk.c.

I have found my answer, what is the difference between these
implementations:
http://osdir.com/ml/ecos.general/2003-03/msg00178.html
DSR locking works in a per-thread basis. So
cyg_drv_cond_wait(&spi_bus->transfer_cond); would trigger a task switch.

Thank you for your help!
Gergely Szentirmai

But in this chip the MCI interface can transfer a sector via the PDC,
so this shouldn't be necessary. You may have to start from scratch and write
a better MCI driver that uses DMA and an interrupt at the end.

It do use it.



--


Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]