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