two serial ports

[Scampy]

Guys,

Quick question, is it possible to have a hardware serial port and a software serial port running on the same PIC with the same code.

Th existing code uses the hardware port (pins RC6 and 7) to communicate with a PC application. The application is used to update and configure the unit rather than as a constant monitoring appliaction, so it's not in "constant" use, but the polling is run each time the cod loops. I now need to use a serial piggy module for my glcd, which will be used constantly to update the GLCD. Is it possible to set a pin up and use software serial commands whilst at the same time using the hardware option.

The module can use i2c / SPI / or Serial, but at the moment, i2c seems problematical compared to serial.

[Dave]

Scampy, I have had problems using DEBUG with REAL interrupts in the past as DEBUG is a software serial routine. I would imagine that the HSEROUT and HSERIN routines would have the same problem. I realize that HSERIN and HSEROUT use the hardware for the serial buffering but, the calls for either may give you grief. I have only used the interrupt routines with PIC's that have 2 serial ports in the past without any problems @ 38400 baud. I do have 1 application that I use both serial ports and DEBUG with in the same program. There I have to shut off both interrupt driven serial ports to reliably use the DEBUG port. I don't know about using the HSEROUT or HSERIN routines? Hope this helps....

[Scampy]

Dave, Thanks for the reply... I've found an alternative for now, but it means a lot more work... ESP8622 I think it's called. A wi-fi module which will either mean getting the PC software to work over the network, or re-write the application as a web page / app ... all good fun !

This then frees up the serial EUART on the PIC to handle the display driver board

[Art]

The UART is useful in next to no time. You wouldn’t want the UART to call an interrupt while the software serial is working.

It depends what you mean by "at the same time”. You could rarely receive from both software serial and UART simultaneously,
but they could definitely both work together on a chip yes.

For a UART with a chip that has some other timing interrupt running.. no problem if you wrote the thing on the other end.
So long as you leave enough duration between transmitted bytes.
The interrupt during PBP software serial command would distort a frame by extending the duration of some bits.
The only way the UART will stuff up is if you don’t check it’s receive buffer often enough, since the hardware is responsible for shifting bits,
it’s also a lot quicker to access. You only have to check a byte is present and copy it which should take PBP a few instructions.

[ardhuru]

I've found an alternative for now, but it means a lot more work... ESP8622 I think it's called. A wi-fi module which will either mean getting the PC software to work over the network, or re-write the application as a web page / app ... all good fun !

This then frees up the serial EUART on the PIC to handle the display driver board

The ESP8266 itself also requires a serial port to communicate, so that will not solve your problem.

I dont know about using the hardware serial port and a software one together, but 2 software ports (change the debug definitions on the fly in your code) definitely work. So, if you can live with the overhead, that would be the way to go.

[Scampy]

Thanks for the comments guys,

Current PIC is an 18F4580. I use the standard serial comms to communicate with a PC applications. I'm developing the project to include additional sensors and as such need more real estate to display the results, so I've obtained a 128 x 64 FLCD, which with a similar font to an LCD, gives me 7 x 21 characters which is ideal.

I've also puchase a serial / i2c / SPI piggy back driver for the display, and at the moment have it running in serial mode as it was not wanting to do much more than control the back light etc. If I can get this running under i2c it would free up the TC/RX pins for either serial connection with the PC or the use of a serial wi-fi board mentioned above.

However I have 4 lines of code which simply fail to compile following the conversion from serial to i2c

i2cwrite SDApin,SCLpin,$00,$42,"TP",DEC1 Pid_channel+1,0

When compiled MCS states "Expected [ at line 743" and "Expected ] at line 743" but placing the brackets after the address and at the end, or any combo thereafter results in "Bad expression" error....

Any ideas

[Art]

The variable in it, I can’t tell if you mean (dig1 var) +1 or dig1 (var+1).
but I don’t know that is the problem, or which way PBP would read it.
You might as well log a write error it doesn’t hurt even if you don’t use it,
and if it was an EEPROM value you’d want to display there was an error.

What is the zero for? .. the last data in the command?

' start of code where other variables are defined
'
buff var byte
badwrite var bit
badwrite = 0



‘where your write command is
'
buff = Pid_channel + 1
I2CWRITE SDApin,SDLpin,0,$42,[$54,$50,DEC1 buff,0],error
doneread:


' somewhere at the bottom of program
'
error:
badwrite = 1
goto doneread

[Scampy]

Art

When used with an LCD or serial out simply displays the current PID_Channel number +1, ie if PID_channel is 0 (channels are 0 to 3), the number 1 is displayed on the screen

The "TT" / "TP" are commands used by the GLCD module, Text type and Text position respectively (just noticed a typo in the example that should be TT not TP - but that makes no difference to the error). The zero at the end is part of the syntax to close the command to the GLCD controller, so it is instructing the program to write to the device (GLCD controller) at said address, "TT" tells the device to display text or the results as text, and then received zero to close the command.

Whilst I could re-write the code to simply write 1,2,3 etc for the display, it was the fact that a line of code thus

i2cwrite SDApin,SCLpin,$00,$39, "TT",#setpoints(2)dig 2,#setpoints(2)dig 1,0

compiles without error, but

I2cwrite SDApin, SCLpin, $39, "TT", DEC1 Pid_channel+1, 0

Fails when i2c is used....

The other thing that puzzles me is the following code compiles by no time is displayed on the GLCD....

'display time on GLCD    
i2cwrite SDApin,SCLpin,$00,$39, "TP",0,6     
i2cwrite SDApin,SCLpin,$D0,$00,[RTCSec,RTCMin,RTCHour,RTCWDay,RTCDay,RTCMonth,RTCYear,RTCCtrl]  ; read DS1307 chip
If RTCHour.6=1 then
i2cwrite SDApin,SCLpin,$00,$39, "TP",0,6			
CounterA=(RTCHour>>4)&$01                           ' Work-Out 12 or 24 hour Display for Hours
else
CounterA=(RTCHour>>4)&$03
endif
CounterA=CounterA*10+(RTCHour&$0F)                  ' Display Hours appropriately for 12 or 24 hour Mode 
If RTCHour.6=1 then			
i2cwrite SDApin,SCLpin,$00,$39, "TT",#CounterA,0
else
i2cwrite SDApin,SCLpin,$00,$39, "TT",#CounterA Dig 1,#CounterA Dig 0,0
endif
i2cwrite SDApin,SCLpin,$00,$39, "TT", ":",#(RTCMin>>4)&$0F,#RTCMin&$0F,0

timeH=(RTCHour>>4)                               'convert the BCD format of the hours register and store in variable timeH
timeH=(timeH &$03)*10
timeH=timeH+(RTCHour&$0F)

timeM=(RTCMin>>4)
timeM=(timeM &$07)*10
timeM=timeM+(RTCMin&$0F)                         'convert the BCD format of the mins register and store in variable timeM

But again, work fine when HSEROUT is used inplace of i2cwrite....

I think I'll skip the i2c conversion and carry on with the stock serial version, and try and get the rs232 to USB board working with the GLCD driver board.

[Tabsoft]

Scampy,

I'm pretty sure the issue you are having with I2CWRITE vs LCDOUT is two-fold.
1. Using Output String Modifiers
2. The use of Brackets "[ ]" with I2CWRITE

First and foremost, PBP does not support "ALL TYPES" of Output String Modifiers for use with the I2CWRITE command.
It only supports one type of modifier with this command, the "STR" modifier.

From the PBP Manual for Output Modifiers:

2.11 Output Modifiers for Formatting Strings

The following information applies to output commands ARRAYWRITE, DEBUG, SEROUT2, HSEROUT, HSEROUT2, and LCDOUT.

I2CWRITE is not listed above.

Continuing from the PBP Manual for Output Modifiers for Formatting Strings:

All of these commands accept an item list to determine output.
Numeric data included in this item list can be converted to ASCII strings using the following modifiers.

Output Modifiers for Formatting Strings
Modifier Operation
{I}{S}DEC{1..10} Send decimal digits
{I}{S}BIN{1..32} Send binary digits
{I}{S}HEX{1..8} Send hexadecimal digits
REP char\count Send character c repeated n times
STR ArrayVar{\count} Send string of n characters

So trying to use DEC, BIN, HEX or REP with I2CWRITE will fail to compile.
The "Bad expression" compile error you get is due to the fact you are trying to use the "dec1" Output String Modifier with I2CWRITE, which is not supported.

However I2CWRITE does support the "STR" modifier.

From the PBP Manual for I2CWRITE:

I2CWRITE
"A modifier, STR, may be included before the variable name. This can be used to write an entire array (string) at once..."
"... If STR is specified, the following variable must be the name of a word or byte array, followed by a backslash (\) and a count:"

What you can possibly do is use ARRAYWRITE to store all of your "String" data into an array (with modifiers) and then
use I2CWRITE with the "STR x\n" modifier to output your formatted string, which is supported.

e.g.

myOutArray var byte[8]

ARRAYWRITE myOutArray, ["TT", dec1 (Pid_channel + 1), 0]

I2CWRITE SDA, SCL, I2CSlaveAddress, [STR myOutArray\4]	' \4 for "TT10" 4 bytes, which is what ["TT", dec1 Pid_channel+1, 0] would be assuming Pid_channel = 0.

Lastly, the issue of when to use brackets "[ ]" with I2CWRITE.
Although sometimes you can compile without errors when not using brackets.
I have found this seems to be for simple cases.
If you have complex statements in you variable list, then you need to use brackets.
Which is what you are seeing the "Expected '['" and "Expected ']'" compile errors from.
It think it is trying to parse the complexity of the input to the I2CWRITE command and gets lost, so errors out.
Then once you put the brackets around your list of data variables it errors out due to the unsupported "dec1" modifier.

I always surround my data variable list in this and other commands with brackets and do not have problems.

Hope this helps.

[Scampy]

Tabsoft, thanks for the reply.

Would that explain the following:

When using HSEROUT the line

Hserout ["TT",#CounterA Dig 1,#CounterA Dig 0,0]

Compiles without errors... but

serout portb.0,T9600,[DEC1 Pid_channel+1,0] 'or the following
serout2 portb.0,T9600,["TT",DEC1 Pid_channel+1,0]

Fails......

If what you are saying about the modifiers, why will they work with the hardware command, but not with the serial command ??

[Scampy]

OK I have an option (possibly ?)

As the GLCD driver and the simple code likes the HSEROUT command lets look at using SEROUT for the communications with the PC application...Before I try this can anyone confirm if this will work with the serial option

    IF RCIF=1 THEN GOSUB coms                   ; Check to see if PC application connected

I'm assuming that it's looking at the hardware port on the PIC ??

[Tabsoft]

No the modifiers will not work with SERIN or SEROUT.
But, they will work with SERIN2 and SEROUT2.
SERIN2/SEROUT2 replaced the old SERIN/SEROUT commands and added new functionality including the support of Input/Output string modifiers.

[Tabsoft]

Unfortunately No.

"IF RCIF = 1 THEN GOSUB coms" will not work with the Software-based SERIN/SERIN2 commands.
The RCIF EUSART Receive Interrupt Flag bit in the PIR1 PERIPHERAL INTERRUPT REQUEST (FLAG) REGISTER 1, is tied directly to the HW EUSART RX pin (PORTC.7). It is part of the PIC functionality of the EUSART hardware module.

[Scampy]

Thanks again,

I'll see if the PC application needs that action, and if not I'll try re-write the section that deals with sending and receiving data from the PC to use serial coms, thus leaving the hardware port on the PIC to deal with cons to the GLCD driver board, which for some reason or another accepts the modifiers DEC 1 etc

[Scampy]

Well after a lot of head scratching I have it working. No matter what I tried it still work and kept halting - Off board Tabsoft stated it worked fine for him using PBP3 so I downloaded the 15 day trial, confirmed it worked, but then as it screwed up my pbp2.60 setting, un-installed it and pointed MSC back at the PBP2.6 folder... tried again and it worked (WT* and other expletives filled the air at this point)

Anyway, just to clear things up, I now have the GLCD running via a driver board using PORTB.0 and software serial commands (SEROUT2) and the PC application communicates with the PIC via an FTDI chip on the PICs hardware UART - and it updates juts fine

Rightt onto the next part of tidying up the menus before replacing the FTDI chip with an ES8622 Wi-Fi module - stand by guys, no doubt I'll have a few more questions for you.

On a serious note, I want to publically shout out a big THANK YOU to Tabsoft for all his help and contributions, both on and off the board - I'm also slowly understanding more of what I'm doing, and how PBP and it's commands work