Searching \ for '[SX] Learning SX/B' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/languages.htm?key=sx
Search entire site for: 'Learning SX/B'.

Exact match. Not showing close matches.
PICList Thread
'[SX] Learning SX/B'
2009\01\31@120909 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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!

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@163658 by tsaavikn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, tsaavik wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324617
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@170619 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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!

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324626
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@173636 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324633
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@175516 by Shawn Lowen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Shawn Lowe wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324641
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@184108 by Capt. Quirkn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Capt. Quirk wrote:

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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324653
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@185340 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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!


--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324657
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@191207 by Capt. Quirkn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Capt. Quirk wrote:

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

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324664
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@192307 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324666
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@194008 by dabaylissn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, dabayliss wrote:

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

Of course the above assumes you want speed ... A PAUSE instruction (or SERIN etc) will take just as long as on a stamp :)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324672
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@195127 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324678
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@195938 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324681
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@200113 by Capt. Quirkn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Capt. Quirk wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324682
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@202304 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324690
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@203459 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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

In the 'scope captures I've attached you'll see that with this program the SX28 is more than 1600x faster than the BS2.

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

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324693
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\01\31@224040 by WMcKILLemALLn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, WMcKILLemALL wrote:

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.

______________________$WMc%_________
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324725
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)


'[SX] Learning SX/B'
2009\02\01@052516 by dabaylissn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, dabayliss wrote:

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.

David
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324756
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\01@065804 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m324767
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@060351 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325384
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@100207 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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

This s a very curious thread; I read your posts and imagine a traveler saying, "I have to get from Los Angeles to New York in four hours but I won't step foot on an airplane!"
SX/B compiles to Assembly -- so does it matter if you receive code examples from those who will offer them that originate in Assembly?  If the answer is Yes then the Propeller might be a better solution for your stated problem (though the serial library for the Propeller is also written in 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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325445
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@102300 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.


--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325457
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@105630 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

Could we have entered the Twilight Zone?.... ;)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325471
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@113745 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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!


--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325484
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@125507 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325504
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@130827 by robotworkshopn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, robotworkshop wrote:

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


Hello,
In order to make suggestions in regards to which SX chip would work for your project it would help if you clearly define everything you want the chip to do.  It would also help to know more about the peripheral devices you intend to connect to the chip.  Here are some questions to get you rolling in the right direction....

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

Robert
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325507
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@131218 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325510
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@133514 by peterverkaikn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote:

Ugha,
Actually there is a free C compiler called CC1B.
Bob Senser has created an environment for it (Notepad++ works great)
cc1b compiles into sasm assembly so you can load it into the sxkey IDE
and you can use SxSim.
http://forums.parallax.com/forums/default.aspx?f=7&m=214117&g=218127#m218127
Don't forget to get the latest cc1b compiler:
http://www.bknd.com/cc1b/index.shtml
regards peter
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=324554#m325517
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@140337 by robotworkshopn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, robotworkshop wrote:

[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?


I think you've missed the point of how assembly and SX/B all fit together.....

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.

Robert
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325529
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@141013 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill Beset By Gremlins
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325530
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@142536 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325534
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@143523 by natpien/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, natpie wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325536
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@144342 by Capt. Quirkn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Capt. Quirk wrote:

http://forums.parallax.com/forums/default.aspx?f=7&m=310418
http://www.bknd.com/cc1b/index.shtml
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325538
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@144651 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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!

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325539
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@151603 by peterverkaikn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote:

[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?
Yes, it is complete. You can compile for all sx devices. You have all the possibilities
that sxb 2.0 offers, except for large arrays on sx18/20/28 (limited to 16 bytes).
But there are libraries written (by me and others), particularly the Task library
that offers the same as sxb tasks.
At the moment I favor sxb over c4sx because I don't like the way cc1b handles
local variables. It uses staticly assigned variables (not a real stack) so you
will frequently use #pragma to set a bank for new locals (this is not automated).
Also, in the libraries I wrote you will see lots of assembly too.
One big advantage of C4SX is that it natively supports libraries.

regards peter
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325549
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@154903 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325558
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@163111 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

Quick question... are 2d arrays allowed?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325570
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@170545 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

Nope.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325581
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@182713 by robotworkshopn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, robotworkshop wrote:

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


If you are going to keep track of the main drive motors then I would seriously consider using a full quadrature encoder on each motor.  It gives you speed and direction.  That will give you much better control since the micro can get you right on target.  With only one channel you only can tell if it rotates and just hope that it goes the right way.  A good source for encoders are the non-optical Microsoft and Logitech mice.  Also HP printers have some nice encoders.  Just find a matching pair of old inkjet printers.  I used them in my encoder article.

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)

You'll want to watch the resolution of the encoders to ensure it doesn't exceed the polling interval you use on the stamp.  Otherwise you will lose count since some may be missed.  That was the whole point of the July article on encoder scaling.  An SX28 sits in the middle to watch the encoders and adjusts the count so nothing is lost.

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

Using the SX chips you have some options.  You can simulate PWm within the ISR routine.  This would be fine for the SX28 or SX48 chips.  When using the SX48 it has a pair of 16-bit timers that can generate the PWM signals so that the ISR can do even more things without worrying about PWM too.  Any other I/O pins can be used for direction.  I was using an L298 which I made to use a SN754410 footprint so I've already written SX48 code that can look at encoders and leverage the hardware to generate PWM.  It hasn't been converted to SX/B 2.0 yet but it could be.

[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 main reasons for using the SX48 over the SX28 are:

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

You don't have to subscribe to get their back issues.  You can either buy the single issue or a CD by year with electronic versions.  Just checkout their website.

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


From what you describe it may be easier to spread out the functions across a couple processors.  I tend to use the SX chips as intelligent peripherals or for controlling the whole show on small projects.

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.

Robert
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325589
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@194213 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325630
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@211453 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325674
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@212903 by robotworkshopn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, robotworkshop wrote:

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.

Robert
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325676
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\03@232458 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

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.

Cheers,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325689
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@070212 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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!

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325724
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@070820 by Zootn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

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!

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325729
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@095155 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325764
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@101402 by Zootn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325773
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@102416 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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.

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325776
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@121109 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

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)


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325796
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@130000 by Ughan/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325808
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@140502 by ringlordn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

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

--Bill
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325825
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

2009\02\04@145137 by JonnyMacn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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:

  • You can use INC x instead of x = x + 1 (same for DEC)
  • When multiplying or dividing by powers of two (2, 4, 8, 16, ...) shift operators are more efficient
      -- use x = x >> 1 instead of x = x / 2
  • TASK is a keyword in SX/B 2.0 so you shouldn't use this as a variable name
  • Even though the compiler is forgiving you should enclose subroutines in SUB/ENDSUB blocks and functions in FUNC/ENDFUNC blocks
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325838
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)
  • 2009\02\04@154555 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    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.

    I guess what I'm saying is, I'll just have to crack down and learn a little assembly... if you and the others don't mind me annoying you with questions :)
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325849
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\04@162907 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    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?

    I'm very confused :(
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=324554#m325863
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\04@174142 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

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

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m325882
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\04@181003 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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)

    I fixed the program (with encoders folded in).  Note that the speed is 50MHz.  According to SX/Sim the ISR takes about 130 cycles (max) -- at 50MHz there 325 cycles between interrupts so there's plenty of time left for the foreground to do its thing.

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

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m325891
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\04@192253 by PJMontyn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, PJMonty wrote:

    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.

    Thanks,
    PeterM
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m325926
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@004015 by Peter Van der Zeen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

    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.

    Cheers,
    Peter (pjv)
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m325979
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@071336 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    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.


    --Bill
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326025
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@083023 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326044
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@092129 by peterverkaikn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote:

    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.

    regards peter
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326063
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@100856 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326081
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@123222 by Peter Van der Zeen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

    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.



     

    IntValue       equ    -100             ;2 uSec interrupt at 5o MHz .... use -50 for 1 uSec or -250 for 5 uSec
     
     
    Interrupt
                  bank   IntCtr           ;not required if you park the counter in global memory
                  inc    IntCtr           ;increment each time we have an interrupt tick
                (some code)               ;some VERY short time critical code (such as ADC code) is permitted here, depending on the size of your base tick
                  mov    w,#IntValue      ;reload interrupt with negative number
                  retiw                   ;return to scheduler (or app)
     
    Scheduler1    
                  bank   IntCtr           ;not required if you park the counter in global memory
    Scheduler2     test   IntCtr           ;test for non-zero
                  snz                     ;
                  jmp    Scheduler2       ;wait here until counter is non-zero. ie at least one iterrupt has occurred
     
                  dec    IntCtr           ;
                  bank   Timers           ;
                  decsz  Timer10uSec      ;
                  jmp    Scheduler2       ;wait for 10 uSec tick
                  mov    Timer10uSec,#5   ;reload 10 uSec timer with 5 2uSec interrupts. This value must be adusted for other interrupt values
     
                (your 10 uSec code -if any)

                  decsz  Timer100uSec     ;

                  jmp    Scheduler2       ;wait for 100 uSec tick
                  mov    Timer100uSec,#10 ;reload 100 uSec timer with 10 10 uSec ticks
     
                (your 100 uSec code -if any)
                  decsz  Timer1mSec       ;

                  jmp    Scheduler2       ;wait for 1 mSec tick
                  mov    Timer1mSec,#10   ;reload 1mSec timer with 10 100 uSec ticks
     
                (your 1 mSec code -if any)

     
                (rest of scheduler counters in the same manner)  
     
                  jmp    Scheduler1       ;
     
     
    Please realize this snippet is not complete... counter definitions, initialization etc. are required. But it should show the intended operating concept. I have not tested it, but I believe it is correct.

    Actually, I find that serial routines work just fine using a 20 uSec (5x oversampling at 9600) sample clock, and I can  run multiple receivers and transmitters at the same time (something of apparent interest to some posters here). Of course those MUST be non-blocking. IE do a little bit of work in each as required, and return to the scheduler.

    If enough others are interested I'd be happy to spend some time developing those and posting them here.

    Cheers,
    Peter (pjv)
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326141
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@135454 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326179
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@152021 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326200
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@155312 by Zootn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

    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

    When you move and address to a fr to the PC, I presume that's only 8 bits, so the addresses and the MOV PC must be in the lower half of a code page? Is that right? Of can you have the MOV PC and addresses in the upper half of a code page because the MOV PC won't set bit 8 of the PC anyway?

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326207
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@161452 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326216
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@163720 by peterverkaikn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote:

    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.

    regards peter
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326227
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@164532 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    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.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326229
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@185449 by dabaylissn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, dabayliss wrote:

    JM - that code is an excellent learning tool - thnx
    Couple of newbie questions to ensure I understood -
    a) The 1.5 bits after the initial start detection - is that to place your sample into the 'middle' of the pulse so that a minor mis-timing doesn't catch an edge?
    b) The timing of the RxReady test is set up so that even if the ready happens immediately after the previous test there will still be another test before a full byte comes in - correct ?
    c) Your interupt seems to be going at least 3 times faster than you ever really use (you're always clocking it down in your code) - so why have it so fast?

    David
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326263
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@202812 by mhubersn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, mhubers wrote:

    Hi Peter,
    I feel dumb asking this but I need to learn somehow.  :)
    You said:
     use MOV txState, #TX_Bits & 255
     to suppress warnings "literal truncated"
    What making that line suppress the warning?  Is it because "& 255"?

    Mark
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326279
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@203449 by peterverkaikn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote:

    Yes, for page 1 for example, the low half addresses are $200 to $2FF
    which won't fit a byte, hence the warning.

    The & 255 strips the higher bits.

    regards peter
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326281
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\05@225809 by Peter Van der Zeen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

    Hi Jonny;
    In general, I believe it is not good practice to put much of anything in the ISR. I realize that generalization cannot be fully adhered to; there are some things, for example ADC/ DAC code that absolutely must be executed exactly at the same time every time if accuracy is important, and hence they MUST reside in the ISR, and at a consistently timed spot to boot, so they are the excepton to that rule..... but that's about it. Everything else should be outside the ISR, and because the ISR is executed every tick, it should be as short as possible. That leaves the most time for the rest of the multi-tasking apps.

    But this is a general practice rule I follow and if your apps are not very demanding, then that rule can be bent quite a ways.

    In the final analysis, the proof is in the pudding, and if bending it works, well, then it works!

    Cheers,
    Peter (pjv)
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326305
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@004954 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    [Quoting: "David Bayliss"]JM - that code is an excellent learning tool - thnx
    Couple of newbie questions to ensure I understood -
    a) The 1.5 bits after the initial start detection - is that to place your sample into the 'middle' of the pulse so that a minor mis-timing doesn't catch an edge?
    b) The timing of the RxReady test is set up so that even if the ready happens immediately after the previous test there will still be another test before a full byte comes in - correct ?
    c) Your interupt seems to be going at least 3 times faster than you ever really use (you're always clocking it down in your code) - so why have it so fast?

    David


    A) Yes; after start bit detection (RX goes low using True mode) one waits 1.5 bit periods to land int the "middle" of the first bit; after that the timing is set to 1 bit
    B) Yes; at 38.4k baud a byte will take 260 microseconds; by checking at twice this rate I should never miss anything.  And Peter's code gives us a buffer so we can actually be receiving a second byte before retrieving the first.

    C) I chose that speed to get very close to a baud-friendly rate (I use 4x [or multiple thereof] oversampling) and so that I could generate a tick timing of 10us that will be used for other processes (specifically, servos -- I've yet to add them in).

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326315
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@122500 by Peter Van der Zeen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

    Jonny;
    You should use an odd number for oversampling on catching the START bit (I like 5 but 3 should work) that way you can properly position the sample for following bits in their middle 20% or middle 33%.. And once START is detected somewhere in the beginning 20% or 33%, then set the sample for only the next bit to 140% or 133%, and the subsequent samples at 100%.

    With today's modern communications we no longer see much skew in the mark/space ratio coming from transmitting devices or communications media, but longish capacitive lines can still mess you up. So that is my recommendation to make your system more forgiving in dealing with skew.

    Cheers,
    Peter (pjv)
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326450
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@162316 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    Ok.. this conversation has gone way... WAY over my head.

    I hope you guys don't mind if I inject a little newbieness to this with a question.


    I was simply trying to transfer a couple bytes between a BS2 and a SX (to prepare to learn more advanced stuff later) and I've
    come accross a major problem.


    The data I'm sending out is getting corrupted somehow and I'd like some expert info on what I'm doing wrong.


    I'm simply sending ABC from my BS2 to the SX and then from the SX back to the BS2.
    It comes out scrambled for some reason.


    I've attached the code both for the BS2 and the SX. My setup is simple, I've got a single wire (pulled down with a 1k resistor)
    connected from pin 14 of the BS2 to pin RB2 of the SX. I'm translating the bytes into binary on the BS2 so I can better see whats going on.


    Here's my results:




    Sent Data...     A: 01000001 B: 01000010 C: 01000011
    Received Data... 1: 01010000 2: 10101000 3: 11101000



    The results are consistant and unchanging. I can't figure out, for the life of me, what's wrong.


    Any assistance would be much appreciated.


     

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326508
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@173122 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    You need some mechanism to allow the SEROUT on the BS2 side when the SX side is sitting on a SERIN statement; this means an extra IO pin for hardware flow control.  You could define another output pin on the SX to gate the BS2 SEROUT statements.  I would create a function like this:

    FUNC RX_BYTE
     CTS = 0
     SERIN RX, Baud, __PARAM1
     CTS = 1
     ENDFUNC

    The you would use it in place of SERIN like this:

    Get_Packet:
     FOR idx = 0 TO 2
       buffer(idx) = RX_BYTE
     NEXT

    The call to RX_BYTE will signal the BS2 that it's oaky to send a byte.  Personally, I wouldn't do it this way -- I'd go with buffered serial so that you can send a message packet and retrieve it at any time.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326513
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@192851 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    I sort of get it.
    My timing was off... I understand that part.  I just don't get how.
    I thought that by delaying transmission things would sync up properly since serin causes the entire microprocessor (either one) to stop and wait for data.

    I thought it'd work like this:
    1> Start both processors at the same time.
    2> Stamp would execute a 5 second delay to give the SX time to enter the SERIN loop
    3> Stamp sends the data at the same rate that the SX is receiving
    4> SX pauses 1 second to allow Stamp to finish DEBUG and enter SERIN
    5> SX transmits data to the waiting Stamp
    On which section is the timing getting messed up?

    I'll try your suggestion of course, I just want to understand the problem more.

    Also... Is it just me or is the SX/B serout/serin a lot more limited than the stamp's?

    PS: I'm planning on doing a form of buffering like you've shown me in your examples, at the moment I'm just trying to get the two to talk at all.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326538
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\06@221543 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    None of your methods are robust in my opinion.  If one device resets an you lose sync with the other everything goes to heck.  Use hardware flow control or buffering on the SX end.  Now... even with buffering on the SX end you still might need HFC because the Stamp has to be sitting on a SERIN statement to receive data.

    Yes, SERIN and SEROUT in SX/B only work with bytes but you can synthesize routines to do what the Stamp compiler does for you.  SX/B is not supposed to be PBASIC compatible, just similar to it.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=324554#m326577
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\07@160531 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    After pretty much an entire day of frustration... I think I've finally got flow control and communication between a BS2 and SX down.

    I do have some questions though.


    1: In order for any serial to come over "clean" I always have to send a byte of trash.... doesn't matter what it is as long as I don't care if it arrives corrupted. I don't understand why this is needed. Is this to sync the serial or establish baud rate or something? (this is what took me all day to discover)

    2: At the end of the SX program cntrl is always set to 0. I checked this with WATCH and it stays 0 most of the program (except during the actual serial communication)
    Why is this?


    3: In the SX program, between sending the trash data and entering the actual transmit loop, I have to have a pause there (duration doesn't matter) otherwise the first byte is garbled. Is this to give the stamp time to reset the pin high and enter its own loop or some other reason?


    4: On the BS2 side, the first SERIN (receiving the trash data) internal flow control with the rdy pin doesn't seem to work. The program won't function unless I set the pin to 0 and the back to 1 manually as I have it. Why is this?


    5: I have to constantly set the pins to high to make everything work. Would a pullup resistor function better for this form of flow control? (I couldn't find enough 10k resistors to test this myself)

    6: Does a serial line need to be pulled down/up?


    JonnyMac:

    You mentioned buffered serial... I'm assuming its nothing like I have here so can you explain it a bit more? Don't bother taking the time to give more code examples, I'm sure you've got better things to do than to code for a newbie :) Just a broken-down explanation would be wonderful.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326722
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\07@220436 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    Have a look at the attached programs -- they work very well together (I have them running on my PDB now).  Use the Pause button on the PBASIC Debug window to verify that the uppercase letter going out is being sent back as lowercase.

    Since the SX at 20MHz is about 1600x faster than the BS2 I'm confident this demo proves that hardware flow control is working else the SX would start transmitting back before the BS2 was ready.  
    Let me suggest you study the SERIN and SEROUT sections of the PBASIC help file; there is a lot of information there that will help you.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326795
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\07@224926 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    It's important to work through problems a step at a time.  Once you get the programs above working, have a look at these -- I think this gets you closer to your ultimate goal.  The SX side uses buffered serial so the SX can be doing something else while serial data arrives.  Hardware flow-control is still used to maintain comms between the Stamp and SX.  
    The SX demo waits from three bytes, adds them, then sends the result (low byte only) back to the Stamp comparison.  I've even attached a screen shot from my PC so you can see what it looks like when running.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326806
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\07@233404 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    One more demo -- sends packets to and fro.  It's important that both sides know (or can communicate) the size of packet otherwise it will be easy to get out of sync.  If your packet values can be less than 128 then you could use BIT7 as a sentinel to re-sync a packet (MIDI does this).

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326811
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\08@141009 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    First, I'm working on understanding your code still, I'll most likely be hitting you with questions soon.

    I was wondering one thing though...
    In the BS2_TO_SX.BS2 file you have the baudmode as:
    Baud            CON     T38K4
    Which I assume T38K4 is a funky way of saying True 38400 (I never knew about the k thing).
    The problem is, according to the SERIN information, the buadmode for non-inverted, no-parity 38400 baud should be: 6
    1,000,000 divided by 38400 minus 20 = 6
    Am I misunderstanding the helpfile on how to set the baud mode?

    As far as studying the helpfiles for SERIN and SEROUT, I've read them several times and I don't see exactly what your pointing out that I should learn.
    Can you give a dense newbie a bit more of a push in the right direction?

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326928
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\08@161030 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    Another problem...
    The BS2_TO_SX.BS2 and SX_TO_BS2.SXB programs don't seem to work for me.


    I connected the pins according to the programs, linked the two grounds together and didn't alter anything except the SX's clock...

    Here's a sample of my result:



    Out: N    In: <?>
    Out: O    In: <?>
    Out: P    In: 8
    Out: Q    In: 8
    Out: R    In: <
    Out: S    In: <
    Out: T    In: <
    Out: U    In: <
    Out: V    In: <
    Out: W    In: 8
    Out: X    In: <
    Out: Y    In: 8
    Out: Z    In: <
    Out: A    In: <?>
    Out: B    In: <?>
    Out: C    In: <?>
    Out: D    In: <?>

    I did alter the clock of the SX, if that makes a difference. I don't have a 20mhz resonator (Just the 4mhz and 50mhz that come with the tech toolkit) so I set it to 50mhz with no improved response, then set it to 4mhz with the same result.

    I understand I can simulate a 20mhz clock with the SX-key but that would make it impossible for me to read the debug screen on the BS2 side (I've only got one com port).

    I have a request for your book... can you please go into detail about resonators and crystals and the like? There's next to no information out there explaining such things to a total newbie of microprocessors. I'm still extremely vague on many issues related to them after studying every single source parallax provides. It seems that most of the material just simply assumes you know how they work, or that your going to use the internal RC clock.

    I'm sorry for being such a trouble with all this. I really am attempting to learn all this on my own without bugging you... I use this forum as an absolute last resort and as a result spend a lot of time re-reading things I've already read, and experimenting for hours with nothing to show for it.

    I'm not trying to be an annoying newbie... I'm just born that way I guess.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m326979
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\08@175229 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    Okay... if you can't get working programs working there may be nothing I can say/write that will help.  That said, I'll try... one last time.

  • Don't assume you've connected anything correctly -- very dangerous; I had to reconnect things two or three times yesterday before I got the first programs working; once the connections were correct everything after that was a breeze.  I even walked away a couple times when frustrated.  I've been doing this a long time and it took some effort; you keep reminding us that you're a newbie so I'm going to drop the connections thing on you ( bet you'll stop calling yourself a newbie now....  :tongue: )
  • Next to the PDB my favorite development tool is a white board and lots of color markers; I did this drawing yesterday to get my head around what I wanted to do:

    SX.TX (o) ---> BS2.RX (i)
    SX.RTS (i) <--- BS2.CTS (o)
    SX.RX (i) <--- BS2.TX (o)
    SX.CTS (o) ---> BS2.RTS (i)
    This should get your connections straight and help you with the code (it did for me).

  • If you're switching the SX to 50MHz then change OSCXT2 to OSCHS2.  I just re-ran the programs using a 50MHz resonator on the SX (instead of the Key) and it still works.  See page 50 of the SX-Key manual for OSC recommendations.  I tend to use OSCXT2 for 4MHz, 8MHz and 20MHz, and OSCHS2 for 50MHz -- that's based on using the resonators I have (same as what Parallax sells).  See section 9.0 of the SX28 docs for gory details on oscillator circuits (what I'm really saying is that using SX/B does not relieve you of any responsibility to learn the SX and connecting things to it).
  • When using True mode serial the idle state of the TX line is output-high (1); this needs to be done at start-up (both programs do).
  • Using hardware flow-control (HFC) with True mode the CTS pin will be high (1) to stop incoming serial, and go low (0) to allow it.  The CTS pin should be initialized output-high to prevent the other side from trying to transmit until this side is ready.  The CTS of the receiving device connects to the RTS of the transmitting device (see above).  The transmitting device will watch for its RTS input to go low before transmitting.
  • Okay, blow-by-blow: The BS2 wants to transmit a byte to the SX via its TX_BYTE subroutine.  Using HFC it checks its own RTS input to see if the SX is ready to receive; when RTS is low (0) the byte will be transmitted.  On the SX side the RX_BYTE function signals that it's ready by taking its CTS output low then dropping into SERIN.  Once the byte as been received by the SX the CTS line is taken back high; this stops the BS2 from sending anything else.  Going the other direction... when the BS2 is ready to receive a byte it goes to its RX_BYTE subroutine where, again using HFC, it will take its CTS pin low to signal the SX that it's ready.  When the SX's TX_BYTE function sees its RTS input go low it will transmit a byte to the waiting BS2.  Everybody is happy -- I've given you three sets of programs that prove it!  :smilewinkgrin:
  • Finally.... I used to work for a guy named Bob who said ever person needs to see/hear/read something three to seven times before it sinks in -- you may need to re-read some material as we all have different rates at which the "Aha!" light illuminates.  Don't assume that reading things once or twice will be enough; you're human, allow yourself to be.  And keep experimenting... that's a much better way to learn than counting on windbags like me!

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327005
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

  • 2009\02\08@202654 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    Ok... I think your getting pretty frustrated with me so I'll just make this as brief as possible...

    I have been understanding how HFC works since about 5 minutes after you originally mentioned it. In fact, I had used something of a crude, inverted, form in my original program I posted without even realizing it. My questions weren't related to how it works, more to the exact problems I was having with my applications of it.

    I know I did something wrong... I was asking what.


    I did verify several times that I had the connections correct... I will go into deftail now (and verify again as I do so):
    BS2 Pin 15 (RTS) -----> SX pin RA.1 (CTS)
    BS2 Pin 14 (TX) -------> SX pin RA.0 (RX)
    BS2 Pin 13 (CTS) -----> SX pin RA.3 (RTS)
    BS2 Pin 12 (RX) ------> SX pin RA.2 (TX)
    LED -> 220ohm Resistor -> RC.7 (LED)
    BS2 Vss -------> SX Vss
    SX is powered by regulated 5.9volt wall-wart to barrel jack on SX Tech board
    BS2 powered by 9volt battery

    When I attempted to use the 50mhz resonator, I did have it changed to OSCHS2. I also changed the FREQ command accordingly.


    When I said I didn't understand resonators, I meant more practical aspects... Are they polarized? How do you read the markings on them? Does static damage them?

    Do magnetic fields damage them? Which is better, a crystal or a resonator? Can I underclock them to run at a slower speed(Use a lower FREQ?)? What speeds are best for what applications? What is too fast for X? What is too slow for X? ect... I've answered some of those, but I just wanted to give an example of the information I still wanted after reading and re-reading the sources you listed and many more.


    I have directly downloaded your attached programs into my stamp and SX, I did not edit the programs at all except to change the clock of the SX, and I still get this result:




    Out: J    In: 8
    Out: K    In: 8
    Out: L    In: 8
    Out: M    In: 8
    Out: N    In: 8
    Out: O    In: 8
    Out: P    In: <?>
    Out: Q    In: <?>
    Out: R    In: <?>
    Out: S    In: <?>
    Out: T    In: <?>
    Out: U    In: <?>
    Out: V    In: <?>
    Out: W    In: <?>
    Out: X    In: 8
    Out: Y    In: 8


    I've attached both programs exactly as I ran them.


    If its not in my wiring or your program, then it must be something else. I wish I knew what.


    I'm sorry your frustrated with me. I will attempt to figure out things on my own from this point. Thank you for your help... I've learned a lot from you.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327041
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\08@205342 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    You might try a better power supply for the SX -- the LM2940-5 wants at least 6.25 volts in (see http://www.national.com/ds/LM/LM2940.pdf).  
    Good luck with your experiments.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327049
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\09@073955 by Shawn Lowen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Shawn Lowe wrote:

    Ugha-
    Try a 4.7k resistor tied to +5V on your TX line coming from the SX.

    Resonators aren't polarized (good question, I had it too). I think they are pretty robust (not too easily damaged).

    Please let us know if you find a solution!

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327161
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\09@075857 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    JonnyMac--
    I can't tell you how valuable the exchange between you and Ugha has been for me and doubtless many, many other new folks that are either to embarrassed to ask the questions that Ugha asks or, if they are truly like me, do not know those questions even exist!

    It is difficult to communicate across several levels of experience. I could see both of you straining. I hope neither of you give up because ALL of us are learning an incredible amount. The subject line of this thread is truly appropriate: Learning SX/B.

    (I noticed that even some of your contemporaries had exchanges in which you and they learned a bit. I think. It was a "bit" over my head, but I didn't mind that as I know the waters can get very deep in this technology. Simple folks like Ugha and me are desperately trying to get out of the shallow end of the pool. Without people like you, only our knees will ever get wet. (Well, Ugha has gone a little deeper than me, but he may be the first to admit there is a long way to go before he can scuba dive!)
    Thanks, again!

    --Bill
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327167
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\09@081949 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    In one of the exchanges Ugha kind of chided me NOT to write demo code for him.  What he doesn't realize is that I don't write code for anyone but myself.  At the risk of sounding very selfish, I participate in these exchanges so that I can learn something.  I spent three or four hours working on the demos above -- not because I wanted to help a stranger (though that's a nice side benefit) but because I wanted to know, with certainty, how to make this process work in case I ever need it for one of my own projects.  Now I do, and to me the time spent was worthwhile.  Not everyone likes experimenting as much as I do... and to me, that's the key to getting to the deep end of the pool (I'm not suggesting I'm there, but I am working my way there).

    The most difficult aspect of these exchanges is hardware.  It's nearly impossible for anyone to know that the other person is connecting things correctly, has good power supplies, etc. -- I wish I was smart enough to know what to say to get programs that work on my desk to work on the desks of others; sadly, I'm not.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327175
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\09@082355 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    I try to participate in these exchanges because I always learn something -- now I know, with certainty, how to use HFC between the SX and a BASIC Stamp and have several demos that prove it.  I wish, though, I was smart enough to know what to say to get programs that work for me to work for others.  I'm not.  I think, though, a big part of that is experience, and that's just a matter of time spent struggling through frustrating circuits/code -- Heaven knows I struggle every day....

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327176
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\10@182538 by WMcKILLemALLn/a
    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, WMcKILLemALL wrote:

    ugha
    Thanks for this post!

    I was just gonna wait on the SX/B Manuel to come in print.

    Bill Chennault:
    I'm sorry that I'm this late in the thread.  I didn't realize that their was any Mopar fans out there.I would almost kill to " street " a 70'HemiCuda, especially a Sox&Martin HemiCuda!!!!!
    Not to many people would recognize a late 60's Hemi.  They didn't call it the elephant motor for nothing!

    I look at JonnyMac and Bean as the Sox and Martin of the Microcontroller "SXB" Stamp!!!!

    __________$WMc%__________
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327689
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\10@192748 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    $WMc%--

    It was a lot of fun while it lasted. BUT, if I had taken that original hemi 'Cuda off the showroom floor and put it in storage, do you have ANY idea what it would be worth today? :)

    Of course, when I was younger, I trashed a lot of '57 Chevy's, too.


    I think I have LEARNED. My Crossfire, which is either no longer manufactured or no longer imported from Europe, is going into storage. My son will inherit it.


    --Bill ps Man! That screaming Sox and Martin engine was fun! It had a tunnel ram manifold and dual 850, gear driven Holley double pumpers on it. I had to look off to the side to see around them. The engine was so well balanced that it would wind to 9k, although I always kept it down close to eight. The first and only time I ever used first gear with the BIG hemi in it, I wound it up to 10k before I could pull a shift. No damage.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327705
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@090923 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    In case anyone ever has the same problems I do...

    The power supply doesn't seem to be the problem.
    I ran the regulated 5v VDD straight from my BOE into the VDD of my SX tech board and still have the exact same problems.

    I can't explain why one person can run JonnyMac's program (him) and I can't. I'm assuming there's something I'm not seeing wrong with my setup... or perhaps the PDB he's using is
    better suited to the task or... something.

    I don't know.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327856
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@092611 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    Ugha--

    I'm very glad you did not give up on this project!


    You might have to be somewhat more direct with Parallax. Your request for their help was down towards the bottom of your message. I'd either send tech support an e-mail outlining the problem and including the url of this entire thread, or start a new thread with a subject line that makes it clear you are asking specifically for their help.


    I've done both, including calling them. I cannot recommend one method over the other. All have worked very well for me. Additionally, folks reading this thread will probably offer help, as well.


    It snowed a little while ago. But, it is too warm and it all went away. Things are back to normal here in The Land Of Oz, except the wind has died way down. I'm sure the gusts aren't over 50mph, or so.


    --Bill
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327866
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@092924 by Zootn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

    Can you take a picture of your actual setup? Or post a correct schematic?

    The FREQ directive does NOT change the running clock speed of an SX running standalone -- whatever the resonator is is what the clock speed will be. The FREQ directive tells both the compiler what frequency to presume when generating code for SERIN, SEROUT, etc. and for setting up the SX-Key in debug mode. If you have a given FREQ, make sure to have a resonator that matches that freq and that your OSC settings are correct, and that you have the parallel resistor (see the SX manual for values) across the outer two pins of the resonator. The resonators are not polarized -- the outer two pins go to the OSC pins, the inner pin is ground.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327868
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@093018 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    I will agree with you that the PDB is the BEST tool for developing SX28 apps -- especially those that want to talk with a BS2.

    Again, don't take the simple stuff for granted; in 35+ years of experimenting I cannot count the number of times when a bad connection or broken wire (inside the insulation) has caused me hours if not days of misery.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m327870
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@190413 by Shawn Lowen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Shawn Lowe wrote:

    Okay-
    This is a very good thread (at least for me) for a couple reasons:

    1. It got me to play with my new PDB!! Yeah, use that device!! :)
    2. It got me playing with my SX!!!


    So, with happiness out of the way, lets get onto unhappiness. I have tried all three of JonnyMac's demo programs for talking to and from a BS2 with an SX. None of them work for me. I have checked and double and triple checked my connections. The darn 'forget to put the resonator in' thing got me...twice ( one day, shawn, you wont be stupid ).


    I am attaching the first program as modified by me. I have a BS2SX not a bs2. I am also attaching the SX program as I could not find a 20 M resonator, but found a 4 M. I am also attaching a schematic of my hookup ( a quick one ).


    I understand Jon got his running on his PDB, and I know his programs work. Just not for me. Im with Ugha - what can I be doing wrong? The program works for me, just no good data. In my first program I slowed it down so I could see the led blink for each byte, and my bs2 cycled through the data, but all I got on the debug window from the stamp was <?>. The other two programs did nothing, I waited about 2 minutes, but nada.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328040
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@191859 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    Shawn:
    I'm glad I'm not the only one going bonkers trying to figure this out!
    PLEASE by all means, let me know if you come up with a solution!


    I've attached two programs I wrote that work a great deal like JonnyMac's BS2_TO_SX programs... except for the case change anyways.
    They are extremely simple and I was using them to just figure out if there was something wrong with my processors... they both work perfectly.


    The SX program is completely in SX/B and very poorly coded (no constants, no subs/functions) as this was purely a test platform to see if
    I could figure out any way for serial to work at all.


    I did find one thing out though... the SX is so fast that when communicating with a BS2 using flow control and SEROUT, you have to wait for the control line to come back up to 1 between each byte or else it'll send the data faster than the stamp can raise pins high and low, thus missing the first bit or two and receiving garbage (This is why my previous program had to send a byte of "trash" to get them in sync).


    My testing reveals no problems sending uninterrupted SEROUTs if flow control isn't used... but I wouldn't trust it to always be true.


    I still can't get JonnyMac's version to work, even after attempting to tweak it. You can attribute that to my complete lack of understanding for assembly though.


    Can someone else attempt JonnyMac's programs? If we can find someone else that it works for, we can compare the setups and track down the problem.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328043
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@210725 by Shawn Lowen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Shawn Lowe wrote:

    Ok
    With attached programs I get:


    4,5,6,7 %11111100

    all else %11110000

    Shawn

    P.S. How do you get a screen capture? Arrgh!

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328057
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\11@221536 by Zootn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

    Shawn -- looking at your photo -- where's your pullup on the serial line?

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328066
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@042136 by Ughan/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Ugha wrote:

    A pullup is needed?

    Is serial active-low? I thought it was active-high?

    Would the SX's internal pullup work?

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328095
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@050714 by Shawn Lowen/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Shawn Lowe wrote:

    Zoot-
    Yeah, I was going to try that last night. I even suggested Ugha try, but I couldn't see anything in any posts about it. I should have been more thourough. I'll give it a shot after work tonight. Ugha, if you can try it sooner, let me know your results!

    After you press Alt+PrintScreen, do you see anything or does it just copy to the clipboard?

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328106
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@064203 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    Zoot--

    After you press Alt+PrintScreen, do you see anything or does it just copy to the clipboard?

    You can paste it into Word or Paint or even Excel (I think). To paste it, call up the target program (say, Word), click Edit/Paste, or simply do a Ctrl-V.

    --Bill
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=4&m=324554#m328123
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@070002 by Zootn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

    Ugha and Shawn -- TIME TO START A THREAD JUST FOR YOUR SERIAL comm. questions. This thread is all over the place ("Learning SX/B??") :-). The need for a pullup has been mentioned several times.

    The serial protocol used by JonnyMac and others is generally open true (not the same as "active-low" or "active-high"). This means when the device wants to send a 0, it drives the wire LOW. When it wants to send a 1 it sets the pin to INPUT, letting the pullup generate the high. Sometimes Jon cheats and has the SX drive the line high, and uses a series resistor to take care of possible shorts, but if OPEN TRUE (OT) is used on the Stamp or SX side with SERIN/SEROUT, you will get the line set to input for "1s".

    The internal pullups on the SX are not strong enough for this purpose, unless your platform is remarkably free of noise and interference.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328128
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@090802 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    Since those having trouble seem to be applying more guesswork than science I'm going to guess that the ghost of Mickey Mouse (I live near the Disney studio) is watching over my desk, making this work for me but not for you!   :tongue:   (Relax, I'm poking a bit of fun to lighten up this thread)
    On the odd event that I just got lucky after four hours of work last Saturday I removed a project from my PDB, reconnected the SX to the BS2, and then re-ran the programs.  Thank you, Mickey! -- they work yet again.  I've even taken a picture of my setup and used different colored wires so that you can see exactly how I did it.  For those that want to pay travel and per diem, I'm happy to bring my setup to your home to prove it to you!   :smilewinkgrin:

    For review (warning: science stuff):

  • True mode means the line idle state is high.  A start bit will go low and the data bits, which arrive LSB first, will have their normal polarity (i.e., a "1" is high, a "0" is low); the stop bit is at the line idle state (high for True mode).  See attached image.
  • True mode communications drives the TX and CTS outputs all the time -- this means that no pull-ups are required for this program to work properly.  It also means that we need to initialize these pins as outputs and high (both sides do this).
  • True mode is not a "cheat" -- it's used when the TX line of one device connects to the RX of another and comms flows in one direction only (on that connection).  Why use Open True mode, then?  We only need this mode when using half-duplex communications on the same wire, that is, the TX line can become an RX line and vice-versa (like with the PSC); by using Open baud modes we can prevent an electrical conflict if both sides try to transmit at the same time.


    As a reminder... frustration rarely brings solutions.  I walked away from my desk more than once on Saturday to clear my head when I got frustrated.  After the first program worked, everything after flowed very easily.  It will for you, too -- if you just hang in and not give up.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328156
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

  • 2009\02\12@095602 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    Aha! After getting my project working (again) I went back and looked at Shawn's image to see what was up.  Shame on you, pal -- you owe me a beer.  Why?....

    Because you're using a BS2sx and didn't change the serial baud constant in the PBASIC program which is setup for a stock BS2.  Maybe this is Ugha-bugga's problem as well: a BS2sx is NOT a BS2; they work at different speeds and require different constants for some functions (e.g., SEROUT and SERIN).   Now, if Ugha said he was using a BS2sx then I apologize.  Shawn changed the $STAMP constant but not the baud constants for the SX.  Lesson for us all (the little things we overlook will kick our butts).

    I modified the program so that it will conditionally compile for any BS2-series Stamp with the correct baud constant for the selected Stamp and the desired baud rate.  I retested and guess what?  It still works (thank you, Mickey)!  :tongue:  No change is required to the SX program because the compiler takes care of the baud timing for the specified rate.

    Man, I hope that this settles this thread....

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328169
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@102135 by Zootn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

    P.S. -- in my experience *all* the Stamps will do 38.4k baud in both directions, with or w/o flow control, but on the slower Stamps you MUST use STR to tx or rx multiple bytes from/to an array or implied array --  if you use individual discrete byte variables, the set up time for each one will blow 38.4k baud.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328173
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@102941 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    As I had this back on my PDB I connected a 'scope to the LED pin just to look at the timing.  You'll see that the LED is on for about 1.5ms which is the time spent in the TX_BYTE subroutine (with flow control).  As a byte at 38.4K takes just 0.26ms to transmit the rest of the time is the BS2 loading the SEROUT instruction and taking its CTS pin low to allow the SX to transmit.

    The very long low period in the signal is due to the BS2 using DEBUG to report in and out bytes to the PC.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328175
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@103214 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    [Quoting: "Zoot"]P.S. -- in my experience *all* the Stamps will do 38.4k baud in both directions, with or w/o flow control, but on the slower Stamps you MUST use STR to tx or rx multiple bytes from/to an array or implied array --  if you use individual discrete byte variables, the set up time for each one will blow 38.4k baud.

    I'm in agreement with Zoot, here.  In fact, in my "packet" demo that was part of Saturday's work the BS2 end has SERIN setup like this:

     SERIN RX\CTS, Baud, [STR iPacket\pSize]
    The point that Zoot is making is that with just one SERIN we're reciving multiple bytes at the deisred rate -- using individual SERINs for each byte would kill throughput.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328176
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@130923 by JonnyMacn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, JonnyMac wrote:

    I've attached the updated "packet" programs that have the C/C baud setup.  And my friend Bean pointed out something in my ASM code that could be improved to allow the SX programs to migrate to the SX48.  All updates tested (working) and attached.

    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328211
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\12@183623 by WMcKILLemALLn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, WMcKILLemALL wrote:

    JonnyMac
    I like the full Program approach, instead of the code fragment approach. Since I'm not just learning the SXB code, But also the compiler/Editor as well. I think this was the reason the BS2 was so successful. It had well documented programs and I tried most of them and got a feel for the $BS2 and the Editor before I ever went on line and did something really complex and need help.

    Just a Suggestion.

    Bill Chennault: Can You Imagine what the SX28 would have done for A ignition module to replace the points? I still struggle to see how a dual point Distributor could make and break @ 10,000RPM's even tough it's at half the crank speed, It still has to fire 8 cylinders???!!!!Chrysler Had there ($h^%) Stuff together.

    ________________$WMc%__________
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328273
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    2009\02\13@114057 by ringlordn/a

    flavicon
    face
    In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ringlord wrote:

    $WMc%--
    Yes, you are absolutely correct. An SX would have improved things immensely. In the meantime, I guess they had strong springs to keep those points from bouncing.

    --Bill
    ---------- End of Message ----------

    You can view the post on-line at:
    http://forums.parallax.com/forums/default.aspx?f=7&p=5&m=324554#m328459
    Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
    The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)

    More... (looser matching)
    - Last day of these posts
    - In 2009 , 2010 only
    - Today
    - New search...