The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Just a quick preview of the next go!bus module I'm working on -- a character LCD!
This module works with most standard HD44780-compatible character LCDs. Above is a picture of a prototype with a white-on-blue LCD, and here's a picture of the module connected to the mainboard:
The small component near the module connector is a potentiometer for setting the display contrast.
This module will also support LCDs with RGB backlights. With RGB backlit LCDs you will be able to set the color and brightness of the backlight, similar to how you set the color of the RGB LED module.
More information coming soon! It will be at least another month before this module is available for sale, but I'll post more information in this thread when it becomes available
This module will also support LCDs with RGB backlights. With RGB backlit LCDs you will be able to set the color and brightness of the backlight, similar to how you set the color of the RGB LED module.
I think my heart just skipped a beat
We're creating v2.0 of our automated test jigs. They're the Netduino-powered machines that test every Netduino off the assembly line. The new ones are powered by Netduino Go, and I think we just found our petite character display
Nicely done. Is it setup like an LCD backpack so we can easily connect our own choice of LCD? Say a 4x20 RGB Backlit?
I am planning on selling this module fully assembled, with an LCD attached so no soldering is required. There will likely be several LCDs to choose from (e.g., positive RGB, negative RGB, and white-on-blue).
If you (or anyone else) would like to purchase the module without an LCD, please let me know once the modules are available and I'll be happy to send you one with a discount. If there's enough demand I might make that option available on the store as well.
Regarding other sizes -- this shouldn't be a problem, but I will need to do some testing to be sure. The PCB has been sized around a standard 16x2 display, but it should also work with other HD44780 displays as long as they have the same pin configuration. The display will be a bit bigger than the module, but that shouldn't cause too much trouble unless it hangs over the module connector on the left. You may need to make some changes to the module drivers, but I'll try to make sure the module firmware works for either situation.
Regarding other RGB displays -- the board is currently designed around an RGB display that has a common cathode line. I think the only 20x4 RGB LCD I've seen is the one sold at Adafruit, and that has a common anode backlight so it wouldn't work with this module in its current configuration.
By the way, I did some testing with Adafruit's 16x2 RGB LCDs (which are also common anode) but I found a few problems with them. First, they appeared to be STN displays (similar to the one pictured in the original post) and had a blue tint in the dark areas rather than the deep black you get with FSTN displays. Also, while they feature integrated backlight resistors, the largest resistor was on the common anode line. The RGB cathode lines each had 10 ohm resistors, but the anode line had a 100 ohm resistor. As a result, I wasn't able to turn all three colors on at once and mixing colors turned out to be pretty difficult as well.
The datasheet for their 20x4 RGB display says it has an FSTN LCD, so it should be better in that regard but I'm not sure what its resistor configuration is. Regardless, since it's common anode it wouldn't work with this module but I might be able to make some changes to accommodate that.
With the HD44780 interface, it's possible to add custom characters:
http://www.circuitva...44780-16x2.html
In the HD44780 datasheet, page 17, table 4, you'll see all supported characters:
http://lcd-linux.sou...ocs/hd44780.pdf
I'm not too familiar with the greek characters, but this may help.
Matt: are you going to support all HD44780 commands, or at least keep the option open to send raw data to the display, so people can extend this themselves?
Great job Matt !!!
What about special characters support ? e.g. Greek letters ?
As Stefan mentioned, the HD44780 controller can handle up to eight custom characters. Here's an interactive character generator and some sample characters: http://www.quinapalu...hd44780udg.html
Matt: are you going to support all HD44780 commands, or at least keep the option open to send raw data to the display, so people can extend this themselves?
I'd be interested in getting some input from the community about this. Currently the module driver has two methods for updating the display: SetLine1(string) and SetLine2(string). I will be adding a method to set custom characters as well, but beyond that, I'm not sure how many other methods should be added. I think it's important to keep the interface relatively simple so people don't have to think about the specifics of the HD44780 controller to use the display.
This approach could lead to some problems, though, if the user needs other specific functionality of the HD44780 such as blinking cursors. For features like that, I'd probably prefer to abstract the functionality away (e.g., ShowCursor(int column, int row)) than add something more complicated like raw commands.
One other issue with sending raw commands is that go!bus is faster than the HD44780 interface. It would be necessary for the module to maintain a command queue, and if that queue overflows, what should happen? Currently, the module stores the content for lines 1 and 2 and updates the display from memory when not servicing SPI requests. If the line content changes while the display is being updated, it re-sends that line to the display and therefore always shows the latest version of the line content.
As I mentioned though, I'm definitely open to community input regarding the driver interface. I want to keep it simple but I also want it to be capable of doing everything you need
As I mentioned though, I'm definitely open to community input regarding the driver interface. I want to keep it simple but I also want it to be capable of doing everything you need
Just wonder if there is any merit is supporting the micro liquid crystal library as a starting point. The library has had more than 1200 downloads so far. It would give people the chance to port existing code.
Can you please share a link to the license (covering hardware, C# drivers and firmware) under which Komodex modules are released? I may have missed it, but I did not see it on your site.
Just wonder if there is any merit is supporting the micro liquid crystal library as a starting point. The library has had more than 1200 downloads so far. It would give people the chance to port existing code.
Good point -- I'll take a look at that library to see if it would be a good idea to implement something similar.
Can you please share a link to the license (covering hardware, C# drivers and firmware) under which Komodex modules are released? I may have missed it, but I did not see it on your site.
You're right, that's something I forgot to specify on the site. The licensing is the same as for Netduino products: The module drivers are released under the Apache 2.0 License and the hardware schematics are released under CC BY-SA 3.0. The module firmware has not yet been released.
I will get that information posted later today. Thanks!
This will be posted soon as well, I just need to clean up the source a bit first. I'd also like to get a better distribution system in place, but I may just release it as a zip file in the meantime.
About the distribution system: is there a reason for not using a repository like GitHub / BitBucket / Codeplex?
Current plan is to use CodePlex, but I still need to maintain my own internal repositories. Up to this point I have used SVN and the process of maintaining code in two different places with SVN is a bit... difficult, so I need to evaluate other options like hg and git to see if they will make the process easier