Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Ken, I just sent a bunch of code to you that should end your timing issues!! If you find that the method that I sent to you works please post it back to this list. I have not tested my code design on the BX so I thought it best to send it privately until the method was proven. Dan Thompson ----- Original Message ----- From: "Ken Arck" <> To: <> Sent: Tuesday, April 01, 2003 8:57 PM Subject: [BasicX] Speed? (was Continued problems with pseudo networking) > At 11:52 AM 4/1/2003 -0800, you wrote: > > I'll try your code and see how it goes. Thanks to you, Dave and others who > have offered me assistance! > > <----Doug, you'll be happy to know that your code does work. I guess it IS > all in the timing! > > Now for something completely different (with apologies to Monty Python).. > > While I haven't actually benchmarked it, it sure seems to me that the BX-35 > is slower than the BX-24, which I base on my observation of the same code > run on both platforms. > > Purely non-scientific I know, but it sure seems that way... > > Ken > -- > http://www.ah6le.net > Version 3.0 of the RC-110 controller is now available. > http://www.ah6le.net/arcom/rc110.html > Coming soon! The RC-210 controller with tons more features! > AH6LE/R - IRLP Node 3000 > http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ken wrote: > Doug, you'll be happy to know that your code does work. > I guess it IS all in the timing! Cool ... I guess the burning question is why doesn't the other code work? I have one BX24 reading a Laipac GPS, Vector2x compass, BAR2001S barometer, HMP2001S humidity sensor, ADXL202 accelerometer ... it changes COM3 to different pins and queries. I'm going further to add a light sensor and interface to a device called a QTrak IAQ monitor, it will add CO and CO2 readings ... But here's where the serial comms between BXs becomes important. One BX24 will quesry the sensors, another will deal with an HMI (LCD and buttons), and take care of massaging the data into high/low/average and hourly averages etc. I hope to use some external eprom to store the data too, and a wireless TX to send to an embedded PC ... way too much fun :) I've seen some articles on interfacing PICs to CompactFlash ... anyone tried that with Basicx? I have a 1GB microdrive ... sure would be cool to log all of this data onto that ... Some uC CompactFlash interfacing details ... http://vadim.www.media.mit.edu/Hoarder/Hoarder.htm http://www.walrus.com/~raphael/pdf/compactflashOnPicArticle.pdf http://www.e-insite.net/ednmag/index.asp?layout=article&articleid=CA46893 Oh BTW this camera can be read by a microcontroller: http://www.seattlerobotics.com/cmucam.htm The docs say it can do this: - track the position and size of a colorful or bright object - measure the RGB or YUV statistics of an image region - automatically acquire and track the first object it sees - physically track using a directly connected servo - dump a complete image over the serial port - dump a bitmap showing the shape of the tracked object You start with one sensor, then another, and another ... <g> I'm completely addicted. hee hee -- Doug

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 11:52 AM 4/1/2003 -0800, you wrote: I'll try your code and see how it goes. Thanks to you, Dave and others who have offered me assistance! <----Doug, you'll be happy to know that your code does work. I guess it IS all in the timing! Now for something completely different (with apologies to Monty Python).. While I haven't actually benchmarked it, it sure seems to me that the BX-35 is slower than the BX-24, which I base on my observation of the same code run on both platforms. Purely non-scientific I know, but it sure seems that way... Ken ------ http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming soon! The RC-210 controller with tons more features! AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ken, > Are there any particular bugaboos/hints/tricks I should look > out for when using the SPI interface for controlling an external > EEPROM *and* ISD chip? Since SPI is designed to be a multidrop network, I don't think there is a problem with multiple devices. I too will be playing with external EEPROM for data logging. I have a dozen microchip 24LC256, and apparently 8 of these can be addressed ... that's 8x256 = 2048 ... tons of storage ... peter anderson has some ideas on EEPROM interfacing here: http://www.phanderson.com/basicx/spieeprom.html http://www.phanderson.com/basicx/spicommand.html Another thing to consider is FRAM because it can do billions of write cycles ... check these out ... http://www.ramtron.com/products/producthome.htm http://www.ramtron.com/products/Bulletins/FM24C256bulletin.htm -- Doug

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Doug wrote: > Ken wrote: >> >> Doug, you'll be happy to know that your code does work. >> I guess it IS all in the timing! > > Cool ... I guess the burning question is why doesn't the > other code work? Good question. My own theory is that ClearQueue is being called in the wrong place, and sometimes erases valid data. But it's hard to say. I think we need to see more of the code -- ideally a complete program that demonstrates the failure. -- Frank Manning -- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 10:48 AM 4/2/2003 -0700, you wrote: But it's hard to say. I think we need to see more of the code -- ideally a complete program that demonstrates the failure. <---I posted the code I was using, yesterday. But here it is in its completeness.. 1st BX-35 (this code is called ONLY when a certain event occurs. In essence, it only runs once every 5 to 15 seconds) ---- http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming in June - The RC-210 controller AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ken, did you try the code snippet I posted? If you want it modified to accomodate an array, let me know. Cheers, Mike ----- Original Message ----- From: "Ken Arck" <> To: <> Sent: Wednesday, April 02, 2003 8:46 PM Subject: Re: [BasicX] Speed? (was Continued problems with pseudo networking) > At 10:48 AM 4/2/2003 -0700, you wrote: > But it's hard to > say. I think we need to see more of the code -- ideally a complete > program that demonstrates the failure. > > <---I posted the code I was using, yesterday. But here it is in its > completeness.. > > 1st BX-35 (this code is called ONLY when a certain event occurs. In > essence, it only runs once every 5 to 15 seconds) > -------------------------------------------------------------------------- -- > ---------- > > Public Sub Network(ByRef Array() as Byte) > > Dim OutBx(1 to 30) as Byte > Dim InBx(1 to 30) as Byte <SNIP

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hi. I haven't tested it but I think you have a few bugs in your code. See my comments below. Rgds Ingvar > -------------------------------------------------------------------- -------- > ---------- > > Public Sub Network(ByRef Array() as Byte) > > Dim OutBx(1 to 30) as Byte > Dim InBx(1 to 30) as Byte > Dim Array(1 to 10) as Byte ***This line shouldn't be here. You declarded the Array in the SUB declaration above. (Array() as Byte) > Dim A as Byte > > Call OpenQueue(InBx, 30) > Call OpenQueue(OutBx, 30) > Call DefineCom3(21, 22, bx0000_1000) > Call OpenCom(3, 19200, InBx, OutBx) > ***The 4 lines above (plus the corresponing DIM's) should rather be declared once in the main module. Now you re-declare the every time you enter the sub. I don't know but that might even cause some jitter at the output pin, if it's changing between input and output when it's declared. > For A = 1 to 10 > Call PutQueue(OutBx, Array(A) , 1) > Next > > End Sub > ---------------------------------------------------------------- > 2nd BX-35 (this is a continuous Do loop) > ---------------------------------------------------------- > > Public Sub Network(ByRef Array() as Byte) > > Do ***Sholdn't be here. Causes the variables below to be redeclared and the com-port to be re-initialized by every loop turn. > > Dim OutBx(1 to 30) as Byte > Dim InBx(1 to 30) as Byte > Dim Array(1 to 10) as Byte > Dim A as Byte > > Call OpenQueue(InBx, 30) > Call OpenQueue(OutBx, 30) > Call DefineCom3(1, 3, bx0000_1000) > Call OpenCom(3, 19200, InBx, OutBx) > ***This is the right place for the DO statement > If StatusQueue(InBx) Then > For A = 1 to 10 > Call GetQueue(InBx, Array(A) , 1) > Debug.Print CStr(Array(A)) > Sleep(0.01) ***Isn't needed. GetQueue manages this itself. I.e. If there is a character available it's read, otherwise it's waiting. > Next > End If > Call ClearQueue(InBx) ***Doesn't make sense. What characters do you want to remove from the input stream? They might belong to the next 10 character transmission. If you think you will receive garbage characters, you will need a protocol to ensure the transmission. > > Loop > > End Sub > -------------------------------------------------------------------- ------- > > (the debug.print statement is in for testing purposes only and I've tried > different values for the sleep call. I also experimented with removing the > ClearQueue call, just in case.) > > 1st BX 2nd BX > --------- ---------- > > Pin 21 ---------------> Pin 3 > Pin 22 ---------------> Pin 1 > > The obvious objective here is to transfer the contents of Array( ) of the > 1st BX-35 to the 2nd one. Eventually, code will be added to do the same in > reverse. > > Ken > -------------------------------------------------------------------- ---------- > President and CTO - Arcom Communications > http://www.ah6le.net > Version 3.0 of the RC-110 controller is now available. > http://www.ah6le.net/arcom/rc110.html > Coming in June - The RC-210 controller > AH6LE/R - IRLP Node 3000 > http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 01:42 PM 4/2/2003 -0700, you wrote: >>>> From: Ken Arck < It looks like you're using local variables as queues. This can be very useful, but you have to be very careful to call CloseCom to close the serial port before returning from the procedure in which the queues are declared. Otherwise, when a return is executed, the OS's serial port driver will continue to point to that area in RAM and may very well scribble on the memory when it's being used for something else. <---A good point. With the size of the program involved, it just isn't practical to post the entire thing so I settled for the relevant parts (but forgot about declaration of the array twice!). I wasn't using CloseCom as you point out, but I just might give that a try to prove out the methodology. I am now using the code that Doug suggested and it seems to be working fine, so I am not overly anxious (at the moment anyway) to revert back just now. Perhaps after my project it done.... BTW, I wrote you a private note a couple of days ago but haven't heard anything back yet. Did you not get it? Ken ------ http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming in June - The RC-210 controller AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 07:55 PM 4/2/2003 -0000, you wrote: I haven't tested it but I think you have a few bugs in your code. See my comments below. <---Thanks for your input! As I posted to Frank, it was the result of not wanting to post 30K of code :-) Ken ------ http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming in June - The RC-210 controller AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: "Ken Arck" <> > BTW, I wrote you a private note a couple of days ago > but haven't heard anything back yet. Did you not get > it? Yes. I have no new information to add. -- Frank Manning -- NetMedia, Inc.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 02:08 PM 4/2/2003 -0700, you wrote: >Yes. I have no new information to add. <--Ok, thanks for the reply. Now a question for the group... Are there any particular bugaboos/hints/tricks I should look out for when using the SPI interface for controlling an external EEPROM *and* ISD chip? Ken ------ http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming in June - The RC-210 controller AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

At 04:43 PM 4/2/2003 +0200, you wrote: Since SPI is designed to be a multidrop network, I don't think there is a problem with multiple devices. <---I was planning on using the same SPI pins as the program EEPROM to minimize pin usage so as to free up as many as I/O pins for other use. There were some caveats in the manual about "knowing what you're doing", so I was looking for...... guidance? :-) Ken ------ http://www.ah6le.net Version 3.0 of the RC-110 controller is now available. http://www.ah6le.net/arcom/rc110.html Coming in June - The RC-210 controller AH6LE/R - IRLP Node 3000 http://www.irlp.net

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ken, > I am now using the code that Doug suggested and it seems to be > working fine, so I am not overly anxious (at the moment anyway) > to revert back just now. Perhaps after my project it done.... Since as Frank pouiinted out, GetQueue will HALT the program if there is nothing in the queue, using that For loop is dangerous IMO. I've played with serial stuff on BX24s a lot, and the only way to really make it robust is to make sure there is a way to recover from errors. In this situation, with the code I posted, you will never even try to execute GetQueue unless there IS something in the queue. I think that's a Good Thing (tm) ... I don't think I would ever write code that relies on the halt until something arrives mentality. I have always basically written the code such that there is a GetQueue for every StatusQueue to avoid that. Sometimes I will start with a StatusQueue, and add another StatusQueue inside a that loop. The first StatusQueue indicates "stuff is arriving" and the inside that loop I basically do what I sent you: keep on checking StatusQueue and execute GetQueue ONLY if there IS something there. So far this has been fairly reliable. -- Doug

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )