martinberlin / CalEPD

Epaper ESP-IDF component with GFX capabilities and multi SPI support
https://fasani.de
Apache License 2.0
94 stars 11 forks source link

3 Wire SPI #13

Closed Johboh closed 1 year ago

Johboh commented 1 year ago

Hi! The https://www.good-display.com/product/285.html display I'm using supports 3-wire SPI where the D/#C is not needed. Instead the D/#C is the first bit of transfer indicating data/command. Does this component support this? I couldn't find anything hinting on this when looking briefly, but I might be missing something. Otherwise I can look into supporting this (if/when I have time at some point).

martinberlin commented 1 year ago

No I'm always using DC pin since I found it the most easy and also much faster since it's all hardware. But if you want to implement it go ahead. I'm not really interested in supporting it by Firmware since is much easier using an additional IO with DC signal.

UPDATE: Also as you can see in my classes I'm optimizing this so it's faster than GxEPD that is a mess and is also toggling CS pin on every byte which is a waste of time. I'm not doing that and I try to send a big chunk of data on every SPI Chip Select toggling.

Johboh commented 1 year ago

In my case its because I have a shortage of GPIO to use (because of PCB constraints) :). I have dropped CS already and tied it to ground.

martinberlin commented 1 year ago

Alright then maybe you will get this working and make a nice open-source contribution to this project. Sounds like a good idea?

Johboh commented 1 year ago

Yes I will look into it.

martinberlin commented 1 year ago

Yeah great. Sorry but the thing is that when you build a Component you cannot just focus on everything, specially when it's something you do as a hobby and no-one is paying for my time. So you need to prioritze and take choices, that not always are of everyone's liking...

Johboh commented 1 year ago

Yes of course, I understand. My initial question was to figure out if the support already existed or if you had already tried it and abandoned it, not asking for you to implement it.

martinberlin commented 1 year ago

Sure I understand. Actually should not be so hard to do it if you figure out how. It could be a global parameter setting and instead of driving DC by hardware you should implement that on a single point EpdSpi. If it's that easy it should work without a lot of changes. But as we both now is not always like this and every change at that low level comes with challenges that you often do not expect.

martinberlin commented 1 year ago

@Johboh if you have time and desire to implement this in a meaningful way where the rest will work then send me an email or message in Twitter: martinfasani

This is closed until someone desires to implement it. I have really not much interest in doing it since is much easier to have an extra IO for DC

Johboh commented 1 year ago

Yes my intention is still do this, but life got in its way :).

martinberlin commented 1 year ago

Anyways before even starting with this make some demos without DC and try just to update the display. All demos are using DC so you need to also check carefully how to set the display in this special mode, so it expects the first bit indicating that is Data or Command. This can be a bit painful to implement when sending big chunks of data and that is one of the reasons I don’t want to complicate my life doing this. Is just an extra IO, so why not doing it with DC? Only acceptable if there is really not any way to have that extra pin