Go to Post The only dumb question is the one you don't ask. - E. Wood [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #34   Spotlight this post!  
Unread 29-01-2003, 01:28
Micah Brodsky Micah Brodsky is offline
Registered User
#0824 (SWAT)
 
Join Date: Jan 2003
Location: Seattle
Posts: 5
Micah Brodsky is an unknown quantity at this point
Re: Re: grrr... not everyone is rejoicing

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


Quote:
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/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.)

Quote:
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!*

Quote:
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
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with communicating with STAMP through serial port Skabana159 Technical Discussion 2 06-02-2003 21:10
Dashreader.dll: A Visual Basic .NET user control to read the dashboard port Ameya Programming 4 12-01-2003 23:40
Custom Dashboard Executable ready for Download! archiver 2001 1 24-06-2002 01:01
Need help with custom switches archiver 2001 3 24-06-2002 00:35


All times are GMT -5. The time now is 00:57.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi