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

Hi I just bought a BasicX-24 to replace the BasicStamp on my HexCrawler Robot (www.crustcrawler.com). Now i realised that i cannot use every I/O Pin as a RS/232 Connection as on the BasicStamp. Is that true ? I need a serial Connection to my Mini-SSC (Servo-Controller) and to my LCD. Can i use Com1 in parallel with my PC and the LCD for example ? Of course without "Debug.print" Commands. Are there any Code-Fragments around for such a setup ? Thanks for every Answer Daniel

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

itisnt wrote: > Hi > > I just bought a BasicX-24 to replace the > BasicStamp on my HexCrawler Robot (www.crustcrawler.com). > > Now i realised that i cannot use every I/O Pin as a RS/232 > Connection as on the BasicStamp. > > Is that true ? > NO YOU CAN USE AS MANY AS YOU LIKE > I need a serial Connection to my Mini-SSC (Servo-Controller) > and to my LCD. > > Can i use Com1 in parallel with my PC and the LCD for example ? YES BUT I'D USE COM23 ON TWO DIFFERENT I/O PINS > Of course without "Debug.print" Commands. > Are there any Code-Fragments around for such a setup ? > HEAPS > Thanks for every Answer > > Daniel > > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/SIG=12coiar9s/M=268585.4521611.5694062.1261774/D=egroupweb/S=1706554205:HM/EXP=1079982533/A=1950447/R=0/SIG=1245hvqf1/*http://ashnin.com/clk/muryutaitakenattogyo?YH=4521611&yhad=1950447 > > ------------------------------------------------------------------------ > *>.

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

--- In , "itisnt" <itisnt@y...> wrote: > I need a serial Connection to my Mini-SSC (Servo-Controller) > and to my LCD. Is your LCD serial in the sense of RS-232 (i.e. baud, start bits, stop bits, etc.) or does it have a clock and data line? If the latter is the case, any pin can be used for serial I/O (by way of ShiftIn() and ShiftOut() calls). If you need to communicate via COMn, you can multiplex the serial output easily enough. Doing so for serial input is a little more difficult unless you have some control over when the devices will be sending (as is probably the case with the LCD at least).

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

--- In , "itisnt" <itisnt@y...> wrote: > Hi > > I just bought a BasicX-24 to replace the > BasicStamp on my HexCrawler Robot (www.crustcrawler.com). > > Now i realised that i cannot use every I/O Pin as a RS/232 > Connection as on the BasicStamp. > > Is that true ? > No. First I assume you mean serial comm in general as neither chip have RS232 levels at more than one port. If I remember BS correctly you can use any pin, but as BS doesn't have buffering or background tasks you can only use one pin at a time and then only for input or output. BX can use two ports simultainously and in full duplex as the comm is handled in the background (or interupt driven). I.e. If you want to use your BX as you used the BS, communicating with one device at a time, you can do it on any pin, just by redefine the COM3 pin to be used. Just a few lines of extra code. Rgds Ingvar

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

Yes i think you are right, i mean serial comm not necessarily with RS232 Levels. The reason i switched to BX is the Multitasking. I have to "serial" Devices: - Serial LCD+ from Netmedia - Mini SSC II Serial Servo Controller (controls 12 Servos) The rest is one Ultrasonic Sensor and two IR-Sensors, all three are not serial Devices. What i would like to implement is one Task for the "Walking" and another Task for the Sensor-Scanning. The Main-Programm runs in Loop, checks Button-Activity, displays System-status, Sensor-Values ..... On a BasicStamp, the command to the Mini SSC looks like this: SEROUT Pin, Baud, [254, NumberOfServo, Position] That mean, i have to send one sync Byte (254), the number of the Servo and the position of the servo. So i think sharing COM3 with both Devices wouldn't be a good idea. Any Idea what the best Hardware-Layout would be ? Daniel --- In , "Ingvar Esk" <ingvar.esk@s...> wrote: > --- In , "itisnt" <itisnt@y...> wrote: > > Hi > > > > I just bought a BasicX-24 to replace the > > BasicStamp on my HexCrawler Robot (www.crustcrawler.com). > > > > Now i realised that i cannot use every I/O Pin as a RS/232 > > Connection as on the BasicStamp. > > > > Is that true ? > > > No. > > First I assume you mean serial comm in general as neither chip have > RS232 levels at more than one port. > > If I remember BS correctly you can use any pin, but as BS doesn't > have buffering or background tasks you can only use one pin at a > time and then only for input or output. > > BX can use two ports simultainously and in full duplex as the comm > is handled in the background (or interupt driven). > > I.e. If you want to use your BX as you used the BS, communicating > with one device at a time, you can do it on any pin, just by > redefine the COM3 pin to be used. Just a few lines of extra code. > > Rgds > Ingvar

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

From: itisnt <> > [...] > I have to "serial" Devices: > - Serial LCD+ from Netmedia > - Mini SSC II Serial Servo Controller (controls 12 Servos) > [...] > the command to the Mini SSC looks like this: > SEROUT Pin, Baud, [254, NumberOfServo, Position] > That mean, i have to send one sync Byte (254), > the number of the Servo and the position of the > servo. > > So i think sharing COM3 with both Devices > wouldn't be a good idea. It's not difficult at all. To get started, probably the easiest solution might be to use the LCD+ example code built into the V2.1 compiler. Module LCDPlusSerialPort can be used as-is by the servo controller. High level code might look something like this: Call SetSSCPort Call LCDPutByte(SyncByte) Call LCDPutByte(NumberOfServo) Call LCDPutByte(Position) Call SetLCDPort Whenever the program needs to move the servo, SetSSCPort closes Com3 and re-opens it with the SSC pins and baud rate. When you're through with the servo, SetLCDPort closes Com3 again, and re-opens it with the LCD pins and baud rate. I haven't tested it, but the idea is to replace the LCD+ main module with the code shown below. Not as simple as SEROUT, but much more powerful and flexible. -- Frank Manning -- NetMedia, Inc. '------------------------------------------------------ Option Explicit Private Const PortNumber As Byte = 3 Private Const LCDInputPin As Byte = 16 Private Const LCDOutputPin As Byte = 17 Private Const LCDBaud As Long = 9600 '------------------------------------------------------ Public Sub Main() Dim Column As Byte Call LCDInitialize( _ PortNumber, LCDBaud, LCDInputPin, LCDOutputPin) Call LCDMoveCursor(2, 1) Call LCDPutStr(" LCD Plus") Do For Column = 1 To MaxColumn Call LCDMoveCursor(1, Column) Call LCDPutStr("=") Call LCDMoveCursor(4, Column) Call LCDPutStr("=") Call Delay(0.02) Next For Column = 1 To MaxColumn Call LCDMoveCursor(1, Column) Call LCDPutStr(" ") Call LCDMoveCursor(4, Column) Call LCDPutStr(" ") Call Delay(0.02) Next Call MoveServo(1, 128) Loop End Sub '------------------------------------------------------ Private Sub MoveServo( _ ByVal NumberOfServo As Byte, _ ByVal Position As Byte) Const SyncByte As Byte = 254 Call SetSSCPort Call LCDPutByte(SyncByte) Call LCDPutByte(NumberOfServo) Call LCDPutByte(Position) Call SetLCDPort End Sub '------------------------------------------------------ Private Sub SetLCDPort() ' This procedure switches Com3 to the LCD Plus. Call LCDCloseSerialPort Call LCDOpenSerialPort(PortNumber, LCDBaud, _ LCDInputPin, LCDOutputPin) End Sub '------------------------------------------------------ Private Sub SetSSCPort() ' This procedure switches Com3 to the SSC board. Const SSCInputPin As Byte = 0 ' Dummy pin. Const SSCOutputPin As Byte = 12 Const SSCBaud As Long = 2400 Call LCDCloseSerialPort Call LCDOpenSerialPort( _ PortNumber, SSCBaud, SSCInputPin, SSCOutputPin) End Sub '------------------------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

Hi Thanks for the Code, my small test-prog has the same idea behind. The problem is that in a walking robot the task who controls the walking-gait creates a lot of servo-commands. So i would have to stop the robot, display something and let it walk again. Not realy what i want. What about the idea of Don Kinzer ? With the shiftout() Command. Sounds good, i think i'll try this the next night (0:46 am in Switzerland....) Regards --- In , "Frank Manning" <fmanning@n...> wrote: > From: itisnt <itisnt@y...> > > > [...] > > I have to "serial" Devices: > > - Serial LCD+ from Netmedia > > - Mini SSC II Serial Servo Controller (controls 12 Servos) > > [...] > > the command to the Mini SSC looks like this: > > SEROUT Pin, Baud, [254, NumberOfServo, Position] > > That mean, i have to send one sync Byte (254), > > the number of the Servo and the position of the > > servo. > > > > So i think sharing COM3 with both Devices > > wouldn't be a good idea. > > It's not difficult at all. To get started, probably the easiest > solution might be to use the LCD+ example code built into the > V2.1 compiler. Module LCDPlusSerialPort can be used as-is by the > servo controller. > > High level code might look something like this: > > Call SetSSCPort > > Call LCDPutByte(SyncByte) > Call LCDPutByte(NumberOfServo) > Call LCDPutByte(Position) > > Call SetLCDPort > > Whenever the program needs to move the servo, SetSSCPort closes > Com3 and re-opens it with the SSC pins and baud rate. When you're > through with the servo, SetLCDPort closes Com3 again, and > re-opens it with the LCD pins and baud rate. > > I haven't tested it, but the idea is to replace the LCD+ main > module with the code shown below. > > Not as simple as SEROUT, but much more powerful and flexible. > > -- Frank Manning > -- NetMedia, Inc. > > '------------------------------------------------------ > Option Explicit > > Private Const PortNumber As Byte = 3 > Private Const LCDInputPin As Byte = 16 > Private Const LCDOutputPin As Byte = 17 > Private Const LCDBaud As Long = 9600 > '------------------------------------------------------ > Public Sub Main() > > Dim Column As Byte > > Call LCDInitialize( _ > PortNumber, LCDBaud, LCDInputPin, LCDOutputPin) > > Call LCDMoveCursor(2, 1) > Call LCDPutStr(" LCD Plus") > > Do > For Column = 1 To MaxColumn > Call LCDMoveCursor(1, Column) > Call LCDPutStr("=") > Call LCDMoveCursor(4, Column) > Call LCDPutStr("=") > Call Delay(0.02) > Next > For Column = 1 To MaxColumn > Call LCDMoveCursor(1, Column) > Call LCDPutStr(" ") > Call LCDMoveCursor(4, Column) > Call LCDPutStr(" ") > Call Delay(0.02) > Next > > Call MoveServo(1, 128) > Loop > > End Sub > '------------------------------------------------------ > Private Sub MoveServo( _ > ByVal NumberOfServo As Byte, _ > ByVal Position As Byte) > > Const SyncByte As Byte = 254 > > Call SetSSCPort > > Call LCDPutByte(SyncByte) > Call LCDPutByte(NumberOfServo) > Call LCDPutByte(Position) > > Call SetLCDPort > > End Sub > '------------------------------------------------------ > Private Sub SetLCDPort() > > ' This procedure switches Com3 to the LCD Plus. > > Call LCDCloseSerialPort > > Call LCDOpenSerialPort(PortNumber, LCDBaud, _ > LCDInputPin, LCDOutputPin) > > End Sub > '------------------------------------------------------ > Private Sub SetSSCPort() > > ' This procedure switches Com3 to the SSC board. > > Const SSCInputPin As Byte = 0 ' Dummy pin. > Const SSCOutputPin As Byte = 12 > Const SSCBaud As Long = 2400 > > Call LCDCloseSerialPort > > Call LCDOpenSerialPort( _ > PortNumber, SSCBaud, SSCInputPin, SSCOutputPin) > > End Sub > '------------------------------------------------------

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

From: itisnt <> > Thanks for the Code, my small test-prog has the > same idea behind. > The problem is that in a walking robot the task > who controls the walking-gait creates a lot of > servo-commands. So i would have to stop the > robot, display something and let it walk again. > Not realy what i want. Well, is SEROUT is fast enough? I haven't measured it, but I'd be very surprised if switching Com3 was slower. I'd guess Com3 can switch pins much faster than SEROUT. > What about the idea of Don Kinzer ? With the > shiftout() Command. If you're using the LCD+, I don't think ShiftOut would work, since you need a separate clock pin. -- Frank Manning -- NetMedia, Inc.

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

--- In , "itisnt" <itisnt@y...> wrote: > What about the idea ... [w]ith the shiftout() Command. Since the LCD that you said you are using requires an RS-232 bit sequence and timing, I don't think that that will work. You could, however, use a parallel interface LCD instead. Many of them can work in either 4-bit or 8-bit mode. Using it in 4-bit parallel mode would require 7 I/O pins. If you add shift registers to do the serial to parallel conversion you can get it down to 5 pins or fewer. Some of these lines can be shared with other external circuits, especially if you have other parallel devices that you need to connect to. I used a parallel interface LCD on my BX-24 Ethernet interface. The Ethernet controller chip also has a parallel interface so much of the circuitry is shared between the two. You can view the schematics on the web page for it: http://www.kinzers.com/don/BX24/Ethernet > Sounds good, i think i'll try this the next night (0:46 am in > Switzerland....) > > Regards > > --- In , "Frank Manning" <fmanning@n...> wrote: > > From: itisnt <itisnt@y...> > > > > > [...] > > > I have to "serial" Devices: > > > - Serial LCD+ from Netmedia > > > - Mini SSC II Serial Servo Controller (controls 12 Servos) > > > [...] > > > the command to the Mini SSC looks like this: > > > SEROUT Pin, Baud, [254, NumberOfServo, Position] > > > That mean, i have to send one sync Byte (254), > > > the number of the Servo and the position of the > > > servo. > > > > > > So i think sharing COM3 with both Devices > > > wouldn't be a good idea. > > > > It's not difficult at all. To get started, probably the easiest > > solution might be to use the LCD+ example code built into the > > V2.1 compiler. Module LCDPlusSerialPort can be used as-is by the > > servo controller. > > > > High level code might look something like this: > > > > Call SetSSCPort > > > > Call LCDPutByte(SyncByte) > > Call LCDPutByte(NumberOfServo) > > Call LCDPutByte(Position) > > > > Call SetLCDPort > > > > Whenever the program needs to move the servo, SetSSCPort closes > > Com3 and re-opens it with the SSC pins and baud rate. When you're > > through with the servo, SetLCDPort closes Com3 again, and > > re-opens it with the LCD pins and baud rate. > > > > I haven't tested it, but the idea is to replace the LCD+ main > > module with the code shown below. > > > > Not as simple as SEROUT, but much more powerful and flexible. > > > > -- Frank Manning > > -- NetMedia, Inc. > > > > '------------------------------------------------------ > > Option Explicit > > > > Private Const PortNumber As Byte = 3 > > Private Const LCDInputPin As Byte = 16 > > Private Const LCDOutputPin As Byte = 17 > > Private Const LCDBaud As Long = 9600 > > '------------------------------------------------------ > > Public Sub Main() > > > > Dim Column As Byte > > > > Call LCDInitialize( _ > > PortNumber, LCDBaud, LCDInputPin, LCDOutputPin) > > > > Call LCDMoveCursor(2, 1) > > Call LCDPutStr(" LCD Plus") > > > > Do > > For Column = 1 To MaxColumn > > Call LCDMoveCursor(1, Column) > > Call LCDPutStr("=") > > Call LCDMoveCursor(4, Column) > > Call LCDPutStr("=") > > Call Delay(0.02) > > Next > > For Column = 1 To MaxColumn > > Call LCDMoveCursor(1, Column) > > Call LCDPutStr(" ") > > Call LCDMoveCursor(4, Column) > > Call LCDPutStr(" ") > > Call Delay(0.02) > > Next > > > > Call MoveServo(1, 128) > > Loop > > > > End Sub > > '------------------------------------------------------ > > Private Sub MoveServo( _ > > ByVal NumberOfServo As Byte, _ > > ByVal Position As Byte) > > > > Const SyncByte As Byte = 254 > > > > Call SetSSCPort > > > > Call LCDPutByte(SyncByte) > > Call LCDPutByte(NumberOfServo) > > Call LCDPutByte(Position) > > > > Call SetLCDPort > > > > End Sub > > '------------------------------------------------------ > > Private Sub SetLCDPort() > > > > ' This procedure switches Com3 to the LCD Plus. > > > > Call LCDCloseSerialPort > > > > Call LCDOpenSerialPort(PortNumber, LCDBaud, _ > > LCDInputPin, LCDOutputPin) > > > > End Sub > > '------------------------------------------------------ > > Private Sub SetSSCPort() > > > > ' This procedure switches Com3 to the SSC board. > > > > Const SSCInputPin As Byte = 0 ' Dummy pin. > > Const SSCOutputPin As Byte = 12 > > Const SSCBaud As Long = 2400 > > > > Call LCDCloseSerialPort > > > > Call LCDOpenSerialPort( _ > > PortNumber, SSCBaud, SSCInputPin, SSCOutputPin) > > > > End Sub > > '------------------------------------------------------

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

Frank I often use several Com3 pins to talk to radios and Ser LCD displays. Currently I am doing a project where I have a serial LCD+ and a serial UHF radio transceiver ( the master), with two out stations a few miles away. The master station code puts new informtion to the LCD once per second, and polls the out stations from time to time, about every 5 seconds. The PROBLEM that arises in that from time to time, an outstation will give the master an uninitiated call, and the incoming data can screw up the stack in the master. I have separate buffers for the LCD, radio data-out and radio data-in. I've tried all sorts of tricks like flushing buffers,do until empty, and turning com3 on and off, and waiting for UARTs to finish etc, but its just not robust. The best I've been able to do is update the LCD when I know there is a window of opportunity when no radio data is likely to arrrive. But that's not elegant.In fact its downright clumsy. Any suggestions? neil Frank Manning wrote: > From: itisnt <> > > > Thanks for the Code, my small test-prog has the > > same idea behind. > > The problem is that in a walking robot the task > > who controls the walking-gait creates a lot of > > servo-commands. So i would have to stop the > > robot, display something and let it walk again. > > Not realy what i want. > > Well, is SEROUT is fast enough? > > I haven't measured it, but I'd be very surprised if switching > Com3 was slower. I'd guess Com3 can switch pins much faster than > SEROUT. > > > What about the idea of Don Kinzer ? With the > > shiftout() Command. > > If you're using the LCD+, I don't think ShiftOut would work, > since you need a separate clock pin. > > -- Frank Manning > -- NetMedia, Inc. > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/SIG=12cnmrqg3/M=267637.4673019.5833256.1261774/D=egroupweb/S=1706554205:HM/EXP=1080000010/A=1945638/R=0/SIG=11t2rh2cf/*http://www.netflix.com/Default?mqso=60178383&partid=4673019 > > ------------------------------------------------------------------------ > *>.

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

--- In , Neil Jepsen <njepsen@i...> wrote: > I often use several Com3 pins to talk to radios and Ser LCD > displays... If you decide to give up or reduce the multiplexing of COM3, you might consider using an external UART. Maxim has the MAX3110E that would work although it is probably overkill for just talking to a serial LCD. Below is a link to a page describing how to hook one up to a BS2. The concepts can be applied equally well to the BX-24. http://www.wd5gnr.com/suart.htm On the other hand, it would probably be cheaper to switch to a parallel LCD with a shift registers for serial/parallel conversion.

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

Don Yes it would certainly wallpaper over the problem, but I'm only multiplexing com3 between three ports and that should be simple. One day when i get some spare time ( I wish) I'll get to the bottom of it. At the moment i don't /actually/ know whats happening and because it only happens once in a while, its hard to find. neil Don Kinzer wrote: > --- In , Neil Jepsen <njepsen@i...> wrote: > > I often use several Com3 pins to talk to radios and Ser LCD > > displays... > > If you decide to give up or reduce the multiplexing of COM3, you > might consider using an external UART. Maxim has the MAX3110E that > would work although it is probably overkill for just talking to a > serial LCD. Below is a link to a page describing how to hook one up > to a BS2. The concepts can be applied equally well to the BX-24. > > http://www.wd5gnr.com/suart.htm > > On the other hand, it would probably be cheaper to switch to a > parallel LCD with a shift registers for serial/parallel conversion. > > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/SIG=12c8e3j3a/M=268585.4521611.5694062.1261774/D=egroupweb/S=1706554205:HM/EXP=1080027312/A=1950447/R=0/SIG=1245hvqf1/*http://ashnin.com/clk/muryutaitakenattogyo?YH=4521611&yhad=1950447 > > ------------------------------------------------------------------------ > *>.

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

From: Neil Jepsen <> > I often use several Com3 pins to talk to radios > and Ser LCD displays. Currently I am doing a > project where I have a serial LCD+ and a serial > UHF radio transceiver (the master), with two > out stations a few miles away. The master > station code puts new informtion to the LCD once > per second, and polls the out stations from time > to time, about every 5 seconds. > > The PROBLEM that arises in that from time to > time, an outstation will give the master an > uninitiated call, and the incoming data can > screw up the stack in the master. > [...] I'm not sure what you mean -- are you saying there is a data overrun in the BX-24 input queue? It's difficult to say without seeing the code, but if you have one or two devices that can send data at an unpredictable time, each of those devices should be connected to a dedicated serial port. Otherwise you could lose data. If you have two of those devices, you've used up both BX-24 serial ports, so multiplexing Com3 doesn't make sense. I'd agree with Don's suggestion about using an external UART. -- Frank Manning -- NetMedia, Inc.

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

On Tue, 23 Mar 2004 13:11:31 -0700, Frank Manning <> wrote: > From: Neil Jepsen <> > >> [...] > > I'm not sure what you mean -- are you saying there is a data > overrun in the BX-24 input queue? > > It's difficult to say without seeing the code, but if you have > one or two devices that can send data at an unpredictable time, > each of those devices should be connected to a dedicated serial > port. Otherwise you could lose data. > > If you have two of those devices, you've used up both BX-24 > serial ports, so multiplexing Com3 doesn't make sense. What if you have a device that could send unsolicited data, but if it does you don't care if it gets lost. Can you then use multiple lines for Com3 each with their own buffers and safely know that you won't get scrambled data? Call DefineCom3(19,20,bx00001000) Call OpenQueue(InputBuffer1, InputBufferSize) Call OpenQueue(OutputBuffer1, OutputBufferSize) Call OpenCom(Com3, BaudRate, InputBuffer1, OutputBuffer1) Call PutCmd( CByte(LightOff),CurrentAddress) Call GetResult 'Talk to me now or forever hold your peace Call Delay(4.0) Call DefineCom3(21,22,bx00001000) Call OpenQueue(InputBuffer2, InputBufferSize) Call OpenQueue(OutputBuffer2, OutputBufferSize) Call OpenCom(Com3, BaudRate, InputBuffer2, OutputBuffer2) Call PutCmd( CByte(LightOff),CurrentAddress) Call GetResult Call Delay(4.0) Thanks, Bob Roos > > I'd agree with Don's suggestion about using an external UART. > > -- Frank Manning > -- NetMedia, Inc. > Yahoo! Groups Sponsor > ADVERTISEMENT > > Yahoo! Groups Links > > To

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

Bob Looks as though my description is at fault.I'll start again: I already have 3 separate com3 lines, and 3 separate buffers. One for the LCD, one for the radio outgoing data and one for the radio incoming data. The program opens a com3 port,chages baud rate, looks to see if there is data in the queue, deals with it, loops until the buffer is empty, closes the port, moves on to the next. ( this is where I suspect the problem is...when the buiffer is empty, is it actually empty and has the uart done its thing?) There are no sleeps in the main loop, so all this happens quite fast. What appears to happen is if incoming radio data ( which is sometimes unsolicited) appears when I'm not expecting it and doing other things, ( or maybe halfway through closing a com3? I am guessing here) the BX24 crashes . It appears to me that statusqueue is not truthful ( there is a warning about this is the docs) and the magic bit of code to determine if the uart is finished doesn't appear to be robust either. I don't really care if an incoming transmission is missed, because it will be repeated soon after, and all treansmissions are protected by an appended CRC. I may be simplifying things, but my requirement is not all that stringent..a missed transmission or string is taken care of by acks and repeats. It should be easy to manage just 3 I/O neil Bob Roos wrote: >On Tue, 23 Mar 2004 13:11:31 -0700, Frank Manning <> >wrote: > >>From: Neil Jepsen <> >> >> >> >>>[...] >>> >>> >>I'm not sure what you mean -- are you saying there is a data >>overrun in the BX-24 input queue? >> >>It's difficult to say without seeing the code, but if you have >>one or two devices that can send data at an unpredictable time, >>each of those devices should be connected to a dedicated serial >>port. Otherwise you could lose data. >> >>If you have two of those devices, you've used up both BX-24 >>serial ports, so multiplexing Com3 doesn't make sense. >> >> > >What if you have a device that could send unsolicited data, but if it does >you don't care if it gets lost. > >Can you then use multiple lines for Com3 each with their own buffers and >safely know that you won't get scrambled data? > > Call DefineCom3(19,20,bx00001000) > Call OpenQueue(InputBuffer1, InputBufferSize) > Call OpenQueue(OutputBuffer1, OutputBufferSize) > Call OpenCom(Com3, BaudRate, InputBuffer1, OutputBuffer1) > > Call PutCmd( CByte(LightOff),CurrentAddress) > Call GetResult 'Talk to me now or forever hold your peace > Call Delay(4.0) > > Call DefineCom3(21,22,bx00001000) > Call OpenQueue(InputBuffer2, InputBufferSize) > Call OpenQueue(OutputBuffer2, OutputBufferSize) > Call OpenCom(Com3, BaudRate, InputBuffer2, OutputBuffer2) > > Call PutCmd( CByte(LightOff),CurrentAddress) > Call GetResult > Call Delay(4.0) > >Thanks, > >Bob Roos >>I'd agree with Don's suggestion about using an external UART. >> >>-- Frank Manning >>-- NetMedia, Inc. >> >> >>Yahoo! Groups Sponsor >>ADVERTISEMENT >> >>Yahoo! Groups Links >> >>To >> > > >Yahoo! Groups Links

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

In my project the code will be the same for several locations, but the table of exactly what to do will differ. The reason that I want to do it this way is so that I can have just 1 copy of the program and different tables. I don't recall an INCLUDE option where I could INCLUDE the code in each of the different tables. That would work too. or I would like to have a way of just being able to change the table without disturbing the code. Can one load from the PC into persistent storage at a location above the program (say the last 1k of the 32)? This is sort of alluded to in the Operating System reference, but not really described. I also got the impression that there was persistent storage in the BX-35 itself (512 bytes). How do you distinguish between that and the eeprom 32k? Any pointers to more information on persistent storage are appreciated. thanks, Bob Roos

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

From: Bob Roos <> > [...] > Can one load from the PC into persistent storage > at a location above the program (say the last > 1k of the 32)? [...] Check out block data classes. You can define the equivalent of 1D or 2D arrays of several different data types, which are stored in external EEPROM. You can also specify whether the arrays are read/write or read-only. > I also got the impression that there was > persistent storage in the BX-35 itself (512 > bytes). How do you distinguish between that and > the eeprom 32k? Persistent data types (PersistentByte, PersistentSingle, etc.) are stored in internal EEPROM. Block data classes are stored in external EEPROM. Also check out the BX-35 memory map in the hardware reference, page 11. -- Frank Manning -- NetMedia, Inc.

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

On Thu, 25 Mar 2004 09:33:09 -0700, Frank Manning <> wrote: > From: Bob Roos <> > >> [...] >> Can one load from the PC into persistent storage >> at a location above the program (say the last >> 1k of the 32)? [...] > > Check out block data classes. You can define the equivalent of 1D > or 2D arrays of several different data types, which are stored in > external EEPROM. You can also specify whether the arrays are > read/write or read-only. This looks like what I need. The source method is the opposite of what I was looking for in data inclusion. I was hoping that I could compile a module with the data and then have that include the common source. But I could make this work with some preprocessing to copy the particular data file to common name. That is certainly better than trying to maintain many copies of the source code. Do you have any code examples of this? >> I also got the impression that there was >> persistent storage in the BX-35 itself (512 >> bytes). How do you distinguish between that and >> the eeprom 32k? > > Persistent data types (PersistentByte, PersistentSingle, etc.) > are stored in internal EEPROM. Block data classes are stored in > external EEPROM. Also check out the BX-35 memory map in the > hardware reference, page 11. Thanks for clearing this up. Bob Roos > -- Frank Manning > -- NetMedia, Inc.

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

--- In , Bob Roos <wybatap@w...> wrote: > I would like to have a way of just being able to change the table > without disturbing the code. Can one load from the PC into > persistent storage at a location above the program (say the last >1k of the 32)? As Frank said, you can use the block data classes. However, that will require you to recompile the image with each separate table. Another way to accomplish the your goal is to simply append your data to the .bxb file. You'll note that the .bxb file is simply a memory image. What's in it gets written to the external EEPROM; its size must not exceed the size of your external EEPROM or you'll get an error when trying to download. Of course, every time that you compile your application, BasicX will create a new .bxb file without your data so you'll have to append it after each build. Say that you have 32K of EEPROM and your program is 10,285 bytes of EEPROM content (program code plus block data). You'll note that the .bxb file is exactly 10,285 bytes long. If you append 1024 bytes of binary data to this and then download, the EEPROM data from address 10285 through 11308 will be your binary data. Alternately, you could pad the .bxb file out to 31K and then append your 1K of data so that the data will be at EEPROM addresses 31774 through 32767. Accessing the data that has been appended is perhaps a little cumbersome. As far as I know, the only way to get to it is to use the GetEEPROM() routine to copy part or all of the data to RAM. Some routines, like PlaySound() for example, utilize an EEPROM address directly. Overall, the simplest course is probably to use a block data type. To avoid having to re-compile for each separate table, you could write an app that overwrites the table data in the .bxb file producing a new .bxb file with the custom table data. This needs to be done carefully so that you don't disturb anything outside of the table itself. The procedure would be to compile the app with a stock or dummy data table and then run your customizing app N times with N different sets of table data to produce N distinct .bxb files. One way to reduce the liklihood of error when writing the custom table data is to include at the beginning of the table a "signature" and a data size element. Your customizing app would then search the prototype .bxb to locate the signature string and then overwrite the specified amount of data immediately following. This may sound complicated but once it is set up it may be less troublesome than doing a lot of compiles to get your unique .bxb files.

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

On Thu, 25 Mar 2004 18:16:41 -0000, Don Kinzer <> wrote: > --- In , Bob Roos <wybatap@w...> wrote: >> I would like to have a way of just being able to change the table >> without disturbing the code. Can one load from the PC into >> persistent storage at a location above the program (say the last >> 1k of the 32)? > > As Frank said, you can use the block data classes. However, that > will require you to recompile the image with each separate table. yes, but I will only recompile any given table when I am at that site. I think what I will do is put the compile into a BAT file. The source code will refer to a "Tables.txt" and the BAT file will copy the correct table into TABLES.TXT based on a parameter. > > Another way to accomplish the your goal is to simply append your data > to the .bxb file. You'll note that the .bxb file is simply a memory > image. What's in it gets written to the external EEPROM; its size > must not exceed the size of your external EEPROM or you'll get an > error when trying to download. > > Of course, every time that you compile your application, BasicX will > create a new .bxb file without your data so you'll have to append it > after each build. > > Say that you have 32K of EEPROM and your program is 10,285 bytes of > EEPROM content (program code plus block data). You'll note that > the .bxb file is exactly 10,285 bytes long. If you append 1024 bytes > of binary data to this and then download, the EEPROM data from > address 10285 through 11308 will be your binary data. Alternately, > you could pad the .bxb file out to 31K and then append your 1K of > data so that the data will be at EEPROM addresses 31774 through 32767. I could write a windows application (no problem for me) to do this append, but it makes the download step separate from the compile. I guess I could do a BAT thing here too. > > Accessing the data that has been appended is perhaps a little > cumbersome. As far as I know, the only way to get to it is to use > the GetEEPROM() routine to copy part or all of the data to RAM. Some > routines, like PlaySound() for example, utilize an EEPROM address > directly. this is the part that I don't like especially. > > Overall, the simplest course is probably to use a block data type. > To avoid having to re-compile for each separate table, you could > write an app that overwrites the table data in the .bxb file > producing a new .bxb file with the custom table data. This needs to > be done carefully so that you don't disturb anything outside of the > table itself. The procedure would be to compile the app with a stock > or dummy data table and then run your customizing app N times with N > different sets of table data to produce N distinct .bxb files. > > One way to reduce the liklihood of error when writing the custom > table data is to include at the beginning of the table a "signature" > and a data size element. Your customizing app would then search the > prototype .bxb to locate the signature string and then overwrite the > specified amount of data immediately following. This may sound > complicated but once it is set up it may be less troublesome than > doing a lot of compiles to get your unique .bxb files. Thanks for the interesting ideas. Do you have any code examples using block data? I am not into OO stuff at all and had sort of initially skipped over that section of the manual ;-) but I am willing to learn! Bob

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

--- In , Bob Roos <wybatap@w...> wrote: > Do you have any code examples using block data? In the Basic Express Operating System Reference on pages 6 to 8 there is a description of how to use block data classes including some example code. You can also find some sample code at ...\BX24_Docs\App_Notes\Block_Data_App_Note.pdf and ...\BX24_Docs\App_Notes\Examples\BlockData.bas in your installation directory. I have used the block data classes in two applications. In my Ethernet interface project, all of the Ethernet parameters such as MAC address, IP address and mask, gateway address, etc. are stored in a single Byte Vector. The elements of the block data are of different lengths and they are generally copied to RAM variables before being used. The data in this example is 33 bytes long. In my dividing head controller project, the entire menu structure and all of the displayed strings are contained in a single Byte Vector. I wrote a special menu compiler that generates the data file for the vector initialization and some associated constants (e.g. the offsets for accessing various sub-elements of the data table). The former component is generated as a .txt file while the latter is a .bas file which is included as part of the project. The generated byte vector is over 2500 bytes in length.

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

Hi Don, Yes, thank you. Those are perfect. I had seen the OSR stuff, but was looking for a bit more. Speaking of generating Block Data. I wrote a windows application that lets me control all the parameters for all the locations in one easy to use, very friendly manner. Then I just say OUTPUT and it builds my block data files. With command line parameters I could probably have it compile and download too. Onward and Upward On Fri, 26 Mar 2004 00:20:11 -0000, Don Kinzer <> wrote: > --- In , Bob Roos <wybatap@w...> wrote: >> Do you have any code examples using block data? > > In the Basic Express Operating System Reference on pages 6 to 8 there > is a description of how to use block data classes including some > example code. You can also find some sample code > at ...\BX24_Docs\App_Notes\Block_Data_App_Note.pdf > and ...\BX24_Docs\App_Notes\Examples\BlockData.bas in your > installation directory.

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

I am writing to the Block Data Class, but I am doing it every time I start with only 1 download. I have this code: If (FirstTime) then Debug.Print "Writing to Block Data" Call Groups.Source("Groups.Dat") ' Call Lines.Source("Lines.Dat") ' Call Ballasts.Source("Ballasts.Dat") ' Call Motion.Source("Motion.Dat") ' Call PhotoCell.Source("PhotoCell.Dat") End If Every reset button or power on I get the message "Writing Block Dat" I thought FirstTime would prevent that. Any ideas? BX-35 about 1 year or so old. Thanks, Bob Roos

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

--- In , Bob Roos <wybatap@w...> wrote: > I am writing to the Block Data Class, but I am doing it every time I start > with only 1 download. > > I have this code: > > If (FirstTime) then > Debug.Print "Writing to Block Data" > Call Groups.Source("Groups.Dat") > ' Call Lines.Source("Lines.Dat") > ' Call Ballasts.Source("Ballasts.Dat") > ' Call Motion.Source("Motion.Dat") > ' Call PhotoCell.Source("PhotoCell.Dat") > End If > > Every reset button or power on I get the message "Writing Block Dat" > > I thought FirstTime would prevent that. Any ideas? BX-35 about 1 year or > so old. > > Thanks, > > Bob Roos Hi Bob. I don't know whe FirstTime doesn't work. It works for me. But it doesn't make sense to put the *.Source commands in an If- clause as these commands are not executed at runtime, but rather parsed at compiletime. I.e. They only work FirstTime anyway. In other words, the content in the source files are not sent to the BX (except for in the array) making it possible to re-initialize at reset. You will have to download the code again to re-initialize the arrays. BR Ingvar

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

Ingvar, It was the CALL that threw me. I thought it had to be executed to happen. The book says: "The Source method must be called before reading or writing to the object's internal data. The Source Argument must be a single string literal" Page 6 OSR. Page 7 says: "Warning -- if you attempt to read or write to the Value Property before calling the Source method, results are undefined...." this led me to believe that it had to be executed to happen rather than making the file name & path part of the definition. now I am more confused ;-) I will play with FirstTime without block data and see what happens. Bob >> >> I have this code: >> >> If (FirstTime) then >> Debug.Print "Writing to Block Data" >> Call Groups.Source("Groups.Dat") >> ' Call Lines.Source("Lines.Dat") >> ' Call Ballasts.Source("Ballasts.Dat") >> ' Call Motion.Source("Motion.Dat") >> ' Call PhotoCell.Source("PhotoCell.Dat") >> End If >> >> Every reset button or power on I get the message "Writing Block > Dat" >> >> I thought FirstTime would prevent that. Any ideas? BX-35 about 1 > year or >> so old. >> >> Thanks, >> >> Bob Roos > Hi Bob. > I don't know whe FirstTime doesn't work. It works for me. > > But it doesn't make sense to put the *.Source commands in an If- > clause as these commands are not executed at runtime, but rather > parsed at compiletime. I.e. They only work FirstTime anyway. In > other words, the content in the source files are not sent to the BX > (except for in the array) making it possible to re-initialize at > reset. You will have to download the code again to re-initialize the > arrays. > > BR > Ingvar > Yahoo! Groups Sponsor > ADVERTISEMENT > > Yahoo! Groups Links > > To

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