I am right now using bascom, or, should I say, trying to, which, even on this forum was touted by some to be the best. Well, I've been struggling with it for almost 3 days now, and it just won't send the program to my chip. Of course bascom does not support the trial version. There is one lady who has been trying to help me, but to no avail. I have tried everything I can think of. I can compile the code ok, but then I cannot send it to the chip thru bascom. An error message shows up and stays on screen for all of about 60 milliseconds. I know because in order to read it, I had to use my dv camera and record the screen, and then play it back frame by frame. The error message just says to see the log above. Trouble is, there is no log above. So far I have only been able to send it using avrstudio. It uses the hex file, but even that's not so reliable. It kind of works when it feels like it.
So I seek the advice of those who have probably been there and done that.
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.
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?
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?
In article , snipped-for-privacy@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:
(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.
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!
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.
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.
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.
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
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.
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 :-)
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.
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.
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.
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!
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.
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!
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.