That initialization code is already in the LCD_AnyPin file.
To invoke it, simply use this after turning it on.
That tells PBP that the LCD hasn't been initialized yet, and it will do so on the next LCDOUT.Code:FLAGS = 0
That initialization code is already in the LCD_AnyPin file.
To invoke it, simply use this after turning it on.
That tells PBP that the LCD hasn't been initialized yet, and it will do so on the next LCDOUT.Code:FLAGS = 0
DT
Seems you can ignore the last few posts.. I had the transistor shorted the whole time I was supposed to be turning it on & off!
A quick thought - rather than try to run ribbon cable around a vehicle, where noise will certainly be an issue, why not simply put a small PIC co-located with the display to communicate with your main device using an (RS232ish) serial link and display it on your display? You only need to run a single wire (or 3 wires if you also want to include power for the device) and it should be cheaper and more robust. You won't need driver devices; simply connect the output pin you choose to use on your main PIC to the input pin you choose to use on the display driver PIC. I've done this for over 30 feet without issues.
Couple of reasons, but most importantly, to keep the program cycling fast.
A hardware serial port might overcome the speed issue,
But would make it more difficult to do fancy things with the display.
Problem Solved!!!
Here's the current circuit I was describing with the LCD data bus obviously omitted:
It does drive a 12 Volt relay this way if the other end of the relay coil is connected to a 12 Volt source.
.................................................. ...............................
I used the same transistor to switch the positive line to the LCD this way:
I could always use the first circuit to drive a relay that in turn switches the LCD,
but that wouldn't be very solid state would it?
Q for Darrel, Does resetting the FLAGS var affect any other PBP related stuff?
I have my own flags set and variables stored in RAM while I'm turning the VFD on & off.
It's working perfectly, but I don't want it to break anything else software-wise.
Cheers, Brek.
Clearing the FLAGS variable will not affect anything else.
There are some I2C bits in there, but they are only used during an I2CREAD/I2CWRITE command.
The only time it could be bad is from within an interrupt handler, since an I2C command may have been interrupted.
DT
Great, no plans for I2C for this projectThanks for all your help too.
Oh, and before I forget.... This:
For old time sake!!
Still waiting for a sine wave version in that old odometer thread.
I used a pseudo sine lookup table to get the next vertical offset when I did it on my LED scroller.
Anyways, the rolling clock gets to stayCode:LOOKUP si,[0,0,1,1,2,2,2,3,3,4,4,3,3,2,2,2,1,1,0,0],offsetit isn't blocking execution.
Bookmarks