I2C Wire.endTransmission() method freezes

[jacobComp]

I use ATTiny 414 and I try to communicate with I2C protocol but program freezes on endTransmission() method. I call this method with no parameters.

[SpenceKonde]

Please provide code for both the devices involved in order for this to be debugged. Also I need to know which version you are using because the head is very different from last release currently.

[jacobComp]

include

void setup() { Serial.begin(115200); Wire.begin(); Serial.println("Started..."); }

byte x = 0;

void loop() { Serial.println("Debug 1"); Wire.beginTransmission(4); // transmit to device #4 Serial.println("Debug 2"); Wire.write("x is "); // sends five bytes Wire.write(x); // sends one byte
Wire.endTransmission(); // stop transmitting Serial.println("Debug 3"); Serial.println(x); x++; delay(2000); }

I wrote simply debug String to COMPort, this code gives Started... , Debug1, Debug2 Writing Wire.end() gives Debug3 too but I need return message to get action Thank you.

[jacobComp]

I think I solved it via enable Internal Pull-up resistor of I2C pins Edit: For Attiny414 in setup() method PORTB.PIN0CTRL = PIN3_bm; // Enables internal pull-up of SCL PORTB.PIN1CTRL = PIN3_bm; // Enables internal pull-up of SDA

[Modac]

Are you using external pullups?

[jacobComp]

Are you using external pullups?

No, hardware design team did not place external pull-up, I realise it after open this issue

[SpenceKonde]

As documented in both Wire.h and the main readme, external pullups are mandatory.The Readme for the version of Wire.h in this core is extensive and detailed.

The total value of the pullups required depends on the capacitance of the bus (contributed by wires and device pins) thoughthe range that actually works is quite wide.... but it actually effects the speed of data transfer because on the modern AVRs, the I2C master won't start timing a high until the pin is actually high! There's more detail in the readme, but basically that's why the SCL clock frequency you can set through wire.h is only approximate, and weak pullups degrade performance until you hit the point where the internal counter overflows and it decides that the pins shorted to ground and gives up.

We provide a method for debugging only to turn on the internal ones, but they are less than 1 third the strength required by the standard and just on the edge of working, an state (in boldface text as I recall) that it UsePullups() should be used only for debugging and if it fixes any issue there is a problem with your external ones. Such as them not existing.

This has always been the case on AVRs, classics too - and basically every microcontroller, because nobody puts pullups strong enough to meet I2C specs. But the Arduino team would prefer to lie to you and pretend you didn't need external ones, resulting in a system that works with one or two devices and short wires and craps out in more complex scenarios with intermittent results. That's bad - if something is connected incorrectly, you don't want it's functioning to depend on whether you put your hand on the outside of the insulated wire or use 2 devices or 1, because then you won't figure out what the problem is for weeks - you want it to fail every time so you know there's a problem and that you've fixed it when you correct it.

I think the Wire.h readme (in this core, not the excuse for documentation on arduino's website) actually has either a table or an equation or both, which I spent a considerable amount of time digging up information on. As you may have noticed the I2C folks seemed to think they'd found a formula to turn lead into gold when they'd designed a mediocre open drain databus (which is better than the other kind of open drain databus, a shitty one. A truly good open drain databus is not possible in our universe, which is why I2C fast mode+ caps out at 1 Mbps, but people run SPI at 80 MHz all the time (they also use "QIO" on a lot of those devices - so rather than being 80x faster, if the host supports QIO (AVR doesn't) you can get 320x the speed vs I2C or more, I don;t even think 80 is the maximum. This is why there are SPI flash chips with sizes measured in GBits, and at most 512kbyte I2C EEPROMS in the same size SOIC8 package).

(end of portion of response that is relevant or useful to you or really anyone else)

The multiverse interpretation of string theory implies that there exist an infinite number of universes where an excellent open drain bus would be possible, far better than what we can pull off here. But I wouldn't try to visit them for design tips though; the physics is pretty convincing that we can't travel to them, which is a good thing because as we crossed the boundary between the universes, the ground state of the particles of which our bodies are composed would change, with the most likely result being that we would be transformed into novel forms of matter and radiation, some of which does not even exist in our physics, turning your multiversal business trip into an event that would make the Tsar Bomba look like a firecracker. And lord save us if you materialized on an inhabited planet on the other side, because those aliens would rightly interpret it as an act of war and be justified in exterminating our species and transforming our solar system's entire mass energy into high energy radiation, simply as self defense. Luckily, as I said, physics is pretty unambiguous that travel to other bubbles of the multiverse is impossible (even the best hope - one most physicists think is impossible - of exceeding light speed in our own universe involves utilizing amounts of energy on the scale of the rest mass of jupiter, so us Karadashev <2 civilizations don't have to worry about causing an interuniversal war, only about some other species doing so and getting caught in the shock wave. Or being hit by an asteroid, our star colliding with a black hole, destroying ourselves via nuclear war, or slow-cooking ourselves by climate change, you know, the usual threats to a species). and we don't understand string theory well enough to even know whether there exists a universe where high performance open drain data buses are possible. Which all is good news, because the last thing I want is be have our universe annihilated because someone wanted their I2C bus to run faster

[InstantMuffin]

Arduino world really wrongly tells you with subtlety that you don't need any pullups when using I2C, and it almost gave me the impression that arduinos are superior in that way to other microcontroller (systems). Arduinos are a somewhat great start to get into the topic, but the community also teaches you a lot of wrong things, and often outdated accessories are rebranded into arduino-friendly devices, for example the LN298.

[SpenceKonde]

@InstantMuffin that's because the most important employee at Arduino is the one who goes around and waters the rest of them twice a week.

As for the obsolete parts, that's ubiquitous in hobby electronics because designs from the dawn of the field get repeated by people who are lucky to guess which end of the soldering iron to pick up in two tries, but are real good at writing books that make them sound like they know their stuff.

Edit I can recommend a really good rigorous book on electronics, very well written, and the guy is sharper than a razor. I managed to get halfway into the first chapter before it became overwhelmingly difficult material. If you've got a kid going into EE or ECE and picking a college (because if that's the textbook they use you know he or she will be getting an education in EE/ECE - not just in beer chugging (my roommate did a double major, he got a BS in BS and a BA in pot smoking; that was a fun year, or the parts of it that I can recall were) , or if you want to take the challenge, when I get back to sommerville next week, I'll get your the name and author. It is very in-depth material, and it progresses very very quickly. But it's a real serious business text book.

Not as much fun to read as my fathers highschool chem text bool (Latimir and Hilldebrandt), but that's because it's not topt ier ciollege level rigorous, but college track highschool level rigor - if you ever wonder why kids aren't iterested in school these days compare a modern chem text book with that. It was fascinating, I couldn't put it down. (and you know what? You come out of it knowing more about chemistry than you do after a modern college chem text book). they went through the elements, one by one, but they didn't just tell you the chemistry, they told you the context, how it was discovered, how it's produced, what it's used for. The times you see that in a modern textbook, 99.9% of examples are environmentalist stuff. I have no opposition to covering that kind of thing, but it should be proportional, ya know? Most chemists aren't doing environmental mitigation stuff, so if you make most of your examples about that, wouldbe chemists will be bored and be like "It's all this boring environmental work, school is boring, I'm gonna drop out get a crap job and spend my life staring at netflix and drinking beer."