Possible to drive 4x40 LCD with 2 Cores ?

[stryd_one]

Ahhh the irony.... You've found a great solution to MTE's question, but he doesn't want to do it any more, and also it wont work in my design.

DOH!!!!

[MTE]

but he doesn't want to do it any more,

??

not really true, I will change to 2 2x40 if its going to difficult to build ;)

[/tilted/]

Well, just for the record, methinks it's not too difficult a build, and will require only a rather small software adjustment.

MTE, I think you can do this... ;D

[stryd_one]

As tilt and I have discussed:

[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 at the same time SID sets RD7 high

     FMcore writes to LCDat the same time SID writes to LCD

[/tt]

Race condition still exists ..... dammit how to get around this?

[/tilted/]

OK then...

[tt]FM Core checks RA0 ;(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 at the same time SID sets RD7 high

    FMcore checks RA0 again

    RA0 returns high ;(meaning SIDcore has just now set RD7 high)

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

    RA0 returns low ;(meaning LCD bus is still free)

        FMCore writes to the LCD.

[/tt]

I don't know the ins and outs of the app, but I'd be pretty sure that the SID and FM have enough work to do each main loop that they only would write to the LCD when there's something to say. ie they wouldn't need to write each cycle. In which case the race is extraordinarily unlikely since the human brain would tend to edit one synth, then the other, not both at once.

That said, the FM synth also uses the LCD bus for communication with the OPL3 chip, so I think we may be....

boned. :-\

[edit] spelling.

[stryd_one]

I don't know the ins and outs of the app, but I'd be pretty sure that the SID and FM have enough work to do each main loop that they only would write to the LCD when there's something to say.

That's exactly right... in fact I think (nearly?) all the midibox apps work like that. I agree, it's extremely unlikely to actually collide, but you know electronics... always screwing up when you least expect it ;)

Also, we don't just write one byte at a time... if we're updating the LCD it's going to be a byte (one of these cycles of error checking included) for every character... our LCD driver is quickly becoming slowed down by all these checks...

We could maybe reduce the slowdown by, instead of handling the arbitration with every write cycle, we could swap access between each core periodically, say, at the beginning of the LCD update functions... but of course that is going to mean we can't make use of the LCD enable lines, so you'll need at least (one or) two spare pins.

That said, the FM synth also uses the LCD bus for communication with the OPL3 chip, so I think we may be....

boned. :-\

Yer maybe ... (It's fun discussing it though :) "text adventure...")

But.. maybe not ... As above, in order to speed this up, we can separate the arbitration process from the actual LCD write, using two other pins. This would have the added benefit of enabling the apps to share control, not only of the LCD enable lines, but of well, any peripheral they are attached to, FM included

But, even as a theoretical discussion, this is fairly extreme. Essentially, we're talking about Asymmetric Multi-Processing, and although it's possible, I can hear a wise little voice from my memory saying "why not use a 32bit micro instead, if you want to do that?" ;D

Regardless, I am curious about this (I'm johnny 5: "inpuuuut!"), so I've done a bit of research into defeating buss contention, and I think I can safely say that there's no universally accepted "right" way to go about it. In fact, I have collected up links to about a dozen patents to different methods, and a handful of different designs as well, and that's just the stuff that's freely available. I had a lot of trouble sifting through the noise (we don't really want to know too much about PCI buss contention in dualcore pentiums, or timing-based buss contention with a single processor) so I'm sure there would be hundreds of ways to do it that have been published... I've seen everything from dedicated MCU's to elaborate logic to CPLDs to using a single pin with automatic latching circuitry... I ran the question by a friend who used to do military encryption hardware and he went the logic route, we had a rather interesting whiteboard session :)

So anyway, I don't know if we're actually going anywhere here, but it's an interesting learning experience!

[stryd_one]

74F786

Perfect.

[cimo]

Perfect.'>74F786

Perfect.

broken link

http://www.digchip.com/datasheets/parts/datasheet/364/74F786.php here it is ! nice find S1.

[MTE]

Yo

I change now my plan to use the 4x40 for SID/FM, instead Ill use 2 2x20 for it, so I exchanged my PC-Temperatures/Speedfan-LCD (2x20) by the 4x40 --> Attachments

More Info about the Software youll find here -> http://lcdsmartie.sourceforge.net/shots.htm

Enjoy :)