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
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 
)
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?
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 
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.
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!!!
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
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
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?
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.
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!
Perfect.
Perfect.'>74F786
Perfect.
broken link
http://www.digchip.com/datasheets/parts/datasheet/364/74F786.php here it is ! nice find S1.
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
