RE: [ECOS] Disk I/O -> scheduling problems

RE: [ECOS] Disk I/O -> scheduling problems

[Paul D. DeRocco]

> From: Szentirmai Gergely [mailto:gergely.szentirmai@axelero.hu]
>
> Paul D. DeRocco Ă­rta:
>
> >   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.
>
> 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.
>
> 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.

Since you earlier said that you poll for the result, I assume you mean here
that you use DMA but not an interrupt. If so, then all you have to do is
have a null ISR that just schedules a DSR, have the DSR signal a condition
variable, and use the same sort of code that the SPI driver uses. Then, your
MCI driver will work in a manner similar to the SPI driver, and they'll
happily interleave the initiation and completion of their respective
transfers.

--

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

Re: [ECOS] Disk I/O -> scheduling problems

[Szentirmai Gergely]

Paul D. DeRocco Ă­rta:
>> From: Szentirmai Gergely [mailto:gergely.szentirmai@axelero.hu]
>>
>> Paul D. DeRocco Ă­rta:
>>
>>>   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.
>>
>> 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.
>>
>> 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.
> 
> Since you earlier said that you poll for the result, I assume you mean here
> that you use DMA but not an interrupt. If so, then all you have to do is
> have a null ISR that just schedules a DSR, have the DSR signal a condition
> variable, and use the same sort of code that the SPI driver uses. Then, your
> MCI driver will work in a manner similar to the SPI driver, and they'll
> happily interleave the initiation and completion of their respective
> transfers.

The code polled for the completition only, the transfare is handled by 
DMA and interrupts. So I needed that SPI driver code-part in the 
function which had to block. The reason why I wrote this letter, because 
I did not know how could it work, until I found that discussion I've 
linked in. (the dsr locking per thread thing)

I have done the modification, it is working ok now!

Thanks for the help!
Gergely

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

RE: [ECOS] Disk I/O -> scheduling problems

[Paul D. DeRocco]

> 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. Does the existing MCI driver do the
entire sector transfer without using any interrupts? If that's how it works,
then, yes, the scheduler will remain locked for the duration, which is a Bad
Idea. 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.

--

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

[ECOS] Disk I/O -> scheduling problems

[Szentirmai Gergely]

Hello

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?

I have tried to unlock dsr-s (at the start of the read and write 
functiions) in my MCI driver for the lengthy operation, and it seams to 
solve my problems, the sampling is not affected by writing the card.

What are the possible effects of this "hack"?

There is some instability using the card, after a time it is unable to 
write to the card. But this can be an error in the FAT implementation 
(it corrupts the card), I need more tests. It is maybe another story.

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();

Currently the MCI does a busy wait (which is ugly, but temporary), but
if it used this mechanism, I'd still have the same problem.


Thank you!
Gergely Szentirmai



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