mornin' all..
A design change has left me with a requirement to use an SD card with
the SPI interface on my LPC2129. This interface has no FIFO buffer
and a high transfer rate, (well, can be, anyway). To implement the
interface, I need to read/write 512-byte sectors. I have a couple of
problems.
All my comms IRQ interrupts have no nesting. I have only one buffer
supply queue into all these interrupts and one out. These queues are
not safely interruptible: I cannot re-enable IRQ interrupts in the
these interrupt handlers. I suspect that the run time of these
handlers may cause a data overrun if an IRQ was used for the SPI at
high speed.
AFAIK, a FIQ could handle the SPI interrupt as it has a separate
enable flag and could interrupt an IRQ handler even if IRQ was left
disabled in the handler, read/write the SPI and, as long as it does
not use my buffer queues, it should work OK? I'm a bit worried by all
this since the Crossworks docs suggest that FIQ is not supported :(
Even if I got an FIQ handler to work with the SPI, how could I let the
rest of my app know that a sector read/write is complete? How can I
post a ctl semaphore unit from FIQ space, (guessing can't)?
Any help or ideas, anyone?
Rgds,
Martin
Crossworks, C++, SPI, FIQ
Started by ●June 18, 2008
Reply by ●June 18, 20082008-06-18
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of mjames_doveridge
> Sent: Tuesday, June 17, 2008 11:29 PM
> To: l...
> Subject: [lpc2000] Crossworks, C++, SPI, FIQ
> mornin' all..
>
> A design change has left me with a requirement to use an SD card with
> the SPI interface on my LPC2129. This interface has no FIFO buffer
> and a high transfer rate, (well, can be, anyway). To implement the
> interface, I need to read/write 512-byte sectors. I have a couple of
> problems.
>
> All my comms IRQ interrupts have no nesting. I have only one buffer
> supply queue into all these interrupts and one out. These queues are
> not safely interruptible: I cannot re-enable IRQ interrupts in the
> these interrupt handlers. I suspect that the run time of these
> handlers may cause a data overrun if an IRQ was used for the SPI at
> high speed.
>
> AFAIK, a FIQ could handle the SPI interrupt as it has a separate
> enable flag and could interrupt an IRQ handler even if IRQ was left
> disabled in the handler, read/write the SPI and, as long as it does
> not use my buffer queues, it should work OK? I'm a bit worried by all
> this since the Crossworks docs suggest that FIQ is not supported :(
>
> Even if I got an FIQ handler to work with the SPI, how could I let the
> rest of my app know that a sector read/write is complete? How can I
> post a ctl semaphore unit from FIQ space, (guessing can't)?
>
> Any help or ideas, anyone?
>
> Rgds,
> Martin
>
Usually, with a fast SD card, the read or write of 512 bytes can be done
in around 500us (minus the wait for the write to actually complete).
Could you not just do this in a polled loop? This is how most of the
filesystems I have looked at handle it.
Without a FIFO, you may find it difficult to reach the full bandwidth of the
SPI port, unless you code the routine in assembler. Use 16 bit transfers
if possible, as this helps a great deal.
I have used the EFSL filesystem with success, and other members on this list
have suggested other options that work well, if you don't want to roll
your own.
Good luck,
Mike Anton
> From: l...
> [mailto:l...]On Behalf
> Of mjames_doveridge
> Sent: Tuesday, June 17, 2008 11:29 PM
> To: l...
> Subject: [lpc2000] Crossworks, C++, SPI, FIQ
> mornin' all..
>
> A design change has left me with a requirement to use an SD card with
> the SPI interface on my LPC2129. This interface has no FIFO buffer
> and a high transfer rate, (well, can be, anyway). To implement the
> interface, I need to read/write 512-byte sectors. I have a couple of
> problems.
>
> All my comms IRQ interrupts have no nesting. I have only one buffer
> supply queue into all these interrupts and one out. These queues are
> not safely interruptible: I cannot re-enable IRQ interrupts in the
> these interrupt handlers. I suspect that the run time of these
> handlers may cause a data overrun if an IRQ was used for the SPI at
> high speed.
>
> AFAIK, a FIQ could handle the SPI interrupt as it has a separate
> enable flag and could interrupt an IRQ handler even if IRQ was left
> disabled in the handler, read/write the SPI and, as long as it does
> not use my buffer queues, it should work OK? I'm a bit worried by all
> this since the Crossworks docs suggest that FIQ is not supported :(
>
> Even if I got an FIQ handler to work with the SPI, how could I let the
> rest of my app know that a sector read/write is complete? How can I
> post a ctl semaphore unit from FIQ space, (guessing can't)?
>
> Any help or ideas, anyone?
>
> Rgds,
> Martin
>
Usually, with a fast SD card, the read or write of 512 bytes can be done
in around 500us (minus the wait for the write to actually complete).
Could you not just do this in a polled loop? This is how most of the
filesystems I have looked at handle it.
Without a FIFO, you may find it difficult to reach the full bandwidth of the
SPI port, unless you code the routine in assembler. Use 16 bit transfers
if possible, as this helps a great deal.
I have used the EFSL filesystem with success, and other members on this list
have suggested other options that work well, if you don't want to roll
your own.
Good luck,
Mike Anton
Reply by ●June 18, 20082008-06-18
On Wed, 18 Jun 2008 05:28:51 -0000, you wrote:
>mornin' all..
>
>A design change has left me with a requirement to use an SD card with
>the SPI interface on my LPC2129. This interface has no FIFO buffer
>and a high transfer rate, (well, can be, anyway). To implement the
>interface, I need to read/write 512-byte sectors. I have a couple of
>problems.
>
>All my comms IRQ interrupts have no nesting. I have only one buffer
>supply queue into all these interrupts and one out. These queues are
>not safely interruptible: I cannot re-enable IRQ interrupts in the
>these interrupt handlers. I suspect that the run time of these
>handlers may cause a data overrun if an IRQ was used for the SPI at
>high speed.
>
>AFAIK, a FIQ could handle the SPI interrupt as it has a separate
>enable flag and could interrupt an IRQ handler even if IRQ was left
>disabled in the handler, read/write the SPI and, as long as it does
>not use my buffer queues, it should work OK? I'm a bit worried by all
>this since the Crossworks docs suggest that FIQ is not supported :(
>
>Even if I got an FIQ handler to work with the SPI, how could I let the
>rest of my app know that a sector read/write is complete? How can I
>post a ctl semaphore unit from FIQ space, (guessing can't)?
>
>Any help or ideas, anyone?
>
>Rgds,
>Martin
How important is transfer speed?
Remember that as an SPI master, a byte only comes in when you send the clocks, so you could do it
polled with no interrupts at all with no risk of data overrun.
>mornin' all..
>
>A design change has left me with a requirement to use an SD card with
>the SPI interface on my LPC2129. This interface has no FIFO buffer
>and a high transfer rate, (well, can be, anyway). To implement the
>interface, I need to read/write 512-byte sectors. I have a couple of
>problems.
>
>All my comms IRQ interrupts have no nesting. I have only one buffer
>supply queue into all these interrupts and one out. These queues are
>not safely interruptible: I cannot re-enable IRQ interrupts in the
>these interrupt handlers. I suspect that the run time of these
>handlers may cause a data overrun if an IRQ was used for the SPI at
>high speed.
>
>AFAIK, a FIQ could handle the SPI interrupt as it has a separate
>enable flag and could interrupt an IRQ handler even if IRQ was left
>disabled in the handler, read/write the SPI and, as long as it does
>not use my buffer queues, it should work OK? I'm a bit worried by all
>this since the Crossworks docs suggest that FIQ is not supported :(
>
>Even if I got an FIQ handler to work with the SPI, how could I let the
>rest of my app know that a sector read/write is complete? How can I
>post a ctl semaphore unit from FIQ space, (guessing can't)?
>
>Any help or ideas, anyone?
>
>Rgds,
>Martin
How important is transfer speed?
Remember that as an SPI master, a byte only comes in when you send the clocks, so you could do it
polled with no interrupts at all with no risk of data overrun.
Reply by ●June 18, 20082008-06-18
Hi Martin,
CTL doesn't touch the FIQ so it's all yours to play with - I can send
you simple example if you want one. Other customers have set an IRQ
from the FIQ handler to sync with the main application.
Regards
Michael
>
> mornin' all..
>
> A design change has left me with a requirement to use an SD card with
> the SPI interface on my LPC2129. This interface has no FIFO buffer
> and a high transfer rate, (well, can be, anyway). To implement the
> interface, I need to read/write 512-byte sectors. I have a couple of
> problems.
>
> All my comms IRQ interrupts have no nesting. I have only one buffer
> supply queue into all these interrupts and one out. These queues are
> not safely interruptible: I cannot re-enable IRQ interrupts in the
> these interrupt handlers. I suspect that the run time of these
> handlers may cause a data overrun if an IRQ was used for the SPI at
> high speed.
>
> AFAIK, a FIQ could handle the SPI interrupt as it has a separate
> enable flag and could interrupt an IRQ handler even if IRQ was left
> disabled in the handler, read/write the SPI and, as long as it does
> not use my buffer queues, it should work OK? I'm a bit worried by all
> this since the Crossworks docs suggest that FIQ is not supported :(
>
> Even if I got an FIQ handler to work with the SPI, how could I let the
> rest of my app know that a sector read/write is complete? How can I
> post a ctl semaphore unit from FIQ space, (guessing can't)?
>
> Any help or ideas, anyone?
>
> Rgds,
> Martin
>
CTL doesn't touch the FIQ so it's all yours to play with - I can send
you simple example if you want one. Other customers have set an IRQ
from the FIQ handler to sync with the main application.
Regards
Michael
>
> mornin' all..
>
> A design change has left me with a requirement to use an SD card with
> the SPI interface on my LPC2129. This interface has no FIFO buffer
> and a high transfer rate, (well, can be, anyway). To implement the
> interface, I need to read/write 512-byte sectors. I have a couple of
> problems.
>
> All my comms IRQ interrupts have no nesting. I have only one buffer
> supply queue into all these interrupts and one out. These queues are
> not safely interruptible: I cannot re-enable IRQ interrupts in the
> these interrupt handlers. I suspect that the run time of these
> handlers may cause a data overrun if an IRQ was used for the SPI at
> high speed.
>
> AFAIK, a FIQ could handle the SPI interrupt as it has a separate
> enable flag and could interrupt an IRQ handler even if IRQ was left
> disabled in the handler, read/write the SPI and, as long as it does
> not use my buffer queues, it should work OK? I'm a bit worried by all
> this since the Crossworks docs suggest that FIQ is not supported :(
>
> Even if I got an FIQ handler to work with the SPI, how could I let the
> rest of my app know that a sector read/write is complete? How can I
> post a ctl semaphore unit from FIQ space, (guessing can't)?
>
> Any help or ideas, anyone?
>
> Rgds,
> Martin
>
Reply by ●June 18, 20082008-06-18
> How important is transfer speed?
Not greatly important. Not max. spped will be OK
> Remember that as an SPI master, a byte only comes in when you send
the clocks, so you could do it
> polled with no interrupts at all with no risk of data overrun.
I guess I could poll the SPI status, yes. The snag is that this
polling can, and will, be interrupted by other handlers. I'm not sure
of the implications of this. I guess that the SPI interface will not
send clocks if there is no data to exchange, so I should be OK?
Rgds,
Martin
Not greatly important. Not max. spped will be OK
> Remember that as an SPI master, a byte only comes in when you send
the clocks, so you could do it
> polled with no interrupts at all with no risk of data overrun.
I guess I could poll the SPI status, yes. The snag is that this
polling can, and will, be interrupted by other handlers. I'm not sure
of the implications of this. I guess that the SPI interface will not
send clocks if there is no data to exchange, so I should be OK?
Rgds,
Martin
Reply by ●June 18, 20082008-06-18
An example of two of FIQ would be appeciated, yes indeed.
I could poll the SPI, as suggested by other posters. I'm not sure
what to do. I suspect that an FIQ. if kept short, whould lose fewer
cycles overall than polling the status register. It's still all very
wasteful since, no matter how I do it, a lot of work has to go into
retrieving a single byte from the SPI :(
I do not know how to fire an IRQ from an FIQ. The stack/registers are
different in these states? If I had spare pins, I guess I could bodge
it in hardware by connecting a GPIO pin to an external interrupt
Perhaps I could do it by fiddling with match registers or something to
fire a timer interrupt. This sounds like a bodge as well..
Rgds,
Martin
I could poll the SPI, as suggested by other posters. I'm not sure
what to do. I suspect that an FIQ. if kept short, whould lose fewer
cycles overall than polling the status register. It's still all very
wasteful since, no matter how I do it, a lot of work has to go into
retrieving a single byte from the SPI :(
I do not know how to fire an IRQ from an FIQ. The stack/registers are
different in these states? If I had spare pins, I guess I could bodge
it in hardware by connecting a GPIO pin to an external interrupt
Perhaps I could do it by fiddling with match registers or something to
fire a timer interrupt. This sounds like a bodge as well..
Rgds,
Martin
Reply by ●June 18, 20082008-06-18
Hi,
mjames_doveridge wrote:
>> Remember that as an SPI master, a byte only comes in when you send
>>
> the clocks, so you could do it
>
>> polled with no interrupts at all with no risk of data overrun.
>>
>
> I guess I could poll the SPI status, yes. The snag is that this
> polling can, and will, be interrupted by other handlers. I'm not sure
> of the implications of this. I guess that the SPI interface will not
> send clocks if there is no data to exchange, so I should be OK?
>
> Rgds,
> Martin
>
The SPI is only clocking the bus if you send some data. So to be able to
receive you need to send something (all zeros, all 0xff or something
like). So if the interrupt delays your loop, there is no problem. The
only thing you loose is speed.
Foltos
mjames_doveridge wrote:
>> Remember that as an SPI master, a byte only comes in when you send
>>
> the clocks, so you could do it
>
>> polled with no interrupts at all with no risk of data overrun.
>>
>
> I guess I could poll the SPI status, yes. The snag is that this
> polling can, and will, be interrupted by other handlers. I'm not sure
> of the implications of this. I guess that the SPI interface will not
> send clocks if there is no data to exchange, so I should be OK?
>
> Rgds,
> Martin
>
The SPI is only clocking the bus if you send some data. So to be able to
receive you need to send something (all zeros, all 0xff or something
like). So if the interrupt delays your loop, there is no problem. The
only thing you loose is speed.
Foltos
