Serial Port and Custom Circuit

[Ryan Meador]

Haha! I can't resist gloating a little bit, sorry everyone... At the very least, perhaps this will make you aware of a (major?) rules change... Apparently FIRST does listen to reason and change the rules accordingly. I asked them to relax the restriction on connecting the custom circuit to the RC's programming port and they did it! Now all us programmers get MORE toys to play with! And we can move some processing off-board. Parallel processing all the way, baby.

[Rickertsen2]

Yea the very least that we will have is a current sensing circuit and an LCD

[JLambert]

Are there any documents on how exactly we are supposed to interface with this board? (Not physically, I'm looking for code-wise interface)

[rbayer]

Yes. Read the documentation for the DEBUG command. Also, RoboCon's bsx file contains SERIN and SEROUT commands that talk directly to this port.

--Rob

[Rickertsen2]

Yes! go to the parallax website. they have some great documentation. Use the SEROUT and SERIN commands. also any book about Basic Stamps will explain things.

[Joe Ross]

me: imagine this program:
serin 'from IFI
serout 'to athalon
serin 'from athalon
serout 'to IFI
Jeff (another team member): hahaha
Jeff: can you get one for $200?
Me: easily
Jeff: i think i have a 600mhz duron sitting around at home

If this had been legal earlier, my custom circuit plans would have been a lot more complex. It is much easier to I/O data serially to another micro then either through the digital inputs or the analog inputs.

[Ryan Meador]

Well said, Joe. That's the reason I went on my little campaign in the first place. The thing is, you'd probably have much more luck with 2 or 3 PIC micros than one Athlon. The Athlon might be able to do a ton more processing, but it still has the bottleneck of 9600 baud back to the IFI controller. Now, if there were only a way to tap directly into the stamps I/O, instead of using it as a router... But that requires removal of the cover on the RC O:-)

[rbayer]

Originally posted by Ryan Meador
Well said, Joe. That's the reason I went on my little campaign in the first place. The thing is, you'd probably have much more luck with 2 or 3 PIC micros than one Athlon. The Athlon might be able to do a ton more processing, but it still has the bottleneck of 9600 baud back to the IFI controller. Now, if there were only a way to tap directly into the stamps I/O, instead of using it as a router... But that requires removal of the cover on the RC O:-)

You can use whatever baud rate you want. Look at the documentation for SERIN and SEROUT and you'll see the ways to set it to what you want.

[Jnadke]

Originally posted by rbayer
You can use whatever baud rate you want. Look at the documentation for SERIN and SEROUT and you'll see the ways to set it to what you want.


But you can't use anything beyond 9600 baud because that's too much incoming data for the Stamp to handle. It has no memory/buffer to store the data. 9600 is more than enough. In fact, I'd recommend using something lower just to be on the safe side.

[Rickertsen2]

BTW if u are trying to connect a pic to the serial port be sure to use a serial driver chip such as the MAX232. Tell me how ur attempts go. Im thinking of just simply connecting a 4x16 LCD to the port to be able to debug my programs and to allow me to build a GUI for selecting "mini programs" and adjust other settings using inout from pushbuttons. Good luck

[FotoPlasma]

I just ordered some free samples of TI's MAX232Ns, this morning. They should arrive tomorrow.

TI will give you free samples of almost any product they have, and they ship UPS Red (overnight). They'll give you either 1, 2, or 3 pieces per part #, and you're limited to three different part #s.

I bought a couple BS2p's (1 BS2p40 and 1 BS2p24) for playing around, recently, and I'm having more than a little fun just thinking of what's possible.

I've been mulling over a dashboard interpreter using a character LCD display driven by one of the BS2p's.

Fun projects abound.

[Rickertsen2]

yea i would order some stamps and such but my team prolly won't give me the money to do anything interesting. But i happen to have a couple crystalfontz (http://crystalfonts.com) LCDs lying around. I am also making a current sense circuit. If i had my way i would either order some of those javelin stamps or some pics and a C compiler. Tell me how things go.

[FotoPlasma]

Heh. I had CrystalFontz in mind when I thought up the dashboard veiwer, in the first place. :)

They have some very attractive character LCDs. Too bad their cheaper onese are parallel, rather than serial driven, but if it's just taking serial data in the first place, you don't have much need for access to a whole lot of I/O pins, so you can spare them for parallel operation.

[Rickertsen2]

yea i have a Crystalfontz Crystalfontz 634 (http://www.crystalfontz.com/products/634/index.html) on one of my computers and a Crystalfontz 633 (http://www.crystalfontz.com/products/633/index.html) on another. They are great.

[FotoPlasma]

I have a couple LCD displays right now, which I'm going to screw around with for a while, but I was mostly considering using the exotic colored displays (yellow on dark blue, light red on dark red, white on blue).

You already have some good ones, but for me, sinking another $60 into a serial LCD is a little steep, when I could pay just as much for two attractive 4x20s (I'm almost becoming comfortable with my soldering ability not to worry at all about just frying these things :p).

[Rickertsen2]

I hate soldering. Im horrible at it.

[Ryan Meador]

Quick question... just why do we need the MAX232 chip? I've never had any problems and I don't use one. I don't even know what it does. One of the various revisions or modifications of the RS232 specs allow for 5V instead of 12 as the signal, and a stamp runs at 5. I haven't checked, but I suspect the port on the stamp outputs at 5V. I'm assuming that the MAX232 is an RS232 voltage converter thingy, but I have no clue what it does...

[Joe Ross]

The RS232 spec says that a 0 can be anywhere between 3 and 25 volts and a 1 is anywhere from -3 to -25 volts. Now, the stamp has an inverted mode, so that a 0 would be negative voltages and a 1 would be positive voltages. However, you still have to generate a negative voltage, unless the stamp breaks spec and reads 0v as something (consitantly).

Are you saying that you've hooked a 0-5v signal to the stamp's programming port and it worked?

[Ryan Meador]

I have connected my comp's serial port to the stamp and had 2-way communication. I didn't use the programming port, however. I connected it to one of the normal I/O pins. I'm assuming the programming port is just another I/O pin...

[Joe Ross]

Originally posted by Ryan Meador
I'm assuming the programming port is just another I/O pin...

Nope. The programming port has a built in RS232 level converter (it says so in the manual). The normal I/O pins don't.

[FotoPlasma]

Originally posted by Joe Ross
Nope. The programming port has a built in RS232 level converter (it says so in the manual). The normal I/O pins don't.

And the only way for a custom circuit board to communicate with the RC directly is through the programming port, so any custom circuit board will need to be able to send and receive true rs232 levels.

[Ryan Meador]

That still seems counter-intuitive. As I said before, I've had TTL voltages interface properly with RS232 voltages when the true RS232 was on my PC. Why wouldn't it work in reverse, having the true RS232 on the stamp and the TTL on the custom circuit? I'm going to try this tonight or tomorrow, we'll see :)

[Micah Brodsky]

Well, I hate to burst your bubble, Ryan, but my team was extremely *disgusted* and *outraged* at your rules change.

For teams like ours that really _cared_ about building an advanced control system, we didn't wait until week 3 to get started! We've been working since before kickoff. And sure, we expected we might get some nasty surprises in the rules when they were finally released, but we understood that going in. Fortunately, or so it seemed, the controls & electronics rules were pretty much the same as they've been for years. So we worked day and night, designing building a system for bidirectional Robot Controller <--> microcontroller communication and control, fast and flexible enough to be able to run a fast-paced robot. This was *the* task for us at the beginning. Everything else depends on getting your basic infrastructure in place. On the morning of Tue, 1/21, I finally got the last piece of our puzzle in place: pulse-synchronized, 100% error free, 80 bytes per second communication from our microcontroller into the RC via the digital inputs. (see http://www.chiefdelphi.com/forums/showthread.php?threadid=16741 for some interesting challenges that aspect presents.)

(I won't explain to you the other side of the coin, unless our controls team leader gives me permission, because it was such a brilliant triumph we might still want to keep it secret until competition, even though we're not using it anymore. Suffice to say, we had designed and implemented 100% legal (no programming, tether, or modem port) circuitry to get data from the Stamp to our microcontroller at nearly 2000 bytes per second (that's even faster than the RC and OI can communicate), error free.)

And then, two and a half weeks into the competition, right after we complete our prototype system and send off an order to DigiKey for our parts, the rules change. The rules COMPLETELY change. Suddenly, the game's not about creating elaborate virtual-instrumentation interfaces. All our work is TOTALLY obselete. Now, any old team that didn't even care enough to get started yet on building an advanced control system can jump right in and be up and running in a day. A month of backbreaking work is thrown in the trash, along with our team morale and motivation.

Well, I hope you're happy. Maybe we're the only team that felt punched on the stomach by this rules change, but that would kind of surprise me. There are a lot of dedicated, inventive teams out there, I'd be pretty amazed if we were the only ones in this pickle.

Thankfully, after a week of disillusionment and grunt work rebuilding our infrastructure, we're finally back on our feet. We're still in the game, only now we've got our own bragging rights, having successfully implemented *both* ways of communicating. Now, we're running at 19.2kbps through the programming port. And we've again mustered the energy to push foreward, to build the very best control system we can imagine.

We'll see you at competition.

--Micah Brodsky
Controls team
Team SWAT 824

[FotoPlasma]

Originally posted by Micah Brodsky
blah blah blah, $@#$@#$@#$@#$@# $@#$@#$@#$@#$@# $@#$@#$@#$@#$@#, moan moan moan, complain complain complain...

--Micah Brodsky
Controls team
Team SWAT 824

Uh, you're acting like it's Ryan Meador's fault that the rules were changed, or even that he was the one who changed them. Last I checked (about 10 seconds ago), Ryan was at least on the same level as you, when it comes to the whole competition. Just another team member on just another team.

Another thing: You act as though your team has been severly direly affected, as though some huge obstacle had reared its ugly head on your team's doorstep, and all you had was a broomhandle and a bucket of Miracle Grow to fight it off. It doesn't seem to me like your team had any trouble, if only a few days after the rule change you had a completely operational system. Oh yeah, and I'm here dicking around with a Basic Stamp which I haven't even been able to hook up to the programming port to test out, because I've been kinda busy trying to teach new team members, and, dare I say it, designing, building a robot for the past couple weeks. Yeah, thanks for being a pompous jerk, and for complaining about HAVING ENOUGH RESOURCES TO GET THE JOB DONE, AND QUICKLY, I MIGHT ADD. You've really made me feel better. Seriously. But not really.

A note about your comment confidentiality, and keeping a totally "obselete" [sic] technology a secret just because you think it's such an accomplishment in control system design. I'm not for confidentiality at all (with certain exceptions). I think that whatever can help you or your team can help someone else and their team. And, as opposed to some people, I would do all I could possibly do to share everything I know about anything with anyone, even if it involved giving away information that would give me (my team) an advantage over another team. Your attitude regarding this whole concept is disgusting.

Oh my, so you can't use your perfect little system (not saying it isn't great, but at this point, I can't tell, because you're apparently not going to release any information about it for your own feeling of superiority)? It's not as though something like this doesn't happen in reality. Say you work for a company who manufacturs staplers. You make staplers for a living. It's what you do, it's what you've been doing. All of a sudden, another company comes up with a way to put staples into paper which is a whole hell of a lot more efficient and effective than just punching it through and crimping the otherside, or whatever. Wait a second, you're technology is obsolete. Ooops. Looks like you've got to redesign your next line of staplers....

I hate you burst most peoples' bubbles, but as I said before, your attitude is just appaling. I didn't mind much.

[SiliconKnight]

Well, it *may* or *maynot* be Ryan's fault that the rules have changed. But how would *YOU* feel, if you've worked on a project for 5 friggin' weeks, only to have a rule change render your work obsolete, *and* hear someone "gloat about it"?

This is a *COMPETITION*, people. It is designed to bring out the best in each and every one of us, by pitting people randomly against others. This isn't "let's sit around the campfire, hold hands and sing happy songs". Sure, we all help each other out... to an extent. But I am not seeing a lot of complete CAD drawings and strategy discussions on this year's robot, am I? (Notice how Chief Delphi had kept quiet about *their* robot design?)

Speaking for myself: I routinely help other newbies out on the board. *AFTER* this year's season is over, I am sure we have no problem releasing our drive train and controls systems design. Hell, if your robot broke down on the field, I'd be more than happy to help you fix it. But I am not about to give away our secrets until I see you on the field. What's to stop another team from copying the design and gaining an advantage? Don't even give me that "Oh, gracious professionalism will stop us from blindly copying". You are playing a game to win here. Look at how many measuring tape clones surfaced after Woodie Flowers announced it to be legal last year. Do you honestly think they are built by teams who strictly followed the "no working on the robot after you shipped it" rule? So until you are willing to give out all YOUR secrets, don't start calling people nasty names for not wanting to give out theirs.

Consider this scenario. You are a crappy student not doing well. Instead of asking around for help, you lobbied the professor to make the finals a really easy, open book exam. Then, you come accross a student who had studied his rear end off, and basically laughed in his face. You think the hard-working student is a pompious jerk then?

-=- Terence

Mentor and Engineering Team Leader
Team 824, SWAT Robotics

[Jeff Waegelin]

Let's all take a deep breath and RELAX. There's no need to argue about this. So, your perfect plan doesn't work. It happens. Just try to make the best of it. We all have problems like that from time to time.

[Ryan Meador]

I can't imagine I'll make this any better by opening my big mouth, but I'm going to do it anyways.

Team 824, I'm sorry for your tragedy. I'd feel just as awful if my work suddenly had little importance. I don't think I'd be quite so vocal about it, however. You noticed that it was 3 weeks in, eh? Well, I posted the question in the first week, I believe. They shuffled it around 4 times before answering it. I even got an email from the FIRST moderator asking me to re-post it because it had been lost. Also, from discussions here on the delphi forums (and one or more replies to my FIRST forum post), I know I wasn't the only person pushing for this rules change. During the two weeks or so that I was waiting for a reply (I was expecting a "no"), I was working on alternative method of communication probably similar to the one your team came up with. Knowing that an answer from FIRST was in the works, I held back on implementing my design (much to the dismay of my coaches). Luckily, my instinct had been right even though I'd been expecting a "no" answer.

The only reason I knew to even suggest this option was some work I did for the government over the summer... I suspect it isn't common knowledge that a Stamp has that capability. I'd been told by IFI itself that serial communication with the RC was impossible!

Now, if you can pull off 19.2kbps through the programming port, you've definately still got some tricks up your sleeve, since the top baud of a stamp is 9600bps.

That bit you wrote about "any old team that didn't even care enough to get started yet on building an advanced control system can jump right in and be up and running in a day" bothers me very much. While you were tackling the problem one way, others of us were dreaming up alternate solutions. That's what engineering is all about.

[Dave Flowerday]

Originally posted by Micah Brodsky
pulse-synchronized, 100% error free, 80 bytes per second communication from our microcontroller into the RC via the digital inputs.
After all the research my team has done into the control system I am highly skeptical of this claim. The way the robot controller samples the digital inputs and the way it passes those values to the BASIC Stamp make it effectively impossible to do this. For instance, it can take up to 33 milliseconds from when the BASIC Stamp instructs an output to change to when that output actually changes. This means that the output sometimes doesn't change until the Stamp is already in it's next loop (and has already issued another Serin command). I certainly hope you release some information to back up this claim at some point. I will freely admit that a large part of my skepticism is due to the nature and tone of your post. Hardly "gracious professionalism".

because it was such a brilliant triumph we might still want to keep it secret until competition, even though we're not using it anymore.
Hmm, a "brilliant triumph"? Come on, our team already had this method of communication up and running last year (as did other teams, I imagine). You might have improved upon it (can't say for sure until some evidence is presented) but it's not like this is a totally new approach or anything.

Suffice to say, we had designed and implemented 100% legal (no programming, tether, or modem port) circuitry to get data from the Stamp to our microcontroller at nearly 2000 bytes per second (that's even faster than the RC and OI can communicate), error free.)
Yeah, let me guess: multiple PWM outputs being decoded by the microcontroller. That would be a nice accomplishment, but please keep in mind that there are a lot of really intelligent people involved with this project. It comes off as really offensive when statements are made that imply that an idea is totally new and hasn't been thought of before. Just because it hasn't been discussed on these boards doesn't mean it hasn't been thought of or implemented by other teams.
The rules COMPLETELY change.
Yup, and I'll agree that our team wasn't thrilled with this rule change either. But this has been the way FIRST has operated for years. Last year's "mice" robots were a prime example. It didn't really seem fair to the teams that evaluated the idea and decided it was illegal. But, this is the nature of engineering. Requirements change all the time
Suddenly, the game's not about creating elaborate virtual-instrumentation interfaces.
I'm not aware that it ever was.
All our work is TOTALLY obselete.
I wouldn't say that. First of all, think about how much you learned in the process. Isn't that the ultimate goal with this project? Secondly, no one is claiming that you can't still use your method. Serial communication has it's own set of problems, and if you've already mastered the digital input method perhaps that's still the better way to go.
There are a lot of dedicated, inventive teams out there, I'd be pretty amazed if we were the only ones in this pickle.
Well, as I mentioned earlier, you're not the only team disappointed by this rule. However I haven't seen any other teams on here making such a stink about it. The rest of us just took it as another method of communication to evaluate and moved on. Like I said, this kind of thing happens all the time in the engineering profession.
only now we've got our own bragging rights, having successfully implemented *both* ways of communicating. Now, we're running at 19.2kbps through the programming port.
I'm glad you figured both methods out. That really is a great accomplishment, and something to be proud of. Our team has both methods of communication up and running as well and we look forward to checking out your circuit at competition. See you there.

[seanwitte]

I have a question for the teams that are using the programming port to send data back and forth from another processor. You're probably using the external chip to offload some high bandwidth sampling or something like that. If you use the serial connection, then won't your sampling circuit still have to sit there waiting for the RC to acknowledge and transfer the data?

We're planning on using a second stamp 2sx and sending the data to the RC using the analog inputs. I can't see a way to use SERIN/SEROUT without creating a bottleneck, but any insight would be appreciated.

On another note, has anyone tried using one of the DAC chips to send data into the RC? We'd be taking an analog value, passing it through an ADC into the stamp, working on it, then converting it back to analog using a DAC on the other end.

[Dave Flowerday]

Originally posted by seanwitte
We're planning on using a second stamp 2sx and sending the data to the RC using the analog inputs. I can't see a way to use SERIN/SEROUT without creating a bottleneck, but any insight would be appreciated.
Well, we're using a microcontroller capable of interrupts so that makes it pretty easy. Since the Stamp doesn't have interrupts, you may be in a bit of a bind. However, the SERIN command does let you specify a timeout value, so you could use that. Unfortunately the timeout is in milliseconds so I don't think you can have a timeout of less than 1ms, which means you can't sample faster than 1000Hz....
On another note, has anyone tried using one of the DAC chips to send data into the RC? We'd be taking an analog value, passing it through an ADC into the stamp, working on it, then converting it back to analog using a DAC on the other end.
We actually had this capability on our custom circuit last year but didn't use it. It should work OK with a few caveats: sampling analog values is obviously slower than reading digital values, so you have to take that into account. Also keep in mind that it probably won't be perfectly accurate (the lowest order bit or 2 might get screwed up, especially with two ADC and two DAC conversions like you're talking).

[seanwitte]

Originally posted by Dave Flowerday
Well, we're using a microcontroller capable of interrupts so that makes it pretty easy.

Are you using the handshaking lines from the RC programming port to fire off the interrupt? Has anyone tried polling those lines?

[Dave Flowerday]

Originally posted by seanwitte
Are you using the handshaking lines from the RC programming port to fire off the interrupt? Has anyone tried polling those lines?
I don't believe there are any handshaking lines on the programming port. According to the documentation from Parallax and Innovation FIRST, the only pin (other than Tx/Rx/Gnd) connected is DTR which is used to reset the Stamp.

We get an interrupt from our processor when there is data available in the receive buffer.

[finatronics]

Hi, I'm Eric, the "Controls Subteam Leader" for team 824.

I just wanted to post a few comments. There were some harsh comments back there from and to my team, I just wanted to say that I apologise if anyone was upset by comments from my team. I understand where my team members were coming from, but they may have responded inappropriately. Either way, we all were upset by the change, as we were proud of the new idea that a member on our team came up with. As he commented, our method is nowhere near as reliable or fast as using the program port, so we will not implement our original design.

I feel it's unnecessary to keep our plans secret at this point, so I will share them here UNDER ONE CONDITION: The main idea was thought up by OUR team with no help from outside sources. If other teams have come up with similar ideas, it's purely coincidence. If you wish to use our ideas, please make reference to us. If you win some award for it and don't specify that WE gave you the idea, we will personally hunt you down for claiming credit for our idea. This is standard "intellectual property rights" that are true of software as well as hardware. Not that anyone will find a use for our design anymore...

Anyways, put simply, we wanted serial communication with the Stamp, and had no way to do it. We noticed that the "Basic Run" LED is directly driven by the Stamp, so we decided to do a Serout to pin 7 (the basic run LED). By puting a phototransistor over the Basic Run LED, we were able to get direct serial output from the Stamp to our external microcontroller at 19.2Kb/s. THIS is the idea that we figured few, if any, other teams have thought of. We were hoping it might be a good way to earn an "innovation" and/or "creative solutions" award.

Data going back to the stamp is standard stuff that most teams using external processors have probably tried before, we planned to send analog information (such as PWM values, etc) through the analog inputs, and digital information through the 16 digital inputs. We hadn't gotten to the Analog inputs yet, but using purely digital we got 2 bytes into the stamp per main loop cycle.

This brings up some other people's comments:
Yes, you CAN use faster than 9600baud on the stamp. The speed used between the stamp and the input and output microcontrollers is 62500baud (nearly 7 times faster!). If you don't believe me, read the following from the default code:

OUTBAUD CON 20 '(62500, 8N1, Noninverted)
INBAUD CON 20 '(62500, 8N1, Noninverted)

Yes, the samples/outputs to/from the stamp are offset by some time before they go in/out of the appropriate microcontrollers. However, if timed correctly, you can still send one byte to the stamp per main loop cycle. Our programming genious figured that out by reading threads here.

Commenting about the questions re: using analog rather than serial... Analog inputs are only sampled 40 times per second. If you use all 7 analog inputs that means the maximum data transfer you can get is 7*40=280 bytes per second. As someone else mentioned, DA and AD conversion can't be expected to work properly, The lower bit or two might be wrong after going through all that conversion. We were planning on this, which is why we were only going to use Analog data communication for analog information. With serial interrupts we can get data at a rate of at least 62500b/s which is 6250 bytes per second. Much faster... Without serial interrupts, I dunno...

Ryan, Yeah, obviously the change of the rules upset us... I don't think our other team member would have been so upset with you if you hadn't "gloated" about it... I mean, it definitely sounded like you were expecting praise from everyone for doing them some sort of unasked for favor... Anyways, what's done is done.

Eric

[Micah Brodsky]

Wow, I certainly kicked up a lot of dust, didn't I! ;)



Originally posted by Dave Flowerday
After all the research my team has done into the control system I am highly skeptical of this claim. The way the robot controller samples the digital inputs and the way it passes those values to the BASIC Stamp make it effectively impossible to do this. For instance, it can take up to 33 milliseconds from when the BASIC Stamp instructs an output to change to when that output actually changes. This means that the output sometimes doesn't change until the Stamp is already in it's next loop (and has already issued another Serin command). I certainly hope you release some information to back up this claim at some point. I will freely admit that a large part of my skepticism is due to the nature and tone of your post. Hardly "gracious professionalism".


(I assume you're only talking about the digital inputs on the RC, and not the digital relay outputs? I was a bit confused by your wording.)

Yes, it can be done. As we discussed earlier ( http://www.chiefdelphi.com/forums/showthread.php?threadid=16741 ) it's pretty difficult to get fast data through the digital inputs because of how inconsistently the RC reads those inputs and how slow it is to get the data to the Stamp. I was, however, able to successfully implement one of the ideas suggested in that thread, synchronization to a signal at precise time within the PBASIC code cycle. I don't know if you could've done it with a SEROUT, as somebody speculated, but fortunately, our secret weapon optical line filled in beautifully.

Interestingly, you're certainly right about the delay. I often waited two, or even three PBASIC loop cycles before the stamp would spit back the data I'd fed it through the digital inputs. Apparently, there's some sort of pipeline-like delay somewhere, maybe in a queue in the Input Microcontroller in the RC. But nevertheless, as long as I provided new inputs right on time, they were all received, every one, error free. (By trial and error, I discovered that the errors abruptly fell to zero if I sent my synch byte out the optical line right before the SEROUT line at the end of the main PBASIC loop.)


Hmm, a "brilliant triumph"? Come on, our team already had this method of communication up and running last year (as did other teams, I imagine). You might have improved upon it (can't say for sure until some evidence is presented) but it's not like this is a totally new approach or anything.

Yeah, let me guess: multiple PWM outputs being decoded by the microcontroller. That would be a nice accomplishment, but please keep in mind that there are a lot of really intelligent people involved with this project.


Okay, I was pretty darn impressed with our optical serial line. Nobody *ever* mentioned anything like that before, as far as I could tell. And it's almost four times as fast as the very best you could do trying to decode all 16 PWM and relay signals simultaneously. And it used lots of random voodoo capacitors. So *nyah!* ;)


Secondly, no one is claiming that you can't still use your method. Serial communication has it's own set of problems, and if you've already mastered the digital input method perhaps that's still the better way to go.


Serial is so far superior to running data through the digital and analog inputs, for the purposes of getting data to the Stamp, that we immediately knew we'd be at a massive relative disadvantage if we didn't use it. (We knew how great serial was to work with, since we'd been using it all along, through the optical line!) Besides the puny bandwidth available through the digital inputs, that lag was also very troubling to me. I thought we could engineer around it if we had to, but if other teams are going to avoid that problem alltogether, we'd better do the same.




ALSO... A comment about some folks talking about using another Stamp connected via serial. Personally, I don't see how you could survive without interrupts. Practically everything related to serial I/O on our microcontroller is interrupt-driven. It all automatically starts, and only when cued by the Stamp. I cringe at the thought of having to wait idly for the Stamp to get around sooner or later eventually at its leasure stop and smell the roses... and then finish the rest of its loop and send you data. Maybe you could somehow use the 'flow control' capability supported by Stamp serial to make one of the chips halt until the other checked by and saw that it was ready to send... Or maybe you could have very-short-timeout SERIN lines scattered throughout the code, to look for a signature code and then grab the data... Or maybe you could interleave the data into individual SEROUT lines scattered throughout the code, so that each chip could listen in whenever it had the chance and probably catch most of the important data... Or something...?


--Micah Brodsky
Controls team
Team SWAT 824

[Adrian Wong]

By puting a phototransistor over the Basic Run LED, we were able to get direct serial output from the Stamp to our external microcontroller at 19.2Kb/s. THIS is the idea that we figured few, if any, other teams have thought of. We were hoping it might be a good way to earn an "innovation" and/or "creative solutions" award.
Us too! :) When encountered with the programming bottleneck, I explained to one of the programmers that the only valid I/O from the robot controller that we could use this year were the Analog and Digitial I/O ports.

"That's it?" they asked. I mentioned in passing that the only other thing directly connected to the stamp is the Run LED. Our programming team had just finished a review of this year's default code, and many of them remembered the "Toggle 7" line. Then one kid piped up, "Couldn't we do something like morse code on that LED and use one of those Banner light sensors?"

One of the negineers present immediately saw an even better solution: using a cheap $1 photoresistor (in place of the Banner sensor) hooked up to the offboard microprocessor. You chould just SEROUT on the LED.

While I can't say our team progressed as far as you did (by the time we had received the parts to assemble our circuit, the team update in question was already released), I'm sure the idea has occured to other teams as well. Anyone with a good familiarity with the code would know about the direct connections to and from the Stamp itself, including the Basic Run LED.

I can see both sides of the argument quite clearly. We were quite excited at having "invented" this new approach as well, and our team captain was basically jumping up and down, yelling "design award, design award!" I could see how if soemone poured all the work that you team did into perfecting that design, they would be irked at a change such as the programming port.

Yet, I also see the other side of the argument. Many teams, ours included, are grateful that FIRST allowed the use of the programming port. It is faster, more reliably, and a logical choice for doing I/O off the roboto controller. This whole thread was probably just stirred feelings unintentionally, since they did not know how much work you put into your project.

However, I must add that your tone leaves much to be desired.

"If you win some award for it and don't specify that WE gave you the idea, we will personally hunt you down for claiming credit for our idea." is not exactly gracious or professional. Other teams that had this idea may even feel threatened to submit it for a design award under their own name, even if they did all the research and implementation of it independent of your team.

[finatronics]

Well, there was a hint (or more?) of sarcasm in that comment. Obviously we won't hunt you down for it, but I'm trying to discourage stealing of our idea and claiming it as your own. Obviously, if you came up with the idea before I posted it here, and have evidence (such as a team full of people saying you came up with the idea before we posted it here), then we wouldn't have any argument about it. More power to you and your team's creativity. We thought it seemed original.
Sorry if my wording sounded "ungraciously unprofessional," not that "gracious professionalism" is a term that anyone could define without trouble (Maybe I'm uninformed, but I've never seen it anywhere outside of FIRST).

BTW: I haven't had a chance to read Micah's latest post, so I'm not referring to that in any way. I just got home from a long evening in time to take a shower and run out of the house for another day at work on the robot.

Eric

[powercat]

Greetings,
I am new to this competition and
programming. I have a few questions
about the programming port (rs232 port).

Are there good references describing
how to program that port ?

If you have code to manipulate this
port, does it interfere with transferring
code to the robot.

Again, a good primer on this would
be sufficient.

sorry for the newbie type post.

[Ryan Meador]

Check out the SERIN and SEROUT commands in the Basic Stamp manual. They'll explain the pinout and function of the programming port, plus how to transfer data with it. You won't have any problem transfering code to the bot as long as you don't mess around with the ATN pin (I think it's DTR on the port). Happy coding.

[mjosephi]

Hi all,
Has anybody noticed that SERIN 16,... (on the programming port) echo's back to sender the received data?
I am assuming this is a verification technique that is used for downloading programs. Do you know if there is anyway to disable the character echo when using the programming port for normal communication?
Thanks.
-Michael

[Steven Carmain]

The problem with this is that your code will be a lot slower because the serin and serout will slow you down. Don't be suprised if your robot is slower and you get basic run errors from taking too much time. In 2001, a debug statement meant that we couldn't balance on the bridge. (Debug = Serin)

[Ryan Meador]

And therein you are wrong. Debug and serin/serout definately are of the same family, but they are quite different. Debug does a good bit more processing on the parameters than serin/serout. Also, debug is usually outputting whole sentences, when a normal serin/serout statement might be handling the equivalent of a single, short word. I'm not going to get into my calculations, but with a clever hack or two my team figures we can output 3 bytes and read in 7 every loop without any slowdown.