1_Wire display...

[David Lesher]

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
<http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf>

This application note describes how a DS2408 1-Wire 8-Channel
Addressable Switch can be used to display characters on an
LCD. The code is written using the 1-Wire API for Java. A
diagram shows how to hook the DS2408 to any LCD using a
Hitachi-44780-based LCD controller chip.

I welcome brick-bats and suggestions.

--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that\'s close..........................
Unless the host (that isn\'t close).........................pob 1433
is busy, hung or dead....................................20915-1433

 

[Rick C]

On Monday, November 29, 2021 at 9:55:43 PM UTC-4, David Lesher wrote:

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf

This application note describes how a DS2408 1-Wire 8-Channel
Addressable Switch can be used to display characters on an
LCD. The code is written using the 1-Wire API for Java. A
diagram shows how to hook the DS2408 to any LCD using a
Hitachi-44780-based LCD controller chip.

I welcome brick-bats and suggestions.

I have no reason to use a brick-bat. If this is what you need to do, it\'s what you need.

The interface to this device is inherently parallel, either 4 or 8 bits. To get all the signals into a single byte you will need to use a 4 bit interface. This means you will need to set 4 data bits and toggle the E signal after setting the R/W and RS controls. Unless you want to read back data, there is no reason to control the R/W signal as the interface can be operated as write only.

The operation of the interface is limited by the instruction timing which is not at all fast. Your 1-wire interface will probably be a lot slower. I seem to recall it takes around 1-2 us to send one bit in the 1-wire protocol which means many us per bit written to the addressable switch. So writing the many bits to perform one bus cycle will almost certainly take more time than the instruction timing... except for the Clear Display and Return Home instructions which have ms level timing.

I didn\'t look at the app note, but if you cobble together the code to send nibbles to the LCD bus I\'m sure you can find no limit to the code for the rest of the interface. Just be sure to write the reset command to the LCD three times to properly reset the bus. The hardware reset in the chip does not work properly and the only way to be sure of the state of the controller is to send the reset command three times in a row. By \"reset\" command I mean the Function Set command. It controls the width of the data bus and nothing you write prior to sending this instruction three times can be assured of being received.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[DJ Delorie]

David Lesher <wb8foz@panix.com> writes:
> I welcome brick-bats and suggestions.

I\'ll add two bits of experience:

1. the 1wire protocol is slow. Check the timings and see if you\'ll be
able to update the display fast enough.

2. \"Remote\" and \"1wire\" don\'t play well. Mine is an extreme case (10
meters of 18 gauge furnace wire) but only one in 4 or so transactions
actually succeed. Check capacitance and noise on that line. You
might need to tweak the pull up resistor if you don\'t have active
pullups on the driver.

 

[bitrex]

On 11/29/2021 8:55 PM, David Lesher wrote:

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf

This application note describes how a DS2408 1-Wire 8-Channel
Addressable Switch can be used to display characters on an
LCD. The code is written using the 1-Wire API for Java. A
diagram shows how to hook the DS2408 to any LCD using a
Hitachi-44780-based LCD controller chip.

I welcome brick-bats and suggestions.

You could just bit-bang it with strong driver relatively slowly and see
if a hack like this works well enough over the required distance:

<https://www.instructables.com/low-cost-1-wire-lcd-for-8-pin-micro-controllers-ro/>

If you refresh the display every hundred ms or something and most of the
\"packets\" are getting through OK then you don\'t really need to be
constantly running CRC checks I don\'t think so long as the result looks
acceptable.

Yeah it\'s dumb but there\'s also not too much to go wrong, there\'s a lot
to go wrong with Maxim app notes!!!

 

[bitrex]

On 11/29/2021 9:58 PM, DJ Delorie wrote:

David Lesher <wb8foz@panix.com> writes:
I welcome brick-bats and suggestions.

I\'ll add two bits of experience:

1. the 1wire protocol is slow. Check the timings and see if you\'ll be
able to update the display fast enough.

2. \"Remote\" and \"1wire\" don\'t play well. Mine is an extreme case (10
meters of 18 gauge furnace wire) but only one in 4 or so transactions
actually succeed. Check capacitance and noise on that line. You
might need to tweak the pull up resistor if you don\'t have active
pullups on the driver.

A 1 wire interface of some type over a 4-20 current loop is a possibility.

 

[David Lesher]

Thanks for the suggestions.

We don\'t care that it\'s slow; if we update every 60 seconds or
so, that\'s sufficient.

We have a slew of DS18B20\'s probes in use now.
With CAT5 cable, no noise issues at all.

The DS2408 is supported by the Ethernet server.





--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that\'s close..........................
Unless the host (that isn\'t close).........................pob 1433
is busy, hung or dead....................................20915-1433

 

[Don Y]

On 11/29/2021 6:55 PM, David Lesher wrote:

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

Your conclusion doesn\'t necessarily follow (just because you have it
\"in use\" doesn\'t mean its the \"least parts\"). Is cost an issue?
Availability of alternate sources? Data integrity? Power consumption?
Flexibility (\"future safe-ty\")?

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf

Why not skip the display controller, too, and just have a single
device (MCU) handle the comms *and* drive the display (glass)?
(don\'t think of it as \"code\" but a \"different VHDL dialect\" :>)

This allows you to augment the capabilities on the display end
in ways that the above solution simply can\'t address (without
adding more components)

What if an \"update\" isn\'t received in N seconds? Do you just
freeze the display with the last value displayed? What if
N tends towards infinity -- do you ever alert the (remote)
viewer (user) that he\'s looking at stale data?

What if updates are received but the data makes no sense?
Do you try to display it? Or, do you discard it? How is
this different (from the user\'s perspective) than an
\"update not received\" condition? Can he take different
remedial actions in each case?

What if you want to add attributes to the display (e.g.,
blink, inverse video, color, etc.)? Are you going
to rely on a sufficiently fast update rate from the far
end to make those happen in \"real\" time? (e.g., paint
value, pause, paint blank, pause, paint value, pause...)

What if you want to change the display, itself (to one that
is functionally identical but uses a different \"controller\")?
As that will require changes to the \"driving\" end of the link,
will the user know that the device *he* owns can only \"talk\" to
a \"model X\" remote display? (i.e., one can virtualize the
display interface if you have \"smarts\" on the remote end)

What if signal quality degrades and you need to renegotiate the
timing of your protocol? Or, new noise sources become present?
E.g., With smarts, you can (later) opt to frequency encode the
data stream without having to change any hardware (no need to
restrict yourself to just two frequencies!).

Etc.

 

[TTman]

On 30/11/2021 01:55, David Lesher wrote:

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf

This application note describes how a DS2408 1-Wire 8-Channel
Addressable Switch can be used to display characters on an
LCD. The code is written using the 1-Wire API for Java. A
diagram shows how to hook the DS2408 to any LCD using a
Hitachi-44780-based LCD controller chip.

I welcome brick-bats and suggestions.

Buy an LCD module that has an integrated RS232 interface? That = 1
wire.... EBAY.

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

 

[Jan Panteltje]

On a sunny day (Tue, 30 Nov 2021 01:55:37 -0000 (UTC)) it happened David
Lesher <wb8foz@panix.com> wrote in <so40ap$44a$1@reader1.panix.com>:

I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.

A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf

This application note describes how a DS2408 1-Wire 8-Channel
Addressable Switch can be used to display characters on an
LCD. The code is written using the 1-Wire API for Java. A
diagram shows how to hook the DS2408 to any LCD using a
Hitachi-44780-based LCD controller chip.

I welcome brick-bats and suggestions.

scope_pic can also be used as a remote graphics display:
http://panteltje.com/panteltje/pic/scope_pic/
it needs only 1 wire RS232 format.
https://www.youtube.com/watch?v=NbSiygGcznw

Only needs 1 PIC 18F14K22

is open source.

 

[Rick C]

On Tuesday, November 30, 2021 at 6:10:12 AM UTC-4, Don Y wrote:

On 11/29/2021 6:55 PM, David Lesher wrote:
I have a request for a remoted LCD display. Having chased available
products to no avail, it\'s time to honor Bob Pease and roll out the
solder.

In this specific case, the least parts count approach seems to
be 1_Wire as we have that in use already.
Your conclusion doesn\'t necessarily follow (just because you have it
\"in use\" doesn\'t mean its the \"least parts\"). Is cost an issue?
Availability of alternate sources? Data integrity? Power consumption?
Flexibility (\"future safe-ty\")?
A {vintage} Dallas/Maxim app note has a reference design:

APPLICATION NOTE 3286
1-Wire 8-bit LCD Reference Design
Jul 20, 2004
http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf
Why not skip the display controller, too, and just have a single
device (MCU) handle the comms *and* drive the display (glass)?
(don\'t think of it as \"code\" but a \"different VHDL dialect\" :>)

This allows you to augment the capabilities on the display end
in ways that the above solution simply can\'t address (without
adding more components)

What if an \"update\" isn\'t received in N seconds? Do you just
freeze the display with the last value displayed? What if
N tends towards infinity -- do you ever alert the (remote)
viewer (user) that he\'s looking at stale data?

What if updates are received but the data makes no sense?
Do you try to display it? Or, do you discard it? How is
this different (from the user\'s perspective) than an
\"update not received\" condition? Can he take different
remedial actions in each case?

What if you want to add attributes to the display (e.g.,
blink, inverse video, color, etc.)? Are you going
to rely on a sufficiently fast update rate from the far
end to make those happen in \"real\" time? (e.g., paint
value, pause, paint blank, pause, paint value, pause...)

What if you want to change the display, itself (to one that
is functionally identical but uses a different \"controller\")?
As that will require changes to the \"driving\" end of the link,
will the user know that the device *he* owns can only \"talk\" to
a \"model X\" remote display? (i.e., one can virtualize the
display interface if you have \"smarts\" on the remote end)

What if signal quality degrades and you need to renegotiate the
timing of your protocol? Or, new noise sources become present?
E.g., With smarts, you can (later) opt to frequency encode the
data stream without having to change any hardware (no need to
restrict yourself to just two frequencies!).

While throwing an MCU at the problem has some advantages, spreading a code base over two processors adds complication and makes debug and maintenance more difficult. Your suggested advantages would not seem to be of much value.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[David Lesher]

Thank you for all your responses.

a) This is not a high-production product; rather it\'s a 1 or 2
off custom device for use with an existing system.

b) That includes a working 1_Wire(tm) system. It uses multiple
Embedded Data System OW-Servers that have 3 channels of 1_Wire
devices, and supports multiple high-level TCP/IP protocols;
no bit banging needed.

c) It works well with multiple devices on long (multiple 100\'s
of ft) twisted pair cable runs. We\'ve not seen any error issues
so far.

d) The system is based around a custom NXP-based controller. It
talks to the EDS\'s via TCP/IP. It talks to other industrial gear
via RS-485.

We pondered driving the display via RS-485, but doubt that
offers major advantages. There\'s no available RS-232 on the NXP,
even if it would run over the cable run available.

Does the above inspire solutions not yet offered?


--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that\'s close..........................
Unless the host (that isn\'t close).........................pob 1433
is busy, hung or dead....................................20915-1433

 

[Don Y]

On 12/3/2021 11:39 PM, David Lesher wrote:

Thank you for all your responses.

a) This is not a high-production product; rather it\'s a 1 or 2
off custom device for use with an existing system.

b) That includes a working 1_Wire(tm) system. It uses multiple
Embedded Data System OW-Servers that have 3 channels of 1_Wire
devices, and supports multiple high-level TCP/IP protocols;
no bit banging needed.

c) It works well with multiple devices on long (multiple 100\'s
of ft) twisted pair cable runs. We\'ve not seen any error issues
so far.

That\'s interesting. Usually, there are noise and ground issues
on lengthy runs, esp if DC-coupled.

d) The system is based around a custom NXP-based controller. It
talks to the EDS\'s via TCP/IP. It talks to other industrial gear
via RS-485.

We pondered driving the display via RS-485, but doubt that
offers major advantages. There\'s no available RS-232 on the NXP,
even if it would run over the cable run available.

Does the above inspire solutions not yet offered?

If you think it will work for you -- and is already in line
with other \"solutions\" you\'ve deployed -- then go for it!

I\'ve taken to using ethernet over CAT5 for most of my
interconnects, now. But, that\'s primarily because it
affords me gobs of bandwidth (which also includes being
able to push new firmware on-the-fly)

I had cobbled together a \"data-over-power\" solution to
communicate with a repurposed Nest thermostat using the
two unused conductors in the thermostat wiring harness
but found it quickly ran out of bandwidth. Even encoding
terse \"commands\" that could be executed by the MCU
*behind* the Nest (e.g., 0x07 = flash display, 0x08 = display
character that follows, 0x09 set color to character that
follows...) proved too slugish.

So, I replaced the thermostat cable with CAT5e and now
I can control the Nest\'s display in real time (animations,
etc. instead of just a static, numeric display). It\'s
still a kludge as I don\'t have direct control over the
Nest\'s hardware. But, foolish to try to redesign a
product that is already so nicely packaged!

[IMO, the Nest is the ideal UI for a thermostat. But,
*as* a thermostat, I found it sorely lacking!]

 

[David Lesher]

Don Y <blockedofcourse@foo.invalid> writes:

That\'s interesting. Usually, there are noise and ground issues
on lengthy runs, esp if DC-coupled.

d) The system is based around a custom NXP-based controller. It
talks to the EDS\'s via TCP/IP. It talks to other industrial gear
via RS-485.

....

If you think it will work for you -- and is already in line
with other \"solutions\" you\'ve deployed -- then go for it!

So we are NOW looking at using the DS28E18 or DS28E17 1-Wire to
I2C chips as it seems there are a metric ****load of displays
driven by same:

<https://www.aliexpress.com/w/wholesale-2.42-i2c-oled.html>

Both are 3.3v which require a bidir level shifter but that\'s perhaps
doable.
--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that\'s close..........................
Unless the host (that isn\'t close).........................pob 1433
is busy, hung or dead....................................20915-1433

 

[Rick C]

On Saturday, December 11, 2021 at 2:02:28 AM UTC-5, David Lesher wrote:

Don Y <blocked...@foo.invalid> writes:


That\'s interesting. Usually, there are noise and ground issues
on lengthy runs, esp if DC-coupled.

d) The system is based around a custom NXP-based controller. It
talks to the EDS\'s via TCP/IP. It talks to other industrial gear
via RS-485.
...
If you think it will work for you -- and is already in line
with other \"solutions\" you\'ve deployed -- then go for it!
So we are NOW looking at using the DS28E18 or DS28E17 1-Wire to
I2C chips as it seems there are a metric ****load of displays
driven by same:

https://www.aliexpress.com/w/wholesale-2.42-i2c-oled.html

Both are 3.3v which require a bidir level shifter but that\'s perhaps
doable.

\"Quickswitch\" is a brand name I believe, but there are multiple sources. Or you can roll your own with a FET on each of the clock and data lines. Tie the gate of a MOSFET to the 5 volt rail through a diode and you should get the right switching voltage to disable the channel for any input greater than about 3 volts. Or use one of the switch based logic interface parts. It essentially creates a bi-dir drive that is totem pole up to about 3 volts and is open drain above that. So you get the rapid rise in voltage through the full 3 volt range with no issues of over voltage on the 3.3 volt side.

I strongly recommend you avoid Aliexpress though. Find other sources. Aliexpress is not there for the buyers.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209