Searching \ for '[PIC]:pins share, a good practice?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'pins share, a good practice?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:pins share, a good practice?'
2002\07\04@084625 by personal

flavicon
face
I think about sharing    PORTB RB4:7 for hd44780 lcd, 4 DAC's data/clk, not enable and not load pin.

I think it should fine. But if it is normally people doing and any disadvantages?

BR,

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\07\04@100453 by rusque (Listas)

face
flavicon
face
Hello BR,

>I think about sharing    PORTB RB4:7 for hd44780 lcd, 4 DAC's data/clk, not
enable and >not load pin.
>I think it should fine. But if it is normally people doing and any
disadvantages?

   this is very common practice. I usually share/multiplex pins with keys
and displays.

   Best regards,

   Brusque

-----------------------------------------------------------------
Edson Brusque                 C.I.Tronics Lighting Designers Ltda
Research and Development               Blumenau  -  SC  -  Brazil
Say NO to HTML mail                          http://www.citronics.com.br
-----------------------------------------------------------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\07\04@160613 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
I am sharing LCD I/O pins with inputs from key switches on an SX chip. The keys can only pull down an input through diodes when it's common connection is set low by an output (key enable) and the internal clamping resistors are used to pull the line high when the switch is open.

One problem I had with this was that it sems that the LCD I/O pins has a pretty high capacitance. If I read the keys right after I had written a zero to the LCD input and the key switch on the same line is open, the clamping resistors was sometimes too weak to pull the (now input) line high quick enough. This resulted in that the switch would sometimes be read as closed even though it was open. The solution was simple though - write a one to the I/O line for a short time, just before the keys are read. It took a while to debug since LCD updates (writes) is not synchronized with key switch reads.

Ruben

> I think about sharing    PORTB RB4:7 for hd44780 lcd, 4 DAC's
> data/clk, not enable and not load pin.
>
> I think it should fine. But if it is normally people doing and any
> disadvantages?
>
> BR,
> ==============================
Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamKILLspampp.sbbs.se
==============================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\07\04@234506 by Bill & Pookie

picon face
Ruben,

A way around the unsynchronized LCD and key switch read, would be to read
the keys every time in the LCD routine and save the value along with a flag
to show new key data.  Then in another part of the program, evaluate the new
key data.
And if you don't already debounce the key switch input, it may be a good
idea to do so.

Bill

{Original Message removed}

2002\07\05@024955 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
Thanks for your reply...

Keys are debounced.

The LCD is updated on demand and the keys are read at an interval
determined by a software timer (about once a millisecond or so).

The keys being debounced is probably why it was hard to find the problem in
the first place, since this effect had to be present enough key readings in
a row to be noticed.

Also, the way the LCD is handled probably had something to do with it:

The ISR handles RS485RX, RS232RX, a combined RS485/232TX (only one at a
time), clocking in bits from an external AD and several software timers.
Every event sets a flag to the main loop when done or has data.

The main loop is divided into two sections - one with functions executed
every loop and one with functions executed at a rate determined by a
software timer (the 1 ms timer). Functions called at the high rate calls a
'housekeeping' routine (se below), routines to handle incoming data
messages (only when completely received) on the RS485/232 lines and a
routine to handle the converted analog input. Functions called at the low
rate handles key reading (and debouncing), front panel led flashing, and a
state machine that is the actual application.

The housekeeping routines is updating IO bits from shadow registers or
internal states, putting incoming RS232/485 characters in buffers checking
for CR termination and if there are characters present in the LCD output
buffer (the application state machine sends characters and control codes to
the buffer instead of directly to the LCD) and the LCD isn't busy (the LCD
can be both read and written) one character is written.

No function in the mainloop is blocking, the ones that can take some time
frequently calls the housekeeping routine to yield time to background
tasks. Functions that can take long time are EEPROM reading/writing,
RS485/232 sending and flushing of the LCD buffer.

So, this sometimes resulted in the LCD being updated enough key readings in
row to make the key look like it was closed when opened, since the internal
clamping resistors didn't have time to rise the level on the input pin
between writes to the LCD and reads of the keys.

I have used this setup successfully for several applications. When I start
a new project I can very often just copy the low level background tasks
(ISR, LCD handling, Serial IO handling, external EEPROM interface, key
and/or input reading/debouncing and timers) and start with the application
state machine right away.

The solution to my problem was simple, just make sure any external
capacitors on the multiplexed data lines are fully charged before reading
the key inputs. This was done by writing 1's to the data lines with no
external device on the line enabled.

Thinking of it, the capacitance on the LCD inputs perhaps wasn't the
problem but more likely an LCL filter on the data lines between the
processor board (with the clamping resistors) and the front panel display
board (with the LCD and keys). The filter is used to minimize radiated
emission for EMC compliance.

Phew... that was a bit longer than I meant, nobody is probably reading this
far :-)

Ruben


> Ruben,
>
> A way around the unsynchronized LCD and key switch read, would be to
> read the keys every time in the LCD routine and save the value along
> with a flag to show new key data.  Then in another part of the
> program, evaluate the new key data. And if you don't already debounce
> the key switch input, it may be a good idea to do so.
>
> Bill
>
> {Original Message removed}

2002\07\06@050734 by Peter L. Peres

picon face
On Thu, 4 Jul 2002, Ruben Jönsson wrote:

>I am sharing LCD I/O pins with inputs from key switches on an SX
>chip. The keys can only pull down an input through diodes when
>it's common connection is set low by an output (key enable) and
>the internal clamping resistors are used to pull the line high
>when the switch is open.
>
>One problem I had with this was that it sems that the LCD I/O
>pins has a pretty high capacitance. If I read the keys right
>after I had written a zero to the LCD input and the key switch
>on the same line is open, the clamping resistors was sometimes
>too weak to pull the (now input) line high quick enough. This
>resulted in that the switch would sometimes be read as closed
>even though it was open. The solution was simple though - write
>a one to the I/O line for a short time, just before the keys are
>read. It took a while to debug since LCD updates (writes) is not
>synchronized with key switch reads.

;-) the 8051 does this in hardware on each IO pin in certain ports. You
have to limit the current though, or you can glitch the power supply of
the CPU on high output capability chips like PICs. The 8051 does not have
this problem (sources only a few mA per output).

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...