>>large body of freely available existing code for the particular compiler-language so I can drop in an I2C class, LCD routines etc and not waste my time writing and debugging such code. This is part of the index from the Codevision Docs: ---------------------- Character Type Functions Standard C Input/Output Functions Standard Library Functions Mathematical Functions String Functions Variable Length Argument Lists Macros Non-local Jump Functions BCD Conversion Functions Gray Code Conversion Functions Memory Access Functions Delay Functions LCD Functions LCD Functions for displays with 4x40 characters LCD Functions for displays connected in 8 bit memory mapped mode I2C Bus Functions National Semiconductor LM75 Temperature Sensor Functions Dallas Semiconductor DS1621 Thermometer/Thermostat Functions Philips PCF8563 Real Time Clock Functions Philips PCF8583 Real Time Clock Functions Dallas Semiconductor DS1302 Real Time Clock Functions Dallas Semiconductor DS1307 Real Time Clock Functions 1 Wire Protocol Functions Dallas Semiconductor DS1820/DS18S20 Temperature Sensors Functions Dallas Semiconductor DS2430 EEPROM Functions Dallas Semiconductor DS2433 EEPROM Functions SPI Functions Power Management Functions ---------------------- I expect the others have a similar list. I don't think GCC does, but since it's open source there are many examples published everywhere - probably has the biggest online codebase. >>I would like to have the option to port my code to other micros if the need arises. GCC is the most portable by far. (GCC for the AVR is itself a port) Codevision & Imagecraft are C so the C code is portable, however the chip specific stuff (setting and reading ports, ADC PWM etc) and UI isn't. You can take GCC code and import it into Codevision (and vice-versa) but it needs a lot of work - unless you design portability into the code in the first place. If you anticipate needing to take an AVR program and porting it to a PIC then GCC is clearly your best bet. -----Original Message----- From: markevans_1 [mailto:markevans@iinet.net.au] Sent: March 16, 2004 12:31 AM To: AVR-Chat@yahoogroups.com Subject: [AVR-Chat] Re: AVR Compiler: which is the best Thanks for all the replys. I have written a handful of programs for AVR and PIC in assembly. I find once you start to include LCDs (especially graphical ones) to the project the code gets quite large quite quickly. So my main reason in looking for a higher level compiler is for managability. As for language preference, I have significant experience in C/C++, java and a bit of BASIC but am not adverse to learning a new latest-and-greatest language. The main requirement is that there is a large body of freely available existing code for the particular compiler-language so I can drop in an I2C class, LCD routines etc and not waste my time writing and debugging such code. Also I would like to have the option to port my code to other micros if the need arises. Looking back on a few hundred lines of assembly you coded a couple of years ago and untangling it is not much fun: even if it is well documented. Furthermore, I find the vast bulk of code I have written is related to GUI stuff. Output a string or draw a line to an LCD, listen for keypresses etc: which requires a lot of code that can be reused from project to project and has little need for highly speed optermised code. Whenever speed becomes an issue though, I would greatly prefer to code in inline assembly, if for nothing more you can easily count clock cycles. I am still a student doing a Computer Science and Engineering Degree. After a 3 year degree of CS you know compilers generate assembly but are never taught or shown what it is or what it looks like: for that matter you are told not to code in it. As for engineering, they do introduce you to it, but there is still a heavy focus on using C for low level stuff where ever possible. I understand the reasoning behind it but I still think programmers should have an understanding of what a compiler does and how it does it to better understand the implementations of the code they write in high level languages. I will download a couple of demos of the mentioned AVR Compilers and see which I prefer. Mark. --- In AVR-Chat@yahoogroups.com, "Cobb, Quentin" <quentin_cobb@t...> wrote: > This is bound to be a huge thread, ranging from "Real men program in > assembler" to "BASIC is almost like a real programming language these days" > > Your mainstream choices are > > Assembler (AVR Studio) > BASCOM > GCC > Codevision C > Imagecraft C > > If you want to learn how the chip works then use assembler, but from the > tone of your email I don't think that's what you're after. AVR assembler is > specific to AVR's and not transferable. > > If you know C then you won't like BASCOM, which is almost like a real > language now, but is still BASIC and suffers from the "it's quick and easy > to get started but slow and hard to get finished" syndrome. > > From your email you're obviously leaning towards C because you know it, so > you'll want to transfer those skills and your question becomes: which C > compiler? > > GCC - Is for Linux, free software aficionados. It works, isn't pretty, > takes a bit of work to get all the bits up and running, has the stuff the > commercial products have, but not in a ready-to-go hold-your-hand package. > > Imagecraft. "Industrial Strength" professional, expensive compiler. I > can't talk much about it as it's beyond my budget so I haven't used it or > seen it used. > > My personal preference is Codevision. There is a free "evaluation" version > that is code-size limited, but good enough for all but the really big > projects. Even if you decide to pay for it, it's still very reasonable. > Much easier to set up than GCC, has nice code generating wizards that save a > bit of manual reading the first time you use a feature. Lots of code > libraries. > > ALL these C compilers meet your criteria, (except Imagecraft isn't very > cheap) > > Good luck > > Q Yahoo! Groups Links
Message
RE: [AVR-Chat] Re: AVR Compiler: which is the best
2004-03-16 by Cobb, Quentin
Attachments
- No local attachments were found for this message.