Hello SX gurus!

I've had an SX tech tool kit for some time, but I was overwelmed by the complexity and
difficulty of writing programs in SX/B so I stuck with my stamps.

However, I've recently been inspired by Bean's SX/B 2.0's task feature to create a hybrid
SX/BS2 board for my current project (A robot) and would like some assistance in both creating
the needed program for my SX28 and learning the language.

I have a bad tendancy to want to learn EVERYTHING when I start on something, so I tend
to ask questions to the point where I annoy everyone attempting to teach me... so I have
a request.

To prevent spam on this forum, I'd like to ask one of you experts to endure a one-on-one
mentorship to help me answer all my questions.

I can't pay you, I can't help you with your projects because you know more than me, so
the only thing I can do to repay you is give you my gratitude and promise I will pass on
what you teach me when I can.

Just to head off suggestions I read the documentation, I've read pretty much everything
I can get my hands on for SX/B... my problem is most SX info is about assembly. I have
no intrest at all of learning assembly so this doesn't help me much.

I have a working knowledge of both C and PBASIC so you don't have to worry about questions
like "What's a function?"

Feel free to post any questions to me either here or in a PM... and thanks in advance for
helping me discover the utility of this little chip!

Checkout Capt Quirks "Best SX Threads index and Code Examples": http://forums.parallax.com/forums/default.aspx?f=7&m=182809
In it you'll find a link to a working draft of Jon Williams' upcoming book Practical SX/B. The book is being re-written from SX/B 1.5 to 2.0 right now, so if you can wait you might want to.

Ugha--
I really hope someone(s) step up and help. I will EAGERLY watch this subject. I have five of Robert's D.'s SX48 modules (direct replacements for the BS2p40) and have yet to use a single one. I would like to put at least one to use next summer.

Good luck to us!

T'Saavik: Thanks for the link! I have to admit I haven't been monitoring this forum that much and I appreciate the link to... well links :)
I've actually read the Practical SX/B (No Assembly Required) that is available for download on the Parallax site... I found it to be the absolute best
source of info on SX/B I've found yet, although I was seriously p... umm... lets just say extremely displeased that it ended so abruptly.

I'm VERY glad to know it was only a draft and also extremely excited to find out it'll be rewritten for 2.0. Has he said when he expects it to be
completed or at least have the draft updated for 2.0?

Bill: I'm glad someone out there feels the same as I :) I'll keep you updated if anyone PMs me or otherwise accepts my request.

It seems to me that a mentoring program for forum regulars would really benefit the Parallax community.

We have the best support of any microcontroller site and really great people who seemingly spend all day helping others...
Why not take it to the next level and try out some kind of mentor or "newbie helper" kind of system?

I've also thought that community projects, where one person purposes a project and everyone chips in/gives advice/guides
the process, would be both useful and fun.

Perhaps each time a project is completed a new person is selected to purpose the next one.

Alright, rambling post over.

Ugha-
I know JonnyMac is working hard to get Practical SXB done ASAP (well, I don't know, but educated guess). I find I learn alot just reading the different posts, as I'm sure you do. Keep at it. Play.

I have a very similar characteristic, I need to learn everything I can, before I can even think of starting a project. I waste so much time, researching a project, that I could have completed the project in time that it takes me to research it. I am fairly certain (in my case), that my learning disabilities and ADD are at the root of the problem. But taking control and organizing my program into lots of small programs and then assembling them afterwards, works for me.

As you know, many of the Basic Stamps are based on the SX chip. So they are both capable of the doing the same functions. What makes the Basic Stamp language so powerful IMO, is it's simplicity, you don't need to learn anything about the chip.

The same thing is true with the SX and SXB until you run out of variable space. Most programs will fit in that space, but after you exceed, the limit, you are forced to learn more about the chip. Learning the chip opens big doors of opportunity.

The point I am trying to make is, to break up your project into little pieces (just like what they say to do). In the beginning the only big difference is that some BS2 key words handle 16 bits (words) and corresponding SX key words may only handle 8 bits (bytes). When you exceed the number of variables, use arrays of variables to extend the memory (and there are many examples of that too). After you get past just two small hurdles, you can exceed the basic stamp.

Use the forums to help plan out your program and divide it up into small workable pieces. Follow a set programming style, comments and name conventions, to make it easier to put everything together. Read N&V # 137 before you start and pay attention to Jon Williams "BREAK NOW" SUB-routine and "WATCH" to help you Debug your code.  Also, there is no good reason for you to start with SX/B 2.0, there is too much good information on the current version.

There is a wealth of examples in the "examples" folder, located, C:\Program Files\Parallax Inc\SX-Key v3.2.92\Examples. And this PDF is a written example of all that code.

Bill--

Dumb question: At, say, 20mhz, how much faster is the SX than the fastest Stamp which executes 19,000 instructions per second? If I have not phrased the question correctly--such as comparing apples to oranges--can you figure out more or less what I mean and come up with an answer?

I appreciate it! Thanks!

You know the answer, but I think it's more about a philosophical perception of horsepower.

Capt. Quirk--
Actually, I do not know the answer because I have never been able to figure out if the Stamps and the SX are scalar or sub-scalar processors. If they are scalar, the answer is easy; the clock ticks and an instruction is executed. If they are sub-scalar, the answer may well be impossible to determine other than in a general way such as the Pentium is faster than the 486 (although I THINK they are both super-scalar processors).

I am just looking for a "feel good" answer. Is the SX faster than the fastest Stamp? I am not looking for an in-depth analysis involving the instructions executed. I like the SX very much and will doubtless use it due to its interrupt structure. That feature alone places it head and shoulders above any Stamp.

Can you, or anyone, say something about their relative speeds as poorly as I have defined the question?

Thanks.

I'm no expert - but having read the docs half a dozen time I would say -
At 20Mhz the SX will execute 20 million single-word non branching instructions in one second. Now of course many instructions branch or call (which pushes you to four or five cycles). Further many things that look like a single assembly instruction are actually 2 (or even 3) words. But if you assume every assembly instruction is 5 cycles (very pessimistic) then a 50MHz clocked SX is running at 10 Million instructions a second.

Now, of course, the assembly instructions are still much lower level than PBASIC. But if you look at the output from SX/B most lines of basic generate 3-6 lines of assembly. Even if you assume 10 (again ultra pessimistic) then you are getting 1 Million Basic instructions per second.

In simple terms - feel good - the SX is going to be at least 100x faster than a 'fast' STAMP ...

David--
Ah! That is exactly what I wanted to know, despite all the caveats! Thank you!

When it comes to SX and SX or SX and Stamp communication, I can easily get around the SERIN/SEROUT limitations by using pin to pin signalling. It is not appropriate in all cases, but in many instances wherein one needs to signal the occurence of an EVENT, it is FAR, FAR superior than SERIN/SEROUT. (I'd hate to send text with it, though. But, how often does one need to send text quickly?)
Thank you.

Does anybody experiment anymore?  Oh... I do!  Just yesterday I wanted to verify how SX/B works vis-a-vis suspending tasks so I hooked up a 'scope.  Am I the only person who finds this kind of stuff fun?  Come one, guys, grab an SX, some LEDs, a 'scope and have a blast.  Why wait to have fun?

Practical information on SX versus Stamp speeds: The SX in turbo mode runs 1-for-1 so a 20MHz clock means you're running 20 MIPs.  The Stamp, on the other hand, has to fetch and decode a token from its EEPROM -- this process takes about 100-150 microseconds; in that time the SX running at 20 MHz can run 2000 to 3000 instructions.

That's a question better suited for Gunther, Bean or one of the Peters.

I just think that people confuse the issue by only comparing a chips in Mhz and instruction speed.

Similar to what David said, when you have 2 programs (SXB & BS2) that do the same thing and they have the same Pause statements, it really doesn't matter how many instructions per second are being executed.  What's important is how easy was it to achieve or goals.

Also the BS2 (with a pic or sx) uses an Interpeted language on an eeprom, and I think it's speed is limited to how fast it can access it's eeprom, in order to execute an instruction. Compared to the SX, where all it's instructions are on the chip.

Capt. Quirk--
Like you implied, it's all in how you use it. I understand that.

FYI, I try to use a microcontroller as if it were not a computer, but a microcontroller. In other words and in my opinion, a microcontroller cannot be the true brains of a robot capable of sophisticated action. I think we need a computer involved. This is not to say that microcontrollers are not valuable assets in our efforts to build robots; indeed, they are invaluable. In all my work with microcontrollers to date, my goal has been to learn how to use them for rather simple, somewhat dedicated tasks. They are ideal for such, the SX even more so than the Stamps . . . but the Stamps work wonders in my machines, as well. They are just not SXs or, much less, computers.

It is good to know that an SX will allow me to reduce my parts count because of its speed and interrupt structure. I have a robot with Stamps that talks to my laptop via Bluetooth. It is in its infancy, though. Sometime this winter, it will not only be run by the laptop (hopefully, if I have the time), but will create x,y coordinate maps which will be stored via WiFi on my terabyte disk storage device. All the maps which are of the same area--such as the den--will be available to the laptop during the robot's operation. I have a very special "thing" that will only run on a computer which will make quick work of comparing the gigabytes of maps to provide the robot with the "good enough" points. From this compilation of maps resulting in good enough points, the robot should be able to navigate fairly well. The more maps the robot creates, the better the resolution available and the more accurate the good enough points.

Hope it works. Eventually, I want it to cut my grass.

Practical information on SX versus Stamp speeds: The SX in turbo mode runs 1-for-1 so a 20MHz clock means you're running 20 MIPs.  The Stamp, on the other hand, has to fetch and decode a token from its EEPROM -- this process takes about 75-150 microseconds; in that time the SX running at 20 MHz can run 1500 to 3000 instructions.  
Just for fun I ran the same program through a stock BS2 (20MHz resonator) and an SX28 running at 20MHz.  Both programs define a pin called LED and toggle it with this simple loop:

Main:
  Led = ~Led
  GOTO Main

The cool thing about the SX's speed is that with it we can create virtual peripherals -- this means we can create a receive UART and not have to be sitting on a SERIN when serial data shows up; we can even buffer it in case we're busy (I do this all the time).

Hello All
I'm glad to see that I'm not the only newbie to the SX-- chips. I struggled at first as I only had the SX-Blitz.(Parallax was out of SX-KEYs when I placed My order for the SX28) With no debug window, This really made things difficult, and I pretty much ditched the SX28.

Then I got lucky, and I mean lucky. I got and SX-Key (FREE), With this I have studied the Debug window and I can make out the architecture of the SX chip. from there I can see memory map, and program flow on a binary level, along with a lot of other info.

The best thing about the SX28, is the SXB compiler___Its in BASIC___the user decides how ASM goes in to it if any!

My suggestion is to use the EXAMPLE programs. Start with the LED BLINKER and study the DEBUG window, Make some changes and see what it does in the DEBUG window.

As a quick tip - if you don't have the KEY, or if (like me), you are sufficiently poor at electronics that you don't want to trust anything you have walked past with a soldering iron then SXSim is an absolutely BRILLIANT learning tool.

Essentially it is a software version of the SX - you can watch all of the instructions execute and the registers change - AND you can play with the inputs / outputs of each pin simply by clicking with a mouse.

JonnyMac and $WMc% and David--
JonnyMac, thank you very much. I had read about the EEPROM fetch, but had not factored it into my thinking. Obviously, using the SX in projects that are able to take advantage of its greater speed and interrupt capability puts one in a whole new world of microcontrollers.

$WMc%, one reason I like SX/B is exactly what you implied; it is a great way to learn the instruction set, which I intend to do. (By the way, I used to run a Sox and Martin Superstock hemi in a '70 Baracuda. Although the engine was pure drag race, I also cruised with it on the street trying to find the unwary rat. It was a rat-eater, even if the rat was wrapped in fiberglass.)
David, there is no doubt that I am "sufficiently poor in electronics!" Thanks for the SXSim tip.

Alright... so I didn't get any PMs or offers for mentorship (I wouldn't want to be stuck with me either hehe)...

I guess I'm just going to have to annoy you good folks with my questions! Yay for you!

Ok... This is an outline of what I want my SX-based project to do. If you wouldn't mind, can you tell me if all this is indeed possible with one SX chip and point me in the
direction of the proper reading materials on how to do it?

First, I want to have the SX monitor two IR wheel encoders, two IR transmitters/receivers and a Ping... also to PWM four motors.
I'd also like the SX to act as a kind of a serial repeater. I will be connecting two BS2s to the thing and they are single tasking, so I'd like the SX to receive any serial signals
then repeat them over and over until the receiver BS2 sends a signal to show it received the serial transmission.
In addition, if possible, I'd like to slap a couple more sensors onto the SX's table and have it monitor those too.

I see that SX/B 2.0 has a 5 limit to its new Task ability, but I'm sure there's some way to get at least most of that working.

I also want to repeat that I have no intrest in learning assembly, which is unfortunate since I've seen examples of everything I've asked for written in assembly.

Anyways, I'd appreciate some feedback if some of you SX gurus have time.

[Quoting: "Ugha"]I also want to repeat that I have no interest in learning assembly...

FWIW, I don't see SX/B as BASIC for the SX, I view it as a programming framework.  I'm not (nor will I ever be) a full-time Assembly guy and thanks to SX/B I don't have to be; I can add it in where it's helpful.  By studying the output from the compiler and using Guenther's book and sources like www.sxlist.com I've learned enough to get my SX/B programs to do what I need them to do -- things I could never do with a Stamp (and I'm a pretty good Stamp programmer).

In my opinion tasks are not the solution to your problem.  Tasks are not designed to eliminate doing interrupt-driven stuff; in fact, task timing is a derivative of the interrupt timing so you must have basic understanding of interrupts before deploying tasks.  Before you do, however, know that tasks add a very big chunk of overhead to the program; oftentimes it's easier just to do the "task" inside the interrupt.  There are exceptions, of course.  Bean has a cool little example SX Boe-Bot program that uses tasks to read a Ping))) sensor and update the servos.

Your program, though, wants to do a great deal more.  Even the serial repeating part is moderately sophisticated and not something you can cleanly do with high-level SERIN and SEROUT while at the same time sending PWM signals to four (!) motors and monitoring encoders, too.  Man, that's a lot of stuff going on.  Perhaps Peter Verkaik or Peter van DerZee [sp?] will chime in as they are both very advanced programmers that do a lot of sophisticated real-time programming.

For grins I've attached an example starter program -- it should let you buffer the communications between two Stamps (running at the same baud rate and using flow control).  The foreground has control of moving data between the RX buffer and the TX buffer; this lets the foreground selectively gate communications between the two Stamps.  
I've also added in PWM control for four outputs.  The way the PWM array is setup you can do this:

speed(3) = 128
... which will set motor 3 to 50%; everything else happens in the ISR so you don't have to think about it.  
Perhaps somebody smarter than me can come up with a way of doing this sans Assembly... but I really don't think it will be as effective.  I say this because I work with SX/B every day (I design products for EFX-TEK with the SX and program them in SX/B) so I'm always looking for the easiest, yet most effective way to get something done.  My focus is always the "what" (product performance) not the "how" (BASIC vs Assembly vs C, etc.).

Good luck with your project.

PS: I'm not really into robotics so I didn't have any encoder stuff to drop in -- perhaps Robert Doerr can help out on that part; he does really cool robotics stuff with the SX.

JonnyMac--


This s a very curious thread

I agree but for a totally different reason. What happened to my rather lengthy post which was immediately after Ugha's last post? The sequence should have been Ugha's post, mine, then yours. Mine simply disappeared. Could it have been magic?

It is indeed strange and wierd and upsetting.

JonnyMac--

In the great scheme of things, my post was unimportant. Your's and other's will be of far more help to Ugha. Besides, I can recreate mine, more or less.

Later!

Ugha--
Why not take a huge load off the SX by using HB-25s to control the motors? They are very easy to use and the support is excellent.

[Quoting: "Ugha"]Ok... This is an outline of what I want my SX-based project to do. If you wouldn't mind, can you tell me if all this is indeed possible with one SX chip and point me in the direction of the proper reading materials on how to do it?

First, I want to have the SX monitor two IR wheel encoders, two IR transmitters/receivers and a Ping... also to PWM four motors.  I'd also like the SX to act as a kind of a serial repeater. I will be connecting two BS2s to the thing and they are single tasking, so I'd like the SX to receive any serial signals then repeat them over and over until the receiver BS2 sends a signal to show it received the serial transmission.  In addition, if possible, I'd like to slap a couple more sensors onto the SX's table and have it monitor those too.

- Are the encoders full quadrature encoders or just a single channel on each one.  In other words are you trying to capture both speed/direction or just the speed?

- Since you mention two encoders yet want to control four motors it sounds like two are set aside for drive wheels and need encoders (the others for something else) or you have two motors per side.

- What are the IR transmitter/receivers for?  Receiving IR commands from a remote?  Object avoidance? Or something else?

- Is the PWM to drive servos (or Servo like) signals?  Or, is it just to vary the duty cycle for speed control with another pin for direction?

- How many serial ports (in/out) do you need?

- What other sensors are you planning to add?

- Are the IR devices and extra sensor somewhat intelligent (maybe their own processor) or are they dumb or raw sensors that the SX will have to process??

Without answers to those it is hard to select any processor.

The SX chips are very capable chips and you may be able to get most of it in an SX48.  The SX48 also has a pair of 16-bit timers that you can leverage to drive H-Bridges, IR, or sensors.

If you read SERVO I had a few articles that used the SX chips.  Most of them were used as intelligent peripherals and in that regard it is a better fit than the Propeller since the SX is ready to immediately while the Prop has some latency as it starts up when it reads the contents of the external EEPROM chip.

In particular the July 2008 issue of SERVO had an article on Encoder matching where an SX28 keeps track of a pair of quadrature encoders and can also accept serial commands from another host.  It was a nice solution to use hi-res encoders with a legacy controller that was used to a low-res encoder.  In the May 2008 issue I used an SX48 to watch a quadrature encoder to perform closed loop control of a motor (could easily control a pair) and it used a standard LMD18200 H-Bridge to drive the motor.  The built-in HW timer generated the PWM for the motor.  The SX48 also controlled extra lights and other stuff with room to spare.  It just accepted commands from an old HandyBoard controller.  The whole setup was pretty slick.  It was controlling the head of the robot where the encoder was directly attached to the head with a slip clutch on the motor to allow the head to be turned.  Upon power up it would initialized the head and center it (another IR detected the center).  You could then just send the position you wanted it to point to and the controller would ramp up/down the motor and hit the spot every time.  If you turn the head manually it will automatically move it right back where it is supposed to be.  I added some code on the host to watch for it and if you turned the head a few times the robot would start telling you to 'STOP IT!'
There was also another SX project in the December 2007 issue which used an SX28 to help impersonate an SC-01 speech chip.  There are parts of all three articles you may find useful.

If Parallax ends up making another volume of the Nuts'N'Volts of the Basic Stamp series maybe they will want to add some of these example projects as well since several articles in the later volumes were targeted at the SX chips.

JonnyMac:
I want to apologize if I gave the wrong impression. I didn't mean to sound rude or insult assembly programmers.

The reason why I first purchased the SX tech kit was because I was under the impression it could be programmed in C (a language
I feel quite comfortable with as I've used it for many years).

Unfortunately I later (after having received the kit) found out that the compiler costs quite a bit of money. I guess I should have
done a bit more research.

Afterwards I had assumed that SX/B would be a viable language that's close enough to PBASIC that I don't have to go through
the process of trying to learn something totally new from scratch (And I've always heard horror stories about how hard it is to
do assembly, and my few attempts at learning it has pretty much proved the stories true, at least in my case).

If I understand you correctly, the SX pretty much requires knowing assembly if I want to go beyond blinking an LED or pulsing
a servo?

Is this due to speed issues (because I'd think I could just run the chip at a higher clock to make up for that) or because SX/B
isn't complete enough to contain all the abilities of assembly?

I don't mean to sound confrontational, but up til now a draft of Practical SX/B (No assembly required!) which, unless I misunderstood it,
is written by you... has been my SX bible and my one shining hope of digging myself out of the complexity of assembly.

Again, I don't mean to be rude or be one of those annoying newbies that question and argue with the people who ACTUALLY
KNOW what their doing (aka, You) but I'd just like to know if I am doomed to face the firing squad of learning yet another (and far
more difficult) programming language.

PS: Thank you for the program... I THINK I mostly understand it.

PPS: I love your book :)
Bill Chennault: I have no idea what happened to your post. Internet grimlins?

[Quoting: "Ugha"]If I understand you correctly, the SX pretty much requires knowing assembly if I want to go beyond blinking an LED or pulsing
a servo?

Is this due to speed issues (because I'd think I could just run the chip at a higher clock to make up for that) or because SX/B
isn't complete enough to contain all the abilities of assembly?

You can write powerful programs using SX/B by itself.  When you have it do multiple things (like receive Serial data in the background) it is more efficient to use some direct inline assembly code.  JonnyMac has some excellent routines that work great and you can pretty much drop them in your program without learning all the intricate details of assembly.  Just focus on the BASIC portion.

SX/B just converts your program into assembly which then gets compiled.  If you start taking a peek at the interim output you can see what each BASIC statement breaks down to be in assembly if you like.  It is just more efficient sometimes to tweak the assembly code to optimize portions of the program.  In regards to the ISR based serial code just treat it as a canned subroutine and forget that it is in assembly.

Most of the projects I've done were with SX/B and I've found it to be fast enough.  They were clocked at either 4Mhz or 20Mhz.  So far I haven't needed to bump it up to 50Mhz since speed hasn't been an issue.

Ugha--

I have no idea what happened to your post. Internet gremlins?

Gremlins. No doubt. (It couldn't possibly have been stupidity on my part . . . could it?)
I have cut a little code in SX/B and found it no more difficult than PBasic. I say go for it and use SX/B.

Oh, I wasn't offended at all -- just trying to [humorously] point out that you're attempting to win the Indy 500 in Volkswagon! ;)
Maybe it's because I started with BASIC but I don't get wrapped around the axle with SX/B.  Honestly, in the beginning I never used Assembly -- but finally got to the point where NOT using it was more of a penalty given my goals; I think that's where you are, too.  SX/B was designed to bridge the gap for those that want to move from pure BASIC to Assembly or, as many of us do, a mix.  Again, I see SX/B as framework, not a language.  I've learned a lot by writing very short program segments and looking at the compiler output.  Bean is a very good programmer and reveals a lot of cool tricks in the context of compiled SX/B (and when others point out new cool tricks he is very fast to implement them so the compiler is always getting better).

To answer your question, no, you don't have to learn assembly to program the SX.  For example, I've attached the code for the EFX-TEK RC-4 (we developed this when were were still at Parallax).  It's a commercial product, we sell a boatload of them, and it's 100% SX/B -- no assembly.  This was written at the time when I didn't want to know anything about Assembly and SX/B gave me a tool I could work with.  The DC-16 has similar code.  But when we got to the FC-4 (a 120 VAC lamp dimmer) there was no choice -- given my programming style -- but to suck it up and use Assembly for the UARTs and the triac PWM code.  Now that I'm comfortable with Assembly I routinely drop little bits into my programs; the beauty of SX/B is that I can mix and match to my heart's desire -- I'm not constrained by the compiler.

SX/B has changed so it has required a lot of rewriting of Practical SX/B -- and the "No Assembly Required" subtitle has been dropped (the later chapters have lots of pre-canned assembly stuff integrated into the programs).  I'm not going to give a done date because that has killed me in the past, but Bean will confirm that I've been sending him a lot of material for technical review.  Capt. Quirk has done a outstanding job with his links thread and that will give you everything that's out there.  I've been using the SX for the past 2+ years in my Nuts & Volts column and Robert Doerr has written some great articles for Servo (you should snag them as they pertain to robotics).  Look at recent projects in my column and Robert's work to get the most of SX/B.    There are only a few 2.0 features that I routinely use and they're advanced memory management tricks -- you probably won't need them for for a while (so don't wait to learn them to start on your project!).

Keep in mind that we we're all new at some point.  Use books and articles as guides, but at some point (sooner is better) you gotta dive in.  We can read about kissing our mate but there is nothing like the real thing! -- I'm suggesting that experience is a teacher you should not ignore or push off for some later time.

Experiment!  Have fun.  When you get stuck, ask questions -- there are a lot of great programmers here that have helped me and others; if you put in a little effort (I know you will) they'll happily help you, too.

Good luck.

I'm new to the SX as well.   My experince has been that ASM was easier to learn the SX/B.  I'm just now getting around to learning SX/B.   The SX only has hand full of instructions to learn. and isn't as troublesome as you might fear.   So my two cents are dont fear ASM,  Gunthers book makes learning it a snap.   I think you'll find with the number of VPs your looking at needing ASM may be in your future, but its not as bad as you may fear.   Putting ASM in SX/B seems to be a snape so you can use Basic for the more complicated bits, and asm for the parts that realy need it.

RobotWorkshop:
I apologize for not replying to you earlier, I guess you posted while I was writing mine.

I'll address your questions and concerns in the order you ask them...

The encoders are single channel encoders. I'm going to use them to keep track of the tracks
on my robot and use the information for a crude form of PID.

The two motors with encoders are for my tracks, the other two will be much more rarely used
and control the robot's forearms.

I have a pair of encoders on each arm of the robot that I will be monitoring with a BS2,
two IR transmitters/receivers for forward ranging and crude motion tracking and I'll also
end up with two IR transmitters/receivers (Either a slot interrupt or maybe a homemade one
using the IR pair that comes in the boebot kit) for the encoders mentioned above. I'm also
toying with the idea of using a super-bright LED and CDS cell instead of IR encoders for
the tracks (which will, of course, require RCTIME to monitor the resistance).

The PWM control is duty cycle for the motors. I have the four motors connected to two
SN754410 H-bridges and I intend to PWM the enable pins on the two chips to control the
speed of the motors.

At this time I'm planning on connecting two BS2s with the SX. One BS2 will handle all
the I/O that I can't place on the SX, the other will be the "brain" and will contain
the scripts and limited AI actions for the robot.

So I'll need the SX to buffer data from and to two sources.

I'm not quite sure what other sensors I may end up adding. A PIR is possible but I haven't
decided for sure what I'll end up doing.

The IR devices and sensors are pretty dumb, excluding the Ping of course. (which does require
some math on behalf of the SX).

I've already a couple of SX28s and I'd like to try to use them. Do you think my application
is too intensive for anything but a SX48?

Unfortunately I've never subscribed to Servo although I may eventually.

Your applications sound great, I'd love to check them out. If I do sign up for Servo, I'll see
what the back issues cost.

Some notes, I don't mind if there are some brief sub-second delays between serial transmission.
In fact, besides the PWM speed control and syncing with the encoders to keep the path
straight, nothing requires exact timing. This is just for fun, not a professional job.

I am willing to offload some more work from the SX to one of the two BS2s if needed, what
time each job (PWM, serial buffer, ect) takes, which one is better suited to which processor,
is something I have no clue about and one of the things I need help with.

Peter Verkaik:
That's great! I'll check it out, thanks!
Do you know if its complete? As in I can do everything with it that I can do with SX/B?

RobotWorkshop (again):
That makes it a lot clearer, thanks!

JonnyMac:
Great to know you weren't offended.

I'm sure I speak for the masses when I say that your book is much anticipated!

I think I'll use the program you attached earlier as a starting point and attempt to write
my own as a learning experience. If I fail horribly, if you don't mind, I'll just go back
to yours with a few tiny tweaks and maybe bug you a little to explain a few aspects.

A few questions for everyone if you don't mind:

1> I read somewhere (I don't remember where) that using the internal clock for serial communication
is bad. Why is this? Is there a way around it?

2> How can I tell how long something will take? IE: How do I know how long it will take to pull
a line high, or to send a serial string? There are a few lists out there for approx duration
of the various PBASIC commands. Is there something of the like for SX?

3> I read that an increased clock speed increases the current usage and will drain batteries
faster. Is this a great increase in usage and is the difference linear?

4> Is there a resource out there for "canned" functions I can do the whole copy and paste thing with?

Thanks again everyone!

[Quoting: "Ugha"]
That's great! I'll check it out, thanks!
Do you know if its complete? As in I can do everything with it that I can do with SX/B?

1) The internal clock is just not accurate enough for reliable serial comms.

2) You can count cycles or use Guenther's SX/Sim.  If you're using buffered serial it's mostly a "don't care" as it's happening in the background (unless you have a full buffer).  When using straight SEROUT it takes 10xbit_time to send a byte.  Bit time is 1/Baud.  At 2400, for example, the bit time is 416 microseconds and a full byte takes 4.16 milliseconds.

3) True, but you'll find a balance.  20MHz seems to be good for battery-run apps (all BS2 Stamps run 20MHz or faster).

4) There's www.sxlist.com, but you'll have to do a bit of touch up to incorporate the code found there into your SX/B programs.  I really don't think there's any true "plug and play" solution, though Peter Verkaik's very advanced approach to programming may come the closest.

Quick question... are 2d arrays allowed?

Nope.

[Quoting: "Ugha"]The encoders are single channel encoders. I'm going to use them to keep track of the tracks on my robot and use the information for a crude form of PID.

The two motors with encoders are for my tracks, the other two will be much more rarely used and control the robot's forearms.

For the arms I would probably add the full encoders as well and at least one limit switch for the home position.

[Quoting: "Ugha"]I have a pair of encoders on each arm of the robot that I will be monitoring with a BS2, two IR transmitters/receivers for forward ranging and crude motion tracking and I'll also end up with two IR transmitters/receivers (Either a slot interrupt or maybe a homemade one using the IR pair that comes in the boebot kit) for the encoders mentioned above. I'm also toying with the idea of using a super-bright LED and CDS cell instead of IR encoders for the tracks (which will, of course, require RCTIME to monitor the resistance)

[Quoting: "Ugha"]The PWM control is duty cycle for the motors. I have the four motors connected to two SN754410 H-bridges and I intend to PWM the enable pins on the two chips to control the speed of the motors.

[Quoting: "Ugha"]At this time I'm planning on connecting two BS2s with the SX. One BS2 will handle all the I/O that I can't place on the SX, the other will be the "brain" and will contain the scripts and limited AI actions for the robot.

So I'll need the SX to buffer data from and to two sources.

I'm not quite sure what other sensors I may end up adding. A PIR is possible but I haven't decided for sure what I'll end up doing.

The IR devices and sensors are pretty dumb, excluding the Ping of course. (which does require some math on behalf of the SX).

I've already a couple of SX28s and I'd like to try to use them. Do you think my application is too intensive for anything but a SX48?

- The SX48 has more Program space/RAM (only important if you are running out on the SX28)
- The SX48 has more I/O (useful if you are running low on pins)
- The SX48 has two 16-bit timers vs a single 8-bit timer.

I use both!

[Quoting: "Ugha"}Unfortunately I've never subscribed to Servo although I may eventually.  Your applications sound great, I'd love to check them out. If I do sign up for Servo, I'll see what the back issues cost.

[Quoting: "Ugha"]Some notes, I don't mind if there are some brief sub-second delays between serial transmission.  In fact, besides the PWM speed control and syncing with the encoders to keep the path straight, nothing requires exact timing. This is just for fun, not a professional job.

I am willing to offload some more work from the SX to one of the two BS2s if needed, what time each job (PWM, serial buffer, ect) takes, which one is better suited to which processor, is something I have no clue about and one of the things I need help with.

It's good to think about the whole picture and how you want it to fit together but you may want to start prototyping each section, get that working, and then see how you want to combine them.

I don't understand why I'd need speed and direction.
If I'm signalling my H-bridge to go forward, why do I need to know that its going forward? I can imagine if it were coasting or something of the like, but I don't understand it on a smallscale
robot on which I will know the direction I command it to go.

Ugha--
These guys know far more than I ever will. HOWEVER, whenever Ugly Buster's motor controller's received a command to instruct a motor to turn in this direction or that direction, it ALWAYS did. Having a quadrature encoder report that fact would have been a huge waste of time.

A quadrature encoder would be just the ticket to DISCOVER which way a motor was turning. But, as far as I have ever been able to figure out, in the machines I have built, anyway, direction feedback is totally useless in the drive mechanism.

All of my gear motors have quadrature encoders. I only use a single channel. A single channel provides data that may be accumulated thereby yielding position information assuming no wheel slippage. An appropriate motor controller, operating under nominal circumstances, sets the speed.

You should get both because without it you don't really KNOW which way it it moving.  You just see pulses and ASSUME it may happen to be going the direction you want/expect.

The other reason is accuracy.  Even if you are going to control the speed how are you going to determine how far you've gone?  By factoring in the direction you can get a much better idea on how far each wheel turned.  Besides it seems to make all the calculations easier.  
If you are just putting a low resolution encoder disk directly on a slow moving wheel then you can probably get by with just using a single channel for regulating speed.

There should be a quadrature example in the SX/B help file which can give you an idea how they are to work with.

Hi Bill;
In regard to using just a single channel of a quadrature setup, this can easily pick up extra pulses on the edge transitions. Just park a unit at the critical switch point and watch the counts accumulate due to noise or vibration. To ensure accuracy on the counts, you must take care of that in software, and this my be easy or more difficult, depending on speed of the pulses. Alternately this can be more easily and totally reliably handled in quadrature. That's why those encoders were invented. And inherently they give direction to boot.

If you don't care about inaccuracy, then a single channel will do. Only you can decide what is good enough.

robert and pjv--
You have certainly given me something to contemplate and, just as certainly, I appreciate it. It is, perhaps, that my machines are designed to operate indoors and, hence, ARE slow moving. Therefore, I "get" away with it.

I still don't understand how one might instruct an HB-25 to move in one direction and it MIGHT move in the opposite, though. Is it because of false inputs on floating pins which may be caused by real inputs on adjacent pins?

Thanks!

That's not what PJV means -- especially at "slow" speeds, the transition from 1->0 or 0->1 on an encoder will "jitter" -- I am having this exact issue with a single (rather than quadrature) encoder on a big 'bot. The quadrature encoding means that *always* when one encoder is crossing an edge, the other is in the middle of a stripe, so even if the edge is bouncing "back and forth" the "click" count is maintained -- basically the count will jiggle up and down during transitions, and remain accurate. With a single encoder, you accumulate counts without knowing direction (i.e. that wheel is jittering at the edge). Regardless, if it works, it's good!

Zoot--
My robots have experienced jitter just as you described. This did not happen often, but I could not account for it until now. Thanks!

I all my gear motors have quadrature encoders of which I use a single channel. Is it also possible to double the resolution by using both channels?

Bill -- Whether or not you get better resolution depends on how you've been treating the single encoder click counts. Regardless, you will certainly  get more stable and accurate counts. If you are taking full advantage of *every* edge with single encoder, that's where you get the errors (when the wheel is physically jittering there is no way to know if the edge is moving past or moving back and forth).

The solution, at trade off of halving your resolution, is that you only count the "click" you get two white-to-black edge changes in a row (or the opposite). A white to black edge change followed by a black to white edge change would be jitter (unless it is followed by a another "perfect" black to white edge change, in which case it's a direction change -- and as you point out, on a heavy 'bot you would theoretically "know" that you changed direction because you told your motors to do it.

In any case, that was my thinking when I was lazy and didn't build quadrature encoders. Now I wish I had - the firmware of counting quadrature is much simpler, actually, and in the long run I'd have probably saved a lot of time and hassle.

To come full circle, there is already a quadrature encoder example in the SX/B documentation (help file). It's a perfect project to get going with an SX -- making a simple peripheral that counts your encoders, maybe does some light pre-processing on them (i.e. "pre-chew" numbers for direction, distance, total distance, etc, so your Stamp(s) don't have to do the work) and deliver it ready-to-go to your host. I do recommend serial tx/rx (SERIN/SEROUT) for communication. It's easy and there are a wealth of examples for both the Stamp and the SX. This way your host can send a string using SEROUT like "!GENC" (get encoders) and expect, say 9 bytes back with current distance and speed (as words) for each motor, plus a byte of bit "flags", motor moving/not-moving, motor direction, for each motor.

Zoot--
Thank you for the detailed reply. I will definitely check out the SX/B help file. For some reason, when I wrote the program that blinked the LED, I did not get very deeply into the help file. :)
Ugly Buster weighs just south of 26 pounds.

Hi Bill;

Actually quadrature operation gives double the resolution of a single channel.

At any instant, with quadrature there is one of 4 possible states.... lo/lo  hi/lo  lo/hi  hi/hi. And the encoder moves through all four of them in one physical cog, and each of them can be detected by the micro. The "forward" sequence is  lo/lo  to  lo/hi  to  hi/hi  to  hi/lo  to lo/lo  and the "reverse" sequence is (not surprisingly)  lo/lo  to  hi/lo  to  hi/hi  to  lo/hi  to  lo/lo.
Four phase states per cog. And the "direction" is determined at any point by comparing the current state to the previous state.

Attached is a state machine implementation of a quadrature encoder for you to peruse. Assemble it and single step through it with the debugger or SXSim to see how easily it works.

The state lookup table is made up of all the possibilities of the previous state combined with the current state.

  
  
Assume RA.1 and RA.0 are inputs and connected to the two quadrature channels 
Assume varable Prev holds the state of the previous sample. 
  
Loop         rl   Prev 
             rl   Prev                ;make room for the new sample coming in 
             and  Prev,#%0000_1100    ;get rid of any carry-ins and older samples 
Sample       mov  w,RA                ;get new sample to w 
             and  w,#%0000_0011       ;disregard all except the two state bits 
             or   Prev,w              ;merge new sample in with previous sample 
             mov  w,Prev              ;get old/new state pairs 
             call Lookup              ;lookup same/forward/reverse in Prev/New state table 
             add  Position,w          ;update position by one... positive or negative 
  
     (delay here to set he speed you want to sample at) 
  
             jmp  Loop                ;get next sample 
  
  
Lookup       add  pc,w                ;jump into table and return with +1 for forward, -1 for reverse, and 0 for no change 
  

P00N00       retw 0                   ;no change 

P00N01       retw 1                   ;forward 

P00N10       retw -1                  ;reverse 

P00N11       retw 0                   ;impossible 

P01N00       retw -1                  ;reverse 

P01N01       retw 0                   ;no change 

P01N10       retw 0                   ;impossible 

P01N11       retw 1                   ;forward 

P10N00       retw 1                   ;forward 

P10N01       retw 0                   ;impossible 

P10N10       retw 0                   ;no change 

P10N11       retw -1                  ;reverse 

P11N00       retw 0                   ;impossible 

P11N01       retw -1                  ;reverse 

P11N10       retw 1                   ;forward 

P11N11       retw 0                   ;no change 

  
  
Cheers,
Peter (pjv)
 

I've attached my first SX/B program.

It compiles fine and I think I've got the logic right, but at this time I haven't tested it (I'd have to wait til tomorrow or the next day for various reasons).

I tried to figure out SXSim but its all greek to me.

Consider it a rough draft or outline. I have attempted no speed management and all issues of speed (Duration on PWMs, serial timeouts, ect) are random placeholders because I've got to gather a great deal more information (How fast can a BS2 go from reading an input to receiving/sending serial, ect... and how long it takes an SX to do various tasks).

I've attempted to create my own crude task engine to split up the various jobs the SX will have to do.

I may even end up rewriting it without using the ACK1 and ACK2 lines, just a single serial line to all three chips.

What I'd like is suggestions on how to include interrupts to prevent the SX from having to wait on the BS2s all the time, as well as advice on better methods to accomplish this without use of assembly.

I understand I'll eventually have to learn assembly, but for now I'd like to stick with SX/B... even if it is slow or takes a lot of work-arounds.

Peter--
Thank you very much for the detailed explanation and the code!

I posted a framework earlier that will handle the serial IO and motor PWMs for you, all you have to do is add in your foreground logic.  When you use inline SERIN and SEROUT you're consuming a lot of time and this will create problems for your application, especially since you want to have speed control over motors.  On that... the PWM command is great from charging RC circuits (analog output) and dimming LEDs, but not so great with motors; the reason is that it only run while the instruction is active so your program will just be sending PWM bursts to the motors; probably not what you want.

I've attached an encode demo that is from an old Parallax AppNote for the PIC -- I just coded it to my particular style.  Since you want two encoders I wrote the program with two and have tested them using a parallel LCD.  Works just hunky-dorey.

Notes:

JonnyMac:
Thanks for the input... the reason why I didn't use anything from your previous code samples is because I wanted to learn the actual SX/B language somewhat before I did the whole
copy and paste thing.

I will, of course, examine your samples closely and will most likely use elements from all of them.

I also appreciate the tips. I wasn't aware of SUB/ENDSUB and the like beforehand (I checked, the helpfile doesn't mention them).

Question... do you think I'm trying to do too much with the SX at my beginner stage? Should I offload the PWM of the four motors to one of the stamps?

Finally, I hope your not getting annoyed with me...
Most people would be quite happy just using your code and moving on to something else. I'm a little different, I want to UNDERSTAND every aspect of my project.
Including the code you've provided. So I guess you could say I'm doing it the hard way.

Time for my first annoying questions...

I can't seem to get one of the example programs you've provided to compile.

First, the Ugha_Robot.SXB you made for me has 27 errors...  To start with is:
speed                VAR                pwmCtrl(0)                ' 0 (stop) to 255 (full)
Is giving the error INVALID PARAMETER "("
Each line that has pwmCtrl(0) in it is also producing the same error. There are several other errors after it but I'm assuming it all has to do with the same thing.
At first I assumed my compiler was outdated, so I upgraded from v1.50.1 to v1.51.03 with no difference in the errors.
I honestly don't see what's wrong with that or the surrounding lines... therefore the problem must be something on my end.

Any idea what it might be?

Also related to the same area... I'm confused.
acc1                VAR     pwmCtrl(9)
This aliases acc1 as the ninth element of pwmCtrl if I understand it correctly... but you only have pwmCtrl defined with 8 elements.
Am I missing something?

"Too much" is in the eye of the beholder -- you'll decide that.  With the programming experience you have there's no reason you can build your project, just do it a step at a time.  You may have noticed that my code samples are somewhat modular.  They're not exactly plug-and-play but they're close enough that I can integrate a module into a new program, do the necessary tweaks for the project at hand, then move forward.  No matter how many samples you get from me or others your involvement will be required.

Like you, I used code from others but spend time learning it, understanding it, then making it my own.  The PWM code, for example.  Guenther's original version presets the output then turns it right back off if it is not supposed to be on.  I decided to add a few cycles to the routine to give absolutely clean output.  Of course, I could only do this after understanding how the original version worked.

If you're in the gift-giving mood give yourself a Parallax Professional Development board and Guenther's book -- you'll be repaid in spades with the hours of fun you'll have and the ability to quickly develop a new project.

I use the 2.0 beta -- download it from the sticky post at the top of the SX forum.

Whoops, there is an error; but I got away with something.  In the original program I declared pwmCntrl as eight bytes but then defined 12 elements.  Here's the rub: in the SX28 SX/B puts arrays of less than 16 elements into one contiguous bank, so the rxSerial array (defined after pwmCntrl) was set to the next physical bank in memory and didn't clobber the end of my pwm aliases.

Here's the compiler (2.00.08) output -- note how the aliases are correct despite my size error:

pwmCtrl          EQU  $30        ;pwmCtrl               VAR     Byte(8) BANK
speed            EQU  pwmCtrl+0  ; speed                VAR     pwmCtrl(0)
speed0           EQU  pwmCtrl+0  ; speed0               VAR     pwmCtrl(0)
speed1           EQU  pwmCtrl+1  ; speed1               VAR     pwmCtrl(1)
speed2           EQU  pwmCtrl+2  ; speed2               VAR     pwmCtrl(2)
speed3           EQU  pwmCtrl+3  ; speed3               VAR     pwmCtrl(3)
acc0             EQU  pwmCtrl+8  ; acc0                 VAR     pwmCtrl(8)
acc1             EQU  pwmCtrl+9  ; acc1                 VAR     pwmCtrl(9)
acc2             EQU  pwmCtrl+10 ; acc2                 VAR     pwmCtrl(10)
acc3             EQU  pwmCtrl+11 ; acc3                 VAR     pwmCtrl(11)

Rip, tear, dissect, toss what doesn't work -- I offer this stuff only as help as you may choose to use it.

Just a note regarding the quadrature decoder code that Peter (PJV) posted.  The function he wrote needs to be called at a rate that is higher than the fastest possible frequency the quadrature encoder will ever generate.  For example, if you have a 256 pulse per revolution encoder running at 1 revolution per second, it will generate a pulse train of 256 Hz.  Unless you have a very high resolution encoder, it's not hard to sample at a rate higher than the encoder will generate.  However, it's also important that the function be called on a regular and consistent basis.  If there is even a single gap between calls to the encoder function that is too long and you miss an encoder state change, then you'll end up missing a creating errors in the encoder count.

Other than these simple caveats, the technique Peter (PJV) showed is the best way to decode an encoder, and never worry about jitter screwing up the count.  It's especially nice for mechanical encoders as they also have switch bounce which is automatically taken care of by this technique.

Hi PJ;
I'm glad you brought that up.... you are abolutely correct.

As many on the forums here know, I generally run all my code in a multi-tasking manner under a very tight interrupt 1 to 10 uSec regime. I would therefore arrange to call this routine very cosistently at the appropriate speed, and never miss a pulse.

Given those real time techniques, I'm sure the things Ugha wants to do could all be readily handled by a single SX, and simultaneously to boot.  Unfortunately (or, depending how you look at it, fortunately) he would have to learn assembler.

It's all a matter of learning, and to squeeze the most out of an SX, assembler is an absolute must...... but all in due time.

PeterM and pjv--

Couldn't pjv's code be made into an interrupt service routine which would make itself known as often as necessary?

The use of the phrase "to call this routine very cosistently" is what confused me. It SEEMS to this newbie that you would not have to call it at all if it called you.

PJV uses a really interesting scheduling structure which means that the interrupt does one thing: it sets a marker that the interrupt has occurred; this is the base timing in the system and everything cascades from there.

I've been experimenting with this style folded into SX/B -- not there yet but having fun.  For grins I wrote an SX/B program that uses a modified version of PJVs encoder routine and a simplistic version of his scheduler.  Note that I'm not good enough with Assembly to know if RETW will work across page boundaries and as that could happen with the placement of the ENCODER subroutine I changed the table call to the READ+offset (I used the code generated by SX/B and tweaked it).

The attached program scans an encoder every 10us, updates eight LEDs with the position every 100us, and toggles and LED every 250ms.  It's happily running on my PDB so while perhaps not a perfect implementation of PJV's scheduling strategy, it is working.

Jonnymac,
retw tables must be in the lower half of codepages.
Good place is directly after interrupt routine, or after
initial jump to interrupt routine.
See attachement. This version should work.

Thanks, Peter, it does work.  Since the program is so small I added a line to force the ENCODER subroutine into another page -- still works.

Hi All;

Peter Verkaik... you are absolutely correct. Please do understand in my small example I was not trying to be perfect and deal with all issues and caveats, just the basic concepts for others to understand.

Jonny... nice going. However, nowadays I prefer to use a counter in the interrupt that I empty in the base of the scheduler. Reason is that running multiple fast tasks, on occasion one could (but should not) overrun the base counter, and hence loose a tick. Obviously this would cause jitter, and loss of total tick counts. With a counter in the interrupt, such cannot happen as all ticks are accounted for, albeit a bit skewed in time but a better solution because long term timing stays perfect.

Peter,
I'm trying to hybridize your scheduler strategy with the way I've done things in the past, that is, UARTS in the interrupt.  I study your state-driven UART and found that it uses fewer cycles per call (by design, of course) so I modified it a bit and stuck it back into the ISR.  So far, so good.  Working on the TX side now.  My intent is to use the scheduler to handle the enqueuing and enqueuing of serial bytes.

I've tested the attached program at 38.4k serial RX which is the design max.

Yay, I got the transmitter working, too!  While probably not as elegant or efficient as your setup, Peter, it seems to be working and I feel like I can do everything else within the context of the scheduler.  I would love to have a thread on your programming strategies -- I finally feel like I'm getting to the point where I can start integrating them into my own projects.

That is so short. Nice. I like the use of __INTOPTION as well.

I have one question for either JonnyMac or pjv --

    MOV   PC, txState                                ' else jump to state
'---
    MOV   txState, #TX_Bits                        ' update state

I was working on the assumption that the address had to be in the lower half of the code page which is why I moved the UARTs back into the interrupt.

The target address must indeed be in the lower half,
the mov pc,w instruction itself may be anywhere in the page.

Here is a tip if you ever want to move the code beyond page 0.

use MOV txState, #TX_Bits & 255 to suppress warnings "literal truncated"
It makes no difference in codesize.

Peter, Peter, and All--
Speaking of "working", here is a video of my implementation on the five processor Ugly Buster. This particular code--as everything I did with the machine--was very simple because I wanted to learn some fundamentals. All this code does is use the quadrature encoders to cause the robot to move straight forward and straight back to its starting place. The movement is ALMOST precise. (I have many of these videos, including ones taken outdoors on the grass, rocks, concrete, and snow should anyone want to see them. Most of these videos include Ugly Buster actually manuevering, like in turns and pivots! [Even in the grass and on rocks.])
http://www.billcnkc.com/Robotics/Ugly%20Buster/07-11-08-a.mpg[/u>
The]
Remember that Ugly Buster weighs about 25 pounds and that there is no use of SERIN/SEROUT to communicate between the slave processors (OEM-BS2s) and the master processor (BS2p40). In this video, the HB-25s are set to about the mid-point in both direction. It proved fast enough both inside and outside, whether it was carpet, my flagstone patio, grass, or snow. (I screwed up in the snow. It was wet and balled up. As soon as it passed through Ugly Buster's timing belt pulley and timing belt track, it compacted into a hard ball. Since I designed the track mechanism with no thought of a variable tension mechanism, a track was promptly thrown! (There are videos of all of this and more, but I do not want to bore anyone.)
Here is the code which runs on two OEM-BS2s that monitors the gear motor encoders on their sides of the machine . . .

Master_Send    PIN         0              ' This is the pin the Slave uses to re-
                                         ' port encoder events to the Master.
Shut_Down      PIN         1              ' If 1, shutdown the Slave.
Encoder_Event  PIN        15              ' The Slave detects encoder events on this
' -----[ Variables ]---------------------------------------------------------------
oldEncoder   VAR       Bit                ' Bit variable to save Encoder status for
                                         ' later comparison.
' -----[ Program Code ]------------------------------------------------------------
Main:
 DO
   INPUT Encoder_Event:INPUT Shut_Down   ' Get encoder event and see if Master wants
                                         ' to shutdown.
   IF Encoder_Event = 1 THEN
     HIGH Master_Send
     ELSE
       LOW Master_Send
   ENDIF
 LOOP 'UNTIL Shut_Down = 1
END
And here is the code that decrypts my five bit instruction set that controls the HB-25s that control the gear motors. I quickly figured out that I did not need all the capability that five bits gave me, but it worked and I was too lazy to change it. (The master sent this code two speeds (normal and "catchup"], which worked for me both indoors and outdoors.) It is important to note, that this code was controlled by the master processor, which in turn received information from the two BS2-OEMs concerning wheel counts. (Not speed, or direction, merely encoder counts.)


HB25                 PIN  15
' -----[ Constants ]---------------------------------------------------------------
command_array        VAR  Byte(1)          ' Set up a one byte array of eight bits.
                                                                       ' The "command set" for the HB-25 will use
                                                                       ' five of the eight bits. The high-order
                                                                       ' bit will indicate forward (1) or
                                                                       ' reverse (0). The low order bits will
                                                                       ' indicate one of 16 speeds specified in
                                                                       ' the table above.
Command              VAR  command_array ' The master's current command
oldCommand           VAR  Byte                    ' A byte to let us know when the master's
                                                                        ' command changes
' -----[ Initialization ]----------------------------------------------------------
' Wait for left HB-25 to power up . . .
DO : LOOP UNTIL HB25 = 1
LOW HB25                                                      ' Make I/O Pins Output/Low
PAUSE 20                                                        ' Wait For HB-25s To Initialize
PULSOUT HB25, 750                                     ' Stop the motor
'------[ Main Program ]------------------------------------------------------------
DO
 ' The following five statements receive and re-construct the master's command in the
 ' command array . . .
 command_array.BIT0 = IN4
 command_array.BIT1 = IN3
 command_array.BIT2 = IN2
 command_array.BIT3 = IN1
 command_array.BIT4 = IN0
 SELECT  Command
   CASE %10011                                            ' Forward, slow
     PULSOUT HB25, 795
     PAUSE 20
   CASE %11000                                             ' Forward, cruise
     PULSOUT HB25, 870
     PAUSE 20
   CASE %11100                                             ' Forward, catchup
     PULSOUT HB25, 930
     PAUSE 20
   CASE %00011                                             ' Reverse, slow
     PULSOUT HB25, 705
     PAUSE 5
   CASE %01000                                             ' Reverse, cruise
     PULSOUT HB25, 630
     PAUSE 5
   CASE %01100                                             ' Reverse, catchup
     PULSOUT HB25, 570
     PAUSE 5
   CASE %10001                                             ' Hard brake
     PULSOUT HB25, 535
     PAUSE 5
   CASE %00000
     PULSOUT HB25, 750                                  ' Stop
     PAUSE 5
 ENDSELECT
LOOP

I have not included the code for the master, since all the master did was act as the "personality" of the robot. In all cases, that personality was derived from the extremely simple things I wanted to accomplish as modified by the encoder counts, which determined position . . . very well on carpet! As soon as the machine was operated on another surface, slippage occured. With nothing but encoders as sensors, Ugly Buster never knew anything was wrong.

I do not know if implementing quadrature encoder code would have helped or not. However, I seriously doubt it. But, I am going to experiment with it, nonetheless. (Not on Ugly Buster; he is at end of life. I am in the process of building an SX operated machine, which I think will be a single processor device, that has Bluetooth onboard and is controlled via a GUI on my laptop using VB6.0. It is up and running now, although it does nothing more than blink LEDs on Ugly Buster. Blinking an LED is no different than sending a signal to an HB-25, though.

This code can doubtless stand a lot of criticism and I will appreciate every bit of it. But, remember that it was written for a multiprocessing environment. I had access to much of the code that would have made execution faster, but there was no need for it. Therefore, I sacrificed execution speed for clarity, which should always be done when appropriate.

I look forward to your feed back. I may defend this approach, but I have no ego. I am here to learn.

--Bill ps When I started with Parallax products about a year ago, I knew nothing about microcontrollers, although I had built robots as long as 30 years ago using Z80s. I learned everything I know from the kind folks on this forum and the the folks that work for Parallax.