Problems with hserout/hserptr

friis

Senior Member
Hi,
I have a pgm:

#PICAXE 28X2
#Terminal 9600
hSerSetup B115200_8,%11

hSerOut 0, ( "AT",cr )
Sertxd (hserptr,cr,lf)
do while ptr <> hSerPtr
b0 = @ptrInc
SerTxd ("RX", tab, #b0, tab, $22, b0, $22,cr,lf)
loop

which I cannot make work. I made a simpler version:

#PICAXE 28x2
#Terminal 9600

SerTxd ("Started.....",cr,lf)
hSerSetup B9600_8,%11
sertxd (hserptr,cr,lf)

main:
b0 = "A"
b1 = "B"
hserout 0,(b0,b1)
sertxd (cr,lf)
sertxd (#hserptr,cr,lf)

which produces the output:

Started.....
[00]
AB
0

The last [00] indicates that hserptr does not work - it should be 2. Should it work for hserout?
best regards
torben
 

lbenson

Senior Member
I think you've left out some steps in your explanation and/or code. What is connected?

Regarding the second example, have you connected hserout pin to the hserin pin? Otherwise, how would hserptr (pointer to location in scratchpad of next hserin byte to be received) be incremented?

How is "AB" being printed?
 

Aries

New Member
hserptr is the SERIN pointer - it points to the next location in scratchpad to receive data. hserout does nothing with it.
 

friis

Senior Member
Hi Ibenson,
I did not leave anything out of the code of example 1 - of course the pgm was longer. But every time I ran the pgm, I got different results - some of which were correct.

The 2. example shown is the result of a compilation - that is why AB is printed.
I ran the compiled pgm 5 times. Twice sertxd (#hserptr,cr,lf) gave the correct result: 2. Twice it gave: 0 and once it gave 1. It must be serptr that is the problem, but I cant see what the problem is. Why does it not give the same result each time?
torben
 

friis

Senior Member
Hi Arles,
Hserptr set the limits for the printing of b0 and b1. If (#hserptr,cr,lf) is 0 nothing will be printed (1st example).
torben
 

lbenson

Senior Member
The 2. example shown is the result of a compilation - that is why AB is printed.
I still don't understand this. Exactly what part of the code you posted caused "AB" to be produced in the output? And how is the picaxe wired so that you expect an hserout to result in hserptr being incremented? I can see how "[00]" gets there, and "0", but how is "AB" output?
 

lbenson

Senior Member
Hserptr set the limits for the printing of b0 and b1. If (#hserptr,cr,lf) is 0 nothing will be printed (1st example).
hserptr is not related to b0 and b1. It relates to the scratchpad, so that if hserptr is 2 then (assuming that ptr started at 0), the two received bytes could be output with SERTXD(@ptrinc,@ptr).
 

Technical

Technical Support
Staff member
In this context hserptr tells you how many bytes have been serially received and stored in the scratchpad memory. It is unrelated to how many bytes have been sent, hserptr does not increment just processing a hserout command. However if the device at the other end responds with some data, this will then cause the hserptr byte count to change.
 

friis

Senior Member
Hi hippy,
I have noticed that the manual does not mention the scratchpad memory in connection with hserout. In other words, I cant use it (the way I do in example 1) in connection with hserout?
torben
 

lbenson

Senior Member
I have noticed that the manual does not mention the scratchpad memory in connection with hserout.
Manual 2:
Code:
HSERSETUP baud_setup, mode
...
- Mode is a variable/constant whose bits specify special functions (not all
features are supported on all chips) :
bit0 - background receive serial data to the scratchpad (not M2 parts)
 

Technical

Technical Support
Staff member
Hi hippy,
I have noticed that the manual does not mention the scratchpad memory in connection with hserout. In other words, I cant use it (the way I do in example 1) in connection with hserout?
torben
You do not access the scratchpad at all in post 1? Scratchpad is accessed via put / get and @ptr
 

lbenson

Senior Member
You do not access the scratchpad at all in post 1? Scratchpad is accessed via put / get and @ptr
In the first piece of code in post 1, there's "b0 = @ptrInc" as part of a loop. This seems rational to me, but perhaps a pause is needed before the loop to give the responding module time to answer--if it is answering. In cases like this I've forked the hserin line to a usb/serial module on my PC so that I can see what is being sent.

Output is being inverted with HSERSETUP--does input also need to be inverted?

(And perhaps more to the point, what kind of module is being talked to that needs an inverted signal?)
 
Last edited:

Technical

Technical Support
Staff member
In the first piece of code in post 1, there's "b0 = @ptrInc" as part of a loop.
Ok yes, we were referring to the simpler test program which implies an expectation that hserptr will increment for each hserout byte (which it does not). More information on the hardware setup would be beneficial for us all to understand what is being attempted.
 

friis

Senior Member
Hi,
As I understand it I would be accessing the scratchpad memory if I had been using hserin. But what would be the point? Barring some hardware failure I might as well look at the variable received byte for byte.
Since I am using hserout I cannot trust that the hserptr is increased byte for byte and I cannot access the scratchpad memory to see what I am sending. It surprises me, however, that if I try it works sometimes.
torben
 

lbenson

Senior Member
As I understand it I would be accessing the scratchpad memory if I had been using hserin. But what would be the point? Barring some hardware failure I might as well look at the variable received byte for byte.
Your command, hSerSetup B115200_8,%11, has bits 1 and 0 set high. Bit1 high means that output with HSEROUT with be "inverted", that is, will idle low. Standard picaxe SEROUT is also "inverted, idle low", but most modules you will connect a picaxe to will be "true", idle high, like old RS232 comms.

Bit0 high means you have enabled "background serial receive", which means that serial input on the hserin pin will be placed in the scratchpad at the location specified by hserptr (which will then be incremented to point to the location where the next background byte will be placed. ptr, the pointer to the scratchpad, will typically have been set to 0 at the beginning of the program, along with hserptr. When your program finds that ptr is not equal to hserpter, you can run a loop "some byte = @ptrinc" until ptr=hserptr to look at what you have received.

But what would be the point?
The point is that your program can be doing other important things while the serial is being received in the background--it doesn't have to spend all its time attending to the hserin line. Then you can look at what has been received in the background into the scratchpad.

Since I am using hserout I cannot trust that the hserptr is increased byte for byte and I cannot access the scratchpad memory to see what I am sending. It surprises me, however, that if I try it works sometimes.
Nothing about hserout affects hserptr--that is what you can trust. As far as "if I try it works sometimes", you haven't told us what you are connecting to that works, and exactly what the code is that "works" and how you can tell that it works.
 

friis

Senior Member
Hi Ibenson,
1. That is the situation described in 1. - apart from the fact that I am (wrongly) using hserout.

2. But I can still look at the variable to see what I got.

3. In the actual pgm I had several like the one shown. Some of them came out right, some of them half right and some of them did not came out at all (hserptr = 0). I did not do any connections.
torben
 

lbenson

Senior Member
For the second program in post #1, there's an inconsistency between the code shown and the output. And none of it can make sense to those of us who are trying to help with your problem if we don't know what you are connecting to and how you are connecting.

If you have something that works sometimes, please post exactly that code and exactly the output (cut and paste in both cases, preferably enclosed with "[ code]" and "[ /code]" forum tags), plus a circuit diagram or description and photograph.

I did not do any connections.
If you have no connections, how do you expect to receive anything? (You could be getting random bytes from a HSERIN pin that was floating, so if you have nothing connected, try pulling down the hserin pin with, say, 100K to 0V.)
 

Flenser

Senior Member
Friis,

You said said about your simpler example in post #1 "The last [00] indicates that hserptr does not work - it should be 2."

The only thing in your simple example that appears to match this value of 2 is the number of characters sent by hserout 0,(b0,b1) so we are assuming that you expect hserptr to be have a value of 2 because you sent 2 characters using hserout.

This is not correct. The hserout 0,(b0,b1) command has no effect on the value of hserptr.

The hserptr tells you how many characters have been received in the background while your simple example has been running.

You can test this by disconnectiong the hserin pin so that you are guaranteed to receive 0 bytes at the hserin pin while the simpler example is running and if you do this the test second sertxd (#hserptr,cr,lf) should always write "0"

Here is my explaination for what happens when the hserin pin is disconnected:
Code:
SerTxd ("Started.....",cr,lf)    ; writes "Started ......"to sertxd
hSerSetup B9600_8,%11 ; background serial is started and there is not enough time to receive a character before the next command
sertxd (hserptr,cr,lf)        ; so the hserptr is 0 at this point and this syntax writes the hex value "[00]" to sertxd
main:
b0 = "A"
b1 = "B"                 
hserout 0,(b0,b1)            ; writes "AB" to sertxd. hserout has no effect on hserptr so hserptr is sitll 0
sertxd (cr,lf)
sertxd (#hserptr,cr,lf)        ; if the hserptr is still 0 at this point this # syntax writes the decimal value 0 to sertxd
If the hserin pin is connected and you are sending bytes to hserin while this code is running then the value reported by second sertxd (#hserptr,cr,lf) will vary depending upon how many bytes happen to be received in the background while this short program runs. i.e. it could be 0, 1, 2 or something else depending upon how long the program takes to complete.
 

friis

Senior Member
Hi Ibenson and Flenser,
I think that I have answered your mail in my message no. 14. I realized that I cannot use the scratchpad memory in connection with hserout. When I had attempted to use it I got varying results - which had surprised me and which was the reason I did not realize that my usage was wrong. The pgm should have been connected to a Simm900 mobile phone, but I have not got around to try the connection.
"depending upon how many bytes happen to be received in the background while this short program runs. i.e. it could be 0, 1, 2 or something else depending upon how long the program takes to complete" - actually, the pgm was not supposed to receive anything (into the scratchpad memory.
torben
 

Flenser

Senior Member
Friis,

Your comment "actually, the pgm was not supposed to receive anything (into the scratchpad memory" indicates to me that you may still misunderstand how the hserptr and the scratchpad memory are used.

When you specified a "1" for bit 0 of the mode in the command "hSerSetup B9600_8,%11" you did specify that you wanted the PICAXE firmware to perform "background receive serial data to the scratchpad". The phrase "background receive" means that this will happen no matter what else your program does.

It does not matter what your code actually does. If you connect a module to the hserin pin and that module transmits data to the hserin pin of the PICAXE chip then the PICAXE firmware will be loading the received characters into the scratchpad memory and updating the hserptr (and hserinflag) variables/flags. Note that _no_ hserin command is used with background receive but the characters are still received and loaded into the scratchpad.

e.g. If a module is transmitting serial bytes to the hserin pin then even with the code below that does nothing the PICAXE firmware will still be loading characters into the scratchpad memory and updating the hserptr variable:
Code:
#PICAXE 28x2
#Terminal 9600
hSerSetup B9600_8,%11
main:
goto main
If your Simm900 module is connected to the hserin pin and is transmitting characters then this next program will show you the hserptr increasing as characters are received in the background (hserptr will eventually wrap around to zero when it gets to the end of the scratchpad memory area).
Code:
#PICAXE 28x2
#Terminal 9600
hSerSetup B9600_8,%11
main:
sertxd (#hserptr,cr,lf)      
goto main
 

friis

Senior Member
Hi Flenser,
Yes, I understand how hserptr works with hserin, but I was not using hserin and I never connected to the Sim900.
torben
 

Flenser

Senior Member
Friis,

hserptr is not used with hserin.
You either:
a) set bit 0 of the mode to "1" in hsersetup to have the receiving done in the background by the PICAXE firmware where the firmware puts the received characters into the scratchpad and updates hserptr. When using background receive you do not use hserin.
b) set bit 0 of th e mode to "0" hsersetup and use hserin. There is no background receive happening so hserptr is not used. (I've never checked to see if it gets updated when bit 0 of the mode is "0".)

If you had no module connected to the hserin pin for your two test programs in your post #1 then I have to admit that I don't understand how the hserptr was being updated.
 

PieM

Senior Member
With SIM900, no need of inverting idle . I use HSerSetup B19200_8, %001.
What else about your module and your program ?
 

Flenser

Senior Member
Friis,

This code on my 20X2 with nothing connected to the hserin pin continually reports the value of "1" for hserptr because no characters are being received by the background receive function.
Code:
#PICAXE 20x2
#Terminal 9600
hSerSetup B9600_8,%11
main:
sertxd (#hserptr,cr,lf)       
goto main
This next code, where I've added hserout inside the loop, also continually reports the value of "1" for hserptr because hserout does not use or change the value of hserptr:
Code:
#PICAXE 20x2
#Terminal 9600
hSerSetup B9600_8,%11
main:
hserout 0,(#hserptr)
sertxd (#hserptr,cr,lf)       
goto main
 

lbenson

Senior Member
If you had no module connected to the hserin pin for your two test programs in your post #1 then I have to admit that I don't understand how the hserptr was being updated.
If the pin was floating, it seems possible to me that it could be picking up random noise.
 

friis

Senior Member
Hi everybody,
I found an original answer from hippy (from Feb. 2019):

Code:
#PICAXE 28X2
#Terminal 9600

hSerSetup B2400_8,%001
pause 2000
SerTxd ("Started.....",cr,lf)
MAIN:
    do
        hSerOut 0, ( "AT",cr )
        pause 2000
        do while ptr <> hSerPtr
            b0 = @ptrInc
            SerTxd ( "Rx", tab, #b0, tab, $22, b0, $22, cr,lf )
        loop
        SerTxd ("----",cr,lf)
    loop
and it assumes that the Sim900 is connected. That clears up the confusion. The hserptr has nothing to do with the hserout - it assumes that an answer (after 2 sec.) has been received from the Sim900.

A problem with (my) memory!
torben
 
Top