|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#33
|
|||
|
|||
|
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 |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
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 |