This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Disk I/O -> scheduling problems]
- From: Szentirmai Gergely <reg at t-online dot hu>
- To: eCos Discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 01 May 2009 01:43:05 +0200
- Subject: Re: [ECOS] 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