I am porting one of my exiting projects from an earlier ATmega128 based design to a new version where I am using a Wemos D1Mini pro (see https://wiki.wemos.cc/products:d1:d1_mini_pro).
While porting my existing (ATmega128) software I ran into a weird effect: I had already added "trace output" to the steps of my "setup" code and verified that the respective code completed successfully on the D1Mini.
So I moved on to the "loop" code and started to re-enable stuff that I had out-commented earlier: But all of a sudden the previously functioning "setup" logic NO LONGER worked correctly.
The only explanation that I could imagine, was that my binary had grown (due to the extra "loop" code that had probably earlier been removed by the optimizer while it was still unused). And maybe my code size now exceeded some kind of "D1 pro mini" limitation.. To verify the hypothesis I managed to somewhat reduce the code size (by dropping some actually unused stuff) and indeed the "setup" problem disappeard again..
My compile output .bin file (the one that still seems to work) is now 264064 bytes large, and the earlier 268000 bytes version had failed miserably.
From what I see the "D1 mini pro" has 16MB of Flash and I am therefore surprised to run into these problems with some binary that is little more than 256kB ..
Maybe I am using some wrong board config?
esp8266/2.3.0/
WeMos D1 R2 & Mini
CPU freq; 160MHz
Flash size; 4M (3MSPIFFS)
Says the board has only a 4Mb flash memory chip and 3Mb of that is being used as a virtual file system.
The problem might not be code size but something simple like a long execution time function you have un commented that does not yield or delay so the wi-fi can maintain it's houskeeping.
Put serial print statements in key parts of your code to determine where the processor stalls or triggers a watchdog reboot.
Riva:
The problem might not be code size but something simple like a long execution time function you have un commented that does not yield or delay so the wi-fi can maintain it's houskeeping.
Put serial print statements in key parts of your code to determine where the processor stalls or triggers a watchdog reboot.
I doubt that "long execution time" can be the explanation here (unless I am missing something ESP8266 specific): As far as I know the Arduino "setup" hook is completed before any "loop" hook calls are made (I even added a separate "initCompleted" flag that I am checking in "loop" to skip the "loop" code in case it was ever invoked before "setup" is done.. the problem is triggered WITHOUT any additional "setup" code)
Even if there was something "long running" in my uncommented "loop" code this should therefore NOT be able to affect the behavior of my "setup" code..
I already have print statements (to some I2C based LCD) in my respective "setup" code - that is how I saw that the code suddenly got stuck at an earlier stage in "setup" after I added code in "loop"..
I meanwhile noticed that the old "Arduino 1.6.4" IDE mentions a limit of 81920 bytes for "Global variables" (when compiling ESP8266 example code).. unfortunately the Sloeber IDE does not seem to output the respective "dynamic memory" usage - so I don't know if my code might be running into that limitation (unfortunately my multi-file .h/.cpp project no longer can be compiled with the old IDE).
(eventhough something in this calc does not correctly add up to the actually uploaded .bin size, it seems reasonable to assume that my program is nowhere near the respective limits..)
You've not given much of a concrete problem description, but I guess if it was a watchdog timer issue, you'd have mentioned the error message.
You are using I2C. Do any of the libraries you are using call Wire.begin() in their constructor function ? I did have a crash problem recently which turned out to be exactly that in an old RTC library, and it only appeared when I recompiled it using a newer version of the ESP8266 Arduino core software.
6v6gt:
You've not given much of a concrete problem description, but I guess if it was a watchdog timer issue, you'd have mentioned the error message.
You are using I2C. Do any of the libraries you are using call Wire.begin() in their constructor function ? I did have a crash problem recently which turned out to be exactly that in an old RTC library, and it only appeared when I recompiled it using a newer version of the ESP8266 Arduino core software.
To complete my problem description:
My "setup" function is instrumentalized with dbgTrace calls between the actual program steps, so that I see how far the code gets (in case something fails), e.g.:
setupComplete= false;
trace("starting");
if (!doSomethingSuccessful()) return;
trace("checkpoint 1");
if (!doSomethingElseSuccessful()) return;
trace("checkpoint 1");
...
trace("setup complete");
setupComplete= true;
As long as all my code in the "loop" function was commented the above "setup" completed successfully.
Problem: as soon as I uncommented all of my code in the "loop" function the stuff in the "setup"(!) function started to fail (eventhough "loop" code at that point was not yet executed and should NOT influence anything that goes on in "setup").
That being said I meanwhile realized that some of the (other) weird behavior is indeed linked to I2C: I had already moved a "Wire.begin()" call (in the RTC lib that I am using) from the respective DS1307RTC constructor to the lib's read/write functions (this might be the same issue that you experienced). I then also already found that for some reason I couldn't get any of the EEPROM libs (neither extEEPROM nor I2C_eeprom) to work in 100kHz mode (something that works fine in my earlier ATmega128 and AT328 based projects). I am therefore now using the 400kHz mode for all of my I2C stuff by setting the respective clock rate after each and every Wire.begin():
Wire.setClock(400000L); // 400kHz
After this change the I2C_eeprom lib now seems to work, as well as the LiquitCrystal+ and the DS1307RTC (eventhough I did not test it very thoroughly yet).
But some I2C related issues still seem to remain: I had had the impression that sometimes the device would fall into some crashed mode and none of my attempts to re-flash some "known good" example code would bring it back to life (i.e. the LCD display would just stay dead..). But I finally realized that it is not actually the device that is crashed but the LCD display / or rather it's respective I2C adapter.. which is quite annoying since that state may persist for quite a while even when completely unplugging the power supply of the device.
So the problem here might be somehow related and maybe it is just the display that hangs rather than the complete device, however it seems to me that this is actually a different scenario and the display here is not completely crashed (unlike the other scenario), since it still displays different status messages after each restart of the device.. (I guess I'll add some LED flashing so that I can more easily see if the device is still alive - even when the LCD is frozen--)
It does look like it is an issue of specific code incomptability between the Atmega186 and the ESP8266 which you are porting the software to. It can't believe that it is a memory resource issue because the ESP8266 outclasses the Atmega186 here in all respects.
Maybe systematically test each I2C device (and any other peripheral device or library routines ) in its own dedicated sketch before testing the whole suite together. Also, maybe suspect that the debug messages you use to determine how far setup() gets may give misleading results (if, for instance, a later system activity prevents these appearing on the console etc.)
I had other porting issues, just as an example:
Wire begin() required specific pin assignments: Wire.begin(sdaPin, sclPin);
An I2C bus expander chip MCP23016 failed with the ESP8266 and I had to remove a timing capacitor to get it to work.
setup() failed if things took too long. I even had to abandon setup() and create my own setup1() which was called one time from the loop() to get around that problem. This after finding reports such as this (which may have been solved in the meantime): WDT fires if setup() takes more than 1 sec · Issue #34 · esp8266/Arduino · GitHub
void ICACHE_FLASH_ATTR setup() {
// dummy - standard setup() does not appear to tolerate long activity.
}
void ICACHE_FLASH_ATTR setup1() {
//
// standard setup() does not appear to tolerate long activity.
//
swSerial.begin(115200);
. . .
. . .
}
void loop() {
static bool setupRun = false ;
if ( ! setupRun ) {
// workaround for crash in prolonged setup()
setup1() ;
setupRun = true ;
}
. . .
. . .
}
But all of a sudden the previously functioning "setup" logic NO LONGER worked correctly.
The only explanation that I could imagine, was that my binary had grown (due to the extra "loop" code that had probably earlier been removed by the optimizer while it was still unused). And maybe my code size now exceeded some kind of "D1 pro mini" limitation..
That seems a very unlikely explanation, to me. Did the compile SAY you were out of space?
Moving to a slightly different platform can make all sorts of "uninitialized data" and "buffer overflows" show up, even when they didn't in your old code...
From what I see the "D1 mini pro" has 16MB of Flash
Maybe I am using some wrong board config?: Flash size; 4M (3MSPIFFS)
I'm not happy that "16MB" and "4MB" don't match, and some vendors are a bit loose on using "16Mbyte" vs "16Mbit" (cloners; WeMos themselves should be OK) I don't THINK that having a smaller config'ed memory than actual memory will cause problems, but I'm not sure...
I doubt that "long execution time" can be the explanation here (unless I am missing something ESP8266 specific): As far as I know the Arduino "setup" hook is completed before any "loop" hook calls are made ...
It does not matter where the long execution code is. If it is too long between yield() calls, it will watchdog.
things like delay() call yield() for you.
If a watchdog does occur, you will get a message on the serial port but you need to ensure that the baud rate is 115200 to see it.
So if you are logging to the serial port, run it at 115200 so you can see any watchdog or crash messages should they occur.
Are you using 5v I2C slaves? If so, how are you level shifting the signals?
bperrybap:
It does not matter where the long execution code is. If it is too long between yield() calls, it will watchdog.
things like delay() call yield() for you.
If a watchdog does occur, you will get a message on the serial port but you need to ensure that the baud rate is 115200 to see it.
So if you are logging to the serial port, run it at 115200 so you can see any watchdog or crash messages should they occur.
Are you using 5v I2C slaves? If so, how are you level shifting the signals?
--- bill
"It does not matter where the long execution code is.": That makes no sense at all - at the point where the problem occurs in "setup" NONE of the "loop" code has been invoked yet. So even if "loop" code completely hung the device, that should NOT interfer with the PREVIOUSLY running "setup" code.
Btw, all my setup code runs in a section where I first set:
ESP.wdtDisable();
so the watchdog should actually be disabled.. unless that functionality does not properly work on ESP8266..
All my I2C slaves (2x EEPROM, 1x LCD + 1x RTC) run on 3v3 so there is no level shifting needed.
PS: I am not using the Serial for any debug messages - on the contrarry I am trying hard to disable all the respective ESP8266 built-in log output since I am using the Serial to let the device communicate with my PC application (while it is directly plugged in..) and free text error/info messages mess up the respective protocol.. (I am therefore displaying all my trace-log messages on the device's LCD. And here is actually one potential problem since that I2C based display might no longer work correctly IF something goes wrong on the I2C level, i.e. when my "setup" related trace output stops it may actually mean one of 2 things: either the respective setup step has really failed or the LCD has crashed and it just does no longer display any new messages.)
westfw:
That seems a very unlikely explanation, to me. Did the compile SAY you were out of space?
Moving to a slightly different platform can make all sorts of "uninitialized data" and "buffer overflows" show up, even when they didn't in your old code...
I'm not happy that "16MB" and "4MB" don't match, and some vendors are a bit loose on using "16Mbyte" vs "16Mbit" (cloners; WeMos themselves should be OK) I don't THINK that having a smaller config'ed memory than actual memory will cause problems, but I'm not sure...
No, I am not getting any compiler errors. (Just to see how the complier reacts I did a test by adding some "char TEST[60000]; and with that the compile actually fails with some "elf*.." message. So I guess that would be the error I would be getting if the 81920 bytes for "Global variables" limit was exceeded.. but that does not seem to be the case with my regular code)
I just picked 4MB setting that was suggested in respectice WeMos examples.. (unfortunately there does not seem to be a 16MB setting but since I am not using the SPIFFS space anyway, I figured that in might not matter..)
PS: Maybe there still is some problem with my I2C setup - which occasionally might cause the LCD to stop working correctly (for the most part it seems to be working fine). Actually it puzzles me why I had not been able to get the I2C stuff to work with my original/old 100kHz settings - it seems to work now that I am using 400kHz (and I am happy to use the faster mode) BUT there should not by any reason for 100kHz not to work, shouldn't there? Maybe something wrong with my I2C Bus Pullup Resistor? (the LCD adapter as well as the RTC comes with a 4.7kOhm built-in pullup resistor and I am not adding any resistor on my own, so I guess my circuit uses the combination of what comes with the RTC / LCD plus whatever the uP might be supplying directly on its respective SDA/SCL pins... this approach works fine on my earlier ATmega128 based circuit - which was 5V based though - but maybe it isn't suitable for the 3v3 ESP8266?).
When measuring the resistance (D1 pro mini pro disconnected, i.e. without the ESP8266's built-in resistor) I am getting 2.3kOhm (SDA/SCL to VCC). Supposing the built-in ESP8266 pull-up is 22kOhm then my combined pull-up might currently be 2.08kOhm. From the calc to be found here: Silicon Labs Community the range for the resistor for 400kHz mode is given as 1.77kOhm-171kOhm.. and my combined resistor seems to be at the low end of that range.. maybe I should better remove one of the built-in resistors (either on the RTC or on the LCD..)
PPS: I just removed the built-in pull-ups from the LCD adapter so there should now only be the 4.7kOhm from the RTC plus whatever built-in pull-up the ESP8266 might be using on its SDA/SCL pins.. it remains to be seen, if this HW change brings any improvement. I already tested that the device still DOES NOT work in 100kHz mode even after this change.. 4.7kOhm might still be too low for 3v3 use - probably for the EEPROM, which according to this (http://ww1.microchip.com/downloads/en/DeviceDoc/21203P.pdf) data sheet typically needs something closer to 10kOhm.. (interesting though that it worked fine with even lower pull-ups in my old circuit..)
Regarding the problems in 100kHz mode: When I use 100hHz instead of 400hHz the device now goes into some kind of autoreset loop and which each restart the below error message is dumped to the Serial console (unfortunately I do not have the faintest idea what it might mean):
wothke:
"It does not matter where the long execution code is.": That makes no sense at all - at the point where the problem occurs in "setup" NONE of the "loop" code has been invoked yet. So even if "loop" code completely hung the device, that should NOT interfer with the PREVIOUSLY running "setup" code.
Obviously, what I was saying is it doesn't matter whether the long execution code actually being run is in setup() or loop() not that unexecuted code can cause a watchdog.
Btw, all my setup code runs in a section where I first set:
ESP.wdtDisable();
so the watchdog should actually be disabled.. unless that functionality does not properly work on ESP8266..
I believe that there are two watchdog timers in the ESP part (A "s/w" one and a "h/w" one)
I don't think user code can disable the second one.
So I don't think there is ever a way to fully disable watchdog timeouts.
All my I2C slaves (2x EEPROM, 1x LCD + 1x RTC) run on 3v3 so there is no level shifting needed.
What LCD device are you using and do you have enough 3v power to power it?
What s/w are you using to run it, an Arduino library or your own?
I think at this point, we need to start seeing your actual code.
wothke:
Regarding the problems in 100kHz mode: When I use 100hHz instead of 400hHz the device now goes into some kind of autoreset loop and which each restart the below error message is dumped to the Serial console (unfortunately I do not have the faintest idea what it might mean):
That is a an odd one in that I would not expect the speed of the i2c interface to affect this type of error.
It could be that the real issue (that occurred before this issue) is caused by something else.
You may want to try installing the esp8266 crash analyzer IDE extension to be able to look into the backtrace and see where it is happening.
bperrybap:
I believe that there are two watchdog timers in the ESP part (A "s/w" one and a "h/w" one)
I don't think user code can disable the second one.
So I don't think there is ever a way to fully disable watchdog timeouts.
yes, I think I had also read that somewhere..
bperrybap:
What LCD device are you using and do you have enough 3v power to power it?
What s/w are you using to run it, an Arduino library or your own?
I am using the "LiquidCrystal+" library - it's been a while but if I remember correctly there was some minor bug-fix that I had to add at the time to make it run reliably (I think it had to do with adding 2 microsecond delays around the "write's" Wire.endTransmission().. which solved display issues that this lib had originally had when using it with my AT328P/ATmega128)
My regular prod-device will be powered via a 12V power supply/battery and I am using a 1A buck converter to create the 3v3. However, for the tests that I had done so far, I had actually NOT separately powered the D1mini but just used the built-in USB connector, i.e. with a potentially weak 5V USB connection and whatever built-in 3v3 converter the D1 might be using, reliable 3v3 power supply might indeed have been a problem during my tests.. (but then again it is funny why I don't see any problem as long as it's 400kHz mode)
That is a an odd one in that I would not expect the speed of the i2c interface to affect this type of error.
It could be that the real issue (that occurred before this issue) is caused by something else.
thanks for the link. It also says "Access to Cache after it is turned off" there. I guess I'll have to find out what kind of scenario that might be..
bperrybap:
You may want to try installing the esp8266 crash analyzer IDE extension to be able to look into the backtrace and see where it is happening.
is that extension available for Sloeber or only for the old Arduino IDE?
wothke:
I am using the "LiquidCrystal+" library - it's been a while but if I remember correctly there was some minor bug-fix that I had to add at the time to make it run reliably (I think it had to do with adding 2 microsecond delays around the "write's" Wire.endTransmission().. which solved display issues that this lib had originally had when using it with my AT328P/ATmega128)
I'm familiar with probably close to 20 different "LiquidCrystal" type libraries but I've never heard of "LiquidCrystal+".
You could try my hd44780 library. For a LCD using a PCF8574 based backpack, use the hd44780_I2Cexp i/o class.
It has been fully wrung out on the ESP8266 parts.
You can install it using the IDE library manager. Run the included I2CexpDiag sketch to verify that things are working.
It will test the i2c signals for pullup resistors and then test the internal RAM of the LCD.
It will be faster than other libraries as it allows the Arduino processor to run in parallel with the LCD command execution.
You can read more about it here: GitHub - duinoWitchery/hd44780: Extensible hd44780 LCD library
with a potentially weak 5V USB connection and whatever built-in 3v3 converter the D1 might be using, reliable 3v3 power supply might indeed have been a problem during my tests..
I'm not sure how much current the on-board 3v regulator can supply.
You may want to check the current draw for the LCD. If it is a 20x4 the backlight can be a fairly large draw.
Another thing I've run into with the Wemos D1 mini and an i2c backpack based LCD is that when I used it on a bread board with other I2C devices like a DS3231 RTC, I needed to had some decoupling to the power going to the LCD or I occasionally saw communication issues. The PCF8574 appeared to lock up and stop responding.
In my case I run the LCD module at 5v and use a low cost 3v<->5v level shifter.
With an additional 0.1uf decoupling I didn't have any issues.
bperrybap:
You could try my hd44780 library. For a LCD using a PCF8574 based backpack, use the hd44780_I2Cexp i/o class.
Thanks for the offer and I might try it just for testing purposes. Unfortunately I'll not be able to use it regularily since GPL is such a pain in the a.. license and I'll not use any libs that would restrict me to using GPL libs only..
bperrybap:
I'm not sure how much current the on-board 3v regulator can supply.
You may want to check the current draw for the LCD. If it is a 20x4 the backlight can be a fairly large draw.
The D1 mini supposedly is using a RT9013 (maybe the mini pro is using the same..) and that should be good for 0.5A . I am using a 20x2 display and from what I found the worst case (with backlight) might be 160 mA (but it could also be much lower, e.g. 40mA)
bperrybap:
Another thing I've run into with the Wemos D1 mini and an i2c backpack based LCD is that when I used it on a bread board with other I2C devices like a DS3231 RTC, I needed to had some decoupling to the power going to the LCD or I occasionally saw communication issues. The PCF8574 appeared to lock up and stop responding.
In my case I run the LCD module at 5v and use a low cost 3v<->5v level shifter.
With an additional 0.1uf decoupling I didn't have any issues.
That sounds like something that I should look into (eventhough the LCD lock ups that I experienced so far, seemed to be reproduceably linked to specific .bin uploads). (I had actually selected the 3v3 LCD version so that I could save the PCB space needed for the extra level shifter.. and keep things simple..)
I looked at my circuit again and I need to correct what I had said earlier: I am actually using the 1A buck converter to create 5V (not 3v3) from 12V and I am using the D1's built-in regulator to draw the 3v3 (i.e. whatever 3v3 stuff I am using - I2C plus ESP8266 - should better not use more than 0.5A).
How would I go about adding "decoupling" (I am not an electronics guy)?
wothke:
Thanks for the offer and I might try it just for testing purposes. Unfortunately I'll not be able to use it regularily since GPL is such a pain in the a.. license and I'll not use any libs that would restrict me to using GPL libs only..
While GPL v3 has a big restriction that forces the entire project/product to be open source, GPL v3 does not restrict a project to using only GPL libs. (yes, if any code used in the project is not GPL v3 then the code must be license compatible with GPL v3)
MIT and BSD libs are license compatible and can be used with GPL v3. However, GPL v3 requires that the entire work be open source and the linked together work will fall under GPL v3 rules even though there are other internally used components that are not GPL v3.
If you are avoiding GPL v3 or other restrictive licenses, keep in mind that there are several other Arduino libraries out there that are using CC BY-SA 3.0
CC BY-SA 3.0 is unsuitable for s/w. It has to be the absolute worst license for s/w as it isn't compatible with anything but CC BY-SA 3.0 so legally it can't be used with anything with any other license. i.e. it isn't compatible with Arduino.
I've been working with several Arduino authors to fix/correct/change their CC-BY-SA licenses to LGPL/GPL to help clear things up.
In a few cases from CC BY-SA 3.0 to CC BY-SA 4.0 but that license is only compatible with CC BY-SA 4.0 -OR- a onetime convert clause that can be exercised to convert the code to GPL v3. But once that is done the code can't ever go back so people who take the code and convert it to gpl v3.0 to be able to use it with other code can never contribute any improvements made go back to CC BY-SA. And the original author loses control since the code is then forever GPL 3.0
Because of these reasons authors often choose to switch away from CC BY-SA licensing to something else that they like and and can maintain control.
Which "LiquidCrystal" library are you using?
Pretty much all of them are derivatives of the LiquidCrystal library bundled with the IDE which is licensed LGPL 2.1+
The LGPL license terms pretty preclude its use in closed source products based on Arduino, given the Arduino development environment. i.e. there is no way to satisfy the clauses that require that a user be able to modify and replace the LGPL code with his own version.
I've seen several "LiquidCrystal" arduino library authors that have improperly (and illegally) relicensed their "LiquidCrystal" derivative code as BSD or MIT or some other less restrictive license but they legally can't do that as the code they were derived from was LGPL 2.0+ which doesn't allow changing to those licenses even for derivatives.
The Author can legally convert their derived work to LGPL 3.0 or GPL 3.0 but they can not convert it to BSD or MIT or CC-BY-SA.
Here are the most popular "LiquidCrystal" type libraries that I'm familiar with that support
a PCF8574 based backpack:
hd44780 is GPL v3
fm's newLiquidCrystal was originally illegally set to CC BY-SA 3.0 but is being corrected by converted over to GPL v3
(There are many derivations of this library floating around but legally they all must be GPL 3.0 just like newLiquidCrystal must be - because it is using some LGPL 2.1+ code and some GPL v3 code)
LiquidCrystal_I2C in the IDE library manager
is missing licensing information; however, it was derived from a library by Mario H that goes back to 2009.
Mario licensed his code as LGPL 2.1+
(There are MANY MANY derivations of this library floating around out there and most don't have any licensing information specified - but legally they are LGPL 2.1+).
Pretty much any "LiquidCrystal" library out there, regardless of the license the author may be claiming, is really legally licensed as LGPL 2.1+ since they all are derivations of code that was originally licensed as LGPL 2.1+
How would I go about adding "decoupling" (I am not an electronics guy)?
Put a 0.1uf capacitor across the power lines on the 4 pin header going to the LCD module.
bperrybap:
If you are avoiding GPL v3 or other restrictive licenses, keep in mind that there are several other Arduino libraries out there that are using CC BY-SA 3.0
CC BY-SA 3.0 is unsuitable for s/w. It has to be the absolute worst license for s/w as it isn't compatible with anything but CC BY-SA 3.0 so legally it can't be used with anything with any other license. i.e. it isn't compatible with Arduino.
I've been working with several Arduino authors to fix/correct/change their CC-BY-SA licenses to LGPL/GPL to help clear things up.
.... Which "LiquidCrystal" library are you using?
I checked.. the lib is by some Francisco Malpartida (in the bundled docs it's called "LCD Library 1.2.1") and it claims to be CC BY-SA. I guess that this might be one of those cases of an incorrectly specified license but how you correctly pointed out already, this license would be just as useless to me as a GPL. I guess I'll have to look for a suitably licensed replacement lib anyway and in the worst case I'll have to write something on my own (which of couse would be an annoying waste of time - but from what I see the kind of MickeyMouse code needed to drive my specific I2C 20x2 1602 LCD wouldn't be too much work either.. and certainly no reason to accept a shitty license).
Regarding LGPL: Since I am not interested in "closed source" stuff, that license should be acceptable. I guess I'd keep sufficient control over my work.
wothke:
I checked.. the lib is by some Francisco Malpartida (in the bundled docs it's called "LCD Library 1.2.1") and it claims to be CC BY-SA. I guess that this might be one of those cases of an incorrectly specified license but how you correctly pointed out already, this license would be just as useless to me as a GPL.
Yes that was an improper license. I've been pushing on fm to fix this for a while.
The latest from a few weeks ago, is that fm will be correcting this by moving the library to GPL v3.0
I guess I'll have to look for a suitably licensed replacement lib anyway and in the worst case I'll have to write something on my own (which of couse would be an annoying waste of time - but from what I see the kind of MickeyMouse code needed to drive my specific I2C 20x2 1602 LCD wouldn't be too much work either..
Actually, it will be quite difficult to find any "LiquidCrstal" Arduino library that isn't already LGPL or GPL.
(I have looked at dozens over the past 10 years)
Every Arduino "LiquidCrystal" library that I've seen was either LGPL, GPL or was improperly changed to something else.
I've even seen a few that blatantly started with or copied another LGPL based work and simply removed or changed the licensing and copyright information.
Something else to keep in mind is that while LGPL does allow the creation of a " work that uses the library" vs a derivative, the use of C++ class inheritance pushes the code into being a derivative work.
i.e. if you created your own LCD library entirely from scratch not using any other code (which is quite a bit work), but then inherited the Arduino Print and/or the Wire class, then your code becomes a derivative work, even though all your code was original non derived code.
So while it is possible to create a non GPL "LiquidCrystal" type library, it becomes quite difficult to be LiquidCrystal API compatible given the Print class or any other library class (including Wire) can not be inherited.
and certainly no reason to accept a shitty license).
GPL isn't a shitty license. You just don't appear to like it.
The entire linux kernel is GPL v2.
GPL v3 has some additional requirements over GPL v2 which is why many people/businesses, especially those creating commercial products don't like GPL v3.
The biggest value of GPL v3 to authors over GPL v2 is that it precludes its use in closed source projects which precludes its monetization in closed source products.
Regarding LGPL: Since I am not interested in "closed source" stuff, that license should be acceptable. I guess I'd keep sufficient control over my work.
For an open source project, there will be little difference between LGPL and GPL, especially GPL v2.
In the Arduino environment it would be very difficult to avoid being at least LGPL, given that the code is linking against or inheriting from LGPL based code - which makes the code subject to LGPL licensing terms.