Conversation
| def init(module): | ||
| module.name = ":driver:ssd1306" | ||
| module.description = "SSD1306 Display" | ||
| module.name = ":driver:ssd1306.i2c" |
There was a problem hiding this comment.
Should we add an alias for the old module name?
If so, how does it work?
There was a problem hiding this comment.
yes, with module.add_alias in the :driver module. See example here. Also add a DEPRECATED: 2024q4 so we can remove it and not forget it like in my own example *cough*😇.
There was a problem hiding this comment.
I added the following code to src/modm/driver/module.lb:
# DEPRECATED: 2024q4
module.add_alias(
Alias(name="ssd1306",
destination=":ssd1306.i2c",
description="DEPRECATED: Please use :driver:ssd1306.i2c instead."))lbuild recognizes the alias and does not complain if I use it in project.xml, but does not generate any files...
There was a problem hiding this comment.
needs to be destination=":driver:ssd1306.i2c", I'll check why it doesn't complain.
There was a problem hiding this comment.
Nope, still does not work 😞
There was a problem hiding this comment.
Oh ffs, I'll check it over the weekend. I need to rewrite lbuild, it's so unpythonic…
There was a problem hiding this comment.
It does build the alias destination for me though.
The reason it doesn't give a warning is that the :driver:ssd1306.i2c module is a dependency of the :driver:sh1106.i2c module, and is thus already included by the time the alias is resolved. If you change the dependency back to the alias:
$ lbuild build
[WARNING] lbuild.node: Node 'modm:driver:ssd1306' has been moved to ':driver:ssd1306.i2c'!
>> modm:driver:ssd1306 [Alias]
DEPRECATED: Please use `:driver:ssd1306.i2c` instead.
Destination: :driver:ssd1306.i2c
>> modm:driver:ssd1306.i2c [Module]
SSD1306 Display in I2C mode
efc4ce5 to
b9dd0fb
Compare
| this->commandBuffer[0] = ssd1306::AdressingCommands::HigherColumnStartAddress; | ||
| this->commandBuffer[1] = 0x02; | ||
|
|
||
| for (page = 0; page < Height / 8; page++) | ||
| { | ||
| this->commandBuffer[2] = 0xB0 | page; | ||
| this->transaction_success &= RF_CALL(this->writeCommands(3)); |
There was a problem hiding this comment.
The command sequence {0x10, 0x02, 0xB0 | page} gets interpreted (at least on my SSD1306 GME12864 module) as three command:
1.0x10: Set Higher Column Start Address for Page Addressing Mode (10h~1Fh) to value 0
2.0x02 Set Lower Column Start Address for Page Addressing Mode (00h~0Fh) to value 2
3. 0xB0 Set Page Start Address for Page Addressing Mode (B0h~B7h) to value page
The first two commands result in the first two columns of display pixels displaying garbage and the last two columns of the frame not getting displayed, so I removed them.
SSD1106 should behave the same way like SH1106 in Page Addressing Mode, but I don't have SH1106 hardware laying arround, so I can't test it. Maybe @TomSaw could check?
There was a problem hiding this comment.
And the hardware test shows:
These lines have a purpose. Whitout, the displays pages (columns of pixels) get ugly shifted.
I remember having read about this necessary micro-management in an adafruit or arduino library comment, not in the datasheet or elsewhere.
@TomSaw I tested the |
ok, but gimme 1,2 days pls. |
|
Is there an update for this? |
|
Tested SH1106 and you actually have to keep the ssd1306::AdressingCommands::HigherColumnStartAddress` assignments in the SH1106 driver if you don't have a preference for fuzzy diagonally shifted pages of pixels. The memory mapping of sh1106 is different (and worse) than SSD1306 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Can I merge this? What's the status of this? |
|
I have to test/debug and maybe fix the problem with the SH1106. |

modm::Ssd1306toSsd1306I2cmodm::Ssd1306Spienums instruct modm::ssd1306toenum class