Re: SPI and polling transfer

Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org>
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Message-ID <[email protected]>
>>>>> "kontais@aliyun" == kontais@aliyun com <kontais-Dw/[email protected]> writes:

    kontais@aliyun> Hi, /* Dump guess for the numbers of cycles where a
    kontais@aliyun> schedule make sense*/ #define SCHEDULE_CYCLES (1<<10)

    kontais@aliyun> #if SPIBUS_MODE == DMA_MODE /* Let's assume about 1000
    kontais@aliyun> CPU clocks is break even where a DMA transfer is faster
    kontais@aliyun> than pure polling */ if (xlen * clk_ratio >
    kontais@aliyun> SCHEDULE_CYCLES/8) {
    kontais@aliyun> ------> can you tell me what does
    kontais@aliyun> this line means , I don't understand

Before Rev. 6040 there was some big chance that an interrupt posted an event
but the scheduler went to sleep despite the pending event. Only with the
next timer tick work resumed. My device was using many small SPI transfers
and some large transfers, and on the Logic analyser I could see periods
of inactivity after a SPI transfer was done _and_ the user programm
still had SPI transfers to send. This behaviour slowed down program execution
substantial.

The only way the driver could work around these delays was to use polling
transfer for these small transfers. The code above was to use POLLING mode
for small transfers even with DMA/IRQ enabled. DMA/IRQ still is usefull for
large transfers or with small transfers at low SPI baudrate with regard to
the CPU frequency (clk_ratio).

With the fix from Rev. 6040 this workaround may or may not be usefull any
longer. WaitforEvent event with the event already posted enters the
scheduler and will run pending thread with the same or higher priority
first. When giving the SPI thread the right priority however, the workaround
is not usefull.

I have a STM32 SPI implementation in the workqueue that uses only common
code for all devices. This driver will no longer support polling mode and
doesn't do the doubtfull heuristic above.

Bye
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.