Odd problem - 14M2 works, 20M2 doesn't

Jeremy Harris

Senior Member
Worth noting that the standard upon which this whole debacle is based used the principle of synchronising each character with the leading edge of it's start bit, exactly as described in the Rev Ed paper, and exactly as taught to me in college 40 odd years ago.

This point seems to be being lost here with esoteric arguments as to who is right or wrong in any particular interpretation of a non-existent "standard". There isn't, as far as I'm aware, an internationally recognised standard for 5V level serial data comms using RS232-like signalling, pretty much each and every manufacturer uses a slightly different take on it in some way or another. There isn't a standard for timing accuracy, either, the limits are when the stop bit slides out of the detection window for that character. I worked extensively on electromechanical Teletypes in the early 70's, and cannot once recall measuring bit rate (rather than baud rate) over multiple characters, because the system relied on re-synchronising at the leading edge of each characters start bit. As long as the bit rate accuracy was sufficient that the stop bit was still seen within the timing window for the last bit of the character, then all was well - the aim when setting them up was to get the centre of the stop bit right on the edge of the detection window, to allow equal drift up and down.

Let's not lose sight of the fact that the Picaxe is an educational system, designed to allow fairly basic programming techniques to be taught and understood by schoolchildren. Some of us routinely push the capability of Picaxe chips way beyond the intentions that Revolution Education have for them, so we should be a little more understanding of some of the limitations. Any flexible, software driven, bit-bashed serial port is going to have some limitations, that's inherent in trying to do something for which the hardware isn't specifically designed.

I've hit the limits of the Picaxe firmware a few times in various projects, but accept that what I've been trying to do is sometimes just too far outside the design envelope for the Picaxe. Perhaps we should be a bit more tolerant of some of these limitations, and not so critical of a small company working on low margins with the primary aim of trying to help educate our kids.
 

JimPerry

Senior Member
Worth noting that the standard upon which this whole debacle is based used the principle of synchronising each character with the leading edge of it's start bit, exactly as described in the Rev Ed paper, and exactly as taught to me in college 40 odd years ago. .....

Perhaps we should be a bit more tolerant of some of these limitations, and not so critical of a small company working on low margins with the primary aim of trying to help educate our kids.
More likely Grandkids :confused:

This Thread is much more of a debate about Angels on Pins than Picaxe ... can it be made private or moved? :rolleyes:
 

westaust55

Moderator
I concur with Jeremy Harris’ comments.

The applicable standard for RS232 upon which I believe/suspect Rev Ed have based the PICAXE SEROUT and SERIN commands is EIA RS232 which several revisions having a letter such as “C” appended as a suffix (eg RS232C or EIA232C).

The voltage levels are defined as ranges with +3 to +25 and -3 to -25 Volts as the allowable range for the two states. A ‘mark” (= 1) is a negative voltage and the “space” (= 0) is a positive voltage on the signal lines between devices.
I recall back in the in1970’s when I had to implement a negative supply to drive signal levels negative (not just to 0 Volts) for communications to dot matrix printers.


Here are a couple of websites with details in the standards (but not a copy of the actual standards)
http://www.radio-electronics.com/info/telecommunications_networks/rs232/eia-rs232-c-d-standards.php
http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html#anchor1154232
and on a later variant RS232F in this TI app note: http://www.ti.com/lit/an/slla037a/slla037a.pdf

I recall that current loop was a common communications scheme prior to and during the early years of RS232 (voltage level based signalling) but I digress.
 

erco

Senior Member
You gotta love the passion in this thread. IMO Goeytex isn't being overly critical of Rev Ed, nor PicAxe. Quite frankly, he's an amazing resource, a real hands-on experimenter, and the epitome of the type of experimenter I'd like to be. His numerous posts are consistently informed, educational and inspiring in their technical content. I haven't delved into any of the timing minutia he details, but I fully believe his claims are factual. Clearly there's some difference between the 14M2 and 20M2. Sounds like he's spent some valuable time identifying specific timing issues in an attempt to help. Some companies would appreciate that effort instead of refuting it.
 

Jeremy Harris

Senior Member
But the key here is that there seems to be a misunderstanding about the fundamental timing method that RS232-like serial comms uses. Rev Ed are using the generally accepted method of measuring bit rate accuracy across a character, as defined in RS232. Others seem to be making up their own methods, by including the variable character to character latency from internal firmware processing within their timing definition.

We know that all software driven, bit-bashed, serial port systems have some issues with latency. This is inherent in the way they work, and will vary with clock speed. It's a known limitation of all software driven serial ports an all devices that have such an option, not just the Picaxe.
 

Goeytex

Senior Member
But the key here is that there seems to be a misunderstanding about the fundamental timing method that RS232-like serial comms uses. Rev Ed are using the generally accepted method of measuring bit rate accuracy across a character, as defined in RS232. Others seem to be making up their own methods, by including the variable character to character latency from internal firmware processing within their timing definition.
And some are hiding behind a specification that is not really "generally accepted", while ignoring or even trying to discredit empirical data that shows what actually works and what does not. Many will not bother to do actual testing and accept the official answer as infallible, while in the mean time help requests will continue to come to this forum where serial comms fail with serin at 9600_8 while 8N1 data is being sent within 2% of 9600 baud.

This should not be all about theories and specifications , but rather about solutions.

Here's an interesting real world tidbit.

On a 20M2 with serin set to 9600_8 data, a device is sending an 8 byte packet of serial data. The received data is corrupted after the third byte. A logic analyzer shows the data being sent at an actual 8N1 at a baud rate of 9688. ( within 1% of 9600)

The code is.... serin c.2, N9600_8, b0,b1,b2,b3,b4,b5,b6,b7

When "calibfreq -5" is added to to 20M2 code the data is received without error. The clock frequency was reduced and therefore the processing overhead time was actually increased, yet the data problem is solved.

I'll let the theorists explain ....
 

Jeremy Harris

Senior Member
As you've quoted me, I guess your barbs are intended to point in my direction...............

First off, the last thing I am is a theorist, I've been hands-on with this stuff for far more years than I care to count and was working with RS232 driven Teletypes more than 40 years ago.

You'll get the sort of incompatibilities that you've found (and that I've never disputed) with any asynchronous serial system like this that doesn't have a defined flow control or handshake protocol. There will be variations in latency with clock speed, and probably with the firmware version used, or with the particular flavour of PIC hardware any particular Picaxe chip uses. The same problem existed with Teletypes, and to get around it hardware flow control was used, which stopped the transmitter sending until the receiver was ready to detect the next start bit.

As I keep saying, what you're seeing is just an inherent feature of bit-banging a general purpose port to turn it into a software driven serial port. Your example just shows that a tweak can bring things into sync and allow a longer data stream to be reliably received. Useful to know, but it doesn't change the fact that the bit stream rate over a single character (which, as several of us keep saying) is within a generally accepted tolerance.

The real answer to getting reliable serial comms without handshaking is to use a proper serial port, one with a hardware UART, rather than a psuedo serial port created by firmware.
 

PADJ

Member
From Basic Commands - SERIN:
A maximum of 4800 baud is recommended for complicated serial transactions at 8MHz. Internal resonators are not as accurate as external resonators, so in high accuracy applications an external resonator device is recommended. However microcontrollers with an internal resonator may be used successfully in most applications, and may also be calibrated using the calibfreq command if required.
 

Goeytex

Senior Member
Useful to know, but it doesn't change the fact that the bit stream rate over a single character (which, as several of us keep saying) is within a generally accepted tolerance.
That if we accept the so-called "generally accepted tolerance" to be for a single byte only, then that renders 100's of devices that send data at within +2 percent of 9600 baud useless with the 20M2 at 9600_8 and other settings since many, if not most, of these of these are not configurable in that there is no way to add an extra stop bit or two to compensate for serial in inaccuracy and/or latency problems. It also, for practical purposes, makes 8N1 rather meaningless. We are not dealing with ancient standards and 40 year old teletypes anymore. It is 2013.

I do agree that using a hardware UART is the best way to go for serial comms. However the 20M2's 2 byte hardware serial buffer is inadequate for serious hardware serial comms and forces the data to be processed after no more than two received bytes, again rendering many good products adhering to a better acceptable tolerance than Picaxe, unusable with hardware serial on the entire M2 product line.
 

SAborn

Senior Member
The bottom line is there is timing issues with some picaxe chips and serial data, and i think i have had more issues with this than any other forum member has reported, and if im correct it was a early post on the 20x2 problems i had, that started Geotex on his testing program.

There was no issue with the 20x2 in the beginning either (apparently), but that has since been fixed in later software versions.

In nearly all cases of picaxe serial problems, tweeking the clock frequency using "Calibfreq" would solve the problem, but it was a pain in the ass to do for each chip or project.

Due to the fact tweeking the frequency would adjust the problem and solve it, would imply to me the default frequency is not correct to start with and should be easy for Rev-ed to adjust once they know there is a problem.

Different USB to serial adaptors can also effect the results, but if a cable adaptor works with every other serial device i own and only works at certain settings with the picaxe then i think its the picaxe that is not correct, not the other devices.

In todays age i would also think a picaxe chip using serial should be able to communicate with a PC as a basic requirement.

I could program the picaxe via PC so all worked there, but with receiving data to the PC (sertxd) and using a VB program to log the data on PC it would receive garbage unless the Calidfreq was adjusted, this was a early version 20x2 and now has been fixed.

You can quote any protocol you like, but if there is a problem that Rev-ed can tweek to fix it, then it will never happen if we as users dont report the problems and do some testing to show the design expert he has it slightly wrong or the problem will never be addressed.

It would seem many are very quick at wanting to shoot the messenger that is only trying to report the problem the best way he can, or discredit his view with lots a technical jargon based over 40+ year old systems.
If it has problems than fix it, if its 40 years old technology than upgrade it to suit todays standards.
So many forum members bit bang on about the standard of Chinese products, well i would like to think a good old British product to not be closed minded to problems and choose to take the Chinese view of "well 50% of everything else worked"( yes except for the most important part i required for my project.)
If it was ebay or paypal you would claim a refund for a device that was not as quoted or as a counterfeit, because it did not work as per the data sheet.
If it was any other chip you purchased would you except it as "it might work or it might not" i think not.

All i want to hear is Rev-ed acknowledge the report of a problem and fix it in the next version and not sweep it under the carpet as "too Hard"
They have a super great range of picaxe chips, which i would like to see even better by a few bug fixes in the version upgrades.
 

Technical

Technical Support
Staff member
All i want to hear is Rev-ed acknowledge the report of a problem and fix it in the next version and not sweep it under the carpet as "too Hard"
They have a super great range of picaxe chips, which i would like to see even better by a few bug fixes in the version upgrades.
On every firmware upgrade, we always aim to improve anything we can. We think the 20M2 tolerances are already acceptable at present, but if we can improve them in any way we obviously will.
 

Billo

Senior Member
Touché!

I agree 100% with this.


Worth noting that the standard upon which this whole debacle is based used the principle of synchronising each character with the leading edge of it's start bit, exactly as described in the Rev Ed paper, and exactly as taught to me in college 40 odd years ago.

This point seems to be being lost here with esoteric arguments as to who is right or wrong in any particular interpretation of a non-existent "standard". There isn't, as far as I'm aware, an internationally recognised standard for 5V level serial data comms using RS232-like signalling, pretty much each and every manufacturer uses a slightly different take on it in some way or another. There isn't a standard for timing accuracy, either, the limits are when the stop bit slides out of the detection window for that character. I worked extensively on electromechanical Teletypes in the early 70's, and cannot once recall measuring bit rate (rather than baud rate) over multiple characters, because the system relied on re-synchronising at the leading edge of each characters start bit. As long as the bit rate accuracy was sufficient that the stop bit was still seen within the timing window for the last bit of the character, then all was well - the aim when setting them up was to get the centre of the stop bit right on the edge of the detection window, to allow equal drift up and down.

Let's not lose sight of the fact that the Picaxe is an educational system, designed to allow fairly basic programming techniques to be taught and understood by schoolchildren. Some of us routinely push the capability of Picaxe chips way beyond the intentions that Revolution Education have for them, so we should be a little more understanding of some of the limitations. Any flexible, software driven, bit-bashed serial port is going to have some limitations, that's inherent in trying to do something for which the hardware isn't specifically designed.

I've hit the limits of the Picaxe firmware a few times in various projects, but accept that what I've been trying to do is sometimes just too far outside the design envelope for the Picaxe. Perhaps we should be a bit more tolerant of some of these limitations, and not so critical of a small company working on low margins with the primary aim of trying to help educate our kids.
 
Top