1
\$\begingroup\$

I have used different ports for data pins of LCD, RD11 and RD0 pins for DB4 and DB5 and RC14 nad RC13 for DB6 and DB7 . I am using DSPIC30F5011. I have incorporated this on design and manufactured PCB. I am using 4 bit mode for LCD Read/Write

What might be the solution for this ?

Issue with the design: My software team feels that if the data pins are on different ports, the code will be increased and latency between reading and writing increases

\$\endgroup\$
5
  • \$\begingroup\$ Please edit your question and explain what you think the problem is. \$\endgroup\$ – Transistor Jul 23 '19 at 7:11
  • 1
    \$\begingroup\$ It's often done this way. It may increase the code size by 40 bytes, and the execution time by a few microseconds but its hardly a big deal, and good software engineers will find the most efficient solution. \$\endgroup\$ – Steve G Jul 23 '19 at 7:29
  • \$\begingroup\$ @SteveG can u provide the logic or some thing to get started ? This board is my first design they may scrap it because of this mistake. \$\endgroup\$ – MightyBeard007 Jul 23 '19 at 7:32
  • \$\begingroup\$ Realistically speaking, this is why it is a bad idea not to have someone on the project who can function in both capacities. In theory, you solve problems like this with communication before designs are committed. In practice, the person who understands both worlds looks at (hopefully in the design stage, but if not later) and says - "no it is not a problem, you just do x, y, and z" or possibly "normally this could work except that pin v is not usable as an output, so we'll have to to white wire it from pin w on the prototypes and respin the board with that change for production" \$\endgroup\$ – Chris Stratton Jul 23 '19 at 13:50
  • \$\begingroup\$ Where having someone who understands both sides is entirely indispensable is when there are tradeoffs between two approaches - balancing the cost of concerns only really understand by the board designer with those only really understood by the firmware people is hard to do optimally, someone needs to actually understand both concerns to decide a course of action. \$\endgroup\$ – Chris Stratton Jul 23 '19 at 13:52
1
\$\begingroup\$

Looks like your software team has never heard of an Hardware Abstraction Layer (HAL) before.

You say 4 bit mode, so it's probably a character LCD. This is an incredibly slow LCD. It has no special hardware requirements. (eg: LCD controller or DMA)

A hardware abstraction layer should be fine.

Issue with the design: My software team feels that if the data pins are on different ports, the code will be increased and latency between reading and writing increases

Maybe. Worst care you get one write for each pin. But in any other future design the addresses of the data pins is not a concern anymore.
Having the LCD pins sequentially on one port is utopic.

\$\endgroup\$
1
  • \$\begingroup\$ Yes, It is an Character LCD \$\endgroup\$ – MightyBeard007 Jul 23 '19 at 8:59
0
\$\begingroup\$

Often the assumption of software team is that without any instructions the hardware team can make thing easy to use from the software point of view. Often the hardware team has no idea as almost anything is possible in software. I understand the frustration of software team but they should have verified the design before it is made. So if hardware is made, consider it as prototype and just modify the software. If few GPIO pins for LCD control being at wrong port is really a huge performance issue, then make a second hardware version. It is likely that the prototype has other issues as well so second version is needed anyway.

\$\endgroup\$
1
  • \$\begingroup\$ Every other thing is just working fine, only issue on the board is this \$\endgroup\$ – MightyBeard007 Jul 23 '19 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.