[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command
We have some instrumentation hanging on I2C bus. I would like to introduce a new u-boot command ispeed to set the i2c speed so fast devices would not be constrained to the lowest denominator speed.
If desired we can make be conditionally included if CONFIG_CMD_ISPEED (suggestions?) so it would not take space when it is not needed (or desired) on a particular board. The proposed syntax would be.
ispeed {i2c bus speed}
Since u-boot uses hex: 100kHz => 186A0, 400kHz => 61A80
I would also set an environment variable in ispeed command indicating current i2c speed ("i2cspeed") so it could be used in scripts.
Looking for your comments?
Best regards, Tolunay
Hi Tolunay,
Am Mittwoch, 3. März 2004 18:36 schrieb listmember@orkun.us:
We have some instrumentation hanging on I2C bus. I would like to introduce a new u-boot command ispeed to set the i2c speed so fast devices would not be constrained to the lowest denominator speed.
Makes sense, but why do you need measuring datas in context of a bootloader ?
If desired we can make be conditionally included if CONFIG_CMD_ISPEED (suggestions?) so it would not take space when it is not needed (or desired) on a particular board. The proposed syntax would be.
ispeed {i2c bus speed}
Since u-boot uses hex: 100kHz => 186A0, 400kHz => 61A80
Hm, I think you should expand the command syntax -- ex.:
ispeed [i2c_bus_speed_in_hz]
Without a argument 'ispeed' gets back the current setting.
With an argument 'ispeed' converts the given string to ulong and setup the new speed. The argument can be a decimal integer, because simple_strtoul() from lib_generic/vsprintf.c understands base option 10.
I would also set an environment variable in ispeed command indicating current i2c speed ("i2cspeed") so it could be used in scripts.
Is it really needed ... I don't think so. You can read back the current setting with 'ispeed' and save the result into a environment variable of your choice. So you can use it again in another or the same script.
Best Regards, Stephan Linz
Makes sense, but why do you need measuring datas in context of a bootloader ?
Well, it is not meant to be full time use. Sort of quick diagnostics and to do some random device/register access by a technician or to check the configuration, upload new config etc..
Hm, I think you should expand the command syntax -- ex.:
ispeed [i2c_bus_speed_in_hz]
Without a argument 'ispeed' gets back the current setting.
Good idea.
I would also set an environment variable in ispeed command indicating current i2c speed ("i2cspeed") so it could be used in scripts.
Is it really needed ... I don't think so. You can read back the current setting with 'ispeed' and save the result into a environment variable of your choice. So you can use it again in another or the same script.
This is probably not needed if the output can be saved in a variable in u-boot. Can you do so using standard u-boot scripting instead of hush?
I am not going to insist much on this. It seemed to be a good idea and we certainly have a case to use it here (folks here are developing an ASIC with I2C interface). It might be useful for some people to have the convenience to switch the i2c speed but I also recognized it might not be useful for everyone so I proposed to make it conditional.
Best regards, Tolunay
In message 20504.216.110.51.8.1078415909.squirrel@www.orkun.us you wrote:
Makes sense, but why do you need measuring datas in context of a bootloader ?
Well, it is not meant to be full time use. Sort of quick diagnostics and to do some random device/register access by a technician or to check the configuration, upload new config etc..
Such code should not go into the normal distribution, then. Just wrte a small standalone application for your hardware tests - there you can do whatever you want to do.
This is probably not needed if the output can be saved in a variable in u-boot. Can you do so using standard u-boot scripting instead of hush?
No, you cannot. There is no eval command in U-Boot version of hush.
convenience to switch the i2c speed but I also recognized it might not be useful for everyone so I proposed to make it conditional.
IMHO it's not even useful if made conditional. I consider it either risky (if you try to increase the I2C speed above the speed of the slowest device on the bus) or useless (if you slow down the speed without need).
Best regards,
Wolfgang Denk
In message 11176.216.110.51.8.1078335375.squirrel@www.orkun.us you wrote:
We have some instrumentation hanging on I2C bus. I would like to introduce a new u-boot command ispeed to set the i2c speed so fast devices would not be constrained to the lowest denominator speed.
I don't understand why such a command might be needed.
Just configure the I2C clock for the maximum allowable speed right from the beginning.
I would also set an environment variable in ispeed command indicating current i2c speed ("i2cspeed") so it could be used in scripts.
What is that good for? Why would you need to change speed?
Best regards,
Wolfgang Denk
Am Donnerstag, 4. März 2004 10:11 schrieb Wolfgang Denk:
What is that good for? Why would you need to change speed?
This 'could' be usefull to speed up the i2c communication if there are more than one i2c devices with significant differences between the clock timing; ex. 27C32 (100kHz@3.3V) and LM75 (400kHz). Tolunay has spoken about like this. But right I see now reason to do so, too. U-Boot has to be a boot loader not a performant operator...
Best Regards, Stephan Linz
In message 04030413332001.12732@pcj86 you wrote:
This 'could' be usefull to speed up the i2c communication if there are more than one i2c devices with significant differences between the clock timing; ex. 27C32 (100kHz@3.3V) and LM75 (400kHz). Tolunay has spoken about like this. But right I see now reason to do so, too. U-Boot has to be a boot loader not a performant operator...
Do you think it is legal to clock the I2C bus at 400 kHz when there are devices on the bus that are spec'ed only for 100 kHz? I may be wrong, but such an idea sounds awfully risky to me.
Best regards,
Wolfgang Denk
Am Donnerstag, 4. März 2004 14:21 schrieb Wolfgang Denk:
In message 04030413332001.12732@pcj86 you wrote:
This 'could' be usefull to speed up the i2c communication if there are more than one i2c devices with significant differences between the clock timing; ex. 27C32 (100kHz@3.3V) and LM75 (400kHz). Tolunay has spoken about like this. But right I see now reason to do so, too. U-Boot has to
^^^^^^^^^ OOPS, this was a small but fine typing error, should be:
" ... But right I see _NO_ reason to do so, too. ... "
(that's life)
be a boot loader not a performant operator...
Do you think it is legal to clock the I2C bus at 400 kHz when there are devices on the bus that are spec'ed only for 100 kHz? I may be wrong, but such an idea sounds awfully risky to me.
You're right, see above :-)
Best Regards, Stephan Linz
Just configure the I2C clock for the maximum allowable speed right from the beginning.
You can have 100khz and 400khz capable devices accessible to the master. You can run everything at 100khz but you will not be taking full advantange of 400khz devices.
Philips AN10216-01 (I2C Manual) Dated March 24, 2003, Page 24 describes how a system can run both 100kHz devices and 400kHz devices on the same bus and access 400kHz devices at 400kHz using I2C bus repeater such as PCA9515.
I understand this might not be useful for everyone so that is why I proposed to make it an optional command that is compiled in only if CONFIG_I2C_ISPEED is defined.
Best regards, Tolunay
In message 20641.216.110.51.8.1078416617.squirrel@www.orkun.us you wrote:
Just configure the I2C clock for the maximum allowable speed right from the beginning.
You can have 100khz and 400khz capable devices accessible to the master. You can run everything at 100khz but you will not be taking full advantange of 400khz devices.
Rigth. But on such a system you cannot run the bus at 400 kHz as this would be out of spec for the 100 kHz devices.
Philips AN10216-01 (I2C Manual) Dated March 24, 2003, Page 24 describes how a system can run both 100kHz devices and 400kHz devices on the same bus and access 400kHz devices at 400kHz using I2C bus repeater such as PCA9515.
I understand this might not be useful for everyone so that is why I proposed to make it an optional command that is compiled in only if CONFIG_I2C_ISPEED is defined.
I don't think this is useful.
What exactly are you trying to do that the speed makes any difference for you? Remember, this is a boot loader, not an operating system.
Best regards,
Wolfgang Denk
participants (3)
-
listmember＠orkun.us -
Stephan Linz -
Wolfgang Denk