Possible to drive 4x40 LCD with 2 Cores ?

[MTE]

Gmorning

I plan to build a MB-6582-SID + a Midibox-FM into 1 box and want to drive both on 1 4x40 LCD

Here my theory :

The LCD have 2 E-Pins...

Will this be possible to drive 2 Cores with the LCD-Ports on this LCD ? Need I some diodes to save each Core-LCDoutput from the other outgoing/incoming Signals ?

Regards

[cimo]

hi

i had the same idea some time ago so i am also interested in knowing if this is possible or not.

Aren t the diodes placed backward?

Simone

[MTE]

The minusside of an diode makes the barrier, right ? So it isnt wrong, but the v0-line is for contrast, so Its only required to drive it from 1 core

Fixed ;)

[/tilted/]

The diodes would prevent damaging things, but I'm not sure that you can drive the LCD bus this way.

As I say, no damage to be had, but you might need the cores to do a little polite handshaking too.

[Screaming_Rabbit]

Aren t the diodes placed backward?

Yepp... seems to me too.

I don't think it will work. Also consider the voltage drop.

Greets, Roger

[cimo]

As far as i can understand the problem is that the core is sending data to the data lines all the time therefore whenever an lcd is going to read some data it ll get it from both the core = garbage

hardware wise we ll need a 8 line logical switch triggered by the core.... ahahah too crazy

software wise we ll need

1 as tilted mentioned, having the cores properly linked

2 tell the core to stop sending data to lcd every second cycle and offset the second core of 1 cycle

none of this seems to me any easy thing to do

[stryd_one]

http://www.google.com.au/search?aq=f&num=100&hl=en&safe=off&as_qdr=all&q=%22quad+spdt%22+analog+switch+TTL+DIP&btnG=Search&meta=

pair of MAX394, driven by a spare pin, and another spare pin on each of the two cores to negotiate control of the bus ?

I have an interest in this myself, keep us posted MTE :)

[MTE]

http://www.google.com.au/search?aq=f&num=100&hl=en&safe=off&as_qdr=all&q=%22quad+spdt%22+analog+switch+TTL+DIP&btnG=Search&meta=

pair of MAX394, driven by a spare pin, and another spare pin on each of the two cores to negotiate control of the bus ?

I have an interest in this myself, keep us posted MTE :)

I understand only the half  ;D but ready to test anything ;) so Ill order these chips as samples and letz figure out how this will work ;)

Thnx

EDIT : Hmmmm which one ? http://www.maxim-ic.com/quick_view2.cfm?qv_pk=1089&t=or

[cimo]

mm

turn on time 145 ns

turn off time 175 ns

now i am not so sure if the following is right but i think that the data is sent at 40Khz, that s the PIC s cpu clock at least; if this is the case then it won t work, you need logic ICs, but i am just guessing, anybody?

Simone

EDIT: i see it says

TTL and CMOS Compatible Logic

still i would be a bit concerned about timing

[stryd_one]

There are faster switches you know, that one isn't etched in stone, it's just the first one I saw, posted it to demonstrate... That's why I left the google search in there...

Anyway it doesn't have to switch with every byte sent to the display, only switch at the beginning of sending the bytes.

My original search was for logic BTW, but I didn't find anything quite so suitable. Let's see about the truth table... We have three inputs and an output... In3 is the control of which core has locked the buss, In1 is from the first core's output, In2 is from the second core, output goes to the LCD

In3 In1 In2 Out

0 X 1 1

0 X 0 0

1 1 X 1

1 0 X 0

So what is that, logic wise? I'm at work, only posting this cause I need to restart my browser and close the tab... If someone doesn't nut this out before I get back from work I'll actually apply thought ;)

Regardless, I think a switch will do the trick.... And it's bidirectional which is good for my own case (but not relevant for MTE)

[/tilted/]

Woudn't it be simpler to have a third PIC which takes parallel data from the 2 CORE PICs and decides for itself how to drive the bus?

[stryd_one]

Uhm... how so? That'd be about the most complex answer I could think of...

The more I think about it, the more a switch makes sense here. If you think about what the aim is, it's just a simple matter of *switching* the LCD from one core to another...

[cimo]

hi

i just wanted to point out that i was horribly wrong on my post

mm

turn on time 145 ns

turn off time 175 ns

now i am not so sure if the following is right but i think that the data is sent at 40Khz, that s the PIC s cpu clock at least; if this is the case then it won t work, you need logic ICs, but i am just guessing, anybody?

those are nano seconds while the PIC runs at 25 microseconds so no probs from that side.So that chip is ok for our purpose.

again and again, beware of timing though

Simone

[MTE]

Im sorry but Im out now for a while (only reading) ....I was by dentist today and have a bad abscess on my upper right teethbone  :'(

[stryd_one]

True but my point is, it doesn't matter if it switches a little slowly, it doesn't have to switch for every byte sent, only when you switch your CS from SID to FM mode... Worst case is that you have to throw a couple of NOP in there to make the core wait a bit for it to switch. BTW, you could make the enable lines to throw the switch, no extra pin required there.

I fooled around with the logic and it's not particularly pretty ;) Lots of gates and diodes required...

But still, you have to have some form of negotiation between the cores as to which one is controlling the LCD right now... I guess you could use a spare pin on each PIC, which are both connected *, and when the core wants the LCD, it checks that the pin is high, and if it is, it sets it low, before writing to the LCD. This way, if the other core wants the LCD, it will test that pin, see it low, and know that the LCD is busy right now.

* I'm sure that if they were directly connected there would be a risk of a short circuit, if one pin was high and the other low. Also, if they were both set as inputs (to arbitrate access to the LCD) at the same time, then they would be susceptible to noise. I'm sure a pullup resistor is the trick here but I'm not that good with analog...anyone?

And... do you think there's enough code space and ram available for these additions?

Edit: uh oh, too late.... Hope you feel better soon MTE!

[MTE]

Thnx Stryd...Im back on Drugs now  ;D

Hm I dont understand how LCDs are working but Ill study this now in the next weeks....my idea was to use the 1st and 2nd line for the SID, 3rd & 4th for the FM (or vice versa), yesterday Ive had a small discussion with doc at icq about it, he means , that the LCD will get broken fast when you turn it on/off in fast intervalls....so I think itll be imppossible to drive such LCD with 2 Cores....but let me see this after a bit of studying, for now I have many time for this, with notebook in the bed  ;D  ;D

[stryd_one]

Hahahahaha

the LCD will get broken fast when you turn it on/off in fast intervalls

Really? In the way I spoke about above (with the switch IC), I don't see how the LCD would receive anything unusual ?

You wouldn't be turning it on and off rapidly, just redirecting the data lines to one of two PICs...

[cimo]

..if i am understanding both of you right:

MTE wants to drive line 1 and 2 of the LCD with MBFM and line 3 and 4 with MBSID

S1 wants to drive the LCD either with MBSID or MBFM (or whatever he s going to use)

wow, i think that both ideas are quite attractive and if we get one going the other will be a piece of cake, i ll take care of dusting properly the cake with dirt

Simone

[nILS]

I could contribute some gearbox sand ;D

[stryd_one]

MTE wants to drive line 1 and 2 of the LCD with MBFM and line 3 and 4 with MBSID

S1 wants to drive the LCD either with MBSID or MBFM (or whatever he s going to use)

Well it's the same thing really... just that the SID will only write to the bottom lines, and FM will only write to the top lines, ever.

I'm cooking up something entirely different, but the theory is the same....

[doc]

that the LCD will get broken fast when you turn it on/off in fast intervalls....

hehe.

I said: You can damage a LCD fast if you pull it from the CORE and connect it again. (I broke about three or four doing this). Means: Always turn your CORE off before you pull the LCD ....

And I also ask: Is this worth the effort? May a second LCD not be cheaper, less painful and easier to implement?  ;D

greets

Doc

[cimo]

And I also ask: Is this worth the effort? May a second LCD not be cheaper, less painful and easier to implement?  Grin

greets

Doc

yeah sure!

(also an oxygen8 is cheaper than an average midibox  ;) )

[/tilted/]

OK.

What if each core were to simply read the E->LCD pin from the other core before doing a write?

Say, using a spare AIN pin?

Say FM wants to write to the LCD.

{Code written in "I know shxt about C" brand C}

[tt]FM Core checks RAO ;(which is connected to SIDcore RD7 - E pin)

    RA0 returns high ;(meaning SIDcore is writing to LCD)

    FMcore returns without writing, does whatever else it does...

    RA0 returns low ;(meaning LCD bus is free)

    FMcore sets RD7 high

    FMcore writes to LCD[/tt]

I guess this would all be better if it were part of the ASM driver for the LCD, right?

Is this a fix? Is there any time during a core LCD write, when the RD7 (E) pin goes low?

[stryd_one]

Totally!

Hahaha why was that not more obvious....Although I'm fast realising that MTE's project and mine, are more and more different...

Only trick is to make sure that the pins don't interfere with each other... Like, if one is low and the other high, you have a short... or could you risk pulling the LCD enable line low when you read it? I dunno you're the one that's good at this stuff :)

[/tilted/]

Only trick is to make sure that the pins don't interfere with each other... Like, if one is low and the other high, you have a short... or could you risk pulling the LCD enable line low when you read it? I dunno you're the one that's good at this stuff :)

Nope, you have the D7 pin as an output, and you set your RA0 pin as an input.

Source impedance is around 2.5k for these pins, so no huge current pull.