AVR-Chat

Larry Barello wrote:

> Anyway, I still maintain that BASCOM is a great way to get started as 
> it is
> entirely self contained, reasonably efficient and has lots of pre-built
> hardware support libraries.

As you mention I think there are a range of alternatives. Which 
alternative you choose depends on what you are trying to do and how well 
the chosen architecture has been implemented. For example a buggy 
compiler and code library will not be used as it cannot be depended on 
and back to the original question, the quality of support and the user 
community may also have a bearing on which platform you choose. Below 
are 4 broad categories; the first two categories are good for beginners 
or prototyping and the last two categories are best for experts and 
production level applications.

1. (BASIC )Interpreters - Code is tokenized and downloaded to EEPROM 
memory for execution by an "interpreter-on-a-chip". Performance tends to 
be poor to very poor and has limited capabilities because of the 
requirement to implement the complete BASIC language on a chip. Easy to 
get started with. Although not AVR based the most common example is the 
Basic Stamp.

2. (BASIC) Compiler plus Virtual Machine - Code is compiled and 
optimized into an intermediate virtual machine language which is 
downloaded to EEPROM memory. The virtual machine language is usually 
quite functional and stack-based. The virtual machine executes the 
program but performance is poor to average. Easy to get started with. 
Example is BasicX.

3. (C, BASIC or Forth) Compiler - Code is compiled to AVR machine code 
and downloaded (programmed) to the flash memory. Performance is good. 
Function libraries can help with getting started but nevertheless this 
requires a certain degree of user sophistication. Examples are Bascom 
and AVR-GCC.

4. Assembler - Performance is very good albeit not always required. This 
is most difficult to get started with and requires a lot of programming 
skill and is the least productive compared to the other alternatives 
based on 3GLs. Most assembly language programmers end up building their 
own library of routines that they reuse across solutions.

>
> I do 95% or more of my work with avr-gcc.  I use BASCOM strictly for
> teaching and getting newcomers started.  Having a completely useful 
> compiler
> for free doesn't hurt either. 

I think you are partly right here.  Again for one-off prototyping and 
even for teaching you may find BasicX or similar better than Bascom. I 
have also seen BasicX used for short-run production applications 
(<1000). I can see a lot of merit in solutions such as the Bascom 
compiler although once the code has been compiled, you pretty lose any 
abstraction layer that you had with the Basic language.

> I can't imagine doing a large multi-file/task project in Basic, but there
> are plenty of engineers out there that do.  If you have a large chip and
> modest requirements you can bang out a tremendous amount of functionality
> with little prior experience using BASCOM.  That is why there exist 
> markets
> for Basic Stamps, PICAXE and other PIC based "easy to use" processors.  It
> is just that BASCOM is way cheaper and way faster than the heavily 
> marketed
> alternatives.

BasicX supports multi-file projects quite nicely including the ability 
to define module public and private functions, variables and constants. 
I'm not sure I quite agree with the statement on cost. If you examine 
the total cost of ownership, things even out a bit more. For example a 
AVR hardware programmer is needed if you intend to use Bascom or C. Off 
the shelf this is $29 from digikey although it is possible to build your 
own that is cheaper (see my website for an example). The Bascom compiler 
itself is also not free although some of the alternatives for C such as 
AVR-GCC are as you mention.

Mike
http://home.austin.rr.com/perks/basicx/ (not just BasicX projects)