[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Building driver for Silicon Labs CP2200 Ethernet chip
- Date: Wed, 30 Apr 2008 14:08:41 +0200
- From: arnout at mind.be (Arnout Vandecappelle)
- Subject: Building driver for Silicon Labs CP2200 Ethernet chip
Chris Johns wrote:
> Arnout Vandecappelle wrote:
>> Chris Johns wrote:
>>> Many thanks for this driver. I have a couple of questions, one of
>>> which is more generic than specific to this driver.
>>> When does a user need to use CP220X_DO_SHUTDOWN ? I cannot see any
>>> documentation about this define.
>> Oops, indeed I forgot to document that.
>> The board I was using had a hardware bug, due to which it was unable to
>> issue a reset of the CP2200 chip. Therefore, once the chip was shut
>> down it was impossible to start it again. I therefore had to remove the
>> shutdown from the driver.
>> Probably a better option would be to record this in the driver
>> configuration, so it can be set from the BSP or from the
application... However, I discovered this problem only at the last
minute, so I didn't
>> implement it that way.
>> Actually, perhaps it's best to simply remove the #ifdefs: on any
>> working board, they shouldn't be needed and shutdown should always be
>> used. Of course, I never tested that code...
> Is the shutdown needed ?
It saves 200mW; this is significant.
> Can the device be reinitialised with the driver if it needs to be ?
Yes, on condition that the board and bsp provide the possibility to
trigger the reset pin (which is not the case on my board).
> If do I would leave the the defines and add a comment at the top to
Can you add this comment?
* This option is inserted into the code because the board on which this
* was developed does not allow a reset of the chip. Resetting is the
* to exit from shutdown mode...
* Since this feature has never been tested, it remains disabled for
now. If you'd
* like to try it, enable this define in the header and make sure the bsp's
* cp220x_do_reset_hard() is properly implemented (pulling the nRST pin
* Note: without this define, the driver powers the chip down to "memory
* when the interface is brought down. Exit from memory mode is possible by
* resetting PHY, which is done when the interface is brought up.
>>> I see the driver has printf and being based on the cs8900 I am the
>>> source of this. Should we have these driver use printf or should they
>>> use printk now it exists ?
>> I'm not sure what exactly the difference is between printf and printk,
>> except that printk can be called from interrupt context. Since none of
>> the prints are from interrupt context, and since with printk my terminal
>> tended to drop newlines, I went for printf... I'm sure these are not
>> good reasons :-)
> I used printf because printk did not exist then. The reason is to
support a tiny RTEMS for small memory targets. On targets that support
printf the printk call should map to stdout.
Sounds like printk should be used then... I'm afraid I did use some
formatters which are not supported by printk, like %hhx, %*s, %<length>s.
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Mind Embedded Development (an Essensium division)