Hello,
I have a general idea of how the SS pin for SPI selects which device you're talking to. But if I'm looking at...say the SSD1306 library for controlling OLED displays, and I need to have two OLED's connected to the same Arduino, how do modify each instance of the SSD1306 so that I use the correct SS pin for that particular OLED?
starsson:
Hello,
I have a general idea of how the SS pin for SPI selects which device you're talking to. But if I'm looking at...say the SSD1306 library for controlling OLED displays, and I need to have two OLED's connected to the same Arduino, how do modify each instance of the SSD1306 so that I use the correct SS pin for that particular OLED?
Examine the library, decode how it decides which pin to activate for CS, Change the library so that It can control two different displays, one at a time.
Depending on how the library is constructed, and how much state data is need to control the display, it could be as simple as defining two Objects. Each Object would be initialized with the correct CS pin value.
You will have to look at the SSD1306 library and see how it is written.
Chuck.
Thanks Chuck. If I just have a more generalized question - it seems like some libraries embed the ss in the constructor, and some hardcode it. So if they embed it in the constructor, that's easy - I just have to instantiate two objects with different SS pin designations.
If it's hard coded, what are the options then? Can I make a copy of the library, say make a copy of <Adafruit_OLED> and <Adafruit_OLED2>, and go in and rename all the .h and .c files to add the "2" at the end, as well as go into the actual header and c file and do a find-replace to add the 2 at the end references to the class?
Personally, I would first look for another library. Then if there is nothing else, re-write it so that it does take a parameter in the constructor or begin() method.
I am also thinking of doing something like this with multiple OLED displays using the SPI. I was thinking, why not put a "dummy" or unused pin number for the CS in the Constructor for the OLED.
I assume that each time there is a function call, the library will set and reset to the CS so setting and reseting a "dummy" pin would cause no harm. Then each time you do a library function call, just set an actual CS (CS1, CS2, CS3, CSx) before the function call and when you return from the function call reset the CS pin.
It shouldn't matter which library you are using. The Adafruit and U8g2 library both put the constructor in the actual program, not the library.
How about that?
The point is that the library that was causing problems for the OP doesn't take a pin in a constructor. It seems that the Adafruit library does, so he must be using something else - which was never specified in the thread.
Setting CS before calling a library function won't work for most reasonably-complex SPI devices. A single call to the library may assert CS several times because de-asserting CS is a signal to the device that a command is complete and a function like "draw a square" needs to use many commands.