Re: [9fans] pcc limitation?

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

On 07.11.2010 20:42, erik quanstrom wrote:
>> In practice:
>> Right now (with incomplete support for some chips):
>> writearr: 260 bytes
>> readarr: 16777217 bytes
>>
>> In the near future (maybe 2 weeks from now):
>> writearr: 1056 bytes
>> readarr: 16777217 bytes
>>
>
> so you're saying that you have > 16777217 bytes of spi data for a single
> command in your program?

You asked for "the largest sequence of commands in practice". That's why
I assumed you wanted to know about the largest command in all environments.


> i think i'm missing something.  you couldn't
> fit that much data in 32kb of ram.
>

Correct. Please see the following quote from my mail:

>> we determine readarr size at runtime based on resource constraints.

In hosted environments with sufficient resources (e.g. Plan 9), the
largest command response can indeed be ~16 MBytes. In
resource-constrained environments we limit command+response size to 260
bytes or even less. And depending on the programmer hardware, there may
be additional constraints (e.g. commands having exactly 1,2,4 or 5 bytes
and no other lengths) regardless of available resources.

If you want to take a look at the context of the code which prompted
this mail thread, please see
http://www.flashrom.org/trac/flashrom/browser/trunk/spi25.c#L594
spi_chip_erase_c7, spi_block_erase_52 and spi_nbyte_program all use the
spi_send_multicommand interface which takes an array of struct
spi_command as parameter (submission of multiple commands at once).
spi_nbyte_read uses the spi_send_command interface which takes the
individual members of struct spi_command as parameters (submission of a
single command).
We would love to use a common interface for command submission
regardless of the number of commands being sent (and we had such an
interface in the past), but sadly some supported hardware enforces
combined commands and other hardware enforces separate commands. The
individual programmer drivers take care of translating the requests to
the format usable by the programmer hardware.

Hardware programming is fun. Side effects include nausea and vomiting.

I hope this answers your questions.

Regards,
Carl-Daniel

--
http://www.hailfinger.org/