I’m having a problem with the hardware serial input to a 20X2. I’ve used this feature before with a GPS and other inputs and found it to work very simply and reliably in the past but not today. I’ve narrowed my current problem down to the following simple program.
The program receives 3 short lines of characters, each line being about 35 characters long. The lines consist of a date/time stamp and a couple of other numbers. The program simply has to extract the single character following the 3rd comma in each line of characters sent. A typical line of characters would be:
6/1/20, 15:57:14, 10,2 (82,82) and the character to be extracted in this case would be "2".
It is my understanding that the hardware serial should occur in the background and be completely unaffected by what the program is doing but that doesn’t appear to be the case here.
The program that follows consists of 2 basic parts. The first part between the dotted lines allows the program to perform as expected by delaying any parsing of a line of characters until the complete line has arrived into the hardware buffer. It does this by waiting for there to be a 100mS delay in the arrival of a new character. The rest of the program simply extracts the required character by looking for the 3rd comma and copying the next character into the variable “Char”. Both parts of the program have a number of sertxd statements so I can see what’s happening.
The following shows the results of running the full program and demonstrate that it’s performing as expected.
However, the whole purpose of using the 20X2 for this project is to be able to process this data as it arrives while doing other things. Therefore, I would expect that the program should operate without delaying until the full line has been read into the buffer. In this example, I’ve simply remmed out the first part of the program and run it again but you can see from the following that it’s a disaster.
The first thing to note is that the hSerPtr isn’t steadily rising as I would have expected and appears to stall after about 15 characters. Only the first 4 characters are correct and from there on its a mixture of garbage and the odd possibly correct character. When the 2 lines are sent a couple of seconds later, it seems to get a few more characters into the buffer but they are obviously corrupted.
When this first happened, I assumed that I was somehow over-running the buffer but the debug data confirms that ptr is never greater than hSerPtr . The other possibility that I thought of was that somehow this 20X2 was affecting the data being sent but a check on that showed a normal transmission. The first part of that actual transmission is shown below.
I also checked that the voltage supplying the 20X2 and that appeared to be stable at 5 volts and for completeness I ran it again using 4 fully charged batteries. Finally, I set up another 20X2 on a breadboard with only the download resistors and the connection to pin b.6 (the hardware serial in pin) and it performed the same.
I’ve spent a considerable amount of time working on this and have run out of ideas so I’m looking for suggestions. I’m sure it has to be something simple and will probably be quite obvious when it’s pointed out – at least, I’m hoping that will be the case.
The program receives 3 short lines of characters, each line being about 35 characters long. The lines consist of a date/time stamp and a couple of other numbers. The program simply has to extract the single character following the 3rd comma in each line of characters sent. A typical line of characters would be:
6/1/20, 15:57:14, 10,2 (82,82) and the character to be extracted in this case would be "2".
It is my understanding that the hardware serial should occur in the background and be completely unaffected by what the program is doing but that doesn’t appear to be the case here.
The program that follows consists of 2 basic parts. The first part between the dotted lines allows the program to perform as expected by delaying any parsing of a line of characters until the complete line has arrived into the hardware buffer. It does this by waiting for there to be a 100mS delay in the arrival of a new character. The rest of the program simply extracts the required character by looking for the 3rd comma and copying the next character into the variable “Char”. Both parts of the program have a number of sertxd statements so I can see what’s happening.
Code:
#picaxe 20x2
#no_data
#no_table
#terminal 9600
symbol char=b1
symbol commacnt=b2 'count of number of commas encountered
symbol temp=b3
symbol temp1=b4
HSerSetup B9600_8,%111 'Switch on background RS232
ptr=hserptr 'Synchronise pointers
commacnt=0 'initialize comma count
do
'----------------------------------------------
do
temp=hserptr
pause 100
loop while hserptr<>temp or ptr=hserptr
sertxd ("Buffer end ",#temp,cr,lf)
temp1=ptr 'save ptr temporarily
for ptr=temp1 to temp 'Display what's in the hardware buffer
sertxd (@ptr)
next ptr
ptr=temp1 'restore ptr
sertxd ("Buffer start & end after sertxd ",#ptr,", ",#hSerPtr,cr,lf)
'----------------------------------------------
if hSerPtr <> ptr then
do
do:loop until hSerPtr <> ptr 'delay until the next character has actually arrived
sertxd (#hserptr,", ",#ptr,", ",@ptr," (") 'display hSerPtr & ptr values and the character being processed
temp=@ptrinc 'save the character into temp and increment ptr
sertxd (#temp,")",cr,lf) 'display the ascii value of the character being processed
if temp="," then
inc commacnt
if commacnt=3 then
do:loop until hSerPtr <> ptr 'delay until the next character after this one has actually arrived
char=@ptr
inc commacnt 'increment comma count to prevent coming here again for this line of caharacters
sertxd (cr,lf,"Char=",Char,cr,lf)
endif
endif
loop while temp<>lf
commacnt=0 'reset comma count
sertxd ("Finished line",cr,lf)
endif
loop
Code:
Buffer end 36
6/1/20, 15:57:14, 10,2 (82,82)
Buffer start & end after sertxd 0, 36
36, 0, 6 (54)
36, 1, / (47)
36, 2, 1 (49)
36, 3, / (47)
36, 4, 2 (50)
36, 5, 0 (48)
36, 6, , (44)
36, 7, (32)
36, 8, (32)
36, 9, 1 (49)
36, 10, 5 (53)
36, 11, : (58)
36, 12, 5 (53)
36, 13, 7 (55)
36, 14, : (58)
36, 15, 1 (49)
36, 16, 4 (52)
36, 17, , (44)
36, 18, (32)
36, 19, (32)
36, 20, (32)
36, 21, 1 (49)
36, 22, 0 (48)
36, 23, , (44)
Char=2
36, 24, 2 (50)
36, 25, (32)
36, 26, (32)
36, 27, ( (40)
36, 28, 8 (56)
36, 29, 2 (50)
36, 30, , (44)
36, 31, 8 (56)
36, 32, 2 (50)
36, 33, ) (41)
36, 34, (13)
36, 35,
(10)
Finished line
Buffer end 105
6/1/20, 15:57:16, 10,0 (80,80)
6/1/20, 15:57:16, 0,0 (0,0)
Buffer start & end after sertxd 36, 105
105, 36, 6 (54)
105, 37, / (47)
105, 38, 1 (49)
105, 39, / (47)
105, 40, 2 (50)
105, 41, 0 (48)
105, 42, , (44)
105, 43, (32)
105, 44, (32)
105, 45, 1 (49)
105, 46, 5 (53)
105, 47, : (58)
105, 48, 5 (53)
105, 49, 7 (55)
105, 50, : (58)
105, 51, 1 (49)
105, 52, 6 (54)
105, 53, , (44)
105, 54, (32)
105, 55, (32)
105, 56, (32)
105, 57, 1 (49)
105, 58, 0 (48)
105, 59, , (44)
Char=0
105, 60, 0 (48)
105, 61, (32)
105, 62, (32)
105, 63, ( (40)
105, 64, 8 (56)
105, 65, 0 (48)
105, 66, , (44)
105, 67, 8 (56)
105, 68, 0 (48)
105, 69, ) (41)
105, 70, (13)
105, 71,
(10)
Finished line
Buffer end 105
6/1/20, 15:57:16, 0,0 (0,0)
Buffer start & end after sertxd 72, 105
105, 72, 6 (54)
105, 73, / (47)
105, 74, 1 (49)
105, 75, / (47)
105, 76, 2 (50)
105, 77, 0 (48)
105, 78, , (44)
105, 79, (32)
105, 80, (32)
105, 81, 1 (49)
105, 82, 5 (53)
105, 83, : (58)
105, 84, 5 (53)
105, 85, 7 (55)
105, 86, : (58)
105, 87, 1 (49)
105, 88, 6 (54)
105, 89, , (44)
105, 90, (32)
105, 91, (32)
105, 92, (32)
105, 93, 0 (48)
105, 94, , (44)
Char=0
105, 95, 0 (48)
105, 96, (32)
105, 97, (32)
105, 98, ( (40)
105, 99, 0 (48)
105, 100, , (44)
105, 101, 0 (48)
105, 102, ) (41)
105, 103, (13)
105, 104,
(10)
Finished line
Code:
2, 0, 6 (54)
7, 1, / (47)
12, 2, 1 (49)
14, 3, / (47)
14, 4, ç (231)
14, 5, 3 (51)
14, 6, (30)
14, 7, y (121)
14, 8, (30)
14, 9, 8 (56)
14, 10, 2 (50)
14, 11, ) (41)
14, 12, (13)
14, 13,
(10)
Finished line
16, 14, 6 (54)
21, 15, / (47)
25, 16, 1 (49)
25, 17, / (47)
25, 18,
(14)
25, 19, ž (158)
25, 20, (30)
25, 21, (30)
30, 22, þ (254)
35, 23, 8 (56)
35, 24, 0 (48)
35, 25, 6 (54)
35, 26, / (47)
35, 27, 1 (49)
35, 28, 6 (54)
35, 29, : (58)
35, 30, 2 (50)
35, 31, 9 (57)
35, 32, ù (249)
35, 33, 0 (48)
35, 34, ø (248)
When this first happened, I assumed that I was somehow over-running the buffer but the debug data confirms that ptr is never greater than hSerPtr . The other possibility that I thought of was that somehow this 20X2 was affecting the data being sent but a check on that showed a normal transmission. The first part of that actual transmission is shown below.
I also checked that the voltage supplying the 20X2 and that appeared to be stable at 5 volts and for completeness I ran it again using 4 fully charged batteries. Finally, I set up another 20X2 on a breadboard with only the download resistors and the connection to pin b.6 (the hardware serial in pin) and it performed the same.
I’ve spent a considerable amount of time working on this and have run out of ideas so I’m looking for suggestions. I’m sure it has to be something simple and will probably be quite obvious when it’s pointed out – at least, I’m hoping that will be the case.