Can anyone recommend a basic compiler for atmel avr that actually works?

your subject:
Re: Can anyone recommend a basic compiler for atmel avr that actually works?

sounds like you are saying the compiler doesn't work, when it is the
download that isn't working. This may well be your fault, or a
programmer hardware fault, and not Bascom. As you say, it is unreliable
using avrstudio.

Suggest you check your hardware settings, and get advise from the user
group, before you condemn this product. They will give you support, even
on the demo software.

Don...



--
Don McKenzie
E-Mail Contact Page:               http://www.dontronics.com/e-mail.html

Crystal clear, super bright OLED LCD (128x128) for your microcontroller.
Simple serial RX/TX interface. Many memory sizes.
http://www.dontronics-shop.com/product.php?productid 460

Yes, that is exactly what I am saying, and your response is
predictable. Just like the girl on the forum told me. You may want to
have a look at the forum, under the topic. "need help with first
program". There was only one person who tried to help, she's from
Denmark, you probably know her or have seen her posts.

It's 2 pages long of going back and forth between her and I over the
past 3 days and nights.. Photos of different screens, and finally I was
able to record, using a dvcam, the error message I get when i try to
"send the program to chip" . I couldn't screen print it because it only
stays up there for 60 to 70 milliseconds and disappears. It doesn't
tell me much anyway. We finally came to the conclusion that what is in
my programmer is indeed a mega8515, not a AT90S8515.

To date, no one else has been willing to help. I talked with an app
engineer from Atmel yesterday, and he said not to worry, that as long
as avrstudio4 can program the hex code that bascom generates, then what
is the problem? OK, well he is right, but the key words there are "as
long as avrstudio can program using the hex code".

Just going out on a limb here, but I am assuming you are a reseller of
bascom?

Joe

nuisancewildlife@earthlink.net says...

Taking the first step is often a difficult one. It requires everything
to go right from beginning to end. Even the typical simple "first
blink" type of program can be a bit tough to get to happen. There are
often to many variables in the process that can affect the outcome.

Somewhere in your chain of processes is a broken or weak link. It can
often be frustrating to find that link.

Simplified, you create object/hex code from source, then transfer that
to the microcontroller. In this case the source is BASIC that BASCOM
converts to a hex file. The source could just as easily be C or assembly
with other tools.

The STK500 is the hardware used to transfer the hex file to the chip.
That could also be other hardware - the AVRISP, or even a homebrew
parallel port programmer.

It appears that the weak link is the interaction of BASCOM and the
STK500. Sounds very much like BASCOM is able to compile your source to a
hex file. And also that you have had at least some success with using
AVR Studio to transfer the hex file to the processor.

BASCOM's main job is to compile BASIC source to a hex. Sounds like that
is happening. BASCOM needs to know what chip to compile for, so that it
can manage the memory locations for flash and RAM for the specific
target. (And use the correct ports/peripherals.) There are settings in
the compiler and in the source code that can define the target chip and
the clock frequency for the target. Those need to be correct to
correctly generate the hex file.

BASCOM doesn't talk directly to the STK500, but provides a way to
connect to the STK500 using the program (AVR Studio) that is installed
with the STK500. When things are set up right, it is very convenient
that a button push in the BASCOM IDE will get the compile and program
your target chip. Sometimes getting this convenient feature set up
correctly can be troublesome. (That might be were your trouble lies.)

If you set aside this for a moment, you might be able to confirm at
least that you have generated a hex file correctly by using AVR Studio
and the STK500 to program your chip from the hex file. If you can
confirm that some steps of your process work correctly, then it will be
easier to identify the weak link and get all of the steps to work in
concert.

Give BASCOM a chance. It is a very good program. The problems that you
are having appear to be in getting BASCOM linked to the programmer that
you purchased (the STK500). This is, by-the-way, the same thing that I
went through with BASCOM and the AVRISP that I use. BASCOM was
generating the hex file and I could use AVR Studio to program the chip.
Once I knew that both ends of the process worked correctly, then I was
able to resolve getting the two major steps correctly linked.

Thank you very much for the reply. You are quite correct. Bascom is
compiling the program. BTW, this program was supplied to me by one of
the users on the mse forum, and has been confirmed to work.

When I discovered that bascom could not send the program to the chip, I
just went into avrstudio to see if maybe something was different, or
wrong, and it was quite by accident that I ended up with avrstudio
asking for a hex file, so I supplied it with the hex file that had been
generated by bascom, and with one click, the chip was erased, and
programmed with the new file. Presto! Like magic.

So I am still fumbling, although not so much in the dark anymore. I
shall continue this pursuit now based upon your words of encouragement,
and I will find the problem of why bascom is not able to send the
program to the chip.

Now a question for you: Is the program supposed to be in a certain
location for bascom to find it, because I put it into my "robotics
folder", and had to specify the location to avrstudio, so what I am
wondering is that maybe bascom doesn't know where to look?

Thank you for the info,

Joe

nuisancewildlife@earthlink.net says...


You moved the stk500 programmer program? Or your source?

Bascom should load the hex from where the project files are, so if you
moved your source, you should be OK.

Make sure BASCOM is finding stk500.exe.

Run BASCOM. Look on the menu under Options, then Programmer. A box is
brought up that lets you pick a specific programmer - you would pick the
STK500. Several options down is a text box that would/should contain the
full path to stk500.exe. By default this is:

C:\Program Files\Atmel\AVR Tools\STK500\Stk500.exe

(I think that is the default. I don't remember moving anything around.)

Edit this text to correctly point to your copy of stk500.exe. Also make
sure that the serial/com port and baud are appropriate for the STK500.

If BASCOM tries to run stk500 but the program isn't there, that might
account for your 10 millisecond window flash that you captured with a
video recorder. BASCOM thinks that it passed the .hex file and ran
stk500. A DOS box pops up, but disappears faster than the human eye can
read the error. Might be the same if the port or baud are wrong.

BASCOM just runs stk500 on a command line with the hex file as a command
line parameter. You could do that, too, if you have a fondness for
commandlines.

Here are the parameters for stk500. This is all hidden in the click of
the program button by BASCOM.
 




STK500 command line programmer, v 2.2 Atmel Corp (C) 2004-2005.

Command Line Switches:
    [-d device name] [-m s|p] [-if infile] [-ie infile] [-of outfile]
    [-oe outfile] [-s] [-O address] [-Sf addr] [-Seaddr] [-e] [-p f|e|b]
    [-r f|e|b] [-v f|e|b] [-l value] [-L value] [-y] [-f value] [-E
value]
    [-F value] [-G value] [-q] [-Y] [-Z address] [-c port] [-ut value]
    [-Wt value] [-ua value] [-wt] [-wa] [-b h|s] [-! freq] [-t] [-I
freq]
    [-J] [-h] [-?]

Examples:
    STK500.EXE -dATmega128 -e -ifFlash.hex -pf -vf
    STK500.EXE -dATmega128 -fF73A -FF73A -EFF -GFF

    Note that there are no spaces between switches and their parameters
    and that hexadecimal values do not have a '0x' prefix.

Parameters:
d   Device name. For a list of supported devices use STK500.EXE -?
m   Select programming mode; serial (s) or parallel/high-voltage (p).
    Serial mode is the default mode if this parameter is ommitted.
if  Name of FLASH input file. Required for programming or verification
    of the FLASH memory. The file format is Intel Extended HEX.
ie  Name of EEPROM input file. Required for programming or verification
    of the EEPROM memory. The file format is Intel Extended HEX.
of  Name of flash output file. Required for readout of the FLASH memory.
    The file format is Intel Extended HEX.
oe  Name of EEPROM output file. Required for readout of the EEPROM
    memory. The file format is Intel Extended HEX.
s   Read signature bytes.
O   Read oscillator callibration byte. 'address' is the address of the
    calibration byte as decribed in the data sheet of the device.
Sf  Write oscillator call. byte to FLASH memory. 'addr' is byte address
Se  Write oscillator call. byte to EEPROM memory. 'addr' is byte address
e   Erase device. If applied with another programming parameter, the
    device will be erased before any other programming takes place.
p   Program device; FLASH (f), EEPROM (e) or both (b). Corresponding
    input files are required.
r   Read out device; FLASH (f), EEPROM (e) or both (b). Corresponding
    output files are required
v   Verify device; FLASH (f), EEPROM (e) or both (b). Can be used with
    -p or stand alone. Corresponding input files are required.
l   Set lock byte. 'value' is an 8-bit hex. value.
L   Verify lock byte. 'value' is an 8-bit hex. value to verify against.
y   Read back lock byte.
f   Set fuse bytes. 'value' is a 16-bit hex. value describing the
    settings for the upper and lower fuse.
E   Set extended fuse byte. 'value' is an 8-bit hex. value describing
the
    extend fuse settings.
F   Verify fuse bytes. 'value' is a 16-bit hex. value to verify against.
G   Verify extended fuse byte. 'value' is an 8-bit hex. value describing
    the extend fuse settings.
q   Read back fuse bytes.
af  FLASH address range. Specifies the address range of operations. The
    default is the entire FLASH. Addresses are byte oriented.
ae  EEPROM address range. Specifies the address range of operations.
    The default is the entire EEPROM. Byte addresses.
Y   Perform the oscillator calibration sequence. See appnote AVR053 for
more
    information.
Z   Loads a value from an EEPROM location prior to chip erase which then
    can be programmed into FLASH or EEPROM using the S option. Address
is
    a hex value. See appnote AVR053 for more information.
c   Select communication port; 'com1' to 'com8'. If this parameter is
    ommitted the program will scan the comm. ports for the STK500
ut  Set target voltage VTARGET in Volts. 'value' is a floating point
    value between 0.0 and 6.0, describing the new voltage.
ua  Set adjustable voltage AREF in Volts. 'value' is a floating point
    value between 0.0 and 6.0, describing the new voltage.
wt  Get current target voltage VTARGET.
wa  Get current adjustable voltage AREF.
Wt  Verify that VTARGET is within 5% of the given value. 'value' is a
    floating point value between 0.0 and 6.0.
b   Get revisions; hardware revision (h) and software revision (s).
!   Set oscillator frequency; 'freq' can be whole Hz, or kHz or MHz
t   Get oscillator frequency.
I   Set ISP frequency; 'freq' can be whole Hz, or kHz or MHz
J   Get ISP frequency.
g   Silent operation.
z   Not used. Supported for backwards compability.
h   Help information (overrides all other settings)

Supported devices:
    To display supported devices type "STK500.EXE -?"

Wow, you know, I have no idea what all that means. What I meant was
that my source file was not in the same folder with bascom. Anyway, it
turns out that the chip was mislabeled. The girl on the ms electronics
forum had me send her the signature block (from avrstudio)last night
and from that she positively identified it as a ATmega 8515, not the
AT90S8515 that was written on the chip (I guess this happens  like
1/100th percent of the time, if that).

So I was up most of the night working on the assumption that she was
correct, and then obtained the data sheets for the mega8515, changed a
few lines of code at the top of the source file to reflect that it was
a mega 8515, and just awhile ago (finally), I was able to compile, and
send to the chip using bascom. I had two programs that it worked with,
so I am a believer now. To success and victory!

Problem solved.

And to follow up with this, to Don, I apologize if I came off a bit
snappy this morning in reply to  your post,  after being up almost all
night, working on this, I was a bit grouchy to say the least.

At least this chip is IMHO, better than the one I thought I had.
According to the data sheets, it has 3 PWM outputs, perfect for speed
control for my now bang bang vehicle. That is, once I figure out how to
use them. Now to the H bridges!

Thanks again to all who helped,

Joe

I have never heard of this Joe, and I have sold and been involved with a
lot of micros.

You may get a good price on Ebay for it. :-)


not a worry at all. I know the frustration.
I went through similar things in the mid 70's, and there was no one to
turn to. I mean no one. The web is magic.

Cheers Don...


--
Don McKenzie
E-Mail Contact Page:               http://www.dontronics.com/e-mail.html

Crystal clear, super bright OLED LCD (128x128) for your microcontroller.
Simple serial RX/TX interface. Many memory sizes.
http://www.dontronics-shop.com/product.php?productid 460

Ah yes, the 70's. I remember doing physics problems with a slide rule.
That would have been around 1975. The professor's opinion of
calculators (though they were few and far between at that time, and
expensive) was, and I quote: "When you use your calculator, you put
your brain in your pocket".

About a year later, we were allowed to use them. I still have my old
Texas Instruments 30C, which is light powered and did a few
'scientific' calculations, like sin, cos, tan, and other basic stuff.
It still works too! Wonder what I could get for that on ebay :-)

Regards,

Joe

I wouldn't have even thought this was possible. The chips are from
different eras, if not production lines!

I agree with Don: you might be able to get something for this on eBay.
Sort of like the upside down Jenny stamp that is worth $1000's to stamp
collectors.

-- Gordon

Well, right now I am having too much fun with it. Hence the delay in my
reply. Now that everything is working, I am just having too much fun.
Of course, I could send to digi key for another one and put this one up
on the auction block...hmmmm.

Joe

Are you asking for a compiler that translates the BASIC programming
language, or a compiler that has a basic feature set?

avr-gcc works well for me to translate code written in C

If you are asking about the BASIC language then I'd have other choice
comments since I don't believe that language is appropriate for embedded
systems programming.

These types of compilers compile down to assembler with a limited
instruction set in any case, so what's your beef?

We're only dealing with syntax here, and it's not much different than
saying text in blue produces better results than text in red. All things
being equal, in a well-designed optimizing compiler, it shouldn't matter
if it's Basic, C, Pascal, Java, or Klingon. Microcontrollers have
limited hardware and a Basic or C or whatever compiler will use the same
assembler code to do things like set interrupt vectors, toggle a
register, or branch.

-- Gordon

Of course, we are all entitled to our opinions. When I made that post,
I was worn out and frustrated from spending about 2 days (and nights)
trying to figure out why the BASIC compiler would not send the compiled
program to the chip.

It's all working right now, so everything is just ducky...

May I ask why you don't believe BASIC is appropriate for embedded
software? It compiles, creates hex file, object file, and for my
application (robotics), it will do very nicely.

BASIC was the first language I ever learned way back in the old days.
Because I learned it, I was later able to learn Fortran, and PASCAL,
which I know are now probably also considered "outdated". It also
opened a lot of doors for me when I graduated university in 1979 with a
degree in Physics because there were not many engineers/physicists who
could program a computer. I worked in the defense industry automating
test equipment with (here's a real good one for you) a language called
hpl. Written by Hewlett Packard for their orignal HP 9815 computer.
Then their 9825's and 9836's also used the same hpl. It was just like
BASIC, but with Hewlett Packard's extra special touch.

I am back in school now, and plan on taking Java next year. That is
because now our computer science dept (which didn't even exist when I
graduated) requires you to learn object oriented programming first.
That will probably be the one and only CS course I take as I have no
interest in learning C or C++. What I have works, and if it
works....I'm sure you know the rest.

You sound like a hard core computer scientist (nothing wrong with
that). I have been using BASIC for years now, even have a version on my
home computer (the one I am using now) and I still use it to solve
complex physics, mechanics, electrical, and engineering problems. Now I
can even use it for embedded software. Well, like I said to Gordon, I
am having too much fun.

Regards,
Joe

If you want to look ahead a little, you will find that C is much more
satisfactory language to use for anything over a page or two, so why not
start now ?

I recommend using AVR processors and the excellent winAVR C compiler - the
price is right and it works very well.

As soon as your programs reach a reasonable size you may find some sort of
in circuit emulator/debugger a great boon. I use the JTAGICE2, which does
the job well after a rather steep learning curve and mediocre documentation.

One great advantage of the JTAGICE2 is that there are no (expensive)
emulation pods etc to buy, and the impact on your pinout is minimal.

Invest effort in tools that will carry you a long way towards your goals

Dave

Thank you very much for the advice. I just happen to like BASIC. It
doesn't matter to me how long the program gets, as long as it gets me
to where I want to go (the solution). No offense, but I have a friend
who earns beaucoup dollars as a computer scientist (He knows all the
'modern' languages). He keeps telling me the same thing.

What I have told him is that what he tells me about BASIC compared to
the more "modern" languages would be like me telling him that Newton's
Laws no longer apply to basic mechanics. A fellow by the name of Albert
Einstein made a whole new theory called General Relativity, which
horrified physicists in his day. Took Newton's Laws and turned them
upside down. But in the classical domain, GR,  (ie, in the context of
every day experience) breaks down to Newton's Laws anyway. So what's
the diff?  C and the other 'modern' languages evolved from the earlier
languages like BASIC, FORTRAN, and PASCAL.

Oh, and let's not forget Quantum Mechanics...

"They stood on the shoulders of Giants"

Anyway, as long as BASIC is here to stay, I will stay with it.

Best Regards,

Joe

Joe:

Noone:

Dave:

I've programmed microcontrollers in assembly and C for over two decades.
Worked on a considerable number of embedded projects/products with a
wide range of complexity and function. I've lost track of all of the
assemblers and compilers that I've used. I'll keep doing things this way
for another decade or two, probably.

But I purchased BASCOM, too. I'm not using BASCOM for saleable products,
but for the miscellaneous prototype or proof-of-concept work that I do.
It works well.

To Joe: Don't let anyone discourage you. Explore using BASCOM.
Investigate C if you want to. But if you are comfortable using BASCOM
for your robotics, then that is great. BASCOM is a great way to start.

Good luck with your projects!

 

Well, I should have read your post first ! Maybe I wouldn't have spewed
my dedication to BASIC so vehemently. No, I will not be discouraged.
When I find myself getting frustrated, or, a little discouraged, I just
work harder.

You have quite an impressive background as described above, and I
appreciate your encouragement. You are right, and I intend to use
BASCOM from now until, well, who knows?

I have watched the progress of computers since the days when I worked
at Honeywell Information systems and COBOL I was the latest and
greatest. The days of huge tape drives, and platter disks. The days
when the equivalent of the computer I am typing on now needed a fully
air conditioned room to accomodate them. The days of punch cards. Ah
nostalgia. But I am glad those days are gone.

Now we have tiny little 40 or 20 pin chips that can perform amazing
feats, and can be programmed over and over again to boot!

Thank you again,

Joe

IMO, it's not "BASIC" but Basic. There is virtually no comparison to a
Basic like Bascom AVR or Visual Basic 2005 to the BASIC language of the
60s and 70s. These days, the only real difference between C and a good
Basic compiler is semi-colons for line-ends and braces to close
structures. Yes, as an option some Basic environments still allow things
like auto-promotion of data types, which can lead to sloppiness and
bugs, but this is not the language but the environment.

-- Gordon

You are right. I shouldn't keep typing all caps, but in the beginning,
it was an acronym for Beginner's Advanced Symbolic Instruction Code,
and that stuck with me. Basic it is then. There have been many changes
like no more line numbers (whew!), and now it is compiled most of the
time, instead of interpreted. Yes, Basic has come a long way. And, lest
I forget to mention it, I am enthralled with Bascom!

Joe