Why in Atmega32 i2c is supported with slew rate limited tri state buffer while in other protocols of transmission is Spi and Uart doesn't exist and also the spike suppressor?
I am living to bring up new earth ,and not to eat and destroy earth.
The slew-rate limiter and spike suppressor
are part of the TWI implementation. I don't
believe they are enabled unless TWEN is set.
You missed the recent discussion regarding whether it was required to put the pullup resistors at the end of the i2c bus.
Slew rate limiting as i2c is a relatively slow bus, and low slew rates help to avoid EMC and signal integrity issues. Similarly with the glitch filter, fast pulses should not occur on the i2c bus, so filtering them avoids potential problems.
There’s an old analog maxim - never have more bandwidth than what you actually need. Similarly in the digital world, if you’re expecting slow signals, don’t accept fast ones. Example is pushbutton switches on interrupts - the human operating the pushbutton is unlikely to press it more than 50 times per second (usually much less than that), so why connect it to an interrupt that will respond to sub microsecond pulses? You’d be asking for trouble.
You missed the recent discussion regarding whether it was required to put the pullup resistors at the end of the I2c bus. .
I think the cause of putting the pull up resistors at the end of the I2c bus is to decrease also the slew rate.
Slew rate limiting as I2c is a relatively slow bus, and low slew rates help to avoid EMC and signal integrity issues. .
You mean the frequency of transmission is slow or you mean the rise time of the pulse required to be slow could you explain more please about I2c is a relatively slow bus ?
I have another question why while googling this subject, i found that in another micro controller and device the I2c slew rate limiter is optional you can set or reset , and also i found that exist in SPI
1. Where you put the resistors would have next to no impact on slew rate.
2. Transmission is slow ie 100 to 400kHz. As i said, slew rate is limited for EMC and signal integrity.
3. Similar reasons for spi. Note i2c is open collector vs spi being push/pull. On some of the TI and Freescale micros you have settings for port pin drive strength. Others have similar features. This is to trade off speed vs EMC / signal integrity issues.
One problem i experienced was i used a level translator ic to convert 3V logic to 5V logic to drive a LCD. During EMC testing it was found the display radiated at around 100MHz. Whilst the data rate was low, the slew rate due to the level translators was very high. I added series resistors to slow it down. Problem solved.
I believe that early I2C specifications required slew rate limiting. And, if memory is correct (it might not be) such slew rate limit circuits were a standard part of original I2C hardware.
When I reviewed the current I2C standard published by NXP for the other thread that was referenced, above, there is currently no such limit. The spec allows such slow rise and fall times but it does not require it.
If this assessment is correct, then the slew rate limit in Mega32 is a kind of "fossil". That is, it is there because the standard used to require it, but that requirement is no longer in place, so there is little need for that capability. You can still use it for standard speed but it is not required.
Until Black Lives Matter, we do not have "All Lives Matter"!
the slew rate limit in Mega32 is a kind of "fossil".
the slew rate limit in Mega32 is a kind of "fossil".
No, the ATmega328 has slew-rate limiters
I should stay out of this...
I would think another consideration is the hardware.
If one has a short physical bus with limited devices, then there will be little bus capacitance to intrinsically limit the signal transition slew rate.
One could then turn on slew rate limiting to slow down the edges.
If one had a physically large bus, and lots of devices, and lots of intrinsic capacitance within the hardware, then the additional, added, slew rate limiting would not be needed.
DocJC is MOSTLY correct.
For open drain devices with resistor pull-up, the rise-time is inherently slower than the fall time. An ON sink FET in an AVR GPIO pin is about 100 ohms. So, the time constant for the fall will be set by the bus capacitance and the 100 ohm FET resistance. For the rise, the pull-up is at least several hundred ohms (and, usually, a few K ohms). In that cases, the time constant is set by the same bus capacitance but a much larger pull-up resistance.
So, for NORMAL open-drain GPIO, the signal is asymmetric, with much faster fall than rise.
Slew-rate limiting uses internal feed-back to limit the dv/dt of the output pin. It works whether the signal is rising or falling. As a result, the output signal from a slew-rate limited pin tends to be much more symmetric, with the rise very similar to the fall.
These factors are true, whether the bus has a lot of capacitance or not. For a normal open-drain GPIO pin not having slew-rate limiting, the rise will be slower than the fall, just because the resistance for the rise is larger than the resistance for the fall. With slew-rate limiting, the two edges change at nearly the same rate, again, no matter what the capacitance loading of the bus.
As fare as I know slew rate limiting has always been a mandatory part of I2C specification.
Note that Atmel never used the term "I2C" and instead uses the fantasy word "twi".
M328 has slew rate limited twi, while the tiny2313 does not, and that was quite a big dissapointment for me.
I realy like the low emi of slew rate limited I2C. especially wen working with AD and DA converters, and non breadboards where signal integrity never is optimal to begin with.
Positive going flanks are usually always slew rate limited on I2C because of the passive pullup resistors, and these also limit the communication speed.
Sinking the outputs hard to GND does not change this, while adding unnessacary EMI.
Last time I read about I2C there was an "high speed" option wich works upto (I believe) 3.2Mb/s, and for that speed the slew rate limititers are disabled, but only after an agreed upon initialisation.
Slew rate limiting is usefull for EMI surpression. Slew rate limited RS-485 drivers are for example also pretty common.
With Slew-rate limited RS-485 transceivers you can often use it pretty reliable on networks even without termination resistors, while with fast RS-485 transceivers on the same bus the signal can get completely swamped in multiple echoes bouncing back and forth through the cable.
I just had a peek at:
and was surprised that the search box turned red at the 3rd letter of slew-rate, which means that there is no mention in that document of the sub string "sle".
It may be that the reduction of EMI transmission of the slew rate limited signals is less of an issue with 4-layer PCB's. When there is already lots of Multi MHz signals in the neibourhood the 2 I2C lines also do not contribute anything significant to the total EMI picture.
Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756
Bunch of old projects with AVR's: http://www.hoevendesign.com
That is exactly what I found. No mention of "slew". And, I am quite certain that there used to be. That was all before or during the addition of the two newer high speed modes. The electrical specs, for the slower speeds, only call out a MAXIMUM rise or fall time with only minimal minimum (10ns, as I recall). Clearly, the I2C/TWI world has changed while we were sleeping.
© 2022 Microchip Technology Inc.