PWMOUT and 4bit LCD Interface on same Port?

[Armp]

Again I'm trying to do the unnatural! I use essentially Hippys 4bit LCD routines on pins B.2 to B.7 on the 20M2. Works well.

There is a note in the archive that explains how to use B.0 and B.1 as outputs at the same time.

A problem which may occur with the use of the above routines is when Output Pins 0 or 1 are used within your program. Because of the use of the 'pins =' assignments, these two bits are always set low whenever the 'SendCmdByte:' or 'SendDataByte:' routines are called.
If it is not desirable to have these two bits cleared while interacting with the LCD, the routines can be modified as follows ...

I've used this method for simple outputs, again works well.

However I would like to use B.1 as a PWM output in the same application.
This Read/Modify/Write doesn't work as it seems that writing to PinsB converts B.1 back into a simple output, shutting PWM off.

PortC is already in use.

Before I spend anymore time on this - can it be done?

 

[hippy]

Before I spend anymore time on this - can it be done?

Yes; simply use 'pinB.X = bitY' or ' pinB.x = bY / $??' sequences to map the bits of the byte being output onto the correct output pins.

Search should turn up more detailed examples. One program using that technique ...

http://www.picaxeforum.co.uk/archive/index.php/t-18014.html

 

[Armp]

So you're saying I have to do it a 'bit' at a time, rather than a 'nibble' at a time?

Change:
pinsB = b0 & %11110000
to
PinB.4 = bit4
PinB.5 = bit5
PinB.6 = bit6
PinB.7 = bit7

EDIT: Yup - that works and is only slightly slower. Thanks for the LCD code, and the quick help!

 

[hippy]

So you're saying I have to do it a 'bit' at a time, rather than a 'nibble' at a time?

It likely can be done by commands handling nibbles at a time but probably becomes complicated in its bit twiddling. Pulling bits at a time is simpler and easier and, as you note, usually not much slower.

It's also more flexible as any bit can be mapped to whatever the outputs are, even if reversed or randomised when wiring up. The nibble versions are really just an optimised version of that.

 

[Captain Haddock]

Thanks guys you've just made a problem understanding how the lcd driving worked become crystal clear in an instant!

 

[Armp]

It likely can be done by commands handling nibbles at a time but probably becomes complicated in its bit twiddling. Pulling bits at a time is simpler and easier and, as you note, usually not much slower.

Just a thought for consideration. A similar micro has a 'Mask' feature for the byte wide IO commands. This limits the effect of DIRS and PINS type assignments to those pins 'selected' by the mask. I find I use this very useful for handling mixed function pins, as in the present example.

eg:
MaskB = %11110000 'use pins 4-7

DirsB = %11110000 would set pins 4-7 as outputs - and leave pins 0-3 unchanged.

PinsB = %01100000 would only change pins 4-7.

 

[hippy]

Masking would only help with not altering particular pins but wouldn't do anything for mapping one set of bits to another which is the primary issue with an ASCII character in a byte and needing to map bits to how an LCD is wired-up.

Beyond it requiring firmware changes to add masking I'm not sure it would be that beneficial and would likely add more confusion for those already having difficulties with pins and dirs usage. Having individual pinX.Y and dirX.Y variables means pins can already be changed without affecting others and also allows the mapping of bits to pins for LCD and other circumstances.