On Fri, 2013-09-13 at 00:12 -0400, Huang Shijie wrote:
> I will send you the datasheet tomorrow.
Thanks. Although according to the date header on your email, it is
*already* tomorrow. Any chance of fixing your clock, please?
> Mark and you want to create the LUT instruction sequence at the runtime,
> But there is some disadvantage if we do so:
> [1] low efficiency:
> If you want to change the LUT regitster, you should unlock the LUT
> register, and change the LUT regitsters, and lock the LUT
> regitsters again.
Although there aren't *that* many operations we perform, so you'd quite
quickly find yourself using things which are *already* programmed into
the LUT instead of having to re-program them again, surely?
> [2] we may can not create all the LUT instruction sequence at the
> runtime. For example, the buffer program(OPCODE_PP):
> the m25p80_write() may write 256bytes at a time, but the Quadspi
> controller only has a 64-byte TX-FIFO, so the controller should
> write a 64bytes firstly, then sends to the NOR with a read-status
> command. Do you want to create a read-status LUT instruction
> sequence at run time? This is not good solution, we should
> pre-populate the read-status LUT information.
I'm not entirely sure I understand this. What *exactly* happens "on the
wire" in this case? Do you really send an OPCODE_RDSR (0x05) byte on the
wire somehow, when you're supposed to be in the middle of sending the
page data to the chip? How does the chip handle that?
> [3] We may can not create the LUT instruction sequence at the runtime,
> since we can not get enough information from the spi_transfer{}.
> A whole LUT instruction sequence may needs the following info:
> 1.) spi command.
> 2.) lines info: single line, dual lines, quad lines.
> 3.) Address width: 3 bytes address or 4 bytes address.
> 4.) instruction type: Read or write or other.
> 5.) length info: how many bytes for this transaction .
> 6.) dummy info: how many dummy is needed for this transaction.
>
> We can not get the dummy info from the spi_transfer{}
Again, what does that actually *mean*, on the wire?
I thought SPI was just 'send some bytes, fetch some bytes'. Why is the
controller doing anything other than that?
--
dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
