Closed AWSW-de closed 4 years ago
I’ve just downloaded the 800x480 16.8 version and it’s working as expected. A busy time-out is indicative of a cabling / connection issue. So have you tried 16.8 with an old display? If you have just purchased a new 7.5” display you know that they have been changed and you have to use the T7 version?
I tested it yesterday works very well with the "Waveshare_7_5_T7" example. Did you still use the "Waveshare_7_5" example instead of "Waveshare_7_5_T7" example?
BTW you have to enter a new screen object line find that in GxEPD2
Hello,
thanks a lot for your replies.
I can confirm, that the 16.8 version used with the "non _T7" sketch works fine for the 640x384 displays.
I used the "_T7" Version for the new displays.
I just found that the cables shipped with the new displays look different: Old vs. New: purple | purple white | white green | green orange | orange yellow | yellow blue | blue black | brown red | grey
So is the wiring different to the old ones or what am i missing? Thanks in advance!
BTW you have to enter a new screen object line find that in GxEPD2
I don´t understand that comment... I used the one in the "T7" example.
Thanks in advance
I think i have found it...
I ordered 3x 640x384 for another project and 1x 800x480 displays from Amazon, but they send me 4x the new V2 version, so the 800x480 "V2" ones... Only the separate delivered one i ordered with the higher resolution works with the T7 sketch. The 3 other ones labelled with the same stickers do not work. These also have the different coloured cables with them. So if they are not damaged ones which i directly (i think) bought from Waveshare then these are different ones. Maybe there are two different types for the new version now... I will send these 3 displays back and stick with the new 800x480 ordered ones...
Thanks a lot!
I would examine the new working display again the 3 others and they should be identical. I’d be surprised if they were different the change in cable colours suggests to aid those who are colour blind and aligns with domestic supply cabling colours
I think the same way, but tried it several times with the possible combinations. The cable colour can’t be the difference of course... What I find interesting too, that the foam they are usually packed in smells much more compared with the 4th one and as I remember with the ones I got before. I will send these 3 back... I think there’s something wrong with them... Thanks a lot and have a nice day. 😊
Of of interest, mine was supplied in a white retail box with blue Waveshare branding and white anti-static foam, it is about 3-weeks old.
Hi! I could solve it for 2 of the 3 displays now. It’s about the blue HAT board. The 3 were delivered (So far not working ones) with a “Revision 2.1” label and these cause the busy timeout although the settings of the 2 switches are the same. I had some older HAT here without the 2.1 label and then the displays work fine. The 4th delivered working one also does not have the 2.1 revision label on the HAT... So it seems that they put in some wrong HAT boards in the boxes...
Mine are revision 2.1 and work ok, the problem your getting suggests a busy line non-connection, have you checked the electrical continuity between ESP pin and pcb connector? Those connections are notoriously unreliable.
BTW you have to enter a new screen object line find that in GxEPD2
Hello, can you give me a hint what you mean with this ?
Where do i have to enter what object line?
I received 3 more HAT connectors today - all in the new 2.1th version and i still cannot get the T7-sketch working with these new HATs... Surprisingly with the old HATs it works great...
Thanks in advance! :)
What happens when you use the GxEPD2 examples for the T7 variant, do they work?
Hello, the example works with the old HATs only too. With the new ones i can't get it to work.
Attached you can find the used example sketch and the wiring of the LOLIN D32 board. In the ones i use the cables are soldered to the pins as shown in the last picture to avoid loose connectors.
Thanks in advance :)
Been through your examples, everything looks OK. Connections look OK. Let's recap:
First of all: Thanks a lot for taking time for my problem. I appreciate this a lot. :)
To the points:
1.: Yes, that was an old photo with the 640x384px display. I just wanted to make sure, that the cables are fixed by soldering... Yes, the same LOLIN D32 boards work fine with the old displays and the new displays (with the T7 sketch) with the old HAT. I use the boards for several projects now with the 7.5" displays, like in a Wi-Fi b/w-picture frame that shows several random photos each day, a monthly calendar which shows some appointments and a few smaller projects. So far i could switch the boards between all projects with the old HAT and displays without any issue. The wiring is the same on all of them...
2.: When i switch to the new 800x480px displays, i update the sketch to an T7-variant with the old HAT works fine. Using the new HATs not.
3.: Yes i totally removed the Arduino installation folder, its working/caching directory (".arduino15") and deleted all libraries in the "Arduino" directory, with the same not working result with the new HATs. The problem drove me so nuts last week, i even completely reinstalled Linux Mint and then downloaded the newest Arduino and the libraries again. Thanks for the hint to the verbose logging checkbox. I just compiled the T7 16.8 sketch with this setting set to on and it uses in every line the "GxEPD2" is named the "/home/
4.: I tried the V2/T7 WaveShare example last week and could not get it compiled. It seems to have an error in the example. There were tons of errors shown and after about an hour i gave up using this example.
5.: Yes, i think so. I tried 5 different ones now and let them all run for a 3-day test with the old displays updating them every hour with my picture frame sketch and an MQTT publish as counter of the done actions and to see if the perform resets by themself. Looked all fine.
6.: Yes from the LOLIN D32 pins to the white connector pins with a multimeter.
7.: I tried the A setting as well with the new 2.1th version HATs but without success. On all HATs i have set it in general set to "B" and the other set to the 4-line SPI setting.
Hope you have an idea... Thanks a lot in advance. :)
So if I read your results correctly (it was useful to go through the tests), the old HAT works with the old and new display, but the new HAT won't allow the new T7 display to work. IF this is the case, then what has changed on the HAT?
Have I summarised the issue correctly - old HAT works, new one not?
I'll have a look through the schematic's if they have published them...
You have summarised it completely correct.
Attached you’ll find 2 pictures comparing the HATs:
Thanks in advance. 😊
Looking at the HAT schematics they have added a new Reset circuit with a very strange arrangement where RESET has to be high to enable the onboard regulator to function, so RST has to go high for a predetermined time to enable the regulator, try tying RESET high to 3.3v and see if the display works, if not move it to Vin/5v with USB power applied to the D32 board, it could be they have redesigned it fit the RPi and left out the microcontroller market
Thank you. I tried it with the connection 3.3V to RESET and 5V/USB to RESET with the LOLIN D32.
Once i got the new HAT working a few seconds after >removing< the connection 5V/USB to RESET, but i was not able to repeat this. You are right, it seems that the "predetermined time" set to high is required. I tried it about 1 hour to repeat it, but without success. That would mean, that a permanent connection to 3.3V or 5V might not help and for the in the end battery powered solution the 5V solution is not valid either, right?
Switching to the old HAT again and the GxEPD2 example where every few seconds the screen is updated is shown successfully again.
I’m going to study the circuit some more, Reset now needs to be high to get the power to be turned on if you have a DVM you could monitor the power to the e-paper and see if it comes on when Reset is at 3.3 or 5v, it could be the latter.
Hello, i just measured it and attached you 2 videos.
The old, working one has a slightly higher 3,3V between GND and RST.
The 2.1, new one is a little less as you can see.
Both go a little down when the blue LED flashs.
It looks like that the 3.3V is meant to be set permanent to the RST pin, but maybe to low in the newer version?
Here are the videos:
Thanks in advance.
I've now watched your videos, interestingly the D32 on-board LED which is connected to IO5 does not blink at all, but it should do as it is the device CS:
GxEPD2_BW<GxEPD2_750, GxEPD2_750::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
There is only 1 line of code that should change, so the one above becomes:
GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
According to https://www.waveshare.com/w/upload/8/87/E-Paper-Driver-HAT-Schematic.pdf the CS line is an input, so it should flash the on-board blue LED, but in your video it does not, this suggests that the HAT is loading the CS line, but how?
Can you remove the HAT and run your new HAT code example, the on-board LED should flash as it updates the display. If it does not then the HAT is preventing the CS line from operating, but why?
It suggests the HAT wiring is incorrect or has changed, but the schematic does not show that?
Also, there is no power to the HAT unless RST is held high for the duration of the screen update.
What you can try is adding these commands to your code either the GXEPD demo or Weather display: PinMode(5,OUTPUT); digitalWrite(5, HIGH);
And you may need to repeat this is various places as the display gets reset, so after every begin statement, this will hold the RST line high and power the HAT
And for the new display there is only 1 line that changes to (commenting out the old one above): GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750_T7(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY)); // GDEW075T7 800x480:
Now as CS on the HAT should be an input (just checked on their latest schematic (https://www.waveshare.com/w/upload/8/87/E-Paper-Driver-HAT-Schematic.pdf) and it is, then this points to the HAT not being powered up; although I'd expect the HAT to present a high impedance load, not a low impedance as it appears to now, because RST is not high permanently to enable power to the board and display.
Hi! Will look at this tomorrow. Just seen your reply. Thank you
Ok, I’m increasingly thinking this HAT redesign was a mistake by Waveshare or they are favouring the RPi market. Although if holding the RESET line high while the screen is being updated with the digitalwrite command won’t make much difference to operations or power consumption, and if these are the new HATs then ideally the GxEPD2 library needs a modification or option to do this. I’m confident that holding RSET high will make the HAT work, but - what has changed on the RPI screen drivers to require this change, who knows?
Hi! Will look and test that on the weekend. This week is to busy so far...
Meanwhile I wrote to the WaveShare support. That is what they replied to me:
To use the new Driver board, we recommend you to test it with our demo codes (newest) firstly. The new driver board requires the reset time much short. Please modify it to make the delay time shorter than 10ms.
Does this help? I could not compile their Arduino example last week, but I will give it a try if they updated their sketch meanwhile.
Thanks in advance.
It doesn’t make sense to me, Reset has to be high to switch the power on, so what they’ve said suggests reset needs to be high all the time with a short pulse low to reset the display and driver. If this is the case then why don’t they label the reset line as RESET Bar that is a line over the top of Reset to signify its an inverted reset line. On the old HAT Reset is low going high for a reset pulse Reset Bar is high going low for a pulse, I see this lack of labelling consistency a lot with Chinese suppliers I think they don’t know or understand the concept. Good luck, let’s hope it works!
To recap, I think your first test should be to disconnect the display Reset line and wire it directly to 3.3v this will according to the schematic turn on the power to the display and then try a screen update. Ideally measure on the HAT the supply voltage too to ensure it gets switched on, problem is where? as there are no easy places to make a monitoring point...
Hello and thanks for your new comments. I will look at these closer tomorrow.
Just gave the WaveShare examples an extra try, because i cannot believe that this stuff does not seem to be tested at all... Please see the attached file below, which is used for an Arduino UNO as they name in their page (now only? as Arduino board - thought there was an ESP32 named before too?): https://www.waveshare.com/product/displays/e-paper/epaper-1/7.5inch-e-paper-hat.htm https://www.waveshare.com/wiki/7.5inch_e-Paper_HAT#Arduino_UNO Hardware connections were set the same as named on the 2nd tab in the 2nd link.
In the example I still had to correct the imagedata.cpp as linked here: epd7in5_V2.zip
RESULT:
I will continue tomorrow. Have a nice evening. :)
OK, also when you test you should add to your list RST tied to Gnd so we have a comparison between RST high and RST low. I’ve just read the data sheet and they are now saying all lines are active low but that seems to be the opposite of the way the software is currently organised. Interestingly it is only the RST line that has changed between V1 and v2
I've now watched your videos, interestingly the D32 on-board LED which is connected to IO5 does not blink at all, but it should do as it is the device CS:
GxEPD2_BW<GxEPD2_750, GxEPD2_750::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
There is only 1 line of code that should change, so the one above becomes:
GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
According to https://www.waveshare.com/w/upload/8/87/E-Paper-Driver-HAT-Schematic.pdf the CS line is an input, so it should flash the on-board blue LED, but in your video it does not, this suggests that the HAT is loading the CS line, but how?
Can you remove the HAT and run your new HAT code example, the on-board LED should flash as it updates the display. If it does not then the HAT is preventing the CS line from operating, but why?
It suggests the HAT wiring is incorrect or has changed, but the schematic does not show that?
Also, there is no power to the HAT unless RST is held high for the duration of the screen update.
What you can try is adding these commands to your code either the GXEPD demo or Weather display: PinMode(5,OUTPUT); digitalWrite(5, HIGH);
And you may need to repeat this is various places as the display gets reset, so after every begin statement, this will hold the RST line high and power the HAT
And for the new display there is only 1 line that changes to (commenting out the old one above): GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750_T7(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY)); // GDEW075T7 800x480:
Now as CS on the HAT should be an input (just checked on their latest schematic (https://www.waveshare.com/w/upload/8/87/E-Paper-Driver-HAT-Schematic.pdf) and it is, then this points to the HAT not being powered up; although I'd expect the HAT to present a high impedance load, not a low impedance as it appears to now, because RST is not high permanently to enable power to the board and display.
Hello, i try to catch up ;) and tried with the GxEPD2 example now:
### STEP 1: ###
I think that you don't see the LED is related to the very poor video resolution. I needed to compress it several times to stay under the 10MB attachment file size here. With the old HAT it flashed on every update. With the new one very more rare because of the busy timeouts which take longer...
I could not find a line in the example like this:
GxEPD2_BW<GxEPD2_750, GxEPD2_750::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
so i think you tought of this one and changed the line:
GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750_T7(/CS=5/ SS, /DC=/ 17, /RST=/ 16, /BUSY=/ 4)); // GDEW075T7 800x480
to this one:
GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750(/CS=/ EPD_CS, /DC=/ EPD_DC, /RST=/ EPD_RST, /BUSY=/ EPD_BUSY));
it does not compile anymore with "expected primary-expression before '(' token". Please see attached file: "GxEPD2_Example.zip".
### STEP 2: ###
Adding these two lines:
PinMode(5,OUTPUT); digitalWrite(5, HIGH);
showes:
expected constructor, destructor, or type conversion before '(' token
What am i getting wrong? Thanks in advance.
Hi! Will look and test that on the weekend. This week is to busy so far...
Meanwhile I wrote to the WaveShare support. That is what they replied to me:
To use the new Driver board, we recommend you to test it with our demo codes (newest) firstly. The new driver board requires the reset time much short. Please modify it to make the delay time shorter than 10ms.
Does this help? I could not compile their Arduino example last week, but I will give it a try if they updated their sketch meanwhile.
Thanks in advance.
I just sent an email to the support with their demo sketch which has an error in the file "imagedata.cpp" like this:
include "imagedata.h"
//#include <avr/pgmspace.h> // >>> wrong - did not compile
// Working workaround:
if defined(AVR)
include <avr/pgmspace.h>
else //defined(AVR)
include
endif //defined(AVR)
After this the sketch can be uploaded to the Arduino UNO, but does not work too with the 2.1 revision HATs. It also works with the old HATs only.
I asked them to provide a tested solution with the 2.1 revision HATs because in their wiki/product page the old HATs are shown only too. See the pictures in: https://www.waveshare.com/7.5inch-e-paper-hat.htm There the old HAT is shown too.
To recap, I think your first test should be to disconnect the display Reset line and wire it directly to 3.3v this will according to the schematic turn on the power to the display and then try a screen update. Ideally measure on the HAT the supply voltage too to ensure it gets switched on, problem is where? as there are no easy places to make a monitoring point...
Tried this, but does not update with the GxEPD2 sketch as in the previous tests. I could not find a valid monitoring point to measure this too.
OK, also when you test you should add to your list RST tied to Gnd so we have a comparison between RST high and RST low. I’ve just read the data sheet and they are now saying all lines are active low but that seems to be the opposite of the way the software is currently organised. Interestingly it is only the RST line that has changed between V1 and v2
Tried this, but does not update with the GxEPD2 sketch as in the previous tests.
I have no idea any more. Hope that the support has a look at their demo sketch and then they might find a solution. I think the new HATs are not working with Arduinos at all. I will try with a Raspberry Pi later today.
The commands should be: pinMode(EPD_RST, OUTPUT); digitalWrite(EPD_RST, HIGH);
or
digitalWrite(EPD_RST, LOW);
It's worth trying both.
if you were getting 'xpected constructor, destructor, or type conversion before '(' token' then that was a syntax typo/error.
If tying RST to 3.3v and testing or RST to Gnd and then testing, then it does look like there is a HAT issue. Waveshare should have tested the boards before release, let's assume they did. So the only possibility is they work with the RPi and in-which case for other customers they are of no use!
If they can confirm HAT-1 and HAT-2 work, then it's a GxEPD2 issue.
Thanks!
Tried it with HIGH and LOW with the corresponding connection without success.
The test with an Raspberry Pi 3B+ with the old and new HAT works fine.
Well that confirms that their new HAT has excluded a major part of their market, how mad is that. Given that the old HAT is no longer available then this is a crazy change, either that or they retain the HAT-1 for microcontroller use.
I hope they prove us wrong, but actually i think the same way... Lets see if they come up with an working Arduino UNO example for the new HAT. Maybe then there is some hope to get this working with the ESP32 as well.
I use Raspberry Pi here for some Smart Mirrors which also host my local git repository and some other services used for Smart Home and NAS usage, but i do not get the idea about using ePaper displays on Raspberry Pi's which need to be powered all the time...
Your super nice weather station here now runs at my house more then 5.5 months without recharging the battery and still is at about 89%... Some of my other projects like a random picture frame almost get similar values and i think this is great to have such gadgets you can control and design yourself...
I tried to get "old" 7.5" displays and also some more old HATs but without success in the last weeks. I received always the newer versions. I still have some old HATs, but not enough for some new ESP32 powered ideas like this next one, where the higher resolution makes a visible difference compared to the old displays:
Lets see if and how they reply.
Thanks a lot again and have a nice weekend! :)
Happy to help. I’ve sent Waveshare an email explaining the problem on the basis that the more complain the more likely they are to resolve the issue. I don’t know how it passed basic quality checks as clearly it’s incompatible with any but a RPi, a silly mistake. The easy solution is to sell the old version as an Arduino variant. If I hear back I’ll let you know.
Hello :)
Got some news from WaveShare today:
They wrote to modify the reset function in their Arduino UNO example sketch to reduce the dalay time to 2ms:
`// Changed from 4ms: /**
// Changed to 2ms: /**
Here as updated sketch too: epd7in5_V2 with 2ms Reset time.zip
That seems to help for their Arduino Uno code. I could update the display with the very slow working Arduino Uno with all my 2.1 HATs and their demo picture was shown.
I have not looked for a similar function in your sketch or i thing i have to take a look in the GxEPD code, right?
Thanks in advance :)
Interesting, it’s the GxEPD2 code that needs to be modified, https://github.com/ZinggJM/GxEPD2/blob/master/src/GxEPD2_EPD.cpp
Scroll down to line 69 you will see the reset function there, the delay used is 20mS not 2mS. You can adjust your library file to try it out, make a back up first then reduce the 20 to 2mS
After changing all three "20ms" values to "2ms" it seems to work :) Finally :)
void GxEPD2_EPD::_reset() { if (_rst >= 0) { if (_pulldown_rst_mode) { digitalWrite(_rst, LOW); pinMode(_rst, OUTPUT); delay(2); // AWSW 20 to 2 pinMode(_rst, INPUT_PULLUP); delay(200); } else { digitalWrite(_rst, HIGH); pinMode(_rst, OUTPUT); delay(2); // AWSW 20 to 2 digitalWrite(_rst, LOW); delay(2); // AWSW 20 to 2 digitalWrite(_rst, HIGH); delay(200); } _hibernating = false; } }
That seems to be a solution.
To recap (maybe for other users helpful):
Thanks a lot! Have a nice evening.
You should let the GxEPD2 author know this is a working solution for the new HAT as it’s the only one now available, do that via Github
I’m very pleased this is solved, Waveshare need to update their documentation too, let’s hope they do.
You should let the GxEPD2 author know this is a working solution for the new HAT as it’s the only one now available, do that via Github
Will do tomorrow. Good point. Might help others too.
I’m very pleased this is solved, Waveshare need to update their documentation too, let’s hope they do.
Yes, they have to. I wrote them a mail, about the issues I found regarding this all and asked them to update their example sketch too.
Thanks 😊
I am not able to report that to ZinggJM in the GxEPD2 repo. It has no Issues section i could write about this... https://github.com/ZinggJM/GxEPD2
Any ideas how to contact her/him?
Thanks in advance.
Unfortunately not, he’s removed issues reporting and his profile does not show an email address, I guess sooner or later he will realise and make an adjustment. Silly really as it needs to be done. I tried looking on the Arduino forum for home but it’s equally as difficult to reach home via that path.
OK, let’s hope it’ll be in the official release soon.
Thanks a lot 😊
Hello,
i hope you can help me with the new version of the 7.5" (800x480) displays and the 16.8th version?
I updated all libraries to their newest version and used the same wiring on my Lolin D32 board that i used so far with the lower resolution 7.5" WaveShare (640x384) displays.
I just entered my Wifi, API, city credentials and selected my language file in the main .INO file. The compile and upload to the board works just fine.
In the Arduino IDE monitor i can see that the weather data is downloaded and the voltage is shown. Usually then the display should be updated. But then i can see 3 "Busy Timeout" messages only and the ESP32 goes to sleep... The information is not displayed then of course... I tried 2 different displays and Lolin D32 boards.
I think the display is not found, but i am not sure, because when i upload an 16.7th version sketch to the same Lolin D32 and connect it to an old 7.5" display it just works fine.
I could not find a changed configuration of the connections in the 16.8 sketch or am i wrong?
Thank you in advance. :)