Effects of 'setfreq' command on 18m2 'serout'

XLSERVICE · Sep 13, 2012

Hi Picaxe Forum

I have an 18m2 Picaxe connected to a Milford Instruments 4X20 LCD screen via a serial backpack.

The backpack is set to receive 9600 8N1.

If I set the Picaxe frequency to 16 or 32, and use the corresponding 'serout 5,N9600_16 or serout 5,N9600_32' commands the LCD works fine.
However, if I set the frequency to 8 and use 'serout 5,N9600_8' the screen is either blank or garbled. According to the Picaxe manual the M2 parts can run N9600_8.

Any ideas what I am doing wrong.

Cheers
Alan

Goeytex · Sep 13, 2012

You are not doing anything wrong. 9600_8 is not a good setting for the 18M2, 20M2 or 20X2 Picaxe chips . At this setting the serout baud rate is quite a bit off specification from the nominal 9600 and may not work with some devices, even other Picaxe chips. If you must use 8 MHhz, then I would suggest using hardware serial ( hsersetup/hserout) which is very accurate.

hippy · Sep 14, 2012

For an 18M2 the measured baud rate errors are well within normal serial baud rate tolerances, all below +/-2.5%.

It may however be that the backpack doesn't allow serial baud rate errors which should normally be tolerated.

Goeytex · Sep 14, 2012

Hippy is right and I stand corrected. The severe serout / serin inaccuracy problems are with the 20X2 and 20M2 and not the 18M2.

You can verify your baud rate with a scope with:

setfreq m8
do
serout pin,N9600_8,("UU")
loop

The width of each bit should be 104.16us for a nominal 9600 Baud. Anywhere where from 102 to 106 should be more than accurate enough to communicate with most devices.

When I test an 18m2 Here I get the following:

9600_8 ..... Actual Baud = 9699
9600_16 .... Actual Baud = 9813

These are both a bit high but within specification. Since 9600_16 works, and 9600_8 does not, this may suggest that the Backpack wants a significantly higher baud rate than 9600.

You may be able to prove this with calibfreq. So at the start of the program add these lines:

setfreq m8
calibfreq 12

This will increase the 9600_8 baud rate to ~9820

XLSERVICE · Sep 17, 2012

Hi Guys

Thank you for your replies.
Should there any difference between 9600_8, 16 or 32 from the backpack's point of view?
I've not got a scope handy at the moment but will try the calibfreq.

Cheers
Alan

jedynakiewicz · Sep 18, 2012

Goeytex said:
Hippy is right and I stand corrected. The severe serout / serin inaccuracy problems are with the 20X2 and 20M2 and not the 18M2.

You can verify your baud rate with a scope with:

Well, when I kicked off with PICAXE a couple of years ago I didn't anticipate such complexity and I certainly didn't think that I might need a decent oscilloscope to get things tuned up. I now know differently and I have a proper oscilloscope sitting on my workbench in order to help troubleshoot problems. One of those problems that my 'scope sorted was "noise on the line" from motors but I can now handle the supression elements pretty reliably. The issue in this thread, however, is one that is most frustrating; I never thought that the serial baud rates might be inherently inaccurate to the point of breakdown of flow. My main issue is that there does not seem to be a definitive guide to this problem; one simply has to trawl laboriously through this forum to try and find the information relating to the problem. Therefore, may I ask for some clarification?

@Technical; could you please give some definitive guidance on this issue.

1). Which chips should I choose for the most reliable (centred to the specification) baud rates?
2). Which chips are less effective in this respect? (- I am not implying faulty, I understand the challenges of running programs on various silicon)
3). What clock speed should I choose for the highest reliability of baud rate on each chip?
4). Is the hserin/out inherently closer to the defined baud rate than other pins? Does this also vary between chips?
5). Does it make any difference which pins I use - e.g. is there any difference in using the serout pin?
6). Are there any specific guidelines regarding the tuning of certain chips using the calibfreq to improve the performance of serial interfacing?

I have tubes of every current PICAXE, but choosing the right one for any application seems to be fraught with pitfalls such as choosing schmitt trigger pins or TTLs etc., but the serial comms problem is right up there at the top of my list. I think that I may have hit this problem with my 20X2 chips and the ERF modules. Simple, definitive guidance would be most welcome.

hippy · Sep 18, 2012

Though not a full answer to your questions - HSEROUT and HSERIN will often give the closest to required baud rates, and particularly with 28X2 and 40X2 using an external resonator or crystal.

Goeytex · Sep 18, 2012

I think that I may have hit this problem with my 20X2 chips and the ERF modules. Simple, definitive guidance would be most welcome.

According to my testing the 20x2 has a serious accuracy problem with serin / serout but only at certain frequency baud combinations. Particularly at 8mhz and serout 9600_8 where the actual serout baud rate is 9158. And where the serin "center" is 10189, meaning at this setting the 20x2 can ony receive data from 9808 to 10570. Data sent to a 20x2 serin 9600_8 at 9600 baud (measured) will generally fail. This also means that a 20X2 when set to 9600_8 cannot send and receive data with another 20X2 set to 9600_8.

I published this data HERE well over 6 months ago. But so far it as not been adequately addressed by Rev-Ed.

At one point, Rev Ed offered to to send me some Picaxe Chips for further testing/ confirmation , but these were never sent. I gave up after several inquiries were responded to by someone that just made what seemed to be excuses. I still have received nothing and have received no explanation as to why.

But the good news is that hardware serial is very accurate on all Picaxe chips that support it.
Also setting the 20X2 to 16mhz clock and using 9600_16 should work ok.

Here's what I do with the 20X2:

1. When using a 20X2 ( my favorite Picaxe) AVOID the following software serial settings: See the chart in the link above.

T4800_4, N4800_4
T9600_8. N9600_8
T19200_16,N19200_16
T38400_32,N38400_32

2. If you MUST operate the Picaxe 20X2 at 8Mhz and also MUST use 9600 baud then use hardware serial hserout/ hserin or background receive.

3. With data intensive applications where the Picaxe must receive a significant amount of serial data consider using hardware serial background receive. It works really really well.

jedynakiewicz · Sep 18, 2012

Hippy, thank you. That gives a useful answer to some of my questions.
Goeytex, I followed the link that you provided; thank you it was most informative.
I now see from that link that this is a real wasps' nest of a topic and I now I can see Hippy's (technical's) reluctance to answer all my questions directly and precisely.

Hippy, I have never used a crystal with the 40X2 chips - I have used external resonators - Can you give me some advice on connecting a crystal to the resonator pins and what type of crystal am I looking for? I guess that a crystal would give me excellent timing for other aspects such as a real-time timer.

srnet · Sep 19, 2012

jedynakiewicz said:
Can you give me some advice on connecting a crystal to the resonator pins and what type of crystal am I looking for? I guess that a crystal would give me excellent timing for other aspects such as a real-time timer.

From manual1;

"If desired a 2 pin resonator, or 2 pin crystal, can be used with X, X1 or X2 parts. In
this case two appropriate loading capacitors must also be used with the
resonator/crystal. See the crystal manufacturer’s datasheet for more information"

The two loading capacitors mentioned connect from the resonator pins on the PICAXE to 0V (ground).

Values of the loading capacitor vary, depending on the crystal used, but are usually in the 10pf to 22pf region.

hippy · Sep 19, 2012

jedynakiewicz said:
Hippy, I have never used a crystal with the 40X2 chips - I have used external resonators - Can you give me some advice on connecting a crystal to the resonator pins and what type of crystal am I looking for?

My advice would be to keep using resonators. Any increase in accuracy of a crystal over resonator would like to be imperceptible in most cases.

jedynakiewicz · Sep 19, 2012

Srnet, Hippy, Thank you. I shall continue predominantly with resonators as advised, but undoubtedly I shall have a play with a crystal as indicated by srnet just to build up my experience. This has been a particularly useful thread and I appreciate the advice received.

Technical · Sep 19, 2012

To first go back to the original post in this thread, there are no known issues with the 18M2 baud rates. In this situation we believe the issue is with that brand of LCD backpack. Serial baud rates are actually generally very tolerant of error – this document explains why:
http://www.picaxe.com/docs/baudratetolerance.pdf

To answer the questions about most accurate commands, hserin/hserout will always be the most accurate command on any chip. You can set any baud rate you choose, standard or non-standard, and the internal silicon will accurately clock out the bits at this exact baud rate.

We have also extensively tested all serin/serout baud rate settings on all PICAXE chips. We agree that setting 3 on the 20X2 is less accurate than it should be, and this is documented in the 20X2 revision notes. This a firmware bug that we apologise for. This is the only setting, on any PICAXE chip type, that we consider out of spec.

http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-20X2-microcontroller/#tRevisionHistory

This will be addressed in the next 20X2 firmware revision. Firmware revisions are a major event requiring several months of extensive testing, so unfortunately do not occur overnight.

What many people don’t realise is that a single setting equates to different baud rates at different frequencies. So ‘setting 3’ equates to the following baud rates:

4800 at 4MHz , 9600 at 8MHz, 19200 at 16MHz, 38400 at 32MHz

As can be seen, the baud simply multiples up/down by 2 when the clock frequency changes by 2. In other words the PICAXE firmware internal processing is *exactly* the same, it is simply the internal resonator speed that causes the different baud rates.

So whilst 9600_8 is generated by setting 3, 9600_32 is generated by setting 1 and 9600_16 by setting 2, which do not have the error. So that is why the workaround on a 20X2 is to simply use a different setfreq frequency for 9600 baud, e.g. 9600_32.

We’d like to thank Goeytex for his help with this, but we do consider there to be some inaccuracy in Goeytex’s test results from the pdf attachment in post 1 of the thread he recently linked

http://www.picaxeforum.co.uk/showthread.php?20342-Solving-Serin-amp-Serout-Problems-with-20M2-and-20X2

As an example, on the 20X2 serin results table the above bauds are reported as having 4 different percentage errors, 5.0, 5.3, 5.5, 6.1% - that simply cannot be accurate for the reasons explained above, the percentage error must be the same regardless of clock frequency. So whilst we do agree that there is an inaccuracy on setting 3 (our calculation 5%), we do not agree with the figures quoted, and the results of our internal tests here are indeed always consistent at all clock frequencies.

We also simply cannot duplicate the errors quoted in this document on a 20M2. We have tested, quite literally, dozens of 20M2 chips from different batches and cannot duplicate any problem at all – the 9600_8 serin baud setting on the 20M2 is within spec (-1.1% to be exact). That is why we asked for his 20M2 back so we could test them, the only explanation we can think of, and we are grasping at straws, to get those results is that they are actually pre-production beta tester parts (there has only ever been one 20M2 production release so far). According to our records we sent 3 x 20M2 to the TX 76xxx address on 6 July 2012. Sorry if these did not arrive, we’ll send 3 more today. According to our records we have not yet received the 20M2 back for testing either.

So in summary:

Setting 3 (9600 at 8MHz) on the 20X2 is out of spec. The other three settings on the 20X2 are ok.
No other parts have any serin/serout baud rates we consider out of spec. This has been extensively tested a number of times.
For greatest accuracy hserin/hserout will always be more accurate than serin/serout
An external resonator is not generally necessary for fully functioning hserin/hserout. Although external crystals are more accurate, any tolerances in the internal resonator will not cause an error exceeding the tolerances allowable under the general RS232 baud rate tolerance anyway (unless at extremely high baud rates).

Goeytex · Sep 19, 2012

Technical,

Thanks for the reply.

I only have one of the 20M2's left but I will save it for you and will gladly send it as soon as I receive the ones that you send. The others 20M2's I had were were shipped out to customers in products. I had a total of four and all tested the same in regards to software serial. I have since modified the product to use a different Picaxe.

The variance in error percentage for 20X2 "serin" can be likely be explained as related to the testing procedure I used. I simply did the math on the numbers returned by the automated testing code. Either way it is too much and the procedure was adequate to identify and confirm the obvious (firmware) issue with the 20x2.

As you noted, except for the 20X2 the serin / serout accuracy for the other current Picaxe Chips is "within specification". However, that does not necessarily mean that there won't accuracy related problems.

For example, the actual serout baud rate of an 14M2 at 9600_8 can be measured at 9310 which represents an error of -3.0% from nominal. And the serin center of a 14M2 set to 9600_8 can be measured at 9794 baud (+2% error) with the minimum baud that can reliably be received being 9280. So, consider one 14M2 sending to another at 9600_8. There is only a 30 baud range of operability due to the combined error of ~5%. Even though both are "within specification", this combination is likely to result in intermittent communication errors.

A similar situation could occur, for example,with an 08M2 sending data to a third party LCD display. The 08M2 set to 9600_8 sends at an actual 9300. However the third party device also uses bit banged serial and deviates 3 percent in the opposite direction expecting data no slower 9300 baud. Both may be "within specification" but still cannot communicate reliably or even at all.

My point here being that "within specification" does not necessarily mean trouble free, especially if something is on the very edge of specification.

Goey

jedynakiewicz · Sep 19, 2012

@Technical; Thank you very much for such clarity of explanation and for the reference documents supplied - the explanation of baud rate is particularly well-written. Your full reply has made me much more comfortable regarding the firmware in the existing chips other than the 20X2 and the latter issue can be easily worked around. You have extinguished a lot of unnecessary concern within this thread.

I think it worth mentioning that this slight and now properly identified drift in the baud rate of one particular chip is, as a problem, not outside the industry norm; such things happen with such complex devices. I guess that many people reading this thread, which is now a most useful reference in itself, may not have trawled through the very lengthy documentation that accompanies the release of the original Microchip microcontrollers upon which PICAXE is based. It is not unusual to find a listing of known bugs in the chips at the time of release and the workarounds (or otherwise) that may be necessary to manage these "glitches". It is an enormous credit to Revolution Education that we so rarely find such issues with PICAXE - the firmware is generally so absolutely spot-on and does "what it says on the tin".

Goeytex, of course, thank you for your endeavours in identifing this problem for the rest of us in the first place and documenting properly. I have learnt a great deal from your discussions on the matter.

Goeytex · Sep 19, 2012

I think it worth mentioning that this slight and now properly identified drift in the baud rate...".

With all due respect, let's not minimize the 20X2 problem for the sake of niceness. This is not a slight drift in the baud rate. It is a relatively large error in baud rate. The problem is fixed in firmware ( not drifting) that can cause severe serial comm problems at the identified settings.

The problem was identified well over 6 months ago, not just "now". Some others had complained about this before I did my testing, but the complaints seemed to fall on deaf ears, or were not taken seriously. I just did some testing and posted my results. So, it might be more accurate to say that is now properly acknowledged.

SAborn · Sep 20, 2012

Its nice to see that the serial timing problem has been finally acknowledged by Technical.

Although i still dont agree with their recommended fix of using 16 meg as a solution, as it still dont fix the problem.

I presently have 2 x 20x2 chips in circuit, one reads a scale weight and "serout N9600_X" to a second 20x2 "serin 9600_X", now the 16 meg change will work with 6 inch of cable between the 2 chips, but when the cable length is extended to 3 meters all that is received is Garbage.

With the program trimmed back to suit the 20m2 chips for a test, all works fine through the 3 meter cable.
The only data being sent for testing is 123 in all applications and not actual weight data at this point of testing.

Thus far i have spent untold hours trying to get the 20x2 chips to operate with serial data to no success.
Due the the present circuit design and code required it is not possible to use Hserin/Hserout or substitute the 20x2 chips for 20m2 chips for the end project.

The conclusion is the current 20x2 chip is useless for serial data transfer between chips.

Technical......... Do you have some 20x2 chips that have had the firmware corrected that you could send me as Beta testers, as at this point i have run out of options other than a complete circuit redesign with difficult code changes to suit the 20m2 chip, that i simply wish not to do.

My view is i purchased the 20x2 chips with understanding they were suitable for the job in hand and followed all data sheet/manual recommendations for in circuit use and designed to that, now find its a firmware fault preventing the correct operation of the chips, and feel they should be replaced with upgraded firmware chips.

I do not ask for all my current stock of 20x2 chips to be replaced, just enough chips to complete this project, without the need to redesign the entire boards. (i feel this a fair request)

Edit.. I should add other baud rates was tried with the 20x2 but still the same results....Garbage received.

Technical · Sep 20, 2012

As already stated, the only issue is with the 9600_8 baud. If you still have issue communicating between two 20X2 chips try the 2400_8 baud (a very accurate setting). If still problems then there is something wrong with your design, as there is no issue with timing at this baud rate. 2400_8 is the same as 4800_16 as 9600_32. If none of these work then the issue is not with the baud rate, it is elsewhere in your design/program.

With a 3m cable you are opening yourself to lots of noise induced issues, so good circuit design is very important. Please post your code/circuit.

An updated firmware won't help if this doesn't work, as 2400_8 setting will not be changed, so if it doesn't work now it won't work on the new chip either. Upgraded firmware is not available yet. When it is released you are welcome to send back your chips for free reflashing, this has always been our policy for anyone who wants a firmware update on any part.

SAborn · Sep 20, 2012

It about what i expected as a reply, its not your problem hey?

There is one other part to this i over looked to mentioned, being the need to use sertxd and serrxd in the program, for these to function correctly with the 20x2 chips it was required to use "calibfreq -13" this solved the sertxd and serxd problems but may have caused other problems with serin/serout.

The use of a 3 meter cable should not be an issue, and what i would think a very workable or even a standard length.
In the past i have used 20m of cable between 2 x 08m chips without a problem (also at 9600)

To me this is just another attempt to back away from the actual problem with the 20x2, as when the chips are changed out for 2 x 20m2 chips everything works as designed even with the 3m cable, so would that imply there is still a cable / circuit fault, i think not.

It would be fair to say Rev-ed has known about these problems for some time, as i had reported the sertxt/serrxd problems here shortly after the 20x2 was available, and it was then the Calibfreq adjustment was suggested, that worked for that problem, but i was unaware it was likely to effect the serin/serout functions, and wrongly assumed it would correct faults there as well.
If the all problems had been listed much earlier i would not have designed to the 20x2 chip.
With the present version of 20x2 firmware and the serial problems it makes it even below Chinese product standards.
Once the serial problems are fixed it will put the 20x2 back to its rightful glory of one of the best chips in the picaxe range, but for now its a lemon!

Buzby · Sep 20, 2012

Hi XLSERVICE,

I'm not getting involved in the serial tolerance debate, I just want you to be aware of another 20X2 quirk.

See here : http://www.picaxeforum.co.uk/showthread.php?13776-calibfreq-freaks

Cheers,

Buzby

EDIT : I'm not sure, but I think this may have been corrected with a fix in the compiler.
I may be giving you a bit of out of date info. Sorry.

Technical · Sep 21, 2012

SAborn said:
There is one other part to this i over looked to mentioned, being the need to use sertxd and serrxd in the program, for these to function correctly with the 20x2 chips it was required to use "calibfreq -13" this solved the sertxd and serxd problems but may have caused other problems with serin/serout.

We are working blind here, without your programs we cannot evaluate what you are saying. For instance you didn't mention use of a calibfreq to start with, is this on 20X2 or on 20M2 or on both? If not both then obviously there is a difference between the two programs. Please supply both so we can test them, also your 20X2 firmware version (is it latest C.2?) and Programming Editor version and download cable type. We have never had to use any calibfreq at all on any serrxd/sertxd on a 20X2, but if you are indeed using a calibfreq then obviously that could also disrupt the serin/serout timings at a different point in your program.

Our previous point was simply that N2400_8 will not change on a new firmware. So if it doesn't work now it won't work on a new firmware version either. However if you already have a calibfreq -13 in your 20X2 program that could explain why you don't see inter-chip serin/serout working at N2400_8. Please remove the calibfreq and try again at this baud rate.

Once again we are really trying to help, but without your test programs this cannot be achieved.

The point by Buzby is out of date - fixed already in the compiler.

SAborn · Sep 21, 2012

Technical,

You must forgive me for my out burst due to frustation, this has been an ongoing problem with the 20x2 ever since it was released, and up to now it would appear the problem has been swept under the carpet, good to see you are finally stepping up to resolving the problem.
Lets face it, as far as i have tested with the current chip range (and not used all the range as yet) this is the only chip with a serial problem, making it a lemon to the rest of the range, over all its the best chip in the range if the serial problem is fixed.

To answer your questions, and granted there is more information you should have that i have not supplied (more so didnt consider it required) due to the fact all other chips work with hardware or software used within the chip and external programs communicating via serial coms.

The first time i suggested a serial problem with the 20x2 it was implied because i was not using a Rev-ed approved Usb to serial adapter (being the one rev-ed sold) then the problem was my serial cable of choice used........ Rubbish!!!
If a cable work faultlessly with every other chip range in picaxe or other serial chips, then the problem is within the chip (20x2)

For the sake of the problem lets except all other picaxe chips operate as expected with software , hardware, serial adapters used, where the 20x2 wont, this quickly eliminates serial problems due to 3rd party software, hardware design, and code used, and serial interface type (various Usb to serial adapters)

If a direct serial cable between picaxe and PC is used, the calibfreq is not always required, but as soon as a USB adapter is used (commonly the blue/green Chinese Usb to serial cable adapters, but no limited to these) the need to adjust internal clock is required to enable "sertxt and serrxd" to operate without corrupt data being received.

( i expect now the problem becomes the method of serial coms used and not a firmware problem........ rubbish!!)

From what i am seeing the use of calibfreq then effects the commands of "Serin/serout" rendering the chip useless when depended on as various methods of serial communications.

I will assemble some basic test code that reflects the code used and supply to you , but unless you put the view of the Rev-ed usb adapter is the only coms link you are prepared to test with to one side, then the problem may never be solved.

It is not as though i am some school kid with a project problem, and wish to blame the picaxe chip, its a long on going problem that just gets worst with the 20x2 and serial coms with every time i have used it, the unfortunate part is i used the chip in several circuits that use serial coms, and once there is more than one chip involved the problem becomes double, with one chip talking Chinese and the other Japanese creating a lot of noise but no communication between chips.

First up, can you purchase one of these cables, as they are compatible with the effects of every other USB adapter i have ever used with the picaxe here, and then test with this cable, as the result here fits all adapter types i have used.
Surely Rev-ed can afford the $3.00 for the cable in the name of research, as half the picaxe users work with them.
(if not let me know and i will purchase the cable and have it shipped to you)

http://www.ebay.com.au/itm/250512172218?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649

Once you have the adapter cable and run a few tests, also try receiving data into a VB program and see if you get 100% data, from what i have seen just because the terminal window receives the data, it dont always mean other standard serial protocol programs will work without adjusting the calibfreq for "sertxd and serrxd"

Im sure by now there will be a witch hunt to prove me wrong, but the fact is, there is serial issues with the 20x2 and without some attention the problem will always exist.

Perhaps i do things with other software interfaces and inter serial links that most other users dont do on the average, but it still dont solve the 20x2 problems.

Give me a few days to sort out some simple test code, and i would like to setup and test the code examples here first so we are all on the same page. Its been a few years in the problem so a few days should not matter, as well it will take that long to receive the Usb adapter cable requested.

Technical · Sep 21, 2012

SAborn said:
If a direct serial cable between picaxe and PC is used, the calibfreq is not always required, but as soon as a USB adapter is used (commonly the blue/green Chinese Usb to serial cable adapters, but no limited to these) the need to adjust internal clock is required to enable "sertxt and serrxd" to operate without corrupt data being received.

http://www.ebay.com.au/itm/250512172218?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649

Once you have the adapter cable and run a few tests, also try receiving data into a VB program and see if you get 100% data, from what i have seen just because the terminal window receives the data, it dont always mean other standard serial protocol programs will work without adjusting the calibfreq for "sertxd and serrxd"

Sorry, but we completely disagree with you. You are expecting us to test and endorse a cheap 'knock off' usb adapter and test with that. It's not going to happen. We actually already have over 30 eBay/Amazon 'bargain' adapters here we have tested, all bought from different vendors. Some work, some don't support the RS232 break so don't download. Some don't even do anything at all, dead on arrival. The quality is, as a whole, so poor we will NEVER endorse their use, or perform any PICAXE calibration tests using them. Some people use them, sometimes they work fine. However we will not endorse or test with them.

Do you get the same results with a good quality adapter, using a Prolific or FTDI chipset? You say for yourself that the problem isn't the same with a direct serial cable link... surely that is a big clue....

For the record, the only adapters we will ever support or test are ones using FTDI or genuine Prolific chipsets.

Have you considered the fact that the PICAXE tolerance may be within the serial spec (which allows up to about +/- 5.5%) but the cheapo USB adapter does not allow this range as it should? All PICAXE chips will be slightly different in their serial tolerances. As already noted the 9600 baud on a 20X2 is not as accurate as we would like, but it should still work with any FTDI / Prolific chipset.

Once again, please provide your PICAXE-20X2 programs and the 20X2 chip firmware versions and we will test here, using the recommended cable (an AXE027).

jedynakiewicz · Sep 21, 2012

SAborn said:
Im sure by now there will be a witch hunt to prove me wrong, but the fact is, there is serial issues with the 20x2 and without some attention the problem will always exist.

Perhaps i do things with other software interfaces and inter serial links that most other users dont do on the average, but it still dont solve the 20x2 problems.

@SAborn,

I am sure that no-one would start a "witch hunt" against you, but perhaps one may be express a voice of objective reason as an observer of this conversation, retaining goodwill and temperate words all round.

The 20X2 is a PICAXE chip with PICAXE firmware that is designed to be programmed over a PICAXE cable AXE027 (or AXE026) connected to a computer loaded with a PICAXE AXE027 driver and running PICAXE programming software. Surely it is only reasonable that if this works okay, which it appears to, then the manufacturers have fully achieved their contract with the purchaser? This would be the approach of any manufacturer or supplier. The concept that the manufacturer would be requested to ensure that their systems work with a low-cost third-party component that has been substituted for their own component is perhaps less than reasonable. I sympathise with your frustration, but perhaps you may just reflect on what you are asking of the manufacturers. I do feel that you are receiving a most generous listening ear on this matter and clearly there is a will to determine just what the problem might be.

When unexpected problems arise in working in electronics it can be very frustrating; running up a prototype before a final model is really the way forward with anything that actually has to operate in a working environment rather than just being a hobby or for education. In an industrial development environment, finding an occasional glitch in the firmware, software or silicon is by no means unusual - in fact with prototype development I would even say it is the norm. But I do sympathise with your frustration when you are trying to accomplish a certain goal and you feel that the barrier to it is outside your realm of intervention.

So yes, as they have acknowledged, the firmware error that causes issues with one specific set of serial baud rates needs to be attended to. But I simply cannot see that the manufacturers need to attend to a matter of making their devices compatible with download cables that they neither specify nor approve when their own download cables function perfectly well.

Goeytex · Sep 21, 2012

A quick test here shows that for uncorrupted data to the PE terminal, a Prolific based adapter needs to receive data at a minimum baud rate of 9224 when the Com Port is is set to 9600 baud. An FTDI based adapter on the same system and with the same settings needs to receive data at a minimum baud rate of 9116.

The FTDI Adapter is tolerant of an error of -5 percent while the Prolific adapter is tolerant of a baud rate error of -3.9 percent. With the 20x2 9600 serout at an actual 9158, it is at the very edge of failing with the FTDI adapter and slightly over the edge with the Prolific. There is nothing wrong with the Prolific adapter. The the most commonly accepted max TX baud error is either 3% or 2% percent depending upon who you listen to.

For the most part the Picaxe software serial is extremely accurate with the TX baud rate error at less than 1 percent except for the 9600_8 setting.

It may be relevant to note that on some other Picaxe chips the 9600_8 setting results in a 3% serout error while the other settings are < 1 percent. If it were me calling the shots, and as time and resources allowed .... I'd look into correcting the firmware in those chips as well. We already know that ~ 1 percent is attainable.

SAborn · Sep 26, 2012

I ran a few tests here quickly with serial data and the 20x2 and thus far have not been able to create errors under normal operations.
It is making me look foolish, but i have had serial issues with the 20x2, or i would not have made the comments i have.
Tests of late have been with 8 x 20x2 chips version C.2 using several different USB adapters, and Yes also the adapter cable listed above, as well as a prolific adapter, a CP2102 adapter, and others, (some use the same driver)

Hmmm! still no errors. (as i blush about now, and try to convince you "i really did see little green men" seriously!)

Due to the fact that Calibfreq was used in my previous code with the 20x2, and was required for Sertxd to not send corrupt data (its a pain in the butt to adjust each chip if it was not required, so would not have done it if it was not needed) effected the use of serin/serout.

The code used in one project to read a 24 bit load cell sensor and display it to a LCD and also send the data via serial, either by sertxd or serout is rather basic and as follows.
The need to use Calibfreq -13 was required to receive serial to the PC via sertxd without serial errors.

Code:

#picaxe 20x2

CalibFreq -13

symbol low_byte =        b0
symbol mid_byte =        b2
symbol high_byte =    b3

symbol tenthou =         b4
symbol thou =         b5
symbol hund =         b6
symbol tens =         b7
symbol units =         b8
symbol temp =         b9
symbol Y =            b10
symbol X =             b11
symbol bitCount=        b12
symbol z =             b13




symbol value =        w1
symbol cali =         w11

symbol disp_value =    w12
symbol tare =         w13
symbol beep =         C.5
symbol en =         C.4
symbol rs =         C.7 
'symbol led =        A.0
symbol weigh =        pinB.1
symbol master_call =     pinB.3
symbol tare_button =     pinB.0

symbol PP =         3
SYMBOL P  =         6


Symbol Din_Pin =         pinC.6
Symbol CLK =         B.6

symbol EEtare =        20
symbol EEcali =        10

'$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

'    cali =        29

'$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$



    low clk
    Z = 0

    let dirsc = %10111111
   
   
    read EEtare  , word Tare
    read EEcali  , word cali
   
    gosub Init
    temp = 1 : gosub wrins
     
    gosub beep2
     
    gosub display_weight

main:
   

    if tare_button = 1 or weigh = 1 then
    pause 200
    goto button_function
    endif

    if master_call = 1 then
    gosub beep2
    gosub master
    endif
   
    goto main
   
   
   

Button_function:

    if tare_button =1 and weigh = 1 then
   
    gosub beep2
    gosub message3
    pause 1000
    gosub cali_adjust
    endif
   
   
    if weigh = 1 and tare_button = 0 then
    gosub beep2
    gosub display_weight
    endif
   
   
   
    if tare_button = 1 and weigh = 0then
    gosub beep2
    gosub tare_enter
    endif
   
   
   
    
     goto main
 
 

     
     
'#rem

display:

bintoascii disp_Value, tenthou, thou, hund, tens, units

'    if tens = $30 and hund = $30 and thous = $30 and tenthou = $30 then        'Blank out the tens if leading zeros        
'    tens = $20
'    endif

'    if hund = $30 and thous = $30 and tenthou = $30 then                'Blank out the hundreds if leading zeros
'    hund = $20
'    endif
   
    if thou = $30 and tenthou = $30 then                'Blank out the thousands if leading zeros
    thou = $20
    endif
   
    if tenthou = $30 then                'Blank out the tenthousands if leading zeros
    tenthou = $20
    endif   
   
'%%%%%%%%%%%%%%%%%%%%%%% Write Numbers to LCD %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

    temp = tenthou                'Write ten thousands digit
    gosub wrchr

    temp = thou                'Write thousands digit
    gosub wrchr

    temp = hund                    'Write hundreds digit
    gosub wrchr

'    if flag = 1 then
    temp = $2E                    'Write decimal point
    gosub wrchr
'    endif
   
   
   
    temp = tens                    'Write tens digit
    gosub wrchr

'    if flag = 3 then
'    temp = $2E                    'Write decimal point
'    gosub wrchr
'    endif

    temp = units                'Write units digit
    gosub wrchr
   
    return   



   
   
init:                           
    pinsC = 0 :pulsout en,P            'Reset all hardware
    pause PP
    pinsC = %00000010 : pulsout en,P    '4 bit mode
    temp =  %00101100 : gosub wrins    '
    temp =  %00001100 : gosub wrins    'Display control
    temp =  %00001100 : gosub wrins    'Clear display   
    pause PP
    temp =  %00000110 : gosub wrins    'Entry mode   
   
    return

'%%%%%%%%%%%%%%% Write LCD Character Routine %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   
wrchr:                        'Write character to display routine
    pinsC = temp/16
    Pause PP
    high rs
    Pause PP
    pulsout en,P
    Pause PP
    pinsC = temp and 15
    Pause PP
    high rs
    Pause PP
    pulsout en,P
    Pause PP
    return

'%%%%%%%%%%%%%%% Write LCD Instruction Routine %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

wrins:                        'Write instruction to display routine   
    pinsC = temp/16
    Pause PP
    pulsout en,P
    Pause PP
    pinsC = temp and 15
    Pause PP
    pulsout en,P
    return
       
    End
   
   
       
Master:

   
    gosub read_weight
   
'    setfreq m16
   
serout b.4,N9600_8,  (value)'value
   
'    setfreq m8
    gosub Disp_Wt

    Pause 500
   
    return
   
Calibrate:

   

    Disp_value = value
   
    if disp_value < tare then
    disp_value = tare
    endif
   
    disp_value = disp_value - tare
    disp_value = disp_value * 10 / cali
    disp_value = disp_value * 10
    return
   
Tare_enter:


    gosub read_weight
   
    write EEtare , word value
    tare = value
    gosub message_2
    gosub display_weight
   
    return
   
   
Read_weight:

    if Din_Pin=1 then Read_weight
   
    low_byte=0
    mid_byte=0
    high_byte=0


    For bitCount = 0 To 7
      PulsOut CLK, 1
      high_byte = high_byte * 2 | Din_Pin
    Next


    For bitCount = 0 To 7
      PulsOut CLK, 1
      mid_byte= mid_byte * 2 | Din_Pin
    Next


    For bitCount = 0 To 7
      PulsOut CLK, 1
      low_byte = low_byte * 2 | Din_Pin
    Next


     PulsOut CLK, 1
    inc z

     if z = 5 then
     Z=0
    return
     endif
      goto read_weight
 
 
 display_weight:
 
     gosub read_weight
    
Disp_Wt:
    
     gosub calibrate
    
     gosub message_1
    
     gosub display
    
     gosub screen
    
     return
    

Message_1:


 temp = 128 : gosub wrins        'Start of first line
   
    for y = 0 to 9                'Write "WEIGHT" to display
    lookup y,("WEIGHT = "),temp
    gosub wrchr
    next y
   
    return

Message_2:


 temp = 192 : gosub wrins        'Start of first line
   
    for y = 0 to 9                'Write "WEIGHT" to display
    lookup y,("TARE SET  "),temp
    gosub wrchr
    next y
    pause 2000
   
temp = 1 : gosub wrins   
    return


message3:

    temp = 192 : gosub wrins        'Start of first line
   
    for y = 0 to 9                'Write "WEIGHT" to display
    lookup y,("CALIB = "),temp
    gosub wrchr
    next y

    return
   
   
Beep2:


'    high led
    for x = 0 to 1
    pwmout PWMDIV16, beep, 250, 600
    pause 150
    pwmout beep , 0 ,0
    pause 50
    next x
'    low led
   
    return
   
   
   
Screen:

sertxd ("<W>", #value,"</W>", cr,lf)
   
    return
   
   
cali_adjust:


    gosub message3
   
   
    if tare_button = 1 and weigh = 1 then
   
    Write EEcali, word cali
   
    gosub beep2
    temp = 1 : gosub wrins   
    gosub display_weight
   
    pause 200
   
    Goto main
    endif
   
    Disp_Value = cali *100
    gosub display
   
    gosub display_weight
   
    if tare_button = 1 and weigh = 0 then
    dec cali
'    pause 50
   
    endif
   
    if weigh = 1 and tare_button = 0 then
   
    inc cali
'    pause 50
   
    endif
   
   
   
    goto cali_adjust

The code has not been tidied up and is as last used as to be fair to all.
Not that i see the code as much use here, but im sure someone will want to dig through it.
And no i dont have a schematic of the circuit on hand only the PCB layout and components, although it is what i would quote as a standard programming serial port setup as per the picaxe manual.

See the next post as the forum would not allow such a long single post and i needed to split it in half.

SAborn · Sep 26, 2012

The latest tests was from a simple board consisting of a 7805 v-reg and filter caps, 20x2, a standard programming port setup (10K, 22K and 180R in series on the serial out), decoupling cap 0.1uf, on/off switch.

A quick test program of...

Code:

#picaxe 20x2


Main:

For b1 = 0 to 10

for b0 = 0 to 3
sertxd ("< 1234567890 > ")
pause 200
next b0

sertxd (13,10)
pause 10

next b1


sertxd (13,10,13,10)
pause 10

For b1 = 0 to 10

for b0 = 0 to 3
sertxd ("> ABCDEFGHIJ < ")
pause 200
next b0

sertxd (13,10)
pause 10

next b1

sertxd (13,10,13,10)
pause 10

goto main

Was used and the serial data recorded to a text file with no errors that i can see.
This was repeated with several chips (version C.2) with the same results, i even left one chip recording for an hour (miles of data recorded) and still no errors.

File Here.
View attachment 12419

Then the same test was done using a VB6 program to record the data, as VB has had problems with the serial data in the past that didnt show in the PE terminal window.
Again no errors..............

File here.
View attachment 12420

My point behind requesting Rev-ed to test with the USB to serial cable i listed above, was it uses the HL-340 driver which is rather common on the market with USB to serial cables of today, and would think its now as common as the Prolific adapters, and it has worked very well with the picaxe other than the 20x2. (although of late its worked perfectly with 20x2 tests......Grrrrrr!).

When i am testing products one of the first thing i will test with is a worst case situation, if i know of one likely to effect the result. (as the cable with the HL-340 driver was used then thought it valid to request it to be used in testing)

In this case the adapter listed previous uses the HL-340 driver, which i would say to be in the top 3 most common drivers in USB adapters on the market, its not the cable listed i wanted tests done with, its the driver the cable uses i was interested in you testing, as many adapters use this driver and i see many of the cables i listed used in schools and other groups that require quantities of USB adapters (lets face it $3.00 compared to $24.00 is a lot of dollars saved when buying many cables)

Over all to date i have not been able to repeat the serial errors i have bitched about in the basic tests done , so if i need to apologize to Technical i will, but for now i will refrain due to a long time past problems with serial data and the 20x2 that replacing the 20x2 with a 20m2 solves the problems.

If i am man enough to step up and suggest there is problems with the 20x2, then i will be man enough to report any test results/problems either way. (good or bad)

I would like to know why i have had the serial troubles i have had with the 20x2, and also like to see any firmware problems fixed, by acknowledging problems things get fixed, and we are all aware of limitations of a chip firmware version, when a firmware problem is not acknowledged then this can cause problems with operations from one firmware version to the next without knowing what has been fixed between versions.

I do have some earlier 20x2 chips here somewhere ??(its like radio shack here, more parts then i know where i put them last) and when i locate them i will repeat tests to see if its a earlier chip version that has given grief to date.

inglewoodpete · Sep 26, 2012

SABorn, I understand the frustration. It used to fail but now it works and there doesn't appear to be a reason why.

What time of the year did the problem occur? Was it mid summer (or at least hot weather?). Communication needs both end to run at (more or less) the same speed. I have had situations, I admit not with PICAXE, where both ends of a comms link have drifted in different directions. Dare I say it but could the HL-340 drift off spec?

SAborn · Sep 26, 2012

IWP,

Its been a ongoing problem across all seasons and most development work has been inside the house or workshop which is at a reasonable constant temp, also there has been at least 3 different people involved in some projects all at different locations with the same type of errors, and i know one of those persons uses the Rev-ed "approved" usb to serial adapter.

I use several usb adapters but the common one is the HL-340 (old favorite)

I appreciate your input of thinking outside the square, as there is a reason for the problems encountered and i am miffed to what it might be.

I am starting to question if its actually in the silicon of the chips and outside of Rev-eds control, but dont know if that is even possible.

Effects of 'setfreq' command on 18m2 'serout'

New Member

Senior Member

Technical Support

Senior Member

New Member

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member