Learning SX/B
Ugha
Posts: 543
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!
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!
Comments
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.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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 [noparse]:)[/noparse] 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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
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.
In the beginning the only big difference is debuging and·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, notes·and file 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 and there is no good reason to increase·your learning curve.
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
Post Edited (Capt. Quirk) : 2/1/2009 4:08:11 AM GMT
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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 [noparse]:)[/noparse]
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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 your 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.
·
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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:
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). And if you create a transmite UART with its own pin you can actually send and receive data at the same time! -- yes, I do this, too.
Programming the SX to get this kind of power does take some getting used to but is worth the effort in my opinion.
Post Edited (JonnyMac) : 2/1/2009 4:42:14 AM GMT
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%_________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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.
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 [noparse][[/noparse]IMHO] not something you can't 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 [noparse][[/noparse]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.
[noparse][[/noparse]Edit] Added a bit of logic to the foreground dequeue/requeue process to prevent sticking when TX buffer is full.
Post Edited (JonnyMac) : 2/3/2009 6:18:22 PM GMT
It is indeed strange and wierd and upsetting.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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
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 [noparse]:)[/noparse]
Bill Chennault: I have no idea what happened to your post. Internet gremlins?
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/showthread.php?p=677182
Don't forget to get the latest cc1b compiler:
http://www.bknd.com/cc1b/index.shtml
regards peter
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
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 [noparse][[/noparse]updated] 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.
Post Edited (JonnyMac) : 2/3/2009 10:50:39 PM GMT
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!