Hi,
I've been searching for clues!

Does this help [ SERIN_TIMEOUT_BIT ] ?

C.

It is for the software uart.

 

It is for the software uart.

Hi J,
Ok, no good for this then.
Thanks,
C.

 

Hi J,
.

Ok, no good for this then.
Thanks,
C.
P.S. At the moment I'm testing 'I's suggestion of HSERGET instead of HSERIN. I've just noticed that when I tested it earlier, I didn't see there are 2x HSERINs.

 

hi,
Use the Tools/Break point manager, to locate which part of the program is hanging.
Then post that section of code.
E

 

hi,
Use the Tools.Break point manager, to locate which part of the program is hanging.
Then post that section of code.
E

Hi E,
In SIM mode, it doesn't hang/block/lock?
In LIVE mode, it does.
C

 

Hi
I've been testing HSERGET in SIM MODE.instead of HSERIN.

I could see that [ rxi ] counts up at each pass, so the incoming [ CHARS ] weren't put in the correct [ STR1 ] slot.

So HSERGET may work, I'll have to come back to it later. (Remind me )

C.

 

Hi,
Will someone clarify, what is this known as, in computing terms, please?

When this is blocked:

C.

 

Hi,
I've been searching for clues!

Does this help [ SERIN_TIMEOUT_BIT ] ?

C.

Serin_Timeout_Bit is only used with the software UART implementation, not the hardware (HSERIN). From the serial UART code I've written in Oshonsoft, there is no easy way to control the hardware UART unless you use register flags and/or interrupts, not the HSERxxx commands themselves (specifically HSERIN). You still use HSEROPEN statement to set up the baud rate and registers
Sending out via HSER is ok, but that also "locks up" the main code until the send is complete. Again, some interrupt routine with buffers is the only way to send/receive data without holding up the program.
The software serial input (bit banging) has that Timeout bit to interrupt the read, and I've used a timer bit to do such a thing, as well as a user "button" to press to cancel a serial read in another program.
The problem with the software serial code is that it has some limitations, like maximum speeds (around 9600 to 19200 baud) and it has some error percentages as well. The error (bit drift) is not bad if one uses the delay between characters when sending, but if you shorten that delay, you can get actual errors in send/receive. To read via software seriel, you have to dedicate a fair bit of CPU time as to not miss any characters. One can use IOC for a software serial pin to trigger a read when it detects the first start bit changing state...
Only with an external crystal oscillator can you get accurate hardware UART speeds, up to 115200 baud. Common crystal frequencies are 3.6864Mhz, 7.3728Mhz, and multiples of those frequencies. For software UART (bit banging), the least baud error I found at 9600 baud was a 8Mhz crystal, with 0.16% error on send, 0.64% on receive (Oshonsoft compiler will list the error in the listing when using software UART)

 

Hi
I've been testing HSERGET in SIM MODE.instead of HSERIN.

I could see that [ rxi ] counts up at each pass, so the incoming [ CHARS ] weren't put in the correct [ STR1 ] slot.

So HSERGET may work, I'll have to come back to it later. (Remind me )

C.

I would check the RX buffer bit first, to verify there is a character to "GET", before reading it. HSERGET will return a zero immediately if there is no character. If there is a character in the RX buffer, it will return that character. Do the read over and over until it returns a zero.
The problem of HSERGET is that if a zero is a valid character in any of your data streams, it will not work properly. Hence, always check the "RX buffer full" bit (PIR1.RCIF in most 16F series chips) to ensure there actually is a character in the receive buffer....

 

Hi S,
I will need to read this a couple of times, to better understand it.

Here is an image of HSERIN also an image of HSERGET in SIMULATOR

I understand that as the program is written for HSERIN, and it will most likely need programming for HSERGET slightly differently.

You can see that HSERGET is a possibility, though, and I will reply again, after playing for a while.

EDIT: Note missing 'E' from $REMOTE., in HSERGET STR1 STRING [ ERROR DISREGARD ]
If I understand correctly, HSERIN receives whole sentences, and HSERGET receives single digits.

Thanks,
C.

 

Hi,
Here's an attempt to use HSERGET.

Looking at the empty STR1() VARIABLES [ HSERGET ] #50, I added a WAIT into the program, which works in SIMULATOR.

Can someone try it in SIM please?

C

 

hi,
This is sim in my PC.
What is the purpose is the Wait command.?
Don't waste program processing time.
E

 

hi,
This is sim in my PC.
What is the purpose is the Wait command.?
Don't waste program processing time.
E

Hi E,
Without the WAIT you get HSERGET #50 result in the STR1 STRING.
With the WAIT you get HSERGET #51 result in the STR1 result.

I just had a stab at it, but I'm sure there's a better way, perhaps a BIT switches at the right time to HSERGET the CHAR.

When I test, I change the $ sentence numbers a little, to prove something's changing.
C.

 

Camera, looking at one section of your code, you increment "rxi" but never check if it overflows past 79. If, for some reason, you get more data than you expect, you will possibly crash the program when you overflow STR1.

 

Camera, looking at one section of your code, you increment "rxi" but never check if it overflows past 79. If, for some reason, you get more data than you expect, you will possibly crash the program when you overflow STR1.

Hi S,
I tried a quick test, and I posted it before finishing it, to see if it looks ok.

I had realised that STR1 counts for ever, and will change it, but thanks for pointing it out.

Can you think of a way round 'E's comment about the WAIT I added to get it to run?
C

 

If you are running at 9600 baud, each character arrives about every 1mS. Having a wait of 15mS means you could miss up to 15 characters!
The simulator does not need those waits either, provided you are checking the status of the receive UART registers. If using software Serial, it still makes no sense to have any Wait in the receive loops, you just wait for the character (with a timeout routine), or you monitor the input pin for change of state to flag that a new start bit has begun, then issue a software serial read..

 

In your code:

nxt_rxin:
If str1(0) = "$" Then
    WaitMs 15  '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Hserget char
    If char = "?" Or char = 0x0a Then Goto msg_eol
    str1(rxi) = char
    rxi = rxi + 1
Goto nxt_rxin

Hserget will return a zero if no character has been received yet. If your loop is fast, it will fill your string with lots of zero characters. You have to filter those out in that loop, or check the receive register for the flag saying there is something in the buffer. Do not do a HSERGET if there is nothing in the receive buffer, there is no point. You have to control the flow of the serial data, and always check validity of each character you get (or filter).

PS Hserin will read anything, based on the variables in the line. It can read a single character, or an entire string of characters, depending on what you ask it to read. Hserget is just a character "read the receive buffer", regardless if there is anything in it or not.

 

In your code:

nxt_rxin:
If str1(0) = "$" Then
    WaitMs 15  '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Hserget char
    If char = "?" Or char = 0x0a Then Goto msg_eol
    str1(rxi) = char
    rxi = rxi + 1
Goto nxt_rxin

Hserget will return a zero if no character has been received yet. If your loop is fast, it will fill your string with lots of zero characters. You have to filter those out in that loop, or check the receive register for the flag saying there is something in the buffer. Do not do a HSERGET if there is nothing in the receive buffer, there is no point. You have to control the flow of the serial data, and always check validity of each character you get (or filter).

PS Hserin will read anything, based on the variables in the line. It can read a single character, or an entire string of characters, depending on what you ask it to read. Hserget is just a character "read the receive buffer", regardless if there is anything in it or not.

Hi S,
HSERIN or HSERGET choice:
HSERIN was working fine, but it blocks/stalls/hangs??, so HSERGET was suggested. HSERIN is preferable.

I'll remove the WAIT

II'll keep searching searching the DATA SHEET, for the UART RECEIVE REGISTER FLAG/STATUS.
Thanks.
C.

 

hi C,
Am I correct in assuming that the full/total program is in one 18F4620, that is reading incoming data, is also controlling the PWM.etc ... ??
E

 

hi C,
Am I correct in assuming that the full/total program is in one 18F4620, that is reading incoming data, is also controlling the PWM.etc ... ??
E

Hi E,
No.
I've added an explanation diagram Here: https://forum.allaboutcircuits.com/...ocation-pic-in-oshonsoft.148795/#post-1270205 #1
Let me know if it's clear.
C.