T6963C moving Data line from PORTB to PORTD problem!

[musti463]

Ok. I ordered new GLCDs (240x128). It will come monday. when arrives my orders. I will take picture of my hardware with my codes (PORTB and PORTD versions). Thank you for your help
_________________
M.Emir SADE

[musti463]

Finally i did it

I made a PCB board for PortD & T6963C application so now everyhing okey. Problem was in my breadboard. Frustrating. I lost my time but i did it. Thank you and i am sorry for my words.

So i wanna transmit GLCD Data and Control lines for 5 meters. Should i use any circuit(buffer, voltage follower etc.) for this job? or thats not enough?
_________________
M.Emir SADE

[temtronic]

5 meters( 16 feet for us imperial thinkers...) is too far to reliably connect a GLCD to a PIC.
Easiest way would be to have a 'master' PIC talk to the 'slave' PIC that has the GLCD attached to it. You can use a MAX232, simply use the UARTs within the PICs.

hth
jay

[Ttelmah]

Yes.
You can stretch normal TTL logic to perhaps 10', but even at this you need very good interference protection/suppression. It becomes harder and harder.
Easiest thing use an off the shelf serial GLCD module. RS485 transceivers, and 100'+ becomes easy.
There are literally dozens of such modules on the market often with add-ons like touch screens available, and 'smart' command sets to draw complex shapes, again often with smart abilities like allowing a second screen to be updated while one is being displayed. Makes the whole job much easier, and prices are in many cases surprisingly close the the 'dumb' units.

[musti463]

I looked RS485. But i can't learn totally. I get incorrect sometimes. I can't set a good communication system. So i haven't got enough times for learn RS485. Now please tell me should i use buffer?
_________________
M.Emir SADE

[Ttelmah]

You'd need proper transmission line design on _every_ signal. Buffer at each end, and twisted pair wires with terminators. You'd also need bi-directional handling on the lines that turn round. Possibly 100* harder than getting a serial LCD, and adding line drivers to this.

Ask yourself a simple question. Why are all the old data bus designs using parallel buffered data (IDE, SCSI etc.) all no longer used. except in very specialist areas?. Answer it is complex and expensive to send signals reasonable distances reliably. Sending single signals faster is much cheaper than sending a whole bus....

[musti463]

Can i make buffer circuits with Rail to Rail 5MHz MCP6284?

So what do you think about "Shift Registers" for this job ? Can i do Parallel to Serial and Serial to Parallel ?
_________________
M.Emir SADE

[temtronic]

As I said earlier use another PIC, 2 MAX232 chips and it's done.
master PIC->max232===two wires===max232->slave PIC=>GLCD.
You've done the 'hard' part the PIC/GLCD wiring.

As Mr. T points out 'noise' on ANY of all those wires will affect the project.
Serial communications between PICs is super easy, CCS does provide examples.

hth
jay

[Ttelmah]

You are missing the key point that the bus to the GLCD, is bi-directional. You need bi-directional buffers and the logic to turn these round correctly at both ends. So, 'no' you can't use shift registers. As Temtronic says, you can do the serial version relatively easily by just adding a PIC at the display and talking to this with a serial bus. Don't get confused about any complexity with RS485. Typically people using RS485, are adding the complexity of a protocol to allow multiple devices. You don't need this. Instead just use four (two pairs) of wires, leave the buffers set to permanently transmit/receive, and just use the simple comms normally associated with RS232. Run the RS485 fast with interrupt driven buffering (say 250kbps), and the data will be transferred nice and quickly. However as I have already pointed out there are serial GLCD's 'off the shelf', and these have the big advantage of already having functions to display different text fonts, automatically draw lines, circles etc. etc.. Makes the main code much simpler.

[musti463]

OK. I made a communication between two PIC by RS485. But i get %30 incorrect data and %70 correct data. I can't understand why i am getting %30 incorrec data.

So what can be max. cable length between GLCD and PIC ?
_________________
M.Emir SADE

[Ttelmah]

Have you got the RS485 lines terminated and biased correctly?.
The distance for RS485, depends on the data rate involved. At 30', it supports 10Mb/sec. Remember that your wire pair should have an impedance that it a reasonable match to the bus (120R). Cat 5 network cable is a close match at a nominal 100R.
As soon as you start sending any digital signal more than a very few inches (at really high frequencies, less than this), you are into having to deal with transmission lines, and understanding the effects of impedance mismatch, termination, etc. etc..

Realistically on maximum distance for conventional logic, it depends on so many factors. Speed involved. Noise in the environment, etc. etc.

You can send conventional TTL about 10', but only with properly terminated lines, and in a shielded environment, at lowish rates, and with careful design. I've seen designs sending signals just 3', at quite low rates, that have noise problems. You have to remember that a wire will act as an aerial, and a logic input with it's protection diodes, makes a very effective radio receiver....

[musti463]

But 18F4685's PORTD pins are not TTL. its ST(Schmitt Trigger)
_________________
M.Emir SADE

[temtronic]

re: distance between PIC and GLCD.
You might get 1' ( 1/3 meter) IF using twisted pairs with one being the signal line the other a ground. So if using CAT5, you'd get 4 conductors and 4 grounds per section of CAT5.You also will need to add a couple 'filter caps' on the GLCD power pins.

re: RS485 errors.
hardware : AS Mr. T points out, proper termination is important. RS485 require a pullup on 'A', a 120r between 'A' to 'B' and a pulldown on 'B'.

software: need to have 'errors' in the USE RS232(...options...)

also...PIC clocks ! IF using the internal RC oscillator, that will cause communications errors, you need to use real crystals/2 caps on both PICs. The internal RC osc is not stabile or accurate for high speed timings.

without seeing your 'communications' code section of your program can't tell what else can cause it.


hth
jay

[Ttelmah]

ST, is _slightly_ better. However doesn't matter at all, since the GLCD inputs use TTL levels.....