Can defines be changed with port input?

[Archangel]

Hello Again Everyone,
Is it possible to alter <h4>DEFINES</h4> by assigning an alias or variable to their value and then making them subject to port input?
I want to alter the DEFINE HSER_SPBRG and LCD lines = X defines by switching port inputs, but I get assembler errors if I try method listed below.
Thank You for your patience, and help.
Joe



DEFINE HSER_SPBRG BAUD ' FOR 20MHZ 129 = 2400, 32=9600,25 @ 4 for 2400
define BAUD Var
BAUD = 129
if PortB.3 =1 then
BAUD = 32

[Acetronics2]

Hi, Joe

As DEFINEs write to special registers or PBP constants ... you could consider it's "a kind" of CON statement !!!

for values, a look to PBPxx.lib and the function listing could give you the value name ... in order you to change it.

For registers, It wil be much better to change their values Through assembler ( As DEFINEs do ...) : Addressing them directly ...

But Think to disable the concerned peripheral before any change ... or the mix might be funny ...

Alain

[Charles Linquis]

You don't need to change defines to change the baud rate. In PBP, the baud rate generator gets set once, at the beginning of the program. Your program can change it any time later by writing to the SPBRG register. I switch between baud rates all the time in my programs.

Just remember - when using the UART, your program writes the output buffer and moves on, which means that you can still be outputting a byte many instructions after the HSEROUT. You should wait at least two byte-times after any HSEROUT command before you change the baud rate.

[Archangel]

You don't need to change defines to change the baud rate. In PBP, the baud rate generator gets set once, at the beginning of the program. Your program can change it any time later by writing to the SPBRG register. I switch between baud rates all the time in my programs.

Just remember - when using the UART, your program writes the output buffer and moves on, which means that you can still be outputting a byte many instructions after the HSEROUT. You should wait at least two byte-times after any HSEROUT command before you change the baud rate.

Hi Charles,
Happy Thanksgiving to you and all who share this forum!
I am thankful to all who post here.

So are you saying, the statement posted below:
<h4>DEFINE HSER_SPBRG 32 ' __ _ FOR 20MHZ 129 = 2400, 32=9600,25 @ 4 for 2400, </h4> might be written as something like:<h4> IF PortB.n = 1
THEN HSER_SPBRG = 32
ELSE
HSER_SPBRG = 129</h4>
JS

EDIT
AHHHH SOOO
I see, just define it to your default and change it later with SPBRG = "new setting number"
<h3>THANKS CHARLES !</h3>

[mister_e]

SPBRG is the USART register. so just writing to it change the baudrate.

SPBRG=x
SPBRG=y
'
'
'
and so on

AND you could also skip all DEFINEs, just write to the according register... as the PICMultiCalc .



RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $24 ' Enable transmit, BRGH = 1
SPBRG = 129 ' 9600 Baud @ 0.16%

[Archangel]

AND you could also skip all DEFINEs, just write to the according register... as the PICMultiCalc .

Thank You mister_e,
so many subtel little turns and twists to learn. Can you answer this?
If I define

DEFINE LCD_LINES 2

and send

serout PortB.4,T9600,[254,128,"9600 baud line 1~"] '128 so as not to add space
pause 100
serout PortB.4,T9600,[254,192,"9600 baud line 2~"]
pause 100
serout PortB.4,T9600,[254,148,"9600 baud line 3~"]
pause 100
serout PortB.4,T9600,[254,212,"9600 baud line 4~"]
pause 100
It still displays all 4 lines as if define was set to 4?
JS

[mister_e]

:eek:

The LCDOUT defines don't alter the SERIN/SEROUT... it's two different things.

If you want to use the internal USART RCSTA/TXSTA/SPBRG you have to use HSEROUT/HSERIN AND the dedicated I/O.

If you want to use your favourite I/O and don't want to mess your time in calcs, use SEROUT/SEROUT2. these allow to change the baudrate on the fly without too much effort, fat free and allow to use almost every PIC i/o.

And if you want to configure your Serial LCD... i don't know how as you never said wich one you're using ;)

But for sure LCD_LINES is not the solution.

[Archangel]

:eek:

The LCDOUT defines don't alter the SERIN/SEROUT... it's two different things.
Yes , that I knew already


If you want to use the internal USART RCSTA/TXSTA/SPBRG you have to use HSEROUT/HSERIN AND the dedicated I/O.
This I am already doing and now understand how to shift baud rates . . easy

If you want to use your favourite I/O and don't want to mess your time in calcs, use SEROUT/SEROUT2. these allow to change the baudrate on the fly without too much effort, fat free and allow to use almost every PIC i/o.
No need, serial backpack works great, tweaking to add features.


And if you want to configure your Serial LCD... i don't know how as you never said which one you're using ;)

But for sure LCD_LINES is not the solution. My real question was, or is : in the <h4>LCDOUT DEFINES</h4> if LCD_LINES 2 has no apparant effect to limit the LCD from displaying more, why is it even used?

[keithdoxey]

<h4>LCDOUT DEFINES</h4> if LCD_LINES 2 has no apparant effect to limit the LCD from displaying more, why is it even used?

In the example code you gave you are sending to a Serial LCD display using SEROUT

LCDOUT DEFINES are exactly what the name suggests...definitions for the LCDOUT command which you are not using!!!

Likewise HSER_ defines are for HSEROUT and will have no effect on any SEROUT commands.

[Archangel]

In the example code you gave you are sending to a Serial LCD display using SEROUT

LCDOUT DEFINES are exactly what the name suggests...definitions for the LCDOUT command which you are not using!!!

Likewise HSER_ defines are for HSEROUT and will have no effect on any SEROUT commands.
I have code for a serial to parallel backpack adapter, so yes i send serial commands to the adapter pic. It in turn outputs parallel LCDOUT commands and it works quite well. The code is designed to accept lcdout formatting commands to position each line on the lcd. It stores hserin data in a variable and then outputs into a standard LCD via LCDOUT. NOW in the lcd Defines which affect the PARALLEL LCD configured as a 4 bit display I have installed the following:
DEFINE LCD_LINES 2. the display seems unaffected when hooked up to a 4 line display, as it continues to correctly display 4 lines of data sent to it. SO THE QUESTION REMAINS, what good is the lines DEFINE if it doesn't limit the output to 2 lines?
JS

[Acetronics2]

DEFINE LCD_LINES 2. the display seems unaffected when hooked up to a 4 line display, as it continues to correctly display 4 lines of data sent to it. SO THE QUESTION REMAINS, what good is the lines DEFINE if it doesn't limit the output to 2 lines?
JS

Hi,Joe

Those defines are written for most common types of displays ...

If using exotic displays ...you also have to verify their commands are those PbP sends when configurating the display ...

Mhhhh, now, If you DO NOT send data one after the other , but specify WHERE you want it to be written ...

Only 2 lines will be used ...

But YOU MUST Tell PbP you USE a 4 LINES Display ... PbP can't think you only WANT 2 lines ... no DEFINE for unwanted lines !!!

CQFD

Alain.

[Archangel]

Hi,Joe

Mhhhh, now, If you DO NOT send data one after the other , but specify WHERE you want it to be written ...

Only 2 lines will be used ...

But YOU MUST Tell PbP you USE a 4 LINES Display ... PbP can't think you only WANT 2 lines ... no DEFINE for unwanted lines !!!

CQFD

Alain.
HI Alain,
The thing is, if you check post #6, I am sending the data in a manner so as to tell PBP where to write each line, I would expect the software to delimit the display to the addresses available only to a 2 line display if it is defined as a 2 line, even with a 4 line display connected, but it displays all 4 lines. Now if I install a 2 line display, and send 4 lines of data as written in post 6, only the lines written for line 1 and line 2 will display. I would have expected the PIC to truncate the third and fourth lines when set to 2 lines, even when connected to a 4 line display. It appears that is not so. So I still have the question, what effect does DEFINE LCD_LINES have on the LCDOUT command?
Regards
JS

[keithdoxey]

OK. I didnt know what the LCD_LINES define actually did so I took a look in PBPPIC14.LIB and located this section of code.....



if (LCD_BITS == 8)
if (LCD_LINES == 1)
movlw 30h ; 8-bit mode, 1 line, 5x7 font
else
movlw 38h ; 8-bit mode, 2+ lines, 5x7 font
endif
else
if (LCD_LINES == 1)
movlw 20h ; 4-bit mode, 1 line, 5x7 font
else
movlw 28h ; 4-bit mode, 2+ lines, 5x7 font
endif
endif


The "Function Set" register of the 44780 LCD controller chip has the following bits


D7 = 0
D6 = 0
D5 = 1
D4 = DL
D3 = N
D2 = F
D1 = -
D0 = -

where

DL = DataLength
1 = 8 bits
0 = 4 bits

N = Number of lines
1 = 2(+) lines
0 = 1 line

F = Font
1 = 5x10 dots
0 = 5x8 dots

So looking at the code in the library file, the define is acted upon but is only used to correctly configure the display driver chip for the LCD display connected to it during initialisation.

When you consider that there isnt a define for LCD_CHARS to declare how many characters are on a line then it follows that it cant do anything clever such as work out that you have reached the end of line 1 and move to the start of line 2.

PBP does an awful lot of the hard work for you but there are times when you have to take care of some things yourself.