1_Wire display

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

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

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.

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!!!

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.

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

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.

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

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.

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