I2C Error? I2C Config incomplete type

#1

So I'm using a small I2C display and I have gotten it to work before but since updating firmware it hasn't been connecting, even when using the help patch. I get these errors:

C:\Users\minus\DOCUME~1\AXOLOT~1.0/build/xpatch.cpp:135:24: error: variable 'const I2CConfig i2cfg' has initializer but incomplete type

C:\Users\minus\DOCUME~1\AXOLOT~1.0/build/xpatch.cpp:136:5: error: 'OPMODE_I2C' was not declared in this scope

C:\Users\minus\DOCUME~1\AXOLOT~1.0/build/xpatch.cpp:138:5: error: 'FAST_DUTY_CYCLE_2' was not declared in this scope

Any help would be greatly appreciated because I am not too well versed in the coding aspect of axoloti. Looking at other topics in the forum I quickly got confused with what they were talking about and if I was even experiencing the same problem.

#2

updating firmware ?are you using axoloti 2.0 by any chance? i2c is well proven on 1.x that's why i am asking. and afaik 2.0 is still a little rough around the edges so that miight be a direction to look in.

what kind of display are you using? theres great objects for the very common SSD1306/1309 and SH1106 OLEDs courtesy of @SmashedTransistors

#3

I have been using those objects, it didn't really work before 2.0 either. It would give me the ping waitsync, but I figured that was a loose wire or something, I only got it to work with the original firmware and seemingly nothing would have changed it but I still can't get it wor.king

#4

What OLED object do you use ?
Do you use the tiar/HW/OLED128x64nice version ?

#5

I tried a few, First I used tiar/HW/OLED128x64nice then I tried the non nice one with and without the scope. All got the same error message

#6

Can you try to make a patch with gpio/i2c/config alone
and run it.

Yes, it won't do nothing but it should compile and run nevertheless like so:

i2cConfig.PNG1044x616 45.4 KB

#7

I just tried it with just the gpio config and got the same error.

#8

what would cause it to not work with just the gpio/i2c/config object?

#9

If you are getting an error during compile, using only gpio/i2c/config , it means the object's code is not written in a way that is compatible with the 2.0 Axoloti installation.

Seriously - 2.0 is not ready for general use, and definitely not ready for use by somebody who doesn't understand much about programming.

So, if you want the best chance of things working, do not use 2.0.

#10

did not know this, thanks for the advice, I'll be downgrading firmware now...

#11

I did not experiment with 2.0 yet as i see only regressions for the features i need for my current projects.

I understand it is quite a deep modification of the software architecture that already allows live code loading of a part of a patch (for ex live reloading of the effect section of a synth) and usage of flash ram for the factory objects (leaving more RAM for other stuff).

#12

I did enjoy the improvements of the 2.0 software but I really wanted this screen to work so I downgraded. However, now I'm getting an issue of the I2C screen getting stuck when changing patches, requiring a full restart of the axoloti to get it to work again. This only occurs when changing patches and happens almost every time.

#13

Interesting. I probably don't have any help to offer, but I wonder what you mean by changing patches.

Changing patches from in Axoloti Patcher, or from within a patch?

#14

From a patch, the problem happens when changing from the patcher too. I use the patch/load object which, works fine except for the screen freezing issue.

#15

Interesting, I wonder if anybody else using an I2C OLED has seen this, and found a solution?

#16

i switch patches via patchbank and program change messages and have an OLED attached. i never had any issues. also loading patches from the patcher never freezes the OLED

#17

I noticed that switching patches do freeze the screen only when you do not have any screen related objects in the loaded patch. When all my patches have all the correct oled objects, it does not freeze.
I also had a lot of trouble in the beginning with my screen freezing but that was probably due to lose wiring, grounds being badly connected because it went away when I encased my circuit in a new housing.

#18

that is to be expected since the last buffer stays in the display if it is not being updated.

#19

IF it's really only an issue of the screen retaining the previous data, I would try modifiying the OLED 'dispose code' to clear the screen when a patch exits.

#20

it is (in my case). i can switch from a patch with the OLED object to one without and back again and the OLED starts working again. and it will always freeze at the last buffer that was input.