serin problem on 20M2

[kenmac]

Hi folks,
I have been dabbling in programming of the new 20M2 and have run into a problem with the SERIN function.
Sending a byte from a 40X2 chip is not read correctly by the 20M2.
The data is sent as N2400 with no qualifiers.
If the data byte is $01, the 20M2 interprets it as $F0. (read via debug)
$55 sent becomes $F0, $AA = $FF.
I tried dropping the baudrate to N600, but same result.
The 40X2 is transmitting correct data - I checked it with a 28X2, and that worked OK.
I also checked the signal with a CRO - it is correct.
I thought that maybe as the 20M2 has an internal resonator it may be sufficiently <>4mHz to affect the SERIN.
However, if that was the case I would expect some random values to result.
Is there something about SERIN on this chip that I'm not aware of?
Does anyone have any clue to what is happening here?


kenmac

 

[SAborn]

The 20m2 might have a similar problem to the 20x2, as i have had many problems with the 20x2 and serial data, the problem is the internal clock frequency is out on the 20x2 and requires the calibfreq command to be used to adjust the clock.

Try running this little program and see if you get any corrupt data in the strings of U, if so adjust the calibfreq till you get no errors in the data, i find i need to go as low as -30 sometimes to get things to work.

I dont know if this is your problem but sounds to me to be like the hassels i have had..........worth a try.

#Picaxe 20m2
#Terminal 4800

'CalibFreq -14

Main:

setfreq m4
CalibFreq 0
Do
SerTxd( "U" )
Pause 2
Loop

 

[hippy]

It all works okay for me ...

#Picaxe 40X2
Do
  SerOut C.0, N2400,( b0 )
  b0 = b0 + 1
  Pause 1000
Loop

#Picaxe 20M2
Do
  SerIn C.0, N2400, b0
  SerTxd( #b0," " )
Loop

What you are seeing is typical of corrupt data which can happen with baud rate or polarity mismatch or sending data faster than the the receiver is able to receive them. Please post your code and then we can see if there's anything obvious.

 

[hippy]

The 20m2 might have a similar problem to the 20x2, as i have had many problems with the 20x2 and serial data, the problem is the internal clock frequency is out on the 20x2 and requires the calibfreq command to be used to adjust the clock.

Some people have had problems with some communications and it is sometimes necessary to adjust clock speeds with CALIBFREQ in some circumstances but it's not a problem everyone experiences.

The test code above for the 20M2 works equally well on a 20X2 for me with no changes other than altering the #PICAXE directive and altering Terminal to 9600 baud to see the SERTXD result.

Most serial baud rate problems seem to be in not specifying the _16 and other suffixes when operating other than at the default frequency or through specifying _4 when the default operating frequency is 8MHz.

It's best to resolve those kind of issues before considering using CALIBFREQ which should not generally be necessary.

 

[kenmac]

Hi Hippy,

The 40X2 Tx code (1 byte) is looped to repeat @ 1 second rate.
The 20M2 code is basically the same as you displayed, except the debug was used instead of Terminal to read variable b0.

loop1:
serin c.0, n2400_4, b0
debug
pause 500
b0 =0
goto loop1

I'll try the calibrate option and see what happens.
Also, I'll get another 20M2 and try that.

kenmac

 

[kenmac]

Hi again,
OK, I have tried varying the frequency (calibfreq) up to +- 14 without any noticeable effect.
I also tried another 20M2 - it behaves the same way.
It seems that the reading always sets the top 4 bits regardless of the data i.e. ($Fx)
I double checked the 40X2 output by connecting it to a 28X2 and using the same code as the 20M2.
That setup works OK, so the serial data/baud rate is correct.
I'll be having another go at this in a couple of days.

kenmac

 

[kenmac]

Hi again,
I've given up on using a 20M2 for serial reception.
I ended up trying the Hserin system but that doesn't work either.
It seems to me that a chip with external resonator is required for Serin to work reliably.
So, now I will be swapping over to a 28X2 to achieve reliable serial control.

kenmac

 

[hippy]

It seems to me that a chip with external resonator is required for Serin to work reliably.

Not at all. The example in post #3 was tested by me with PICAXE chips and works fine with data received by a 20M2 and also by a 20X2 which equally uses an internal resonator.

That you also cannot get serial working using HSERIN suggests there is something else to it, perhaps some hardware or wiring issue, perhaps a signal voltage issue.

I would suggest using the exact code in post 3, using SERTXD and not DEBUG nor adding PAUSE commands in the receiving loop and seeing if you have any luck with that. Perhaps also post a circuit diagram or photo of your hardware setup, even the full code of what you have been using.

 

[Goeytex]

Hi again,
I've given up on using a 20M2 for serial reception.
I ended up trying the Hserin system but that doesn't work either.
It seems to me that a chip with external resonator is required for Serin to work reliably.
So, now I will be swapping over to a 28X2 to achieve reliable serial control.

kenmac

You have given up too soon and have prematurely jumped to a conclusion.

I almost never have problems like yours and have never had to use cablib freq to get serial coms to
work between 2 different Picaxes. And an external resonator is absolutely not required.

Please post your complete code for both programs - leaving nothing out, and a diagram of your connections.
The problem is likely very simple and very can be easily solved.

 

[srnet]

It seems to me that a chip with external resonator is required for Serin to work reliably.

Just not the case at all.

The AXE133Y LCD\OLED display for instance uses Serin with no external resonator on a 18M2.

Mine works fine and you would not expect Rev Ed to be selling the thing if it did not work reliably.

 

[SAborn]

and you would not expect Rev Ed to be selling the thing if it did not work reliably.

You try to convince me that is the case with the 20x2, as i will prove you wrong, its a issue i have raised in the past that apparently "only some of us" have a problem with, but thats not to say a problem dont exist or has been addressed.

 

[Technical]

Hi Hippy,

The 40X2 Tx code (1 byte) is looped to repeat @ 1 second rate.
The 20M2 code is basically the same as you displayed, except the debug was used instead of Terminal to read variable b0.

loop1:
serin c.0, n2400_4, b0
debug
pause 500
b0 =0
goto loop1

I'll try the calibrate option and see what happens.
Also, I'll get another 20M2 and try that.

kenmac

It's just luck that the other systems are working. As you add more lines of code to the 28X2 and increase processing times they will eventually stop working too.
Think about what is happening. The PICAXE receives a byte, and then spends a long time sending out the 'debug' serial data ('debug' + pause 500 may well will be more than your second gap between transmissions). It then jumps back to the start and waits for some new high/low signals to indicate a new byte.

If it happens to jump back to the start at the time the master is half way through a transmission , it will still start thinking that is valid data and start to receive it. But it's actually only half a byte, and hence corrupt. But the receiver has no way at all to know this.

That is the whole point of serial qualifiers, to get rid of corrupt data like this via synchronisation.

Try this in your two lines instaed:


SerOut C.0, N2400,("?", b0 )
SerIn C.0, N2400,("?"), b0

The "?" then synchronises the two devices

 

[srnet]

You try to convince me that is the case with the 20x2, as i will prove you wrong, its a issue i have raised in the past that apparently "only some of us" have a problem with, but thats not to say a problem dont exist or has been addressed.

Do you know of a specific reliability issue with serin on the AXE133Y then ?

 

[Goeytex]

I did some testing. Connected a 20x2 to a 20m2 with the code above. Works ok at 2400 baud.

However with both processors at 8mhz and the baud rate increased to N9600_8, I cannot get a single
byte though unless the 20x2 calibfreq is changed to somewhere between 15 and 25.

Update: With the same 20x2 now connected to an 08m2, N9600_8 works fine with calibfreq "0" on the 20x2.
In fact it tests ok at 16mhz and N19200_16 with calibfreq at " 0".

Seems to me there is an issue here that needs to be investigated and addressed. I probably never ran into this before
because I never combined a 20x2 and 20m2 with the M2 using serin.

Another Update: Back to the original 2 processors, but I reversed their roles. The 20M2 sends the data and the 20x2
receives. Same code. Works with no issues @ 16 Mhz on both processors, N19200_16, and no need to use calibfreq.

Kinda strange and leads me to suspect there may be a problem with the 20M2 serrin coding.

 

[srnet]

I did some testing. Connected a 20x2 to a 20m2 with the code above. Works ok at 2400 baud.

However with both processors at 8mhz and the baud rate increased to N9600_8, I cannot get a single byte though unless the 20x2 calib freq is changed to somewhere between 15 and 25.

Which is odd when you think about it.

If there were just a clock speed variance (which is suggested because of the calib freq 'cure') then the same % error ought to exist at all baud rates, and the failure rate ought to be the same.

 

[marks]

I think this has been pointed out a few times by Hippy lol!
What you must realise the 20x2 can process data quicker than a 20m2
while calibrate freq does work its really crippling the 20x2.
it depends on the code too it must recieve and process and be ready for the next serin
thats why a 20m2 has no problem sending to a 20x2
and 0ne needs to think about speeds , code effiency and vary pauses as required (or instead put some code between our transfers)

 

[kenmac]

Wow - that stirred things a bit!
I probably didn't mean "given up" - just deferred further action until a later time.
I really don't like "unresolved" problems.
Having had success with the 28X2 I decided to use that chip in lieu of the 20M2.
This problem has held up my work on a small project and I just needed to move on.
Thanks for all your good advice - I shall return to this when time permits.

kenmac

 

[Goeytex]

I think this has been pointed out a few times by Hippy lol!
What you must realise the 20x2 can process data quicker than a 20m2
while calibrate freq does work its really crippling the 20x2.

How is this an acceptable explanation when there is not a problem with same 20x2
transmitting serial data to an 08m2, given the same code/timing while NOT having
to change the 20x2 clock speed?

Your explanation would then imply that an 08m2 operating at the same clock speed as a 20m2
can process serin data considerable faster than the 20m2, with the 20M2 unable to reliably
process 1 byte of serin data sent from a 20x2 at setfreq M8 ,N9600_8.

And how do we explain that INCREASING the 20x2 clock speed offers a temporary "cure" when
sending serial data to the 20M2 if it's because the 20m2 processes data slower?

And how does increasing the 20X2 clock speed cripple it ?

 

[SAborn]

Do you know of a specific reliability issue with serin on the AXE133Y then ?

No, as i have never used the AXE133Y.

I do although design many circuits that use serout or sertxd mainly for data logging or reading data from RFID systems, eveything has worked well up to the point of using the 20x2 chip (which just also happens to be my favorite chip) then the data became corrupt, thats the same program as used in other chips adjusted for the 20x2 pinouts, after much trouble shooting, adjusting the calibfreq solves the corrupt data problem, but its a pain in the ass to have to tailor each chip to a circuit, when i should be able to dump a program into a chip and it work.

As i and only a few others have complained about this problem and the rest of you dont seem to have encountered the same problem it falls on deaf ears to have something done about it, and looks to fall into the too hard basket.

 

[g6ejd]

If a machine code routine to read serial data is coded correctly; that is wait for a signal transition, then wait half a bit time to get to the centre of the data bit, then read all the rest of the word at the centres, the tolerance to speed variation is quite large. I wonder if the 20M2 part serial routine is not designed like this?

 

[srnet]

the tolerance to speed variation is quite large

It should be, assuming 10 bits for simpler maths, if you start sampling 1/2 bit after the start bit then the clock has to be out by around 5%, to miss-sample the serial stream.

 

[srnet]

after much trouble shooting, adjusting the calibfreq solves the corrupt data problem

Is the timing of the serout stream correct, i.e do you have a situation whereby the serial out is at the correct baud rate (indicating an accurate clock), but calibfreq has to be used to receive accuratly ?

 

[SAborn]

Here is an example of what i posted in a thread a while back of the corrupt data from the 20x2 and adjusting calibfreq to solve the problem.

View attachment 20x2 Calibfreq.pdf

 

[srnet]

I saw that, just wondering what the timing looks like on a scope.

 

[MartinM57]

If a machine code routine to read serial data is coded correctly; that is wait for a signal transition, then wait half a bit time to get to the centre of the data bit, then read all the rest of the word at the centres, the tolerance to speed variation is quite large. I wonder if the 20M2 part serial routine is not designed like this?

Who actually knows what goes on inside a PICAXE other than RevEd? .... but I can't believe for one moment that RevEd has implemented software serial control in assembler and ignored the onboard UART/EUSART/whatever serial handling peripherals. There's enough posts from Technical talking about single/dual character buffers that are exactly consistent with the on board UART/EUSART after all.

The internal oscillator accuracy (choosing 20X2 and 18M2 at random) is quoted by Microchip at +/-2%. These could conspire against you, on a chip by chip basis. There's an interesting note on the 20X2 (PIC18F1XK22) datasheet..

To ensure these oscillator frequency tolerances, VDD and VSS must be capacitively decoupled as close to the device as possible. 0.1 &#956;F and 0.01 &#956;F values in parallel are recommended


...and yes, I've had some rare serial problems with internal oscillator PICAXEs that are only fixable with CALIBFREQ. Wheenver I've used an external resonator, no problems.

 

[srnet]

but I can't believe for one moment that RevEd has implemented software serial control in assembler and ignored the onboard UART/EUSART/whatever serial handling peripherals

How could serin (which can be on most input pins) use the internal hardware UART ?

Hserin is the only pin connected to the onboard UART.

 

[hippy]

How could serin (which can be on most input pins) use the internal hardware UART ?

Hserin is the only pin connected to the onboard UART.

That is mainly correct; hserout also connects to internal UART.

SERIN, SEROUT, SERTXD and SERRXD are all handled by software bit-banging as is the download interface. The hardware UART is only used with the HSERIN and HSEROUT commands.

The rationale for that is six-fold; not all early PICmicro had UART, it allows the download interface pins to be more conveniently placed, it simplifies hardware interfacing, consequently reduces costs, allows for a one-chip solution, and it minimises potential issues in circuit construction.

 

[srnet]

SERIN, SEROUT, SERTXD and SERRXD are all handled by software bit-banging as is the download interface

Do you know if the delay routine used for baud timing with the bit bang is the same for serin and serout ?

 

[Dippy]

I don't know the guts of PICAXE but I'm sure they haven't ignored the USART. Maybe that's not quite what Martin meant(?).

The HSer background UART receive, for example, is almost certainly an interrupt driven read-buffer routine which is invisible to the user.
Whether it was written is ASM or compiled something I don't know. I wrote one for myself.
The soft Serin will probably be a bit-bashed ASM routine.

On the comms side there are a few potential pitfalls with (Serin/out) Serial.
Firstly, when having serial problems it's often easy to blame oscillator accuracy straight away.
Asynchronous comms, by it's nature, can cause headaches. PICAXE makes it as easy as possible I would have thought.

Just out of vague interest I have had occasional problems with soft serial comms on PICs as well as PICAXEs.
I have scoped PICs and PICAXEs (both INTOSC) with soft serial and found minor timing errors in both which could be cured with a bit of OSCTUNE twiddling. And, occasionally, out-of-the-box the timing was out-of-spec for Serial.
With Xtal+USART the timing was, in my limited tests, always 'perfect' - according to my 'scope plus calculator.

In summary, I would say that INTOSC soft serial timing can give problems now and then, but I would suggest a thorough examination of the code and hardware in both devices before blaming the oscillator for data errors.
And, yes, I saw the datasheet note too

If there are doubts then the only way to check is to 'scope it.
If someone could do some timing tests (with a proper 'scope) of soft vs USART and INTOSC vs EXTOSC that would be helpful.
This subject crops up a lot and it would be nice to nail it , but don't blame PICAXE by default.

 

[Armp]

It should be, assuming 10 bits for simpler maths, if you start sampling 1/2 bit after the start bit then the clock has to be out by around 5%, to miss-sample the serial stream.

This 5% has to cover the tolerance of both the sender and receiver oscillators, and the software sampling jitter.
If one clock happens to be +2%, and the other is -2% you will start to get errors.

 

[hippy]

Do you know if the delay routine used for baud timing with the bit bang is the same for serin and serout ?

I'm not really sure on how to answer that with respect to being "the same" as the code which handles input and output differs but both SERIN and SEROUT are adjusted to achieve the timing. It's more in getting the timing right to do the job than how that's achieved.

 

[Goeytex]

I did a bit more testing and found considerable deviations in actual measured baud rate and character spacing between 08m2,18m2,20m2, and 20X2. I used sertxd for the serial output. I am not a protocol expert, but as I understand it with a baudrate of 9600 a bit ( either high or low) should be 1 sec / 9600 in width, or about 104.2us. Using $55/U and a good digital scope only one Picaxe was close to that. The bit times varied from 99us to 106us among the chips I tested. Maybe this is an acceptable deviation?

I also noticed that calibfreq would increase the baud rate using a positive factor ( calibfreq 10). But calibfreq has no effect whatsoever when using a negative factor ( calibfreq -10. This applied to all Picaxes I tested. Calibfreq also has no effect upon pulsout when a negative factor was used.

Another thing I noticed was that all the chips were fairly accurate using pulsout as an indicator except the 20X2 which was a tad slow.

 

[Armp]

I am not a protocol expert, but as I understand it with a baudrate of 9600 a bit ( either high or low) should be 1 sec / 9600 in width, or about 104.2us. Using $55/U and a good digital scope only one Picaxe was close to that. The bit times varied from 99us to 106us among the chips I tested. Maybe this is an acceptable deviation?

Nice work.. Did you notice any correlation between the width of a 1 and that of a 0 in the same stream. If they both increased and decreased together that would suggest an Osc problem, if there was a static difference between them that could be software related.

 

[srnet]

but as I understand it with a baudrate of 9600 a bit ( either high or low) should be 1 sec / 9600 in width, or about 104.2us

That would be my understanding too.

I was working on the serial OLED driver, so had an 08M2 on the breadboard as the sender, and put the scope on the serout.

9600 baud produces a bit time of 106.7uS.

I checked the intosc frequency by timing this pulse;

high c.2
pause 500
low c.2

Which gives on the same scope a measured time of 500.00ms (yes really)

 

[Goeytex]

Did you notice any correlation between the width of a 1 and that of a 0 in the same stream.

The bit times were fairly steady within the same stream ... within 100 nanoseconds or so. I'll post a chart later
this weekend after I do a bit more testing.

 

[MartinM57]

SERIN, SEROUT, SERTXD and SERRXD are all handled by software bit-banging as is the download interface. The hardware UART is only used with the HSERIN and HSEROUT commands.

Well, I've been wrong on some things in the past, I appear to be wrong on this now, and I'm definitely going to be wrong on things in the future .

I will watch with interest...

 

[Goeytex]

Don't feel alone Martin. I pretty much ignored SAborn's information concerning the 20X2 since I hadn't personally experienced any problems. But now having taking a few scope readings and comparing Picaxe Chips I am getting a better picture.

With serout set to 9600 baud a 28x2 is actually outputting 9190 baud based upon a bit width reading of 108.8us. (-410 bps ) .
With serout set to 9600 baud a 20M2 is actually outputting 9880 baud based upon a bit width reading of 101.2us (+280 bps)
With serout set to 9600 baud a 08M2 is actually outputting 9290 baud based upon a bit width reading of 107.6us ( -310 bps)
A second 08m2 reads exactly as the one above.

I'll let the serial experts determine what all this means. But it looks to me that bit banging serout is not very precise.
And if the 20M2 serin timing matches its serout timing, it is a wonder that a 20x2 and a 20M2 can communicate at all
given a 690bps difference when set to N9600_8

More: With the 20M2 set to N2400_8 the actual rate is 2387
With the 20x2 set to N2400_8 the actual rate is 2394

This may explain why 2400 works ok between the 20x2 and 20M2 but 9600 fails miserably.

 

[Dippy]

Interesting...


Is it possible to do a couple of different Pulsouts for each to see if that follows the trend?
And can you do a crystal clock on the 28X2 for comparison?
How does it compare to Hserout?

(I appreciate this takes time )

 

[Armp]

With serout set to 9600 baud a 28x2 is actually outputting 9190 baud based upon a bit width reading of 108.8us. (-410 bps ) .
With serout set to 9600 baud a 20M2 is actually outputting 9880 baud based upon a bit width reading of 101.2us (+280 bps)
With serout set to 9600 baud a 08M2 is actually outputting 9290 baud based upon a bit width reading of 107.6us ( -310 bps)
A second 08m2 reads exactly as the one above.

As requested before - can you give separate numbers for 1s and 0s please?

 

[Goeytex]

Yep I can do it (and have before), but did not keep the data. Initial tests show hserout to be dead on in regards to bit width. However there is some dead time in the 20x2 between characters that does not exist with the 20m2. The 20M2 sending "UUUUUUU" via hserout looks like a steady oscillator output while the 20x2 has a gap between characters.

So far pulsout looks pretty much dead on, indicating good OSC accuracy but I need to test systematically and record values at different clock speeds. My guess at this point is that the serial bit banging code is the reason for the serout variances.

Sorry, but I have no 28x2 to test, but I do have a couple of 28X1s around here some where on a starter board with the resonator. Will that help any ?