Am Montag, den 18.07.2011, 13:49 -0400 schrieb Mike Frysinger:
> On Sat, Jul 16, 2011 at 13:32, Andreas Pretzsch wrote:
> > The sspi command writes the given data out on SPI and prints the data it
> > reads to the console. For write-only slaves (i.e. a SPI-connected latch
> > used as output expander), this is pointless and clutters the console.
> > When called as "sspi.w", this output is omitted.
> >
> > The flag is optional and backwards compatible, previous sspi revisions
> > would simply ignore the flag (checked back to 2011.03).
>
> i think the flag is misleading. "sspi.w" makes it sound like it'd
> call the SPI layer with a NULL read buffer and not simply omit the
> output. what you describe is more like a "quiet" flag.
Correct, strictly speaking.
I chose it from a usage perspective, hence the "write", but ".q" for
quiet or similar would also have been possible. "write" just felt more
natural to me.
I also thought about passing NULL for the read buffer, but a quick
browse through the code showed that most, but not all SPI drivers are
prepared for that. And as there is already a static rx buffer in the spi
command code, I preferred to keep a few needless byte copies over fixing
all the spi drivers...
On the long run, the sspi command should be reworked anyway, as today
the read data is not usable in a script, it's just dumped to the
console.
Following the common U-Boot way to do this, I'd suggest
sspi [<bus>:]<cs>[.<mode>] <bit_len> <dout> [din_env_var]
and either never print the read result to the console (my favorite) or
only if no env variable to store is passed. To be defined, comments
welcome.
The issue here is that the current sspi command would barf due to excess
argument, hence "new" sspi usage in an env script won't work on older
U-Boot revisions, whereas this is fine with the ".w" approach.
Not really that of a problem, admittedly. Maybe I was a bit too deep in
the "don't break it if not really necessary" mode...
> along these lines, doesnt the general shell provide basic output
> redirection to support "silencing" all commands rather than having to
> add a "quiet" flag to them all ? then your script could simply do
> "sspi ... >/dev/null" (or however u-boot does it).
Not that I know of. Just tried on hush parser, no effect. Also looks
like the whole redirect code is disabled by a #ifndef __U_BOOT__.
Maybe one could change env stdout before and after, might work, but I'd
call that grotesque...
--
carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch Tel. +49-(0)731-5521572
Hahnengasse 3 Fax: +49-(0)731-5521573
89073 Ulm, Germany email: a...@cn-eng.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
