Solving Serin & Serout Problems with 20M2 and 20X2

Goeytex

Senior Member
Resolving Serin & Serout Errors on 20X2 and 20M2 Picaxe Chips


This note only deals with the Picaxe 20X2 and 20M2. However other Picaxe chips may have similar issues and should be tested.

In the process of working on a project that used both a 20X2 and a 20M2, I tried to send 2 bytes of serial data from the 20X2 to the 20M2 at 9600 baud using software serout and serin. No matter what I did not single byte could be received without error.

Both Picaxe Chips were set to 8Mhz. The 20X2 used " serout C.0, N9600_8, ($55,$55)" and the 20M2 used "serin c.0, n9600_8, b0,b1". A qualifier was added as well as delays but to no avail. The baud was reduced to 4800 but still no good. Only at 2400 baud was data able to be sent & received.

So I got out my newly acquired TEK THS730A digital scope and started testing. Here is what I found.

20X2
  1. When set to 9600_8 the actual serout baud rate is 9158. This is a -4% error.
  2. When set to receive with serin 9600_8, data can be reliably received only between 9808 and 10570, meaning serin 9600_8 is set by firmware to receive at a center baud rate of 10189. This is an error of 6.1% from a nominal 9600.
20M2
  1. When set to 9600_8 the actual serout baud rate is 9882. This is an error of +3.0%
  2. When set to receive with serin 9600_8, data can be reliably received only between 9624 and 10650, meaning serin 9600_8 is set by firmware to receive at a center baud rate of 10137. This is 6% error.
The inaccuracy at these setting renders the serial comm of both of these chips pretty useless when set to 8Mhz and incompatible with almost any device that sends data at the prescribed standard of 9600 baud. There is no wonder these 2 chips could not communicate with both set to 9600_8 . They are both so far off specification, and in opposite directions that at 9600_8 it would be impossible. A second pair of 20M2s and 20X2s confirmed these findings.

The Fix ? ... There is none....at least not at 9600_8 and other some other settings. Calibfreq has to be taken all the way to 31 on the 20x2 and to -15 on the M2 to get a single byte through. And at these settings sertxd fails with corrupted data to the PE terminal, not to mention the adverse affects on pulsout & pwm timings.

The good news is that the serout error on the 20X2 is less than 1 percent at 9600_16 with an actual baud rate of 9557. The serin error on the 20M2 is less than 1 percent at 9600_16 with an actual center baud rate of 9690... Both really good for software (bit- banged serial). And at this setting for both chips, unlimited back to back bytes can be sent & received without error.

By doing extensive testing on both chips severe accuracy problems were found at certain settings on each.At other settings the accuracy is good.

To keep this from being too boring, attached is a chart of the of the actual baud rates of serout and serin in for all possible frequency / baud combinations of these two Picaxe Chips from 2400 to 38400 baud and from 4Mhz to 32Mhz.

Solutions? ... All are work arounds .

1. Refer to the attached tables and use frequency / baud combinations that have the least error or that are compatible even with the error.

For example, a 20M2 can send and receive data to another 20M2 at 9600_8 because the error for both serin and serout is in the same direction. However, a 20X2 at 4800_4 cannot send data to a 20M2 at 4800_4 because the actual serout baud rate of the 20X2 is outside of the serin range of the 20M2.

2. If you must use a certain baud rate at a certain frequency/ baud combination that shows the 4% error or 6.1% serin error ( 9600_8 is very common), use hardware hserout instead of "serout" . This would be particularly applicable for serout 9600_8 with the 20X2 at 8mhz. 9158 baud is so far out of specification that it will likely fail with most any other device, even another 20X2.

What won't work.
1. Using a qualifier if the serout baud rate is outside of the "range" of the serin rate. The qualifier cannot be recognized reliably.
2. Adding a delay between bytes sent when serout is outside of the range of serin. Delays will not solve gross accuracy problems.

It is a myth that serin cannot process back to back bytes fast enough at 8mhz and above. Pacing, was only an issue in my testing at 2400_4 where the processor overhead is the highest and when the space between bytes was less than 900us. This can be easily proven at 8 Mhz and above by sending 32 back to back bytes at a rate within the serin expected range, (without a qualifier) . It works fine.

Attached are tables that show the actual baud rates for every serin / serout setting on the 20X2 & 202M2 chips from 2400 to 38400 baud. 64mhz was not tested on the 20X2.

EDIT:
The tables have shaded rows that indicate serial baud / processor frequency combinations that should be avoided.

It should be noted that a 20M2 CAN communicate with another 20M2 at these high error settings because the error for both serin and serout is in the same direction.

However a 20X2 cannot
communicate with another 20X2 at these settings because the baud rate error for serin and serout is in opposite directions.
 

Attachments

Last edited:

mrburnette

Senior Member
So I got out my newly acquired TEK THS730A digital scope...
Valuable info- thanks for compiling. Bit envious of the Tek... my old 422 is still hanging on after 30 years... I think I will die before the Tek!

- Ray
 

srnet

Senior Member
Good work.

Those really are substantial variances from the standard baud rate, I dont understand why the delays used in the soft UART routines are not a lot more accurate than that.

Some of the variance could be down to the errors in the RC internal oscillator, but still ............
 

Goeytex

Senior Member
Good work.

"...I dont understand why the delays used in the soft UART routines are not a lot more accurate than that.

Some of the variance could be down to the errors in the RC internal oscillator, but still ..."
I don't understand why the accuracy shifts way off only at certain settings, especially the serin nominal center
baud rate going in a different direction than serout on the 20X2. If it were an oscillator error you would think
the shift would be in the same direction and that the error would be seen in other command like pulsout or pwm.

At 8mhz Serout 9600_8 goes to 9158 ...while Serin 9600_8 goes a nominal 10189 with 9608 being the lowest possible baud rate
that it can work with. This has to be firmware related.

All of these settings that show the huge error in accuracy parse the same baud_rate value to the compiler.
That is a 7 where baud value = (Nxxxx_x) and a 3 where baud value = (Txxxx_x).
 
Last edited:

srnet

Senior Member
I don't understand why the accuracy shifts way off only at certain settings, especially the serin nominal center
baud rate going in a different direction than serout on the 20X2
Well some of it could be explained by there being a couple or more bits of assembler routine working as standard delays.

You call the routine once for 38400_32, 4 times for 19200_16 etc. If the base delay routine is way out, then you could expect this way outness to occur at particular baud and frequency combinations.

I recall from other threads that Technical were preparing an explanation, did I miss it ?
 

Goeytex

Senior Member
Well some of it could be explained by there being a couple or more bits of assembler routine working as standard delays.

You call the routine once for 38400_32, 4 times for 19200_16 etc. If the base delay routine is way out, then you could expect this way outness to occur at particular baud and frequency combinations.
How does that fit with the fact that on the 20M2 both serin and serout error shift in the same direction with the "bad settings" while on the 20X2 the serin / serout error shifts in opposite directions with the "bad settings"?

I recall from other threads that Technical were preparing an explanation, did I miss it ?
Still waiting.
 

westaust55

Moderator
Asking questions and prompting for answers in the Finished Projects section would, I think, have a lower probability of being seen and/or a response.
 

Goeytex

Senior Member
Asking questions and prompting for answers in the Finished Projects section would, I think, have a lower probability of being seen and/or a response.

The questions are mostly rhetorical and official answers from Rev-Ed are not really expected as Rev-Ed does
not seem willing/ready to address these serial inaccuracy problems at this point.
 
Last edited:

hippy

Technical Support
Staff member
The questions are mostly rhetorical and official answers from Rev-Ed are not really expected as Rev-Ed does not seem willing/ready to address these serial inaccuracy problems at this point.
It's not really fair to suggest Rev-Ed are unwilling to address any issue or are ignoring this one. As Technical has said elsewhere there will be more information given but the matter needs to be investigated, analysed and assessed, plus a response has to be formulated.

All that takes time and has to be fitted in with other things that Rev-Ed and their staff are doing; as always schedules, priorities and resource allocation come into play. "Are we there yet?", won't get anything produced any sooner.
 

Goeytex

Senior Member
Hippy,

There is no unfairness here at all.

My statement of, "not ...willing/ready" was an either / or ... giving two logical possibilities with no conclusion
on my part as to which. And nowhere did I use the word "ignoring" this thread. Your word, not mine.

You assumed that I concluded that Rev Ed was "unwilling" which I have not. Only that it was a logical possibility
(especially given Rev-Eds silence on the matter).

But I will call not your response here unfair, but rather that you simply missed the either/ or ..... or that I did not
communicate it well enough. I have not made a conclusion and am leaning closer to "not ready" given Technical's
promise in another thread to give an explanation. I know this kind of stuff takes time.

This is why I posted here in Completed Projects and not in the main forum. If my intent was to push
with "Are we there yet?" as you said, then I would have posted in Active and not here in the basement.

My purpose in this thread was to simply make the data available to those unaware of these problems
and to help users with the problems to get things working. Fair enough ?

Goey
 
It is an UN EXCUSABLE Omission from the Manual? and the lack of any 'Notes" left me with about 5 wasted hours trying to get a "Stable" 2400 Baud Project to work @ 9600 Baud
I finally trashed the code and design and used a Parallax BS2-PE... It worked... W/O trying to fix the "Un fixable code.
I am Totaly amazed at the lack of professionalism shown by the creators of Picaxe.
I had a similar issue in the speed at which the "Processor" executes simple commands. Picaxe is a GREAT learning tool... However it is good when it works, "Simple Tasks"...
I think I am going to build an Amicus18 PCB. I have Fab available in China... Anyone Interested?
 

mrburnette

Senior Member
It is an UN EXCUSABLE Omission from the Manual? and the lack of any 'Notes" left me with about 5 wasted hours trying to get a "Stable" 2400 Baud Project to work @ 9600 Baud
...
Smacks of SPAM if you ask me... and BTW, "UNEXCUSABLE" is not a real word, perhaps you meant 'inexcusable'???

Now, everyone pretty much knows on this forum that 20 pin and smaller PICAXE are RC clock devices and so some variation is to be expected. Goeytex has done a good deed and documented the issue for the 20X2 and the 20M2, but generally we know that chip-chip RS232 communications has been (and remains) problematic. Of course I don't like it, but I know it and it has been the subject of several threads. When I think about projects, I pretty much eliminate the concept of chip-chip RS232. Seeing that the biggest use of the serial RS232 capability is to program the PICAXE from the PC and to display data on displays such as LCD/OLED/PC_terminal, I do not think that this requires a trip to the hospital... maybe to the pub, but I'm inclined to look for any good reason to have a cold beer.

I'm up to my eyeballs in Atmel stuff for a friend; but I vote to give Technical the opportunity to do some serious in-depth research. Goey seems to agree (not putting words in his mouth, however.) A position statement from RevEd would be helpful and with more interest in PICAXE-PICAXE communications, it would seem that corrective action needs to be taken (or explain/document a workaround.)

Hippy, I understand you are an employee and wish to remain in that state, so I can appreciate you not getting dirty, but I suspect the longer this issue is open, the worst it will become. Maybe it is time to let management know there is some static coming from the end-users. While we are waiting on Technical, perhaps you can answer if you have coded and whiz-bang routines to communicate between chips for info/status/command passing; that is, something universal? ... you can call it the HipBus for all I care!

- Ray
 

westaust55

Moderator
. . . and used a Parallax BS2-PE . . .

I had a similar issue in the speed at which the "Processor" executes simple commands.
Picaxe is a GREAT learning tool... However it is good when it works, "Simple Tasks"...
With respect to the comment about “speed at which the 'Processor' executes simple commands” if one compares the PICAXE chips with the Parallax chips since Mr Johnson elected to move to a “Parallax BS2-PE” both use Interpreted BASIC and thus have lower overall throughput speeds compared with a microcontroller executing machine/assembler code.

By comparison:
A PICAXE at 4 MHz executes a typical command in ~0.25 ms which equates to around 4,000 instructions per second.
A PICAXE at 8 MHz executes a typical command in ~0.125 ms which equates to around 8,000 instructions per second.
A PICAXE at 32 Mhz executes a typical command in ~0.031 ms which equates to around 32,000 instructions per second.

Then using data from the Parallax website:
BS2pe operates at 8 Mz (turbo) and executes 6,000 instructions per second = 0.333 ms relative to 4 MHz clock
BS2e operates at 20 Mz and executes 4,000 instructions per second = 1.25 ms relative to 4 MHz clock
BS2px operates at 32 Mz (turbo) and executes 19,000 instructions per second = 0.421 ms relative to 4 MHz clock
BS2sx operates at 50 Mz and executes 10,000 instructions per second = 1.25 ms relative to 4 MHz clock

Now I am not a user of the BASIC Stamp products but do know the architecture and the use of an external EEPROM
for the BASIC interpreter but I do not “knock” the Parallax product.

But clearly there is no speed improvement in execution when comparing the typical time to execute an instruction at the same clock speed.
 

Goeytex

Senior Member
Mr Johnson could have solved his 9600 baud problem by simply using setfreq m16 and using
serout pin,T9600_16 ....Or by using hserout.

This thread should be about identifying & solving problems, not throwing rocks at Rev-Ed. I have been assured that the issues
brought up here will be addressed in due time.
 

mrburnette

Senior Member
A long, long time ago...
Back in my USAF days of the late 60's and while working night shifts, much of the maintenance in the center was being done. I got to know one of the teletype dudes pretty well and being mechanically inclined, I watched him do repair and regular PMs. He had a little testset that would send out "RYs" and would adjust the teletype until he centered the adjustment between the two extremes where the RY string would garble. A little research this morning yielded the fact that U* is the ASCII version of RY.

Thought: Maybe in a PICAXE to PICAXE scenario, the chips could be calibrated automatically. In the USAF, the receiver was always the master and the transmitter always the slave (concept I think evolved because correctly received data is the ultimate goal of communications.) Using the master/slave concept in the PICAXE world, upon initialization, the receiving PICAXE would request a U* pattern of the transmitter based upon a preselected U* pattern and BAUD rate. The request would have to originate from the receiver to the transmitter which implies an abstract command code over serial or a dedicated line. My thinking is a dedicated line would be the better approach... if the line is LOW, it is business as usual. If the line goes HIGH, the transmitter initiates a test pattern and goes into wait mode monitoring the dedicated line. The receiver will analyze the pattern, deduce an adjustment (+/-) parameter and communicate that to the transmitter over the dedicated line as a PWM signal. The transmitter will decode the PWM as +/- from the 50% mark. The transmitter will make adjustments and resend the test. This continues in small steps until the receiver sends the same PWM twice at which time the main() program restarts.

There are many scenarios that could play-out in the above. I have just thrown one out but I have not prototyped it as my buddy is still expecting me to deliver on his AVR code for a Gray code interface between his Dynon and his transponder (I'm rewriting the AVR to utilize a PICAXE... so do not throw tomatoes, please!)

I wrote a quick 08M2 program a little while ago that is sending an endless string of "U*" at 9600 to my scope. I really need someone with a storage scope to replicate the test, but I am seeing an almost perfect waveform overlay except every once in a while, there is some jitter in the signal... the jitter appears to start after bit 2 and continues with each successive bit in an additive mode; that is, the jitter appears to get worst with each successive bit. The next character for n characters are perfect and then the jitter will repeat. Without a storage scope, I cannot tell if the jitter is random or repetitively timed. Of course, it could just be the cheap scope... the Tek is engaged in another project and it is not convenient to move it at this time (and it is not storage, anyway.)

Code:
#picaxe 08m2

Disconnect
Do
sertxd ("U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*U*")
Loop

- Ray
 
Last edited:

srnet

Senior Member
A lot of modern PICs are capable of auto-baud detect, so its not impossible that the PICAXE firmware could include such a feature.
 

Goeytex

Senior Member
I really need someone with a storage scope to replicate the test...
Using the Tek THS730A, I do not see the jitter you described. I tested 08M2, 18M2 and 20X2.
This was confirmed by sending "UUUUUUUU..............." from the DUT @9600 to a Picaxe 20X2 Pulsin at 64mhz.

The value read was consecutive 164,164,165,164,165,164,164,165........ ( From 18m2) for the high bits
and the same for the low bits, (except for extra space between bytes.)

This indicates a jitter of less than 1us.

Terminal readout:

=====================================
Testing Serout Jitter on 18M2 ....

____________ Ones___________
165 164 165 164 164 164 164 164 164 164 164 165 165 164 164 164 165 165 165 165 165 164 165 164 164 164 164 164 164 164 164 164

____________ Zeros___________
165 164 164 91 165 165 164 164 90 164 164 164 164 91 164 165 165 164 90 165 164 164 164 90 164 164 164 165 90 164 164 165
========================================

Note: the 90/91 represents a byte value overflow and is the space between bytes (since I used byte variable instead of word with pulsin.)

........ Add 256 to the 90 and the pulsin value is 346. (346 x .625us = 216us)

Pulsin @ 64mHz = .625us per unit.
165 X .625 = 103.25us
1000000 / 103.25us = 9685 bit rate



Goey
 
Last edited:

mrburnette

Senior Member
Using the Tek THS730A, I do not see the jitter you described. <...>

Goey
A most sincere Thank You for rerunning the test. I can conclude that the jitter I saw was most likely the results of the trigger on the LCD scope. And, my apologies for not pulling out my Tek from its other assignment before I posted. Utility o'scopes are just no match for the high end product and can often throw the old bloodhound off-scent.

- Ray
 

exartemarte

New Member
I can't contribute anything to the 20M2/X2 discussion, having used neither. However, I noticed mrburnette's comment about eliminating the concept of chip-chip RS232 in projects and thought it might be worth mentioning that a project of mine uses serial data transmission from a Picaxe to an Atmega328.

I tried it out initially using a Picaxe-28X2 Module, which lives permanently on a breadboard, at 9600 bauds and once the protocols were sorted out there were no problems. The actual project uses a Picaxe-08M at default speed, so the baudrate is limited to 2400, but again there have been no problems. Note, however, that the AVR expects a signal which idles high, so the T---- rather than the N---- parameter is needed on the Picaxe.
 

Goeytex

Senior Member
@ Hippy & Technical

Hippy said he could not duplicate the problems I have seen with two 20X2s both sending & receiving data at 9600_8. I suggest we run the same exact test and compare results. Here is my test. No Scope required.

The code for each is below. Schematic is also attached.

The code tests the 20X2 serin at 9600_8 and 9600_16. It then sweeps the receiving Picaxe set at serin 9600_8 sending data starting from 11K and then decreasing. The Terminal displays if the data is bad or good and at what values. This sweep test is used to determine the minimum and maximum baud rate that can be received with serin set at 9600_8.

The results seen in the terminal are in attached txt file.

Code:
'TRANSMITTER TEST CODE

#picaxe 20x2

#no_table
#com 1
setfreq m8

symbol baud_val = w0
baud_val = 720 'If this is changed, it must also be changed on Receiver 

pause 100
hintsetup %01100110  'Interrupt on 1,2 high
setintflags OR %00000110,%00000110

do
pause 100 ' Wait for interrupt
loop


interrupt:
setfreq m8
pause 10 ' Stabilize

if hint1flag = 1 then  norm
if hint2flag = 1 then  sweep


norm:
sertxd ("norm",cr,lf)

'Send 4 bytes with serout (Acutal baud = ~9200)
setfreq m8
pause 50 'Freq stabilize
serout c.3,N9600_8,($55,$55,$55,$55)
pause 500

'Send 4 bytes with serout 9600_16 (Actual baud = ~9600)
setfreq m16
pause 50 ' freq  stabilize
serout c.3,N9600_16,($55,$55,$55,$55)
pause 500
flags = 0
setintflags OR %00000110,%00000110  
return


sweep:
hsersetup off ' prevents first byte glitch
setfreq m32
pause 50  'Freq stabilize
hsersetup baud_val,%10
pause 10
hserout 0,($55,$55,$55,$55) ' Send 4 bytes
flags = 0
setintflags OR %00000110,%00000110  
inc baud_val
  
  if b0 = 0 then  '(Workaround for hser val bug)
  inc baud_val    'val cannot be a multiple of 256
  endif           'or hserout will hang processor 
return
Receiver code:
Code:
'RECEIVER TEST CODE

#picaxe 20x2
#no_table
#com 6
#terminal 9600

symbol baud_val = w2
symbol checksum = w3
baud_val = 720 'If this is changed, it must also be changed on TXmitter 

main:
setfreq m8
pause 1000

   Test1:
	pulsout c.5,50 'INT1 to tell TX Picaxe to Serout packet

	'---------------------------------------------------------------------
	'Serin = 9600_8
	'Receive 4 bytes from serout 9600_8 on other Picaxe
	serin [2000,timeout],c.3,N9600_8,b0,b1,b2,b3 'receive 4 bytes 
	sertxd ("1) Serial 9600_8 data = ")
	sertxd (#b0," ",#b1," ",#b2," ",#B3," ",cr,lf) 'Send to terminal
	pause 100


	'---------------------------------------------------------------------
	'Change serin to 9600_16
	'Receive 4 bytes from serout 9600_16 on other Picaxe
	setfreq m16
	pause 100 'Freq Stabilize
	serin [2000,timeout],c.3,N9600_16,b0,b1,b2,b3 'receive 4 bytes 

	setfreq m8 ' back to 8Mhz
	pause 100
	sertxd ("2) Serial 9600_16 data = ")
	sertxd (#b0," ",#b1," ",#b2," ",#B3," ",cr,lf)
	sertxd (cr,lf)
	pause 2000
 
pause 1000

'----------------------------------------------
test2:
sertxd ("Sweeping with hserout",cr,lf,cr,lf)
w0 = 0  'clear
w1 = 0  'clear

do
	pulsout c.4,50 'Trigger int2 on Sending Picaxe
 	'Serin @ 9600_8
	'Receive 4 bytes from hserout sweep from other Picaxe
	serin [2000,timeout],c.1,N9600_8,b0,b1,b2,b3
	checksum = b0+b1+b2+b3
	sertxd ("Baud_Val = ",#baud_val,cr,lf)
	sertxd ("Received Data = ",#b0," ",#b1," ",#b2," ",#b3," ",cr,lf) 
  		
 		if checksum =  340 then
  			sertxd ("Checksum OK",cr,lf)
  			
		else
			sertxd ("Checksum Bad",cr,lf) 
		endif 

	sertxd (cr,lf)
	inc baud_val
	 
	 if b4 = 0 then  'compensate for hser val bug
	 inc baud_val
	 endif
          if w2 > 900 then endtest
	 	 	 
	pause 200
loop


timeout:
sertxd ("timeout",cr,lf) 'For debugging (Should never get here)
goto main 

endtest:
sertxd ("Test Ended",cr,lf)
sertxd ("Cycle Power To Start Over",cr,lf)
end

Note that with the 20X2 there is a Firmware or Silicon "bug" with hseretup when the value of "baud_setup" is a multiple of 256. When the baud_setup value is a multiple of 256 the Picaxe will hang upon the next hserout command. Other Picaxes were not tested for this bug. Firmware is C.2

For example:
hsersetup 768,%10
hserout 0, (b0,b1)
Picaxe Hangs Here​
 

Attachments

Last edited:

Goeytex

Senior Member
Since the validity of my testing has been questioned by Technical & Hippy, I decided to take unused 08M2 and 14M2 Picaxe's and do the sweep test to determine the actual serin value on these chips at 9600_8 and 9600_16. I also measured the actual baud rates at serout 9600_8 and 9600_16.

Here are the results.

08M2 9600_8
Serout = 9292 (-3.2% Error)
Serin center = 9230 (-3.85% Error)
Serin minimum = 8752
Serin maximum = 9708


08M2 9600_16
Serout 9600_16 = 9578 (<1% error)
Serin center = 9565 (<1% error)
Serin maximum = 10101
Serin minimum = 9029


14M2 9600_8
Serout 9600_8 = 9310 (-3% Error)
Serin center = 9794 (+2% error)
Serin maximum = 10309
Serin minimum = 9280



14M2 9600_16
Serout 9600_8 = 9598 (<1% error)
Serin center = 9854 (+2.6% error)
Serin maximum = 10389
Serin minimum = 9324


Most interesting is the 14M2 set at 9600_8 where the serout is too slow while serin is too fast, when at 9600_16 serout is spot on while serin remains fast.
 
Last edited:

hippy

Technical Support
Staff member
Most interesting is the 14M2 set at 9600_8 where the serout is too slow while serin is too fast, when at 9600_16 serout is spot on while serin remains fast.
This ( differences, not the actual values ) is to be expected.

SERIN and SEROUT both use different timing loops to achieve their results, thus there will usually be some difference in accuracy of each.

In addition, SERIN and SEROUT each cater for four separate base baud rates ( 4800_4, 2400_4, 1200_4 and 600_4 ) and each of those will usually also differ in accuracy. The other baud rates are one of those base baud rates with the affect of clock frequency applied. For example ...

9600_8 uses the 4800_4 base rate run twice as fast.

9600_16 uses the 2400_4 base baud rate run four times as fast.

Thus there can be no correlation between 9600_8 and 9600_16.

Code:
 4800_4  |  2400_4  |  1200_4  |  600_4
 9600_8  |  4800_8  |  2400_8  | 1200_8
19200_16 |  9600_16 |  4800_16 | 2400_16
38400_32 | 19200_32 |  9600_32 | 4800_32
76800_64 | 38400_64 | 19200_64 | 9600_64
Any inaccuracies in 4800_4 will be reflected in 9600_8, and any inaccuracies in 2400_4 will be reflected in 9600_16. When going from 9600_8 to 9600_16, any change in accuracy is simply due to the move from base baud rate of 4800_4 to 2400_4.
 
Last edited:

Goeytex

Senior Member
Thus there can be no correlation between 9600_8 and 9600_16.
Exactly the point that I have been trying to make for several months now. I pointed this out (In different words) at the beginning of this thread.

Yet if we look at the numbers in the tests above we can see that a 14m2 using serin 9600_8 CANNOT receive data from an 08M2 sending data at 9600_8. But an 08m2 with serin 9600_8 CAN receive data from a 14M2 sending at 9600_8.

Two 08M2s can communicate at 9600_8 because both serin and serout deviate in the same direction. However 9600_8 between two 14m2s will be marginal as the serout is 9310 while the min serin is 9280 leaving only a 30 baud margin before failure.
 

hippy

Technical Support
Staff member
Yet if we look at the numbers in the tests above we can see that a 14m2 using serin 9600_8 CANNOT receive data from an 08M2 sending data at 9600_8.
Except the evidence I have of an 08M2 sending to a 14M2 doing precisely that would seemingly prove otherwise.

Code:
#Picaxe 08M2
SetFreq M8
Do
  SerOut 0, N9600_8, ( "U" )
  Pause 1000
Loop
Code:
#Picaxe 14M2
#Terminal 9600
SetFreq M8
Do
  SerIn C.0, N9600_8, b0
  SerTxd( #b0, " " )
Loop
It honestly does work, for me, I'm seeing 85 printed every time.

We will continue to investigate the issue.
 

mrburnette

Senior Member
SERIN and SEROUT both use different timing loops to achieve their results, thus there will usually be some difference in accuracy of each. <...>
Thus there can be no correlation between 9600_8 and 9600_16. <...>
Oh, crap-o-la... finally, I get it! I can be denser than iridium sometimes. Thanks, the fog has lifted and I see the battle field.

- Ray

Exactly the point that I have been trying to make for several months now. I pointed this out (In different words) at the beginning of this thread.
<...>
 

hippy

Technical Support
Staff member
SERIN and SEROUT both use different timing loops to achieve their results, thus there will usually be some difference in accuracy of each. <...>
Thus there can be no correlation between 9600_8 and 9600_16. <...>
Oh, crap-o-la... finally, I get it! I can be denser than iridium sometimes. Thanks, the fog has lifted and I see the battle field.
Glad that's helped resolve some things but I'm not sure if "correlation" was the most appropriate word to have used.

What I was saying, if it's not clear, is that the behaviours of 9600_8 and 9600_16 are not related to each other ( one may have some inaccuracy, the other a different inaccuracy ), not that they could not be used to communicate with each other.

And I'd best add, that by "inaccuracy", I mean some divergence from what would be perfect, and not a divergence that is necessarily unacceptable. It's rare that any serial timing is ever absolutely accurate even with cystal oscillators, simply because they aren't absolutely accurate themselves.
 

Goeytex

Senior Member
Hippy,

You might try sending more than 1 byte at a time and see what happens. Sending only one byte is probably not a very good test. I suggest sending at least 4 consecutive "U"s, and then look for one bad byte in the packet. When all 4 are good I call it good. If any one byte is corrupt I call it bad. Like I mentioned earlier, we need to do the same test.

Even better why not use the code I provided? ....Or write your own that sweeps hserout on the sending Picaxe and uses serin on the receiving Picaxe and ... then chart the min and max baud rates that can be received at various serin settings. And send more than one byte consecutively as that how most data will be sent/ received with serial comms.

No one is expecting perfect accuracy, but I think it reasonable to expect the nominal settings to be compatible.
 
Last edited:

hippy

Technical Support
Staff member
You might try sending more than 1 byte at a time and see what happens. Sending only one byte is probably not a very good test. I suggest sending at least 4 consecutive "U"s, and then look for one bad byte in the packet. When all 4 are good I call it good. If any one byte is corrupt I call it bad.
The problem is that more than one byte doesn't just test baud rates but adds the issue of response to inter-byte gaps and missed start bits. A corrupt data packet doesn't equate to wrong baud rates alone so it's necessary to systematically work through the issue to get a full understanding of it.

That also applies to test code as well; while complicated / comprehensive tests may show there is an issue it doesn't always explain why there is an issue or identify its cause.

Unfortunately it's not a case of simply 'doesn't work' which everyone including ourselves can replicate so there's something more complicated involved. I updated the 08M2 to 14M2 test to send five "U", and that again worked without any corruption of data seen.

Please don't take any of that as denying the behaviour you see as we believe you. The behaviour we see differs and we are intending to get to the bottom of why that is.
 

Goeytex

Senior Member
I agree that that looking at all factors necessary and is a good idea. That is what I did. At first I thought that the issue may be related to processor overhead/byte spacing since that is generally the direction folks are pointed in when serial problems come up. However empirical data shows that this is not always the case. The fact is, that when serout data is sent at a rate outside of the range of serin, the data will be corrupted. This has NOTHING to do with space between bytes.

Certainly at lower processor speeds character pacing may be needed to compensate for processor overhead, but that is generally not a problem with Picaxe's at processor speeds at 8Mhz and above. Baud rate error can effect data integrity just as much if not more.

When the serout data rate is at the bare edge of the acceptable range of serin, the data may be intermittently corrupted (some good bytes, some bad). This is the case with the 14M2 and 08M2 that I used as an example.

With Picaxe 20X2 C.2 Firmware and 'serout' 9600_8 the space between bytes is right at 3 stop bits (328.8us). However with 'hserout' 9600_8 the space is right at 2 stop bits (208.8us). In other words serout has more time/space between bytes than hserout. However when hserout is within the acceptable range of 20X2 serin unlimited back to back bytes can be received without error. Since hserout has less space between bytes that serout, this highly suggests, if not proves outright, that 2 stop bits is adequate and three stop bits is more than adequate and that harping upon space between bytes with the issues that I am referring to is missing the boat.

Given the 20x2 C.2 firmware's three stops bits with serout ....with ANY serout/serin combination at 9600 baud & above where serout is withing the 'range' of serin, unlimited back to back bytes can be received without error. The same is true with hserout to serin, even though hserout has less space between bytes. Again not a space between bytes issue.


I've repeated this many times, but try to send serial data from one 20x2 at 9600_8 to another at 9600_8 and not one single byte will make it. The serin range is too high to receive any serial data from the other due to serial inaccuracy both with serin and serout on the 20X2. It does not matter if the bytes have 1 stop bit, 2 stop bits or 100 seconds between them. The combination is out of specification in regards to baud rate. It simply won't work.

There are other combinations that won't work, as well as combinations that are marginal.

I am waiting to be contacted for exchange of chips per Technical's offer. My email address is in my 'settings"
 
Last edited:

Goeytex

Senior Member
This will be boring to most, but here it is anyway. This will be the last I post here until I receive some additional Picaxe Chips for further testing.

My point about spacing with serin/serout comms between 2 Picaxes may be further supported when a 14M2 with hserout is used as the sending Picaxe\device for testing. Hserout on the 14M2 has only 1 stop bit compared to 2 stop bits with hserout on a 20X2, and 3 stop bits with bit-banged serout. With hserout on the 14M2 (Firmware Version A) there is no extra space between bytes. In other words, the waveform of "UUUUUU..." looks like a clean square wave with no gaps.

Sixteen back to back data bytes of "UUUUUUUU…" are sent from the 14M2 hserout to the 20X2 serin set at 9600_8. The starting baud rate is ~8500. After each packet, the hserout baud_setting on the 14M2 is decremented by a value of 1, slightly increasing the baud rate. The data is monitored via sertxd from the 20X2 code and recorded in the Terminal Buffer.

Here the effects of spacing CAN be seen. With only one stop bit from the 14M2 hserout, the normal 9600_8 serin range of the 20X2 is reduced on the high end, but the low end is not affected. However with 2 or more stop bits, there is no reduced bandwidth. It remains at approximately -+5.1 from its serin center baud rate of 10100.

There is no reduced range/bandwidth when using Picaxe to Picaxe serout & serin since serout has sufficient space (3 stop Bits) between bytes. However reduced bandwidth WILL show up if the sending device (Particularly a non Picaxe) is set to one stop bit and actually conforms to 1 stop bit. But, IF the sending device uses only 1 stop bit ( 8,n,1 is very common) AND IF the baud rate is within the reduced serin range at 9600_8, at least 16 back to back bytes can still be received.

I will repeat to drive the point home. Based upon my tests here, byte spacing is not a factor with serout to serin comms between 2 Picaxes at 9600_8, because the Picaxe serout uses 3 stop bits and therefore there is no reduced serin bandwidth due to byte spacing. Data may not be received reliably, but it is not due to space between bytes, it is due to baud rate.

Byte spacing CAN be a problem at 9600_8... IF

1. The sending device uses 1 stop bit (actual) AND
2. The actual baud rate being sent is not within the reduced serin range (bandwidth).

If the baud rate is outside of the reduced bandwidth area, but within the normal bandwidth area, adding some extra space between bytes will allow data to be received without error. But the problem here (with the 20x2 in particular) is that the center baud is simply too high. Most devices will generally be sending data within 2% of 9600 baud and will be outside of the 20X2 serin range.

This can be proved by sending 16 back to back data bytes using 1 stop bit (actual) at a baud rate anywhere between 9750 - 10000 baud to a Picaxe 20X2 set for serin 9600_8. It will work ok. Then try the same thing sending at below 9700 baud and above 10000 baud.

Tests here show that with 20X2 serin set at 9600_8 ...when the sent stop bits are 2 or more, that the serin range/bandwidth is ~+-5.1 percent from the serin center of ~10100 ...And when the sent stop bits = 1 that the serin range is reduced to +- 2.4% from a now serin center of ~9830.

At 9600_16 the serin range (bandwidth) is approximately +- 5.1% percent from its center baud rate of ~9960 regardless of stop bits (1 or more).

I think that if the Picaxe 20X2 9600_8 serin was centered somewhere between about 9500 and 9700 instead of its current ~10100 baud, that devices sending serial data at the nominal baud rate of 9600 (+-2%) and 1 stop bit could communicate OK with the Picaxe 9600_8 serin with a reasonable margin of error.

All Picaxes will benefit tremendously in serial comms reliability and compatibility if both the serin center baud rate and serout baud rate were within 1 to 2 percent of their actual settings instead of deviating as much as 4 to 6 percent in some cases.
 

Andy2No

Member
I've just spent hours trying to get the BASIC "firmware" on the 18M2 on my new AXE133 LCD display to run at 4MHz, instead of the 16MHz it switches to after initialising the display. I'm sending a loop of test messsages to it from a 08M, and it worked fine until I tried to run the 18M2 slower. I assumed it was to do with timing problems communicating with the LCD, but couldn't see why, from the data sheet. It looks like it's the baud rate problem discussed in this thread instead.

The last thing I tried was changing the clock speed on the 08M, with setfreq m8, and using N2400_8. That gives a garbled display too. The only way it works (at N2400) is if the 18M2 runs at the 16MHz speed of the original firmware, and the 08M runs at 4MHz. I guess I could try different baud rates but I've lost enthusiasm for it at the moment. I've wasted the entire evening fiddling with something that was just never going to work, because there was nothing in the manual to tell me it wouldn't.

I wanted to try to get the 18M2 to multi task, so it can be doing something other than just wating for the next serin. I thought I'd try PWM modulating the backlight (I've changed to an LCD that has one, and fitted the extra bits to switch it on and off). As it's controlled by C2, it would just have to be turned on and off in a loop, with pauses in between.
 

srnet

Senior Member
I've wasted the entire evening fiddling with something that was just never going to work, because there was nothing in the manual to tell me it wouldn't.
Thats just not realistic.

You modified the 18M2 code to run at a much slower speed than it was designed for and it did not work, no surprises there.
 

Andy2No

Member
I tried to get it to run at 4MHz because PICAXE multitasking only runs at 4MHz.

The 18M2 just sits there most of the time, waiting for the next byte from serin. I can't see any other way of getting it to do something more useful when it's not busy, and it's mostly not busy. It seemed like a good opportunity to try out the multitasking, but it evidently can't be done.

The 08M that's feeding it the test messages is running at 4MHz. Why should the 18M2 have to run so much faster? I'm assuming 16MHz was picked because the N2400 setting works fairly well at that clock speed. It doesn't work for me at either 8MHz or 4MHz.

The only other thing I can think of is to send it a command (via serin) that tells it to stop waiting for serin, and go and do something else. I'd then need to send it a message by some other method, e.g. using C.0 or C.1, to tell it to go back to waiting for serial input. It seems like a bit of an unwieldy solution though.

Yes, I tried to make it run much slower and I also tried to make it run at half speed. I can't get it to do either. Any good reason why it shouldn't be able to? Isn't the serial data buffered?
 

srnet

Senior Member
Any good reason why it shouldn't be able to?
Yes.

The code works well enough at 16Mhz, when its recieving data at 2400 baud, which is what its been designed for.

Incoming data is not buffered, so the code has to quite a bit to do between the end of one incoming byte, and then be finished in time and ready and waiting for the arrival of the next byte.

If you want incoming data to be buffered, then you would need to port the code across to an X2 Picaxe which have background serial receive.
 

Andy2No

Member
Yes, I've been laboriously rewriting my 08M test program to add a long pause between each byte sent, and it does work with the 18M2 running at 4MHz after all. I'm not sure how useful that would be though. Also, it remains to be seen how well the multitasking would work, if responding to the serial input has to be more or less instantaneous. I would guess it's not going to work, so the relatively powerful 18M2 just has to sit there twiddling its thumbs waiting for the next byte, doing nothing useful.

Moving it to an X2 part seems like a good idea, though there's no PICAXE-18X2, as far as I can see, so the AXE133 board wouldn't be much use for that. I'd have to make a new board, and retire the AXE133.

I guess the only practical approach to getting it to do more would be the idea I had of using C.0 or C.1 as an extra control line to start serial input, and sending a serial command to tell it to stop waiting for more, so it can do other things. At this point, I'm not sure what those other things would be, it just seems a shame not to do more with it.
 

Goeytex

Senior Member
UPDATE:

I received three 20M2's from Rev Ed for comparison testing. These do not show the same test numbers as the ones I previously tested. They are much better on the serin.

For the serout test the following code was used:

Code:
#picaxe 20M2
#no_data

main:
setfreq M8
pause 10 ' stabilize
time = 0 
do 
   serout b.7,N9600_8, ("UUUUUU")  'Or serout b.7,N9600_16 
   pause 400 
loop while time < 10

setfreq m16
time = 0
do 
   pause 20   'stabilize 
    serout b.7,N9600_16, ("UUUUUU") 
   pause 800    
loop while time < 20

goto main:
SEROUT RESULTS:

Baud rate was measured with a TEK THS73A Digital scope.

N9600_8 ...... Actual baud out = 9250 Error = -3.7%
N9600_16 .... Actual baud out = 9576 Error = < 1%


SERIN TESTS

In Test 1 six bytes were sent from an 08M2 using hserout. (8N1 - See note 1)
In Test 2 six bytes were sent from a 20X2 using hserout. ( 8N2 - See note 2)

At the end of each test the hserout baud numbers where errors began and ended were noted and then
measured with a Tek THS-730A Scope. The error could be + - 25 baud as this the resolution of hserout at 16mhz

The sending program:

Code:
   setfreq M16     
     hsersetup baud,%10      
do
    for baud = 460 to 360 step -1    '8666 - 11062 Baud        
        hseresetup baud,%10      
        pause 10 
        pulsout c.2, 100  'Interrupt for 20M2
        hserout 0,baud,("UUUU",b0,b1)  'send UUUU + baud info total of 6 bytes
        Pause 4000     
      next baud
loop
The 20M2 was programmed as follows:

Code:
#picaxe 20M2
#no_data
setfreq M8  '(or M16)
symbol baud = w2
pause 400 'Stabilize let terminal open
setint %00000100,%00000100

Main:

DO
pause 100
loop

 interrupt:
      pause 10      
      serin b.7,N9600_8,b0,b1,b2,b3,b4,b5  '0r N9600_16
      sertxd (b0," ",b1," ",b2," ",b3," ",#Baud,cr,lf)
      w0 = 0 : w1 = 0 'clear all
      pause 10
      setint %00000100,%00000100
   
   return  'To main
SERIN TEST RESULTS

Test 1: Data sent from 08M2 with Hserout (8N1)

N9600_8
Min ......... 8992 -6.3%
Max ......... 9624 +.25%

N9600_16
Min ....... 9158 -4.6%
Max ....... 10214 +6.4%


Test 2: Data sent from 20X2 With Hserout (8N2)

N9600_8
Min ........ 8964 -6.6%
Max ........ 9934 +3.5%


N9600_16
Min ........ 9150 -4.7%
Max ........ 10214 +6.4%


Test 3: Data sent from 20X2 with 5 ms between bytes

N9600_8
Min ....... 8964 -6.6%
Max ....... 9934 +3.5%

N9600_16
Min ....... 9150 -4.7%
Max ....... 10214 +6.4%


Notes:

1. On the 08M2, hserout sends 1 actual stop bit between bytes
and is an accurate representation of a device that strictly
adheres to "8N1".

2. In contrast, hserout on a 20x2 sends 2 actual stop bits,
meaning at 9600 baud there is an extra 104us between
data bytes which is the same as "8N2"

My Analysis:

Serout at 9600_8 sends data at an actual 9250 baud. This is too low with an error of ~ 3.7%. This is likely the same or a similar firmware issue that has been identified in the 20X2 and may be correctable in firmware. This setting may cause comm problems with some devices.
Any device receiving data from a 20M2 set for 9600_8 must be tolerant of a -3.7 percent baud rate error and this is at the very edge. From my research, nowadays a 3 percent error is considered max, with many manufacturers specifying 2 percent. To the best of my understanding, there is no general consensus.

Serin at 9600_8 has problems when the data received is at a true 8N1. This setting will likely result in errors when used with devices that send data a a true 8N1, and when the actual baud rate sent is at or slightly above an actual 9600 baud. This is related to processor overhead, since adding a stop bit on the TX side allows a range from 8964 to 9934 which is more than adequate.

The severe serin problems I noted with the 20M2's previously tested are not reflected with the 20M2's recently sent to me by Rev Ed. I will be sending one of these to Rev Ed for evaluation.


Goey
 
Last edited:

Morganl

Senior Member
Thank you for your dedication to sorting this Goeytex!
This could be the reason i had to change baud settings to get it work.

I know bit banged is not simple to get right, really impossible depending on frequency and instruction timing, and sometimes some bits here and there have to be stretched to best fit the total byte+top/startbits time, maybe therefor you see what you noted in "Notes".
More problematic is when the reciever have a bit different mapping of either the bit stretching or total byte time. Being same or different picaxe, or another microcontroller using inexact bitbanging.
It all eats on the margin, and your measurements seem it eat upquite a bit, at both ends, and to that sould be added oscillator frequency ofsets different direction sender/reciever, their drift, and link noise...

I do not blame RevEd for bitbanged serial not being exact.

However it would have saved me, you and probably may others not speaking up some head sctraching if RevEd could document what setfreq/baud on what picaxe is the most exact and clean.
That would make any sort of serial comms, especially with other hardware and/or over RF have a better success rate.

Any update on this, RevEd?
You do have a logic analyser?
Try sending bytes of alternating bitvalues (%10101010 and %01010101) and see how nice all bits fits in their slots.

Checking the receive is a bit harder, one idea is to clock the picaxe from a frequency generator and try the limits, whille recieving mentionned bit pattern from am known good hardware transmitter.
For self compatibility also try to use different picaxes at different setfreq and baud as transmitters.
 

hippy

Technical Support
Staff member
You do have a logic analyser?
As tempting as a humorous or sarcastic reply is; I can confirm that we do have multiple logic analysers, scopes and other appropriate test equipment. We have extensively measured, analysed and assessed the software bit-banging baud rates, both sending and receiving, between PICAXE variants and against other references. Considerable amounts of time and effort were invested in doing so.
 

Morganl

Senior Member
Point taken... i think it was a point... ;)
I will connect my own analyser next time i think there is a problem.

About analysing, any progress on the M2 series servo pulses or PWMDIV options yet?
 
Top