Initial version of 2.9" ePaper Board

[bonnyr]

A new board to go with the WS29v2 custom chip (alpha)

[urish]

Amazing!

The only thing I'm not sure about is the name of the board. I'm thinking epaper-2in9-bw, and down the road epaper-2in9-bwr (for red), epaper-2in9-bry (for yellow), but I'm open the other suggestions.

I did some research trying to figure out what models are out there for 2.9" by different sellers:

Colors	Waveshare	Adafruit	Good display
White, black †	SSD1608	IL0373	UC8151D
White, black, red	SSD1680	UC8151D *	SSD1680A **
White, black, yellow	SSD1680	UC8151D *	SSD1680

* Older revisions used IL0373
** Older revision used SSD1680
† Some places say it's IL3820, but as far as I can tell, it's the same as SSD1608

Also, I found a useful github repo with a list of many different driver ICs, their datasheets, and a table that shows which ones are equivalent: https://github.com/CursedHardware/epd-driver-ic

[bonnyr]

Wow, such thorough research - thanks @urish !

I am happy with the name suggestion although the chip supports BW/BWR using an attribute, so changing the board name is a little unnecessary I think. Adding support for yellow as the colour rather than red can easily be added as an attribute value.

Right now the chip is based on the Waveshare documentation so I guess the controller is SSD1680. I am not sure whether supporting others may be better done in the same chip - I'll check the datasheets (thanks for the links).

I would like to make a suggestion as well (although this may belong in another topic/issue).
Since the implementation of these are going to be done using a custom chip, why not allow the board implementation to be referred to like the "dependencies" stanza in diagram.json?

[urish]

I am happy with the name suggestion although the chip supports BW/BWR using an attribute, so changing the board name is a little unnecessary I think. Adding support for yellow as the colour rather than red can easily be added as an attribute value.

Awesome! In that case, maybe we should just call it epaper-2in9? Hopefully, the different controllers aren't too different, otherwise, we may want to have one board variant per manufacturer (e.g. epaper-adafruit-2in9), and have each use the right controller chip (if/when we implement additional controller chips).

Since the implementation of these are going to be done using a custom chip, why not allow the board implementation to be referred to like the "dependencies" stanza in diagram.json?

That's the plan, down the road. Right now, I'm not sure I'm happy with the board.json syntax - so I'd like to have all the custom boards live in one repository, so once we have a final syntax, it'll be easier to update everything at one go. Otherwise, the migration will be more complex (or we'll have to break existing boards and the designs that use them).

One of the things I dislike about the current syntax is mixing of pin positions and their connections. It makes it difficult to reason about what's connected to which pin (for LED's, for instance, you define the connections to the external pins as part of the LED definition). It will also be difficult to support boards that carries multiple MCUs (wokwi/wokwi-features#186), if we decide to support this use case.

Ideally, once we start working on wokwi/wokwi-features#302, I'll sit for a day or two and try to prototype an alternative. Perhaps some model that resembles diagram.json - a board will just be a collection of parts (chips, LEDs, maybe buttons, 7-segments, etc.) a list of external pins and their positions, and a list of the internal connections. We'll see :-)

[bonnyr]

I am happy with the name suggestion although the chip supports BW/BWR using an attribute, so changing the board name is a little unnecessary I think. Adding support for yellow as the colour rather than red can easily be added as an attribute value.

Awesome! In that case, maybe we should just call it epaper-2in9? Hopefully, the different controllers aren't too different, otherwise, we may want to have one board variant per manufacturer (e.g. epaper-adafruit-2in9), and have each use the right controller chip (if/when we implement additional controller chips).

So, just to make sure I'm on the same page - this is the name field you're referring to, right? Is that supposed to be unique
in the Wokwi ecosystem? If so, I would like to suggest that there's either an additional field called id for that purpose or change the name field to do that.

In my mind, we have 3 fields:

• id : this is a unique type identifier
• name: this is a human readable name for the part
• description: this is a long description for the part

Since the implementation of these are going to be done using a custom chip, why not allow the board implementation to be referred to like the "dependencies" stanza in diagram.json?

That's the plan, down the road. Right now, I'm not sure I'm happy with the board.json syntax - so I'd like to have all the custom boards live in one repository, so once we have a final syntax, it'll be easier to update everything at one go. Otherwise, the migration will be more complex (or we'll have to break existing boards and the designs that use them).

One of the things I dislike about the current syntax is mixing of pin positions and their connections. It makes it difficult to reason about what's connected to which pin (for LED's, for instance, you define the connections to the external pins as part of the LED definition). It will also be difficult to support boards that carries multiple MCUs (wokwi/wokwi-features#186), if we decide to support this use case.

Ideally, once we start working on wokwi/wokwi-features#302, I'll sit for a day or two and try to prototype an alternative. Perhaps some model that resembles diagram.json - a board will just be a collection of parts (chips, LEDs, maybe buttons, 7-segments, etc.) a list of external pins and their positions, and a list of the internal connections. We'll see :-)

Awesome, can't wait!

[urish]

So, just to make sure I'm on the same page - this is the name field you're referring to, right? Is that supposed to be unique
in the Wokwi ecosystem? If so, I would like to suggest that there's either an additional field called id for that purpose or change the name field to do that.

Sorry I wasn't clear - I was referring to the name of the directory. Whenever wokwi sees a part that starts with board-, it'll trim the board- prefix, and then look for it in this repo, under the "boards" directory. e.g. board-ds18b20 goes to https://github.com/wokwi/wokwi-boards/tree/master/boards/ds18b20