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

Some thoughts: I assume the intent behind trying to be compatible with VB is being able to develop a module on a PC then port it over to the BX. That seems like a good idea to me but I've seen some posts on this list the last few weeks (and the last day or so) that indicate that VB compatibility might be getting in the way of the best development environment. One example that springs to mind is the variable length string always being 64 characters. Fine for a PC with 32MB, bad for a BX-24 with several hundred bytes. I've used VB once because I had to but otherwise I do assembly/C/C++, and on my BX-24 I do all my debugging through the serial port using routines I've put together myself. I intend to develop those routines into a debug monitor and never use VB for anything, ever. In the past I've programmed PICs in assembly and used their simulator to develop my algorithms, and I've not found this to be any more onerous than using a higher level language I imagine you did some research before you started developing this product and perhaps you felt that the VB compatibility was a strong enough feature to pursue. Now that you have a user base, perhaps a survey of what that base would like to use would be appropriate. How many users are using BASIC outside of this product? Not me - I'm learning BASIC by using my BX-24 anyway so it doesn't matter to me much whether it's that or some proprietary language. My preference would be something much closer to C. I guess it comes down to VB being a language for application writers, but the BX products are far more low-level and the people who program them are more likely to be systems guys and therefore versed in asm/C/C++. My two cents, and my compliments to Frank for his extensive involvement in this list and his top-notch support. Matt Daughtrey, Congruent Software Office 212.941.7500 Cell 917.743.5704 Pager 800.708.7524,

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

I have my own wish list for basicx. I am perfectly happy to use the basicx IDE and don't care about developing under VB, but I would like syntax highlighting and autoindent. I believe that with a reasonable IDE, VB users can easily use the product even without the VB IDE and rely on their experience. I suppose the VB compatibility issue is important to Netmedia because they want to make their product attractive to the hordes of VB programmers out there. I don't blame them, and I think it is indeed a great idea. I also don't think 100% compatibility is necessary in order not to lose attraction to the VB crowd. I believe it is important to weigh the advantages/disadvantages and in some cases allow statements that are not VB compatible where it makes sense. I also believe that the installed user base should weigh most heavily in deciding what makes sense and what doesn't. After all, Netmedia wants to sell their product and wants their users to be happy with it. If existing users have problems with features of the product, then it makes sense that future users will also, unless changes are made. String storage and handling in basicx is not as well thought out as it needs to be, given the architecture, period. I like basicx because of the multitasking, networking, development board with in circuit emulation and all the features, it is a great concept and a great product. My main interest in using basicx was centered around the idea that it would allow me to do faster development than with other tools, but it has enough problems that I have chosen to concentrate on other tools for AVR. Now, here is the biggest item on my wish list. Rather than have the operating system code preexisting in the chip, containing code for all the functions whether I use them or not, I would prefer that the OS, networking and functions be in a library to be built with my code at compile time and only include those functions that I need. Yes, I would not have to buy Netmedia's BX01 chips anymore (actually, I don't expect to buy any more of them at this point anyway), but I would pay for such a compiler that contains the multitasking OS and the serial networking in libraries. With all the preexisting code that Netmedia has, I just can't believe that this is not feasable. I would also like to be able to determine accurately and reliably task stacks and how they will or will not work within program memory. Given the inconsistencies of basicx at this point and the difficulty in using the product reliably, I can only consider it an interesting toy and I would not develop with it for a customer. It is also true that I would very much like to be able to do so reliably, or I would not give this feedback to Netmedia and the basicx community. Kurt Stevens

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

> From: Matthew Daughtrey <> > > Some thoughts: > > I assume the intent behind trying to be compatible with VB > is being able to develop a module on a PC then port it over > to the BX. [...] Well, that's a side benefit, but the intent is to reduce the headaches in porting a program from one machine or compiler to another. Of course, a lot depends on what other VB compatible compilers become available on other microcontrollers. The OOPic is one example. Will there be others? Believe me, it's a lot easier for us to develop a proprietary language than to conform to an existing one. -- Frank Manning -- NetMedia, Inc.

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