Re: Re: serial connection
 

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

Re: Re: Re: serial connection
 

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.

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

Re: Re: grrr... not everyone is rejoicing
 

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


(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/sh...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.)

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!* ;)

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

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.

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

Programming Port - Programming
 

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.

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.

SERIN echo
 

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

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)

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.