Solving Serin & Serout Problems with 20M2 and 20X2

[Goeytex]

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

[rkjohnsonsr@gmail.com]

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]

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]

. . . 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]

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]

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.)

#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

[srnet]

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]

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

[mrburnette]

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]

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.