I'm not asking which compiler is best, but...

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would appreciate some opinions on whether or not CodeVision is worth paying for. My most important consideration is time to market, so what I need is a platform with a lot of library support, primarily for mega and xmega chips. I'm not doing any 32bit or ARM development, at least for now.

Most important, good libraries for SD card access, I2C and UART communication. I'm not doing anything with displays at this time.

I don't want to start a debate about code generation or optimization and such.

I realize its only about $200, but every little bit adds up quite quickly and I have a tiny budget.

Thanks...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are doing this commercially, it is a no-brainer!

$200 is 10 hours at $20/hour. You will certainly save this in development time due to the libraries and ease of use. Especially for an Xmega.

Yes, the Code generation is accurate but not as fast as avr-gcc. It is miles easier to follow in a debugger too.

Only you can weigh up the pros and cons of your particular situation.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The win is if you use graphics lcds. Licensed CV gives you routines for a bunch of them.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CV includes FatFs for the SD support so that's another argument in its favour.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
$200 is 10 hours at $20/hour. You will certainly save this in development time due to the libraries and ease of use. Especially for an Xmega.

Yeah if the free stuff does not have the library support then I'll break out the credit card.

If I am correct, WinAVR with GCC has no debugger and no libraries.

But Atmel Studio 6 does, is that right? Or does CV offer stuff AVR Studio lacks? From playing with AVR Studio, it seems to have a steepish learning curve...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There seems to be a confusing overloading of the word 'library'. Since fortran was written in the 50s, a 'library' has been an archive of object code of subroutines that the linker searches through to resolve references in the symbol table of a project being compiled and linked. This is object code that is already compiled. It isn't an include file of source code to be recompiled everytime. Thirty years ago, separate compilation and linking was the only way to get a large program put together. So now lets look at the object code libraries that come with the gnu c compiler... there is a rough correspondence between the routines in the standard .h files and the .a library files that contain the .o object files the the linker puts in the final executable object code file. So if you include stdio.h, and link with libc.a, the linker finds the files it needs. If you include math.h, you need to link with libm.a. Similar for stdlib.h, memory.h etc etc. Now let me opine that since the gnu c compiler is used to compile probably 99% of the AVR c programs ever written, you could consider the c source of those programs the worlds largest source library of c routines for AVRs. File systems, Ethernet, graphics.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If I am correct, WinAVR with GCC has no debugger and no libraries.

No, AS6 will both Simulate and control a JTAG hardware debugger. (for CV or avr-gcc)

Most programs and most peripherals have been used with avr-gcc at some time. You just need to use Aunty Google to find them and iron out any bugs. CV comes with proven libraries.

So at the end of the day, any toolchain can be used. You might need to do some work first! This is where CV scores. You know that you can use a DS18B20 or a SSD1289 chip and it will work first time. (thanks to Uncle Pavel)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If I am correct, WinAVR with GCC has no debugger and no libraries. But Atmel Studio 6 does

AS6 and WinAVR are closer than they used to be. (in the old days, AVR Studio did not include the C compiler; you had to install WINAVR separately. The latest Atmel Studio (6.1) essentially includes everything that WINAVR used to include, plus the Atmel-proprietary tools like the assembler and debugger support.

avr-gcc includes avr-libc, and AS6.1 additionally includes Atmel Software Foundation (ASF.) Neither of these is the sort of high-level library that supports graphics LCDs or SD cards, and while there is lots of code "on the net" for such things, that's not the same as having a vendor-maintained and tracked library.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Libraries: All C compilers/IDEs come with the standard C libraries - for things like math, printf, and so on.

Libraries for I/O devices - are specific to the microprocessor. The best selection of those is from the Auduino contributions - so long as you stay with their somewhat odd compiler environment.

Look to at examples, such as in the libraries for I/O, from
http://pjrc.com/teensy/teensydui...
And the other libraries on this web site. The author/owner, Paul, is a superb resource. Look too at his user forum
http://forum.pjrc.com/forum.php

The compiler for this world is freeware GCC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Libraries: All C compilers/IDEs come with the standard C libraries - for things like math, printf, and so on.

Yup, that's true, I did realize that. Although CV seems to tote a particularly good floating point library, and I think GCC AVR does not include floating point support.

The libraries I am looking for are to do things that are not part of standard C, like talking to SD cards, servicing UARTs, I2C and SPI communication and so on. I could adapt other code to do these things but the time to do this really adds up. If I could find these off the shelf, especially if they are documented, that's a big win.

Quote:

Libraries for I/O devices - are specific to the microprocessor. The best selection of those is from the Auduino contributions - so long as you stay with their somewhat odd compiler environment.

I use that on another project.

At least for me, its about the most annoying environment there is. I use Notepad++ for editing, which is fine, and Arduino's environment just to build. The problem here is no control over optimization. Building a makefile is not my best skill, and if I do that there is not much left of their environment.

Some of the libraries available for Arduino are great, like the serial IO and contributed SD libraries. There is also an excellent I2C library I use that does not use interrupts, so I can service I2C devices in an ISR. It all works great, but there are other aspects or Arduino that are not so great. I'm trying to move away from Arduino, especially since I want to use an XMega chip for the next project.

Quote:

Look to at examples, such as in the libraries for I/O, from
http://pjrc.com/teensy/teensydui...
And the other libraries on this web site. The author/owner, Paul, is a superb resource. Look too at his user forum
http://forum.pjrc.com/forum.php

The compiler for this world is freeware GCC.

I'll check all that out thanks!

I could use Arduino libs for the mega chips, but I didn't think they were available for the Xmega chips. Does Arduino support XMega?

Thanks very much to everyone!

I'm thinking CV is probably as good as I'll find, and I can eval it for free.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
and I think GCC AVR does not include floating point support.

I don't know where you are getting your information from, but a lot of it seems to be wrong. GCC for AVR does have floating point support. I don't know how it compares with CV, however.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can do everything you ever want with ANY toolchain.

They all compile, link, support the C language, floating point, maths etc.

CV comes with Help, Libraries, Wizards all in full working order and maintained by Pavel.
AVR-GCC is quite capable of doing all these things, but you have to find everything yourself. e.g. documentation, examples, third party libraries.

I also wonder where you are getting your GCC information from. AVR-GCC is an excellent toolchain that works fine. When you have found all the 'extra' bits you need, and learned how to use them, it will perform (a little) faster than CV.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking AVR-GCC didn't support floating point because the Arduino environment does not. Or at least not in part, for example, sprintf() does not work with floats.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I was thinking AVR-GCC didn't support floating point because the Arduino environment does not.

Of course it does.

float f;

void setup() {
  f = sin(3.141592 / 7);
}

void loop() {
  f += 1.0317;
}

Quote:

for example, sprintf() does not work with floats.

It does if you read the manual:

http://www.nongnu.org/avr-libc/u...

In other words the compilation needs -lprintf_flt and -Wl,-u,vfprintf. Not sure how (or even if) those can be made part of the Arduino build but if they were its version of sprintf() would show floats with %f rather than "?".

Do not base your judgement of avr-gcc by limitations imposed by Arduino's limited use of it.

avr-gcc actually has possibly the best implementation of (32 bit) float support (size/speed) of all the AVR C compilers. The arithmetic arrives for the cost of about 700 bytes. Other compilers require several K to deliver the same and are horribly inefficient (no names, no pack drill). It has fixed point math support which I don't believe to be available in any other AVR C compiler.

I would rate CV and avr-gcc as pretty much equals. Though, as David says, CV scores if you are looking for pre-written library code. While you can probably find support for all the same devices for avr-gcc dotted around the internet (a) you actually have to find it and (b) you have no assurance to the provenance of what you find - it may be utterly brilliant or utterly crap. With CV you know you are getting good library code and it's all readily available in one place. There's also the Codewizard that will generate internal peripheral setup code for you. That is why you may consider it worth paying the entrance fee to save your time and heartache.

(personally I would go with avr-gcc inside AS6 but that's because I know where the good libraries are and like to believe that I can sort wheat from chaff).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rubbish. The Arduino supports floats as a default. Any class with a print() method will display a f-p value.

sprintf() is part of the C library and as such, also supports floats. However the default linker options will link with the integer-only cut-down printf() library. You would need to alter the Arduino configuration files to link with the libprintf_flt.a

As a general rule, you can do anything with a micro. Sometimes it is a lot of faffing about.
This applies to the Arduino too. e.g. 100 digit arithmetic or control a nuclear bomb.

In fact, most sensors and hardware seem to have been used with Arduinos. You are more likely to find an Arduino library and examples than any other target platform.

Why not just ask either here or in an Arduino forum?
e.g. "how can I display f-p?"

Incidentally, I agree that sprintf() is a nice way to format multiple values in a single statement.
C++ does have a rather unpleasant << arrangement but it is not supported in the basic Arduino.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You would need to alter the Arduino configuration files to link with the libprintf_flt.a

Can you actually do that? I seem to remember that the underlying Makefile is not exposed to the user.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would not call it "User". But you can rearrange the Arduino build if you hack hard enough.

If you are doing Arduino projects, you really want it to build straight out of the box. So you can't ask a punter to go hacking the build directories.

But the simple solution is to use dstrtof() or the regular Arduino classes.

Or you write a C helper function.
Or you write a new C++ class.

I tend to write a specific helper function that calls multiple print() methods. This means that your loop() function just has single statements to do complex formatted displays. i.e. it makes your main program logic readable. You still have to deal with the separate display function, but you treat it as another 'job'.

I am not very good with C++. You can probably add the << and formatting 'features' of C++. Personally, I think it is horrible!

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Personally, I think it is horrible!

Yeah, totally agree with that. C++ improves C in a lot of ways but the stream output nonsense just looks like change for change's sake. I cannot see how it adds anything to the language though I suppose the argument goes that new classes can over-load their own version of the << operator and allow formatted serialization of the data they contain. Me, I'll just stick with (s)printf() thank you very much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I suppose the argument goes that new classes can over-load their own version of the << operator and allow formatted serialization of the data they contain

Precisely.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still does not make it easy to use though!

std::cout.setf ( std::ios::hex, std::ios::basefield );
std::cout.setf ( std::ios::showbase );
std::cout << 100 << '\n';

or

printf("0x%x\n", 100);

you decide. Both print "0x64". Know which one I prefer!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For those who are non-plussed by C++'s stream output ( and related, input ) notation, take umbrange in the fact that a standards compliant version requires dynamic allocation -- it won't be coming to the AVR any time soon.

As for avr-gcc's suitability given the need for library support.... As has been said, there are libraries that are compilable by avr-gcc all around, the tricks are finding them and proving them. At the beginning of development, CV wins big, but I would say that that advantage ( in "library" code at any rate ) gets smaller with time as you find libraries you like and continue to use. At this point, almost all of my code work ( except when I explicitly am working on extending the library code I have ) is on logic code. It's taken me some time to get to that point, of course. I would say that CV has the primary win if quick development is valuable [b]now[\b]. In the long run, avr-gcc can be just as fast to develop with. It does require a bit more planning, however.

Martin Jay McKee

Edit: Strictly speaking, I guess, stream operators could use predefined buffer areas and have a default allocator that created data references there, but it would still have a fairly high memory footprint and is not exactly microcontroller friendly.

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will also echo the statement that there are a lot of libraries in the Arduino community. Realize that these libraries are typically written in C++. The Arduino environment provides a setup() and loop() function, but then links that with another source file behind the scenes that provides a main() which calls both of those other functions (and some other things). Arduino scans the header file names that are included and builds up the switches that need to be sent to the compiler to automatically link in the appropriate libraries.

Your Arduino "sketch" then gets routed to the AVR GCC C++ compiler. You're using C++.

In theory, a lot of those "Arduino" libraries can be used by any straight-forward C++ application.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In theory,

Though not necessarily that easy in practice. It can help a lot to prebuild a libcore.a and ensure that is in the link to mop up any unresolved's the library you are trying to use may be reliant upon. Of course that libcore.a needs to be built for the right target and if the target is not one of the Arduino processors (mega8, mega88, mega168, mega328, meg1280, mega2560) then you may come unstuck.

So yes Arduino provides a lot of library code but there may be "issues" with trying to use it outside the Arduino environment. Often, however the library source may simply provide a "template" for a separate C/Asm implementation that follows the same "flowchart".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Exactly. That's why I prefaced it with "In theory...".

Now that I think about it, that preface covers almost all situations in embedded systems. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I am accosted with, "But in theory it should work because...!" My typical ( not so clever perhaps ) response is that, "in theory, theory and practice are similar, but, in practice, they rarely are."

Even if the Arduino libraries are not directly usable, they can still provide code that can be lifted fairly easily or, at least, provide a model.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stream IO is more than syntactic eye candy, the stream IO base classes provide a lot of utility for C++ applications (by subclassing them) on suitable platforms, but AVR and other micros are not usually suitable platforms. That's not to say there is no place for OO practices in a micro, I have used them to great effect. One just has to be aware of performance impacts. At least that's what I have found so far. I still benefit from code reuse through inheritance.

As for sprintf being used in Arduino, no you can not do it without "hacking" the environment, where hacking in this case is modifying the environment source and rebuilding. There is no config file that can be edited to change what is linked or what optimization settings are used.

Arduino also provides no debugging, period. Before someone nitpicks that statement, I don't consider flashing LEDs or toggling pins high and low debugging. I am referring to source level debugging.

And finally, the theory of using Arduino libraries in other environments is much easier than the practice of doing so. Many Arduino libs use other Arduino libs and that's not always good, as some of them have performance issues. For example, the DigitalWrite() and DigitalRead() functions obfuscate bit manipulation from new programmers, but with a considerable performance penalty. There are also good third party libraries, and I have used two in particular extensively, but porting them off Arduino is a pretty good project and I prefer to avoid that.

All this said, I am in no way anti-arduino. I brought a pretty good project to market using the Arduino environment. So, I don't really want to do it again. What I learned doing that I'll apply to the next project, using better tools, and learn even more.

Cliff and David, thanks for explaining the floating point in GCC-AVR. That's great information.

It sounds like CV is worth the price to me, since I'm looking for the library functionality it offers and it will do much of the setup for me. Also, I am planning to target an XMega chip, and after looking I found little if anything from Arduino on XMega.

One thing though, what about the Atmel Software Framework? Does it include any of these high level libraries? I did do some Googling but the docs on ASF don't seem particularly helpful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can make sense out of the ASF, you deserve a medal!

There are some example Xmega projects. If one matches your needs precisely, it might be usable. OTOH, the APIs are pretty convoluted. So you will struggle adapt the examples. Starting from scratch is a minefield.

Regarding the Arduino. Since the hardware is well defined and shields have fixed pin-outs, you can avoid the DigitalWrite() etc. This has a dramatic effect. In fact, you can make Arduino projects fly as fast as anything else.

You can use debugWIRE with the UNO or JTAG with the MEGA2560 when developing. Once you are up and running, there is nothing wrong with printf() statements to the UART.

Of course, everyone's circumstances and requirements are different. However, a sit down with a quiet think can find solutions to most things. Or even just ask here!

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
If you can make sense out of the ASF, you deserve a medal!

Okay, I feel better!

Quote:
Regarding the Arduino. Since the hardware is well defined and shields have fixed pin-outs, you can avoid the DigitalWrite() etc. This has a dramatic effect.

Yes, I did that in my own code, but not in any libraries.

Quote:

You can use debugWIRE with the UNO or JTAG with the MEGA2560 when developing. Once you are up and running, there is nothing wrong with printf() statements to the UART.

Of course, everyone's circumstances and requirements are different. However, a sit down with a quiet think can find solutions to most things. Or even just ask here!

I have never heard of debugWIRE, I'll track it down. Printf() statements are fine, although in my case, the UARTs were in use by the app I was debugging. Really, nothing beats a source level debugger for most software bugs! It can be a huge help.

I removed AVR Studio 5 and installed 6.1, then I installed the eval version of CV. With the great info from you guys I decided that's the way to go. The app I'm planning is essentially a special purpose serial multiplexer, and there is an I2C device to talk with, so having interrupt driven serial UART library support and an I2C library should make the firmware pretty straightforward. The XMega chip gives me all the UARTs I could need, and plenty of processing capability. So I should be in good shape.

Thanks everyone!