PDA

View Full Version : Hserout overides debug and serout2



acjacques
- 13th June 2022, 23:52
When trying to send serial message to same pin using HSEROUT and DEBUG and SEROUT2.
I have noted that HSEROUT overides any other messages .
If HSEROUT is uncommented only it work. If HSEROUT is commented the DEBUG and SEROUT2 works concurrently without problem.

h= 1234
main:
serout2 portb.5,baud96T,["Serout2=", dec4 h, 13,10]
debug "Debug=", dec4 h,13,10 'configured to same PORTB.5 same baud rate
'hserout ["HSerout=", dec4 h, 13,10] 'configured by chip to same PORTB.5 same baud rate
pause 500
goto main

Is this behavior normal ? Are there any way to enable and disable HSEROUT in order to have the 3 outputs working in the same pin ?

acjacques
- 14th June 2022, 00:53
Solved:

I use:

TXSTA = $24 ' enable HSEROUT just before use it
HSEROUT...... here
TXSTA= $0 ' disable HSEROUT after the use. This will allow Debug and Serout2 be used in the pin


Solved

mpgmike
- 14th June 2022, 12:19
My first question is why would you try to do the same thing 3 different ways in such a way as they conflict with each other?!?

HSEROUT is Hardware based. If you look at the data sheet for whatever PIC you're using, there is a UART peripheral built in. HSEROUT uses that. Many of the PBP Commands are "bit-banged" where the function (command) is software driven, not hardware. This means that with PBP you can have an SPI function on a PIC that the data sheet claims that function is not available. However, if your PIC has SPI, using certain commands won't use it, choosing to implement everything in software instead (as you've found out).

What I see is you were attempting to try to do the same thing with software driven commands and hardware driven commands at the same time. Your question suggests the hardware commands over-rode the software commands -- as it should be.

PBP is magical in many ways. Like Arduino, the software seems to make things happen, even when you don't know why. I suggest you spend some time with the PBP Reference Manual to better understand which commands activate hardware, and which ones make things happen outside of built-in peripherals (part of the magic of PBP). Using certain commands will create a functional output without ever tapping the hardware -- even if it's built into the PIC you're using. Yes, it can get confusing.

When I bought PBP3.1 many years ago, I spent a few more dollars for the paper copy of the PBP3 Reference Manual. I read through it many times, made notes in the margins, highlighted different things in different colored markers... I tried to get to understand the tool I purchased. I eventually had to laminate the covers and punch new holes because they were falling off. I do many things differently than most folks on this forum because of that experience. I don't rely on software commands when there is hardware already built into the PIC which can do a better job than the software commands. It requires manually manipulating the SFRs the long way. Software commands are awesome when you want to do something the PIC data sheet says can't be done -- and PBP does that quite well at times.

Ultimately you have to find what works best for you. The more you know -- knowledge is power -- the better you will do with your projects.