search

ecto / duino

:bulb: Arduino framework for node.js
958 stars 214 forks source link

Add support for LiquidCrystal #15

Closed rwaldron closed 11 years ago

rwaldron commented 12 years ago

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!

sockdrawermoney commented 11 years ago

Wow, yes. This would be awesome indeed.

natevw commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.