Photon, TCA9548A, multiple i2c SSD1306's (the cheap ones)

General
21

@peekay123 So, I actually did set them all to -1, I just didn’t set a variable to do it ( display0(-1); display1(-1); etc).

@ScruffR I actually am using that library, (where you see Adafruit_SSD1306_JJ, its actually the same, at the time for some reason, either from ignorance or some other reason, I couldn’t find that lib or I’m not sure what, but I had attempted to upload the library from the CLI to my project and kept getting issues with it complaining about me not being the owner - why that mattered when uploading it to a private project I’m not sure, but I ended up going through and changing every instance of _RK to _JJ and it finally let me do it… of course then I forgot I had done this and ended up just copying everything out of RK’s into ‘tabs’ associated with the project I’m running now.

That probably sounded a lot more confusing than it needed to be - point being, I’m using RK’s lib in all instances, but had gone back to the Adafruit lib (from Adafruit) to look at differences and see if I could understand what/why some of the changes were present.

To the bit about the hex value being passed to switchvcc - ok, I can accept that 0x3C is 60 (though historically - granted I’m used to the Arduino IDE - when I’ve done that, I get some error or a warning about converting data types without some ‘method’ or another). My question was more that why is any value other than the values its expecting not causing it to barf? In the header I see:

#define SSD1306_EXTERNALVCC 0x1
#define SSD1306_SWITCHCAPVCC 0x2

Though now that I’m looking a bit deeper, I see that it doesn’t appear to care what the value is if it’s not EXTERNALVCC as its not an else if, its just an else, so I think I answered my own question there… which now that I’m actually waking up, I can see you (@peekay123) already mentioned :stuck_out_tongue:

Unfortunately I don’t have anything with a 0x3D address anymore so I can’t test that again, but I’m pretty sure I tried giving it what you suggested early on in my testing:

display0.begin(SSD1306_SWITCHCAPVCC, 0x3C);
display1.begin(SSD1306_SWITCHCAPVCC, 0x3D);

Which should have worked… right? I was fairly certain I’d tested all that was suggested I test, but maybe I missed something. If I get my hands on another display, I’ll change the address I’ll try again, though I don’t think it’ll be any time soon.

I made this more complicated than it needed to be didn’t I… I’m pretty good at that… :slight_smile:

22

You should be able to use the library independent of ownership, but sure thing you can't upload a library with a name already in use by someone else - the library management wouldn't know which of the two versions you want to import.

You don't upload a library to a project, you upload a lib into the Particle Libraries Repository from where you can import it into your project - hence the need for unique names. Private libraries are just hidden from others but still need to be keept uniquely named in order to allow for eventually publishing it.

I'm not sure whether your recollection might play you some tricks :wink:
Arduino IDE behaves just the same but there might have been other reasons that caused such message just creating the impression it was a uint8_t vs. hex value issue (e.g. signed/unsigned or range conflict, "incompatible" implicit type conversion, ...)