Repository navigation
Add support for LiquidCrystal #15
Description
LiquidCrystal is the built in LCD lib that ships with Arduino, see also: http://www.arduino.cc/en/Reference/LiquidCrystal
I'm not going to pretend that this will be a simple "drop-in" addition, it will definitely require a new handler in du.ino, but I can promise that it will be totally awesome!
Activity
adamavenir commentedon Dec 28, 2012
Wow, yes. This would be awesome indeed.
natevw commentedon Jan 2, 2013
Hoping to tackle this over the next couple days. Unless there are objections/better ideas, I'll likely add a new message type(s) to the protocol so the device-side LiquidCrystal can do most of the work.
natevw commentedon Jan 3, 2013
Started in on Plan A, but the trouble with using LiquidCrystal on the device side is the text-based framing protocol used to communicate via node.js and the board — printing text and creating characters would need to be specially escaped which would be a PITA. Might still do this, but ends up very ugly.
Plan B is that LiquidCrystal.cpp is only 300 lines and if ported to JS could simply use existing digitalWrite commands and delay. Delay also sucks in node.js land, but since that's already implemented on board...
ecto commentedon Jan 3, 2013
How do you feel about a Plan C of transitioning to Firmata? Or allowing both protocols, and keeping the simpler classes on the text-based one?
natevw commentedon Jan 3, 2013
Essentially, transitioning to Firmata would get rid of this library's du.ino component? Would this library then simply provide higher-level classes on top of e.g. another node.js Firmata library?
That would still mean Plan B for me as Firmata only provides (AFAICT) the same pin-level read/write functionality as this does. In many ways porting LiquidCrystal to JS is cleaner, the main drawbacks are the command delaying (which ultimately might be better implemented as a buffer mode that empties after timeout instead of a do-while spin loop) and not being able to swap in other LiquidCrystal-compatible libraries for I2C, etc. driven displays.