This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001397] I2C driver for Kinetis microcontrollers


Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397

--- Comment #52 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2185
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2185&action=edit
Best fit aggressive clocking (incremantal).

(In reply to comment #51)
> I tested the patches at different frequencies using code like this:
> 
> 
>     cyg_i2c_device device = {                        \
>             .i2c_bus        = &cyg_i2c0_bus,		 \
>             .i2c_address    = 0x0C,               	\
>             .i2c_flags      = 0,                     \
>             .i2c_delay      = i2c_bus_time           \
>         };
> 
> It works at 100/400Khz properly. The there is more error in the frequency
> than some end users will want.  It seems to run about 10% too slow.

The frequency divider calculator is conservative, if exact frequency is not
available, it will pick the previous (lower) frequency. Since there are more
such combinations, in the CDL you can select up to which FIT to look, (takes
more time). It will still be lower or equal, but may be closer. If it is
permissible, here is a (non tested) incremental patch with somewhat aggressive
approach, it will pick the closest frequency even if it overclocks. We can give
user a chance to (dis)allow aggressive clocking by means of CDL.

Please advise.

> 
> In the CDL "SMB register options" is misspelled. register is missing an r.
> 
Thanks, I'll fix.


> I don't have means at the moment to test SMB options. I suggest this is
> tested after releasing this code. When the STM32 I2C is in a similar state
> to this code, I can build hardware that supports built in ALERTB processing
> for both processors and test the SMB support. The current patches seem
> adequate for I2C and work fine with my large application.

I agree, then I would remove SMB CDL from current release since it may be
misleading.

> 
> I would like to test default clock speed, meaning the frequency in the CDL.
> How do I write code that uses the default rather than .i2c_delay. Yes, I am
> being lazy and not digging into the code.

I don't think that there's such option, I guess the idea is that every device
on the bus has it's own clocking requirement. Frankly I don't know what is it
for.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]