Hi,
I have a bunch of code that was originally written with a fully licensed copy of CodeVision 3.x but now needs to be maintained by someone else who does not have a license...
The code size is way over the CV evaluation size, so that route is not an option...
Are there any guides to porting code from CV to gcc/AS 7?
Thanks
Nick
I have a bunch of code
now needs to be maintained by someone else who does not have a license...
What is a bunch? What is his time worth to port, compared to cost of license?
Have you looked for someone to maintain it that has a license?
These are the questions you need to ask yourself and weigh the results.
As for the porting, most of the code is ansi C so no problem, but each toolchain has extenstions,
so you would need to see what non-standard extensions were used, in addition, how the interrupts are handled.
That usually covers most porting between AVR C compilers.
It is just a cost vs time equation....
Jim
jgmdesign 
As for the porting, most of the code is ansi C so no problem, but each toolchain has extenstions,
so you would need to see what non-standard extensions were used, in addition, how the interrupts are handled.
That usually covers most porting between AVR C compilers.
With one other item....
If the original programmer using CV used the 'wizard' for the peripherals (I2C for example) then they used Pavels librar(ies) which are encrypted and he will not release the source code without getting lawyers involved.
So, the license costs 150 euros....small price to pay to keep the Advil away. I know it is for me....I pay the fee every year
If the code is not too complex maybe its worth a rewrite, but as the other jim wrote....How much code are you supporting?
East Coast Jim
EDIT:
You could also post your location as there are many freaks here that own CV licenses so maybe you could contract out the support? - Just a thought
david.prentice 
The maths is quite simple:
How much is a CV licence ?
How many hours of your maintainer's time would be spent in translating CV projects into avr-gcc projects?
It is straightforward to process syntax differences. I even have scripts to automate the process.
It is harder to handle the built in libraries e.g. EEPROM, USART, I2C, LCD, Graphics controllers, hardware chips, ...
Only you know how many projects are in a bunch of code
Only you know the size and complexity.
Only you know your maintainer's rates (and capabilities)
The maths is easy for an IAR licence. i.e. a lot of hours to pay for it. And you still have to write/port your own libraries
CV is a lot cheaper. And you get a lot of Wizard, libraries, ... for your money.
David.
p.s. if you are a vicar you might get special consideration.
I suppose I should have been clearer !
I am an IT professional and EE who was involved in both the c & c++ standardisation processes as well as contributing to a number of standard texts - I understand the languages well and am quite capable of porting the code to as 7/GCC from scratch. A porting guide would save time as I don't know about CV extensions.
The code is not a commercial product - it's a legacy system that I wish to extend to add support for new devices. It's written from scratch - no wizard and no CV magic libraries - about 30k lines of reasonable C.
I'm moderately time rich in these "interesting times" however the project is cash poor; if I can port the code in a day or two then it makes sense to do so in order that future maintenance is easier.
I fully intend to add a hardware abstraction layer as well as shift pretty much all I can to ANSI C, as I also wish to add msp430 and possibly ESP32 support.
The main issues will be with bespoke #pragmas and the way that library code is treated, none of which are especially tricky.
If anyone has done this before, it'd just save me time and be very welcome.
Thanks
david.prentice You have made yourself "less clear".
if I can port the code in a day or two : A single day's work is more than the cost of a CV licence.
A porting guide would save time as I don't know about CV extensions : CV comes with built-in documentation.
I understand the languages well and am quite capable of porting the code to as 7/GCC from scratch : You can read GCC docs online. Ok with a bit of effort.
The main issues will be with bespoke #pragmas and the way that library code is treated, none of which are especially tricky : The #pragmas for built-in libraries control builds and linking.
External modules, libraries, ... can be treated in the conventional way. i.e. adding files to project, adding search paths to library headers, object code, ...
David.
p.s. if you want "helpful advice", attach a typical project from your bunch of code. Then we can see what is involved. I am sure that you can find something "commercially insensitive"
You have made yourself "less clear".
Sigh. The joys of public fora.
if I can port the code in a day or two : A single day's work is more than the cost of a CV licence.
If you read my post you'd see that I'm currently time rich and the project has no money, plus I wish to add support for other platforms. Why would I stick with CV when other maintainers would have the same issue (no license) plus no cross-platform support?
A porting guide would save time as I don't know about CV extensions : CV comes with built-in documentation.
CV comes with many 100s of pages of documentation. I'm quite capable of reading and understanding that, but it would help if someone had been there before...
The main issues will be with bespoke #pragmas and the way that library code is treated, none of which are especially tricky : The #pragmas for built-in libraries control builds and linking.
Yes. That's why I stated that I think they'll be the main issue.
p.s. if you want "helpful advice", attach a typical project from your bunch of code. Then we can see what is involved. I am sure that you can find something "commercially insensitive"
Trite and sarcastic. Unnecessary & unworthy.
I asked a pretty simple question, i.e. is there any guide to doing a conversion that as it would save time and effort. I'm not sure what the issue is with that. Oh, and it's not a commercial product, but there is possibly some IP involved.
Frankly, it would have been simpler not to bother asking.
david.prentice I suggested attaching an "insensitive project". Then we could offer practical advice. i.e. port it for you. show you what is involved.
I would not describe the relevant items of CV documentation as 100s of pages.
But it is a lot simpler to walk you through an example than to second-guess your situation.
Seriously. Complete professional documentation might look large. But you can navigate with search, hyperlinks or regular index.
If I wrote a "porting guide" with simple example it may or may not match your specific requirement.
And would be a lot more work than "walking through your project"
It is always easier to answer a specific question than to use generalities that may not be relevant.
Frankly, it would have been simpler not to bother asking.
Your question was perhaps a little too general. Can we assume you're not asking about the obvious CodeVision / avr-gcc differences:
E.g.
If not the above; hopefully we can avoid an outright Compiler War as happened here:
https://www.avrfreaks.net/forum/porting-codevision-code-avr-gcc
theusch 
If not the above; hopefully we can avoid an outright Compiler War as happened here:
lol -- I resemble that remark. The checklist near the end of that thread is a starting point in generic terms:
Conclusion 1: PORTx.n syntax must be addressed when porting from CodeVision to GCC.
Conclusion 2: ISR syntax must be addressed when porting from CodeVision to GCC.
Conclusion 3: "bit" variables must be addressed when porting from CodeVision to GCC.
Conclusion 4: Memory-space handling (flash, eeprom keywords) syntax must be addressed when porting from CodeVision to GCC.
Conclusion 5: None of the above are standard (ANSI/ISO) C and are extensions.
Conclusion 6: CodeVision project options under which the project was developed must be considered (as would compile-time switches for GCC).
As a long-time CV user, the answer is "it depends".
1. Let's start with when the CV code was developed, in particular which compiler version. 1.x had extensions to do AVR work, that were smoothed in 2.x to be closer to "standard". 3.x added some stuff to make the code look like GCC.
2. It depends what the app is. Is it real vanilla C, a "processing" app? Ir is it an app that uses "all" of the AVR with cycle-counted ISRs and other code fragments?
3. Is there a lot of inline assembler?
4. Standard C library functions should be pretty close, and gcc will support more of them. But toolchain-provided additions such as delay may take some work.
Is the 20k lines all one program? Have you thrown a program at the compiler and fixed the obvious stuff? How does it look?
3. Is there a lot of inline assembler?
Out of curiosity, does it have a mechanism to connect inline assembler with C variables?
That is the source of gcc's much maligned syntax.
david.prentice This drives me bananas.
The thread will speculate for days if not weeks.
When the OP just has to attach one sample project. The issues will be apparent. The specific project is "ported" (if possible).
We can walk the OP through the "porting" procedure.
This involves 5 minutes of the OP's life to attach a project.
And 10 minutes of my life to assess the issues.
no wizard and no CV magic libraries - about 30k lines of reasonable C.
If true, possibly 20 minutes to check the output from the automated script.
But much more time to explain each step.
Hey-ho. I am out.
David.
If size and speed really don't matter, I would rewrite the CV code to be real ANSI, and some HW mapping functions, and make sure that still works.
Then move that to GCC.
In general simple stuff like byte and bit is way smaller and smarter on CV. Where the GCC is better at optimizing a bigger project.
Out of curiosity, does it have a mechanism to connect inline assembler with C variables?
Another long-time CV user here. Yes, I can write...
volatile unsinged int result;
volatile unsginged char x,y;
void test() {
#asm
LDS R30,_y
LDS R31,_x
MUL R30,R31
STS _result,R0
STS _result+1,R1
#endasm
}
There's a well defined use of registers, so in the above R30 and R31 are always available for asm functions.
The 'volatile' is there to ensure that the optimiser does not put the globals in registers
@OP
The list of CV-isms in #10 is pretty complete. Deal with those and the few remaining oddities will be easily found and fixed the first time you run a compile.
Another long-time CV user here. Yes, I can write...
volatile unsinged int result; volatile unsginged char x,y; void test() { #asm LDS R30,_y LDS R31,_x MUL R30,R31 STS _result,R0 STS _result+1,R1 #endasm }
There's a well defined use of registers, so in the above R30 and R31 are always available for asm functions.
The 'volatile' is there to ensure that the optimiser does not put the globals in registers
gcc does not understand inline assembly, so it needs to be allowed to select a register or to be told about it.
One of the fine points of gcc inline assembly is reducing the clobber list, preferable to nothing.
Can CV inline assembly connect to an auto variable?
The two compilers use the top registers of the AVR different.
GCC always build up around R25:R24 where CV use R31:30 (Z)
In many simple cases the CV way is the best, but when it get more complicated Z really get's "busy"
I remember that it really made some odd code for a function that swap two integers.
gcc does not understand inline assembly, so it needs to be allowed to select a register or to be told about it.
I think that might highlight on of the fundamental differences between CV and GCC.
CV has no concept, or use, of a linker. In a project, each file gets compiled to what is in effect a .asm file and these are then concatenated into one file which is then run through avrasm2 to produce the binary.
So in effect the #asm directive simply tells the compiler to stop compiling C and simply pass what it sees straight to the asm output file for that file.
N.Winterbottom wrote:If not the above; hopefully we can avoid an outright Compiler War as happened here:lol -- I resemble that remark. The checklist near the end of that thread is a starting point in generic terms:
theusch wrote:Conclusion 1: PORTx.n syntax must be addressed when porting from CodeVision to GCC.
Conclusion 2: ISR syntax must be addressed when porting from CodeVision to GCC.
Conclusion 3: "bit" variables must be addressed when porting from CodeVision to GCC.
Conclusion 4: Memory-space handling (flash, eeprom keywords) syntax must be addressed when porting from CodeVision to GCC.
Conclusion 5: None of the above are standard (ANSI/ISO) C and are extensions.
Conclusion 6: CodeVision project options under which the project was developed must be considered (as would compile-time switches for GCC).
As a long-time CV user, the answer is "it depends".
1. Let's start with when the CV code was developed, in particular which compiler version. 1.x had extensions to do AVR work, that were smoothed in 2.x to be closer to "standard". 3.x added some stuff to make the code look like GCC.
2. It depends what the app is. Is it real vanilla C, a "processing" app? Ir is it an app that uses "all" of the AVR with cycle-counted ISRs and other code fragments?
3. Is there a lot of inline assembler?
4. Standard C library functions should be pretty close, and gcc will support more of them. But toolchain-provided additions such as delay may take some work.
Is the 20k lines all one program? Have you thrown a program at the compiler and fixed the obvious stuff? How does it look?
Thank you (and to all but one of the others) for a helpful and informative post.
To answer your questions:
1. The code dates from about 2009, more than that I do not know.
2. The app is fairly basic - there are some simple peripherals: an RTC & some shift registers - both TWI, a rotary encoder with a switch (so some pin change stuff). Part of this exercise is to replace the older RTC with a DS323x series one.
3. Luckily, none
4. stdlib stuff will likely be fine, so not concerned about that (much). There are 8 modules and some lib files. None of the CV libs are used. With the library files and headers, there are 67,387 lines (according to CV) - that will likely include the CV stdlib and mega168*.h header files, so the actual code size is, as I stated before around the 20k lines mark.
Whilst the code is in "an individual style", I've seen far worse from allegedly professional programmers. The code is readable, commented sensibly, reasonably structured, has meaningful variable & type names and is about as clean as I could expect. It compiles under the demo version of CV 3.37 completely cleanly, which in my book is a decent start. Unfortunately, the evaluation version's code size limit is way too small for this app.
The target is an ATmega168 @ 20MHz - I may change that too.
There is a lot of bit twiddling which will have to be dealt with, loads of "flash" qualifiers, as well as a lot of #pragmas, specifically
It will get first hit against AS 7 sometime next week. I have run it through doxygen which has helped greatly in the understanding of the overall structure - I generally do this with code that's "third party", i.e. not in-house or not to our/my coding standards.
Thanks again.
theusch In this contex, "well-defined" seems to mean fixed. Is Z implicitly clobbered even if it is not used?
"Clobbered" is such a mean word. ;) Yes, in CV when you do an asm section the entry "clobbers" Z.
The registers R0, R1, R22, R23, R24, R25, R26, R27, R30 and R31 can be freely used in assembly routines.
"Clobbered" is such a mean word. ;) Yes, in CV when you do an asm section the entry "clobbers" Z.The registers R0, R1, R22, R23, R24, R25, R26, R27, R30 and R31 can be freely used in assembly routines.
For writing efficient code, I'd say that the GNU mechanism is superior.
It can be used without tying the hands (?) of the optimizer.
OTOH if one is using inline assembly because C is too clunky for what you want,
legibility reigns and CV's mechanism is better.
OTLF one could easily define a CVasm macro that does what the name suggests.
One would still need quotes.
There is a lot of bit twiddling which will have to be dealt with, loads of "flash" qualifiers, as well as a lot of #pragmas, specifically
- #pragma used+/used-
- #pragma library
- #pragma warn+/warn- (probably why it seems to compile cleanly!)
That seems like a fairly short list to search out in the CV doc set.
Good luck with your project, and please come back if you have a specific question as it seems there are lots of CV experience available here.
Jim