BASCOM for AVR?

I'm not using it myself, but a colleague used to. He used to be quite happy with it, until he realised he spent too much time debugging nasty problems which were caused by the buggy implementation of the 'drivers' and libraries that come with it. He also mentioned that the chip-specific header files with register- and bit-names seem to be incomplete and inconsistent sometimes.

It's still Basic, but of course that's not what you want to hear :)

Seems like Deja Vu all over again:

Unfortunately my knowledge of my own past postings is not encyclopedic ((embarrassed grin)) ... besides, the reliabilty of a product can go up or down considerably over that period of time.

Also, back then I was thinking about using it for an 8051 project; now it's AVR. I used it today and it seems to work well; hidden problems are what I'm wondering about.

No information about BASCOM transpired then, either. Only that BASCOM has no snob appeal because it's not C.

It works quite well when using peripherals and components that it supports. So one can get quite complex things going quite quickly if there is library support for what you want to do. Unfortunately as soon as you want to do something reasonablt complex which is not supported by the libraries, you are stuck. To then switch to C, you basically have to start from scratch. IMO using something like this, is counter productive in the long run. Using something like Codevision for the AVR also gets one going very quickly, but if one then wants to go further than the available libraries, you are coding in C, and it is much easier getting other source code going, or writing your own low level stuff.

Regards Anton Erasmus

Please tell me more about Codevision.

Codevision is a decent toolset for the C language on AVR, and I don't mean to take away from that, but recent versions of AVR Studio do a tremendous job of supporting gcc development. This includes full debugging like breakpoints, single-step, etc.

If you're not already familiar with the C language, AVR Studio and gcc can give you a chance to take a look without costing you a dime. And they won't expire in 30 days.

Having said that, BASCOM is pretty decent, and is a much quicker way to get things done. In my mind ot comes down to what you're comfortable with. BASCOM is more like a Basic Stamp - it is a quick way to focus on the problem and not the language. C is more flexible, especially given the vast amount of source code you can find in C to solve many different requirements.

I like them both. Like most modern embedded developers, I think a working knowledge of C is essential, but BASIC is good when you're in a big hurry.

Eric

Ah... right. I have both gcc and ImageCraft. Need to get into them. I know C but don't like C.

(Should have explained that I'm not a newbie, I'm a computer science professor, but not specializing in microcontrollers.)

The advantage and disadvantage of BASIC is that it's open-ended; implementors are free to add new statements (not just library functions). As a result, in BASCOM you have a special line for configuring all the port pins for an LCD. In C it's about 16 #define's.

I don't think programming language progress came to an end in 1978 or whenever it was that C came out. I'm not really enamored of BASIC either -- I think the time is right for a new language for microcontrollers.

But my question about BASCOM was simply whether it is reliable or has hidden disadvantages. It seems to work well. I have nothing against tools that make the job easy. That's what tools are for. The only question is whether BASCOM can be taken at face value or whether any hidden "gotchas" are going to get me. Nobody has pointed out any problems with it so far.

Liking it isn't a requirement :-)

I like the reliability of Java and C#, but we're not quite there yet with small micros. NanoVM is a cool step in the right direction.

Hmm...BASIC and Pascal came out of universities. Maybe you have some ideas for a new language?

Eric

Starting to, actually. BASCOM has good ideas but isn't systematic. C is systematic but locked into a rigid structure that doesn't always meet our needs.

The big need that I see is this: We need to give the compiler a lot of declarative information to tell it how to generate code. (E.g., what the clock speed is, which LCD pins are wired up to which port pins, etc.) C does this clumsily with #define and it can take 16 #defines to set up an LCD. What we need is something that is conceptually (not syntactically!) like the old COBOL "Environment Division," where you make a lot of declarations to tell the compiler what hardware it's generating code for. The compiler then uses this information as it goes along.

As small languages go, I much prefer Pascal to C. C# is very nice but I can't see how to scale it down small enough to be practical for an ATtiny or PIC.

I think there's Pascal for AVR. Has anybody ever used it?

A lot of IDEs have some kind of wizard that helps define things for you. Sometimes it an extrernal program. Microchip has a cool program like this for the PIC24 devices. It's a graphical program that displays the modules and pins of the chip. You click on a module to bring up its properties and then you select which pins it uses and it's various settings. The graphical display then changes the colors to show that you are done configuring that module and it changes the colors of the pins you selected to show that those pins aren't available for other purposes. It auto-checks these things as you configure other modules and gives you an error msg if you try to set things up in an incompatible manner. When you're done it spits out the C code to make these settings for you. This is a free tool, as is the MPLAB IDE and C30 compiler (based on gcc, but supported by Microchip).

Since NanoVM is an extremely small JVM for 8K Atmel AVRs, it stands to reason that we can do this for the CLR also. There's also a free tool that plugs into VS2003 that generates code for H8 MCU's (an 8 bit MCU used in the earlier Lego "brick"). This is very do-able, but would require some time to make it useful for AVRs or more modern devices, and I'm just too busy right now. But when it comes to PICs I'd target the PIC24 and dsPIC families since they are much stronger processors and have all of the same easy prototyping capabilies (DIP packages and lots of free software) that make the PIC16 and PIC18 so appealing.

I know of 2 different products that have embedded Pascal support, but I haven't tried them myself. Maybe someone else can weigh in on this:

Eric

Creating it by wizard is a Good Thing, but then it needs to become a textual part of the program.

Yes. Sounds like a good idea. It would need to be a principled subset of the CLR.

Codevision is a reasonably standard C compiler for the AVR with an integrated IDE. What makes it easy to get going is a Code Wizard to initialise most of the peripherals as well as a set of libraries for standard components such as LCDs.

Look at http://www.hpinfotech.ro/html/cvavr.htm for more info

Regards Anton Erasmus

That sounds handy. I gather the wizard generates C code which you can then look at and edit?

Is it considered reliable?