Greetings!!
New user here! I have a couple of questions -
I’m sure this has been asked before but searching has yielded no results. I am using 128x32 oled screens and there is a way to set the i2c address on the pcb itself.
My question is, Is there a way to display different sets of information on each screen? ( since you can use the same sdl / sck pads with i2c ) ?
As a novice proffieboard user, I am struggling with finding information on file structure and upgrading. I have a working 5.6 config on the test bench, everything works as should ( buttons / 1 oled / blade etc ) however, when I upgrade to 7.4, nothing works. Is this because the file structure changed?
I followed the instructions on the main web site , when that didn’t work , I followed Fett263’s site instructions, but still not working. If I flash back to 5.6 , everything works as should. It seems that there is no singular source for a unified current instruction. Is there a place to go to see exactly how the 7.4 file structure should be ? as well as the config? ( I notice there are things missing from 6.9 concerning blaster setup ). I know once I have the board set up as it should, programming it should be straight forward. ( Im sure others reading this is shouting “its so easy!” ) but maybe i’m missing something and doing hours and hours of reading form multiple sites is nothing but confusing lol .
The easiest thing would probably be to just have multiple of each image file, and let each display choose randomly. Sometimes they would show the same, sometimes they wouldn’t…
It is also possible to set up a different controller for each display, but there aren’t really a lot of options for controllers today, so creating a new controller will probably require some coding.
That’s weird. Normally all you should need to do is to copy the config file over, compile and upload. Backwards compatibility is nearly 100%.
Are you using the same config file with 5.6, and 7.4, or are you creating a new one? What does your config file(s) look like?
Thank you for the quick reply! Yes the config is identical ( since the hardware / sounds haven’t changed). I’ll have another go to see what happens. Additionally , What I tried was creating everything from scratch ( except the sounds) but the configs, as I received a fresh 2.2 board. The only way I was able to get it working was using a file structure and config from the 5.6 build. Again, I will have another try without changing anything. I was also wondering because concerning oled animations, the structure and options are different depending on the OS.
Can you expand on your answer about setting up a different controller? having it play randomly would be ok but I have one yellow oled and then a white oled. I was planning to display animations on function ( blaster based ). For example, the yellow would have a power cell animation, and the white would display counter / ammo etc. But if I understand your answer correctly, this is not possible straight from the board without an additional controller?
No, it isn’t.
Newer OSs support more files and more ways to organize the files, but it’s always a superset of what was supported before.
“Controller” in this case is a class which tells the display what to do.
You can see how the standard controller setup looks here:
Another way to set up a controller for a display is shown here:
This second one is basically a regular controller, but with a rectangle reserved for showing bullet counts.
Controllers are meant to give “control” over what is displayed on the screen, but currently there just aren’t a lot of options to choose from. However, if you want one regular, and one with bullet counts, you may be in luck…
PS: In the color display code I’m working on, I’ve created a way to to specify a directory name when creating the controller. This means that display A could take images from one directory and display B could take images from a different directory. This is not implemented for OLED screens yet, but I could take a look at it and see if I could backport it.
This creates two displays, one which reads images from a directory called A inside the font directory, and another one that reads from B. The second display has the ID 0x3D (The default is 0x3C)
Also, for blasters, you might want to use BlasterDisplayController instead of StandardDisplayController.
You’ll need the latest from github master to make this work. Eventually this will all be a part of ProffieOS 8.x
What’s the best place for documentation on these different display controllers? I hadn’t heard much of them before but now I’ve seen them be mentioned in several places.
There isn’t a lot of documentation written for this.
Up until recently, the only use case was bullet counts, which has some documentation written here:
Apart from that, you could always read the code, but it’s pretty low on comments, so it’s not particularly obvious how to use it or why it’s written that way I’m afraid.
Gotcha. Yeah, I’ve read that but obviously there’s things not mentioned in that, and ofc you’re adding new features too.
I suppose a better question would be: Is there a plan to document that stuff? I can certainly look through the code, but generally it’s hard to understand intent and philosophy through that, so I’d appreciate having somewhere I can read to gain an understanding of intent and projections for feature expansion.
I think you’re already aware of how all of this works.
We always need more documentation, things tends to get documented when people use it or ask questions about it. The POD, the source and this place are the tools and resources we use to do that. I also intend to document everything that is new in ProffieOS when OS8 goes into alpha. (Although I can always use some help with that.)
As for deeper understanding, future plans and intentions. Start by reading the code. It doesn’t always do a good job of explaining everything tough, but I’m more than happy to answer any questions you have about it. (Please note; the idea here is that the code should be easy and straightforward to read, so if you find it difficult, don’t spend hours trying to puzzle it out; just ask.)