I will try to write more info possible since if i help you, you can help me
I am making a small project to control a digital camera on breadboard: I am using 1 adc, 2 external interrup for a rotary encoder, some gpio, and the i2c to control a oled like this, the code is at the bottom. before moving to the breadboard i used an arduino uno and there all works perfectly
I am using the last version so 1.1.4, the package of the chip is a xu so very very smal on a breadboard adapter like this, the serial to ttl is a cp2102 board like this , the library is this i choosed it in the first place because i needed the smallest possible but really the size of the sketch is not a problem
the problem is that sometimes it freezes,i upload the sketch, it runs well and then the i2c stop working and also the upload of new code stop working. I don't have a 100% reason why i think the problem is with wire/i2c, this is more a "sensation"
Since i am going to make a first prototype pcb and i don't want to wait weeks and weeks to have it and then weeks and weeks if i made any mistake i decided to write here to discover if there is some unknown (to me) problem with my choise of resources (example: i can't use both i2c and the external interrupt in this chip or any other oddity)
if there isn't any these are the possible problems:
solder error
shitty breadboard
library of the oled
Are proper decoupling caps in place? Can you please post a schematic? I'd like to be sure it's not a hardware issue before I look at the library.
For others: ATTinyCore uses a custom version of Wire that uses either TinyWire, Wire, or SoftI2CMaster depending on the hardware available (by doing this in a Wire library, code from parts can usually be moved between parts with different I2C hardware with no code changes, and no changes to libraries to make them include a different I2C library instead of Wire - ATTinyCore/avr/libraries/Wire at OldMaster---DO-NOT-SUBMIT-PRs-here-Use-2.0.0-dev ยท SpenceKonde/ATTinyCore ยท GitHub
It is not particularly well exercised yet (only recently added) so there may be issues to be found.
in the attachments there is the schematics. it is 99% the same in the breadboard:
difference: in the breadboard there is only one decoupling cap (near the digital and not for the analog) - see edit
in the breadboard i am not using the optocoupler (it goes directly to the led)
in the breadboard the power cames from a separate supply and not from the battery
known thing missed: pull up resistor for the i2c - see edit
i am testing with the decoupling cap and the pull up right now
EDIT:
added a decoupling cap (100nF) for the analog and 2 pull up resistor (10k)
video: youtube
do you have any idea? it looks like a i2c issue, for you?
the i2c_scanner usually works ok but if i run it after the oled stop working and i get error for all the address:
..........
Unknow error at address 0x73
Unknow error at address 0x74
Unknow error at address 0x75
Unknow error at address 0x76
Unknow error at address 0x77
Unknow error at address 0x78
Unknow error at address 0x79
Unknow error at address 0x7A
Unknow error at address 0x7B
Unknow error at address 0x7C
Unknow error at address 0x7D
Unknow error at address 0x7E
No I2C devices found
Can't look at the schematic until I get home from work.
It looks like something is going wrong with I2C, but it's hard to say exactly what.
Is it connected to serial so you can get debug output? I would try: after first successful I2C interaction and after it starts misbehaving, print the values of the USI registers:
Serial.print(F("USICR:"));
Serial.println((int)USICR);
Serial.print(F("USISR:"));
Serial.println((int)USISR);
Also, what state are the I2C lines when it's unhappy? Are either of them low? if so, what is pulling it low? ie, if you disconnect that line (between OLED and pullup, leaving it connected to the attiny), does it stay low, indicating that the attiny is holding the line low? If you disconnect it between ATTiny and pullup (so it's still connected to the screen), and the line stays low, that indicates the screen is holding it down. Either way, it's useful debugging info.
yes it is connected with the serial for debuggind and uploading:
i think you would rather a binary output
I2C Scanner
USICR:101010
USISR:0
Scanning...
USICR:101010
USISR:10000
Unknow error at address 0x01
USICR:101010
USISR:110000
Unknow error at address 0x02
USICR:101010
USISR:110000
Unknow error at address 0x03
USICR:101010
USISR:110000
Unknow error at address 0x04
USICR:101010
USISR:110000
Unknow error at address 0x05
USICR:101010
USISR:110000
Unknow error at address 0x06
USICR:101010
USISR:110000
the lines are always low in all the situations so it is the tiny that brings them down
to be sure i just tried the oled with the uno and it works perfectly
i would say it is a Wire problem, do you have a t167 to test the library?
Have you done the test I described, ie, disconnecting the I2C lines from the ATTiny (leaving everything else connected) and confirming that the lines are not held low?
Have you done the test I described, ie, disconnecting the I2C lines from the ATTiny (leaving everything else connected) and confirming that the lines are not held low?
Can the problem be reproduced by a test sketch that just exercises the screen?
yes i done the test, when the oled isn't connected to the attiny sda and scl of the oled are high
when it is connected are low even with the pull up resistors!
if i disconnect everything from the t167 PB0 and PB2 are always low
right now my attiny167 is not able anymore to use the oled, the i2c_scanner doesn't work anymore, maybe the pins broke (?)
by the way, if it is a library problem soon or later it will be fixed. I am quite sure it is not a design problem, i think that i can send the gerber files to make the prototypes and see if the problem get fixed outside the breadboard. do you agree?
Sounds like a library issue. It will not be magically fixed for us - I am the one maintaining that library! (It is not the same wire as the stock core has - the support for alternate i2c hardware was added for ATTinyCore) What behavior do you see? Like does it die at the same point every time? The fact that it works at first is strange.
I didn't have a chance to look at the .sch last night (a plain old image is the preferred way to post schematics here, so we don't need special software (I often answer forums on phone, for example - I know many others do as well)
i will try to change the oled library (SSD1306), do you have any suggested library to use it throught i2c with the attiny version of Wire?
i put the image of the schematics, it is very simple just the minimum circuit + photoresistor + rotary encoder + led + optocoupler
please tell me if you see any error, i checked it 20 times so i don't think that there is a mistake but i could be always wrong
if you say me that it is ok i will order immediately a few boards and when i have them i will solder a new attiny167 so we will discover if it is a lib issue or hardware
I see no issues with that design (though I'd put a 4.7uF cap across the supply for good measure - I always put at least a small filter cap on the supply)
It's very strange indeed that it doesn't work at all anymore - does the screen work elsewhere? I would recheck for silly mistakes (loose wires, SCL/SDA swapped (I now swap them as a debugging step, same with tx/rx, since I seem to have barely better than statistical chance to get that right). This is sort of important to figure out - if the pins on the '167 have been damaged, we must have missed a hardware design flaw - you can't do that in software.
I have no experience using the SSD1306 OLED displays with Arduino, so I can't comment on what the right library is...
yes in my uno works well
tomorrow i will sent the board to be printed so in a few weeks i will have them home
then we will be sure that the problem is not in the breadboard