Heltec OLED Wif Kit 32 - Target with screen

[tribalmatt]

Hi everyone,

I felt setting the Heltec Esp32 OLED board (https://heltec.org/project/wifi-kit-32/) up to run with the SDK would be a good learning experience. They are inexpensive and I could use some debugging that is visual. I set up a new target with the SSD1306 driver over i2c and have I have failed to get the OLED to work. I don't get a particular error. Just nothing drawing. I have confirmed all pins look good. I played around the "hz" to make sure that does not fail. I confirmed the address is correct. I have these working in Arduino and started with the Esp32 thing target and compared those changes in the Arduino SDK to the those for the Heltec and I think I have all that correct. Happy to share if that is helpful.

My feeling is the SDK is not properly set up for Monochrome display over SSD1306 (see below) and my knowledge for drawing in Poco in JS in Monochrome is completely lacking.

In the SSD1306.c code these lines at #211 (below) seem like incorrect logic. I have changed this, so it is forced to Monochrome in the manifest and the c code, and that did not help me.

if (xsmcHas(xsArg(0), xsID_pixelFormat)) {
	xsmcGet(xsVar(0), xsArg(0), xsID_pixelFormat);
	pixelFormat = xsmcToInteger(xsVar(0));
}
else
	pixelFormat = kCommodettoBitmapFormat;
if (kCommodettoBitmapGray256 != pixelFormat)
	xsUnknownError("gray256 pixels required");

Any pointers on next steps. Like I mentioned at the top. I don't get any failure. I just don't draw. I was using the cfe8x8 example...but tried PUI balls as well. Maybe I am expecting a conversion to happen from 256 to monochrome and that is my failure. Maybe I need to set up an example using PocoMonochromeBitmapDraw()?

I do not have experience setting up GDB and JTAG on Esp32 so maybe that is where I need to go next.

A side question...what is the "host" folder and "provider.js" file in the targets?

Thanks for any pointers,
Matt

[phoddie]

The SSD1306 driver does work over I²C, at least it did that last time I tried.

While the SSD1306 is a monochrome display, the graphics are rendered at 8-bit gray. The driver converts them to 1-bit, with optional dither, while sending them to the SSD1306. The SSD1306 driver documentation describes this and other details.

I do not have experience setting up GDB and JTAG on Esp32 so maybe that is where I need to go next.

That shouldn't be necessary. I didn't use GDB to develop the driver. ;)

I don't get a particular error

When I²C fails in the driver, you should get a JavaScript exception. That is usually triggered on this line.
That you don't see that exception suggests you are confirmed for SPI (which fails silently, because SPI write provides no feedback).

I suggest checking that you have configured the driver to operate over I²C (it supports both I²C and SPI) and that the pin numbers used by the driver match your wiring.

[tribalmatt]

Here are some more notes.  I had confirmed that I was writing out over i2c.  I added logging data into that part of the driver to check pins etc.  And if I put the wrong data in I get failures in i2c_param_config().  I also had some failures where you pointed out.

And also as I look at it more closely...it is not failing silently but is continuously crashing and opening with no error message. xsBug just gets stuck in an endless start loop.

Here is what my manifest looks like. I have also tried format "Monochrome" with no luck.

{
	"include": [
		"$(MODDABLE)/modules/drivers/ssd1306/manifest_i2c.json"
	],
	"config": {
		"screen": "ssd1306",
		"touch": ""
	},
	"defines": {
		"i2c": {
			"sda_pin": 21,
			"scl_pin": 22
		},
		"spi": {
			"miso_pin": 12,
			"mosi_pin": 13,
			"sck_pin": 14
		},
		"ssd1306": {
			"format": "Gray256",
			"width": 128,
			"height": 64,
			"sda_pin": 4,
			"scl_pin": 15,
			"rst_pin": 16
		}
	}
}  

Thanks again,
Matt

[phoddie]

"format": "Gray256",

That doesn't do anything since as there is no MODDEF_SSD1306_FORMAT used by the driver.

Two questions:

• What script are you running with this?
• Do you know where it crashes - e.g. what JavaScript is last executed? If no you can figure it out by stepping through the script in xsbug.

[tribalmatt]

On Wed, Sep 29, 2021 at 3:52 PM Peter Hoddie ***@***.***> wrote: "format": "Gray256", That doesn't do anything since as there is no MODDEF_SSD1306_FORMAT used by the driver.

It seems there is a check at these lines for color format. I am not sure if it is used later. https://github.com/Moddable-OpenSource/moddable/blob/public/modules/drivers/ssd1306/modSsd1306.c#L211-L217

Two questions: - What script are you running with this? I tried the examples "commodetto/cfe8x8" as well as "piu/balls". I build

with this. mcconfig -d -m -p esp32/heltec_wifi_kit_32

- Do you know where it crashes - e.g. what JavaScript is last executed? If no you can figure it out by stepping through the script in xsbug. My script code is never hit. My first line is debugger; like helloworld.

If I turn on xsBugs break on start feature...the xsBugs stops and then loops at: moddable/build/devices/esp/setup/commodetto.js (23) # Break: step! And then seems to fail at line 25 moddable/build/devices/esp/setup/commodetto.js (25) # Break: step! The first thing I noticed when I pasted this here is, why is the path "esp" and not "esp32". helloworld runs fine. Is there something really fundamental I am missing? Or is this just how the SDK works. The code is the same in both commodetto.js files so not sure it matters. Just seems like I might have missed some platform bit. Thanks Again.

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KSCES3CKNJQTKMJWMTUEOKDFANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

That doesn't do anything since as there is no MODDEF_SSD1306_FORMAT used by the driver.
It seems there is a check at these lines for color format. I am not sure if it is used later.

There is a check for the color format. But, that does not use the format from the defines section of the manifest.

Here's a modified version of your manifest. I was able to build and run commodetto/cfe8x8 using it. I don't have the Heltec board, so I just commented out the I²C writes in the driver. In that state, frames are being rendered, they just don't get delivered.

{
	"include": [
		"$(MODDABLE)/modules/drivers/ssd1306/manifest_i2c.json"
	],
	"config": {
		"screen": "ssd1306",
		"touch": "",
		"format": "Gray256"
	},
	"defines": {
		"ssd1306": {
			"width": 128,
			"height": 64,
			"sda_pin": 4,
			"scl_pin": 15,
			"rst_pin": 16
		}
	}
}

You are correct that build is using the Commodetto setup from from the esp target instead of the esp32 target. They are identical, so it is harmless. I'll fix that in the SDK. Thanks for reporting that.

[tribalmatt]

Commenting out the i2c writes was helpful. That got me moving again. I am failing on the modI2CWrite(); form doCmd(). I had improperly used xsErrorPrintf() and that was causing the more strange crash. I tried to diagnose the write...but I don't know the best way to log the error from i2c_master_cmd_begin(). modLog() seems to require a constant. The sdk has ESP_ERROR_CHECK macro and esp_err_to_name(). But what is the best way to log that to xsBug from the module? Maybe I am missing something easier. Seems like a configuration issue. Thanks, Matt

…

On Thu, Sep 30, 2021 at 10:44 AM Peter Hoddie ***@***.***> wrote: That doesn't do anything since as there is no MODDEF_SSD1306_FORMAT used by the driver. It seems there is a check at these lines for color format. I am not sure if it is used later. There is a check for the color format. But, that does not use the format from the defines section of the manifest. Here's a modified version of your manifest. I was able to build and run commodetto/cfe8x8 using it. I don't have the Heltec board, so I just commented out the I²C writes in the driver. In that state, frames are being rendered, they just don't get delivered. { "include": [ "$(MODDABLE)/modules/drivers/ssd1306/manifest_i2c.json" ], "config": { "screen": "ssd1306", "touch": "", "format": "Gray256" }, "defines": { "ssd1306": { "width": 128, "height": 64, "sda_pin": 4, "scl_pin": 15, "rst_pin": 16 } } } You are correct that build is using the Commodetto setup from from the esp target instead of the esp32 target. They are identical, so it is harmless. I'll fix that in the SDK. Thanks for reporting that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KUPFSJRHQXHIT2RQBTUESOWFANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Seems like a configuration issue.

Yes, if modI2CWrite is failing, a bad I²C configuration is usually the reason.

modLog() seems to require a constant

It does. modLogVar doesn't, but that may not be what you want.

modLog and friends are useful when you don't have access to the virtual machine (the). If you do, then you can just xsTrace to output a string to the xsbug console or xsLog for a printf style trace. In both cases, like printf, you need the trailing \n:

xsTrace("message\n");
xsLog("message with number %d\n", 12);

[phoddie]

One other thought - it could be that the I²C address is incorrect. Some I²C components can appear at one of several addresses depending on the hardware configuration. The SSD1306 is one of them. Here's the relevant text from the dat sheet:

The valid addresses are 0x3C and 0x3D. The driver defaults to 0x3C (60), but you can change that to 0x3D (61) in your manifest:

	"defines": {
		"ssd1306": {
			"width": 128,
			"height": 64,
			"address": 61,
			"sda_pin": 4,
			"scl_pin": 15,
			"rst_pin": 16
		}
	}

[tribalmatt]

I had confirmed the address with an Arduino tool. Maybe I should port that to JS. This shows 0x3C. I don't know the relationship between pins and address or if there is one. But this boards pinout lists 2 sets of I2C pins. One open and one for the OLED.

…

On Thu, Sep 30, 2021 at 7:53 PM Peter Hoddie ***@***.***> wrote: One other thought - it could be that the I²C address is incorrect. Some I²C components can appear at one of several addresses depending on the hardware configuration. I don't recall if the SSD1306 is one of those. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KWWV5ZBMEBRARIOZULUEUPB3ANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

I don't know the relationship between pins and address or if there is one.

There isn't one. The pins are the physical connection of the I²C bus. The address is the logical address on that bus.

But this boards pinout lists 2 sets of I2 pins. One open and one for the OLED.

I was going to order a board to try, but it ships from Europe. Is there availability in the US of the board or an equivalent? (It looks like it may be the same as the HiLetgo boards available on Amazon, for example)

[tribalmatt]

It is the same as the HiLetGo (This is branded Heltec when it arrives). I am happy to send one your way. I have logged all the data and so far have not learned much. - The error returned from the ESP32 sdk is "ESP_FAIL". How is one supposed to enable readable error messages? I would have thought these were enabled by default in debug. - The pins and address are correct. - To the best of my knowledge the clock speed is correct. 100000 seems standard. I also tried 400000 - The timeout bit is not clear and this is just the 32000 value. - I have tried with pullups enabled and disabled. - I used a reset pin and not. But I don't think this matters from how I read the code. - I tried a different command instead of SSD1306_DISPLAYOFF. No luck. - I tried a read command and this failed with ESP_ERR_TIMEOUT - I tried manually setting the reset pin LO and then HI and this did not help. - The arduino drive I used does have many delays written into the i2c code. Maybe something is up there. - I also tried various states of setting the reset pin manually that others recommended. That is where I stopped. Any other ideas?

…

On Fri, Oct 1, 2021 at 9:21 AM Peter Hoddie ***@***.***> wrote: I don't know the relationship between pins and address or if there is one. There isn't one. The pins are the physical connection of the I²C bus. The address is the logical address on that bus. But this boards pinout lists 2 sets of I2 pins. One open and one for the OLED. I was going to order a board to try, but it ships from Europe. Is there availability in the US of the board or an equivalent? (It looks like it may be the same as the HiLetgo boards available on Amazon, for example) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KSMD2S72DXXGU33OJDUEXNXHANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Well, that seems thorough.

Maybe there's a subtle detail in the requirements that we're overlooking. That said, we've used this part for a long time without a problem. @andycarle, you often have good insights into strange I²C problems. Any ideas?

(I ordered a HiLetgo board to be able to try this out.)

[tribalmatt]

Finally progress. No errors and piu/balls basically works as it should. cfe8x8 does some strange truncation and drawing...that I can look at later. The reset pin needs to be set LOW and then HIGH. And in my first attempt I did not set the reset pin to be in OUTPUT mode. So this did not work. In the SSD1306 driver in the Heltec Arduino SDK they do this with the mode to OUTPUT... pinMode(_rst,OUTPUT); digitalWrite(_rst, LOW); delay(50); digitalWrite(_rst, HIGH); I mimicked this with ESP-IDF code that looks like this. modLog("set gpio pin hi/lo\n"); gpio_pad_select_gpio(16); gpio_set_direction(16, GPIO_MODE_OUTPUT); anErr = gpio_set_level(16, 0); modLogInt(anErr); modDelayMilliseconds(100); anErr = gpio_set_level(16, 1); modLogInt(anErr); I will work on cleaning up my code and integrating it with the RST pin define. If I can get it working using modGPIO like the SPI path I will do that as well and then send along my changes. Thanks for the help.

…

On Fri, Oct 1, 2021 at 1:23 PM Peter Hoddie ***@***.***> wrote: Well, that seems thorough. Maybe there's a subtle detail in the requirements that we're overlooking. That said, we've used this part for a long time without a problem. @andycarle <https://github.com/andycarle>, you often have good insights into strange I²C problems. Any ideas? (I ordered a HiLetgo board to be able to try this out.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KR5OYMHD6JXFYCWKXTUEYKDXANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Wahoo! You figured it out. Congratulations.

There is support for managing the reset pin in the driver already. Maybe you can just use that? Take a look at MODDEF_SSD1306_RST_PIN It looks like the sense is correct (e.g. reset inactive is HIGH and reset active LOW)

[phoddie]

Hey, @veenstr. My Heltec board arrived today. When you have a PR, I'm ready to give it try.

[tribalmatt]

The existing support is currently just for SPI it should really be independent of communication prototcol. I had attempted using the MODDEF_SSD1306_RST_PIN code in the I2C path, but did not have any success there. I will update the code to use the MODDEF_SSD1306_RST_PIN. And clean it up so both methods ideally work.

…

On Fri, Oct 1, 2021 at 3:59 PM Peter Hoddie ***@***.***> wrote: Wahoo! You figured it out. Congratulations. There is support for managing the reset pin in the driver already. Maybe you can just use that? Take a look at MODDEF_SSD1306_RST_PIN It looks like the sense is correct (e.g. reset inactive is HIGH and reset active LOW) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#711 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KWGD4DKTRRIXFB3GSLUEY4MFANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Huh. I hadn't noticed that the reset pin support is only on the SPI path, not I²C. Thanks for taking the time to make that consistent.

[tribalmatt]

I created a pull request with all the changes. Please let me know if you have any questions. Thanks for the help.

…

On Mon, Oct 4, 2021 at 12:59 PM Peter Hoddie ***@***.***> wrote: Huh. I hadn't noticed that the reset pin support is only on the SPI path, not I²C. Thanks for taking the time to make that consistent. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KQCUA7NUQYJDQKIWATUFIBRVANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Thanks for the PR. We'll review that soon. Meanwhile, if you could complete the individual Contributor Agreement, that would help move things along. Thank you.

[tribalmatt]

Can I just digitally sign that? Or do I unwed to wet sign and scan?

…

On Tue, Oct 5, 2021 at 6:43 AM Peter Hoddie ***@***.***> wrote: Thanks for the PR. We'll review that soon. Meanwhile, if you could complete the individual Contributor Agreement <https://github.com/Moddable-OpenSource/moddable/tree/public/licenses#contributor-license-agreement>, that would help move things along. Thank you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KWLFAVZF65IYTUBVKTUFL6JBANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

Digital is perfect and email to [email protected]. Thanks.

[phoddie]

The PR looks great. Thank you! We've merged that. Everything I tried worked on the board I have here.

The "format" property is in the correct place in your manifest. It needs to be in the "config" object so that it is picked up as the pixel format to use when building.

FWIW - Some of the examples look much better with dithering enabled. 'piu/balls is a good example. To enable dithering, add "dither": 1 in the SSD1306 defines.

You mentioned that the commodetto/cfe8x8 example didn't render correctly. That example assumes that the display driver supports partial frame updates. The SSD1306 supports only full frame updates. The code can easily be rearranged to draw the entire frame at once, rather than line-by-line:

Timer.repeat(() => {
	render.begin();
		render.fillRectangle(black, 0, 0, render.width, render.height);
		for (let i = 0, y = 0; i < text.length; i++, y += 9)
			render.drawText(text[i], font, colors[color % colors.length], 0, y, render.width);
	render.end();
	color += 1;
}, 1000 / 12);

Because more is being drawn at one time, you need to make the display list longer when instantiating Poco. The default is just 1024 bytes.

let render = new Poco(screen, {displayListLength: 3072});

FWIW - the SSD1306 driver could support partial updates easily on 8 pixel horizontal bands. Or it could allocate a full back buffer to support arbitrary partial updates, but that's more memory and some more work.

[tribalmatt]

I have used the balls sample, with and without dither. It works much better with a black background. I have a few questions about the balls app and configs but will start a new discussion for that, as that was my next learning to understand the drawing and app framework. I did have a question on leaving comments in the json file. Does the moddable have a style for a JSON comments that is then ignored when parsing into headers and config files? Something like "comment": "Lorem ipsum dolor sit amet, consectetur ...". So we could leave optional notes for configuration files that then don't break a header or config file based on white spaces. For example the dither. Or is it best to just include "dither": 0... and then assume someone looks at the readme? Thx

…

On Wed, Oct 6, 2021 at 3:24 PM Peter Hoddie ***@***.***> wrote: The PR looks great. Thank you! We've merged that <82db9e6>. Everything I tried worked on the board I have here. The "format" property is in the correct place in your manifest. It needs to be in the "config" object so that it is picked up as the pixel format to use when building. FWIW - Some of the examples look much better with dithering enabled. 'piu/balls is a good example. To enable dithering, add "dither": 1 in the SSD1306 defines. You mentioned that the commodetto/cfe8x8 example didn't render correctly. That example assumes that the display driver supports partial frame updates. The SSD1306 supports only full frame updates. The code can easily be rearranged to draw the entire frame at once, rather than line-by-line: Timer.repeat(() => { render.begin(); render.fillRectangle(black, 0, 0, render.width, render.height); for (let i = 0, y = 0; i < text.length; i++, y += 9) render.drawText(text[i], font, colors[color % colors.length], 0, y, render.width); render.end(); color += 1;}, 1000 / 12); Because more is being drawn at one time, you need to make the display list longer when instantiating Poco. The default is just 1024 bytes. let render = new Poco(screen, {displayListLength: 3072}); FWIW - the SSD1306 driver could support partial updates easily on 8 pixel horizontal bands. Or it could allocate a full back buffer to support arbitrary partial updates, but that's more memory and some more work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISN6KRCD635HIT72WHUMZLUFTEBDANCNFSM5FAVRZFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[phoddie]

I did have a question on leaving comments in the json file. Does the
moddable have a style for a JSON comments that is then ignored when parsing
into headers and config files? Something like "comment": "Lorem ipsum
dolor sit amet, consectetur ...".

No. You can put a "comment" or "note" block at the top level and it will be ignored. Anything you put in "config" will find its way into the binary.

Is there a convention for this sort of thing? If there is, we could look at supporting it.

For example the dither. Or is it best to just include"dither": 0... and then assume someone looks at the readme?

I'm generally wary about using comments to replace documentation. Comments are great when explaining something subtle, mysterious, or bizarre. Commenting everything creates a lot of noise can obscure the important comments. Here dither seems pretty straightforward. But, that's me. If you want to try something else here, that's fine too.

[tribalmatt]

Dither was generally a poor example. I had a note in mine like below. I guess this note could go in the ssd1306 driver docs. I am just not sure if that is hardware specific or not. But I feel it was. ``` "ssd1306": { "dither": *true*, "//hz_alt_slower_refresh": 100000, "hz": 400000, "width": 128, "height": 64, "sda_pin": 4, "scl_pin": 15, "rst_pin": 16 } ``` As for json, there is not a common convention that I know of. People do random stuff. Most of it is easily ignored as it ends up in some large js program where some kb of comments just does not matter. When you say code block at the top is ignored. I tried like c style and this failed. Anything like this would be fine in my opinion. ``` /* ssd1306 driver notes */ ``` I tried a comment like it is used in the readme and those fail. I understand that this is just for the readme's. ``` "include": [ /* other includes here */ "$(MODULES)/drivers/ssd1306/manifest.json", ], ``` I will try and update the doc for the ssd1306 with the bits I would have liked to see. I like comments in configuration files. And I like to see more comments in example projects. I agree with the sentiment that the main SDK and code body should have fewer comments. I immediately went for an example using the ssd1306, based on the sparkfun example. I missed quite a bit with this example until I traversed the code. I also completely missed there were driver examples until after I sent this to you. Also in general, I probably comment more than others. Thx again.

[phoddie]

When you say code block at the top is ignored. I tried like c style...

What I wrote was: "You can put a "comment" or "note" block at the top level and it will be ignored". Apologies for the confusion. What that intended to mean was that you can do this:

{
	"comment": "words",
	"include": [
		"$(MODDABLE)/modules/drivers/ssd1306/manifest_i2c.json"
	],
	"notes": "more words",
}

But, you should not do that inside of elements used by the tools. For example, this will put the comment into the binary as part of the mc/config module. That's probably not what you want.

{
	"comment": "words",
	"config": {
		"touch": "",
		"comment": "other words"
	}
}

I will try and update the doc for the ssd1306 with the bits I would have liked to see.

That would be great.