From: Sanita D. <san...@gm...> - 2014-02-13 08:23:47
|
Hello, I've started working with SDCC a few days ago and, naturally, I have some issues. I'm hoping you can help me solve them. I went through the mailing list archive and I didn't see a similar question. I have a project for 8051 that requires IAR Workbench and SDCC working together. That is, some parts of the project will be done in IAR and should later, as a library file, be included in a .c file made with SDCC. For starters I'm just trying to do the opposite, to see how SDCC and IAR work together. What I'm doing is: - create an example.c file that includes 8051.h file from SDCC\include and write to port P0 i.eg. P0=0x01; - make a .lib out of it "sdcclib examplelib.lib example.rel" - go to IAR, add this .lib file to my project. I've also added the path to my lib in the preprocessor. - use the functions from my examplelib library in my IAR project However, this does not work. When I add the library and try to build the project, I keep getting the error: "Fatal Error[e8]: Corrupt file. Unknown or misplaced tag encountered in module NO MODULE NAME ( C:\...\pstlib.lib ). Tag unknown [67]", "Error while running linker". Am I missing anything? Thanks in advance. Sanita |
From: roelof 't H. <ro...@it...> - 2014-02-13 08:55:35
|
On Thu, 2014-02-13 at 09:23 +0100, Sanita Dobraca wrote: > > However, this does not work. When I add the library and try to build > the project, I keep getting the error: "Fatal Error[e8]: Corrupt > file. Unknown or misplaced tag encountered in module NO MODULE NAME > ( C:\...\pstlib.lib ). Tag unknown [67]", "Error while running > linker". > > Am I missing anything ? As far as I know different make compilers are not producing compatible library files. So in my opinion that will not work. roelof |
From: Maarten B. <sou...@ds...> - 2014-02-13 09:03:50
|
Hello Sanita, This is virtually impossible. There is no standard calling convention for 8051. Every compiler uses its own invention, be it IAR, Keil or SDCC. AFAIK only Raisonance and Keil are compatible. On top of that every compiler uses its own object and library format. IAR has no clue how to interpret the contents of an SDCC generated .rel file nor how to interpret the sdcclib generated library. SDCC has another tool for generating libraries called sdar which is similar to gnu AR, but I don't believe IAR can handle that either. I'll make the story even worse. It's already difficult to keep source code compatible between these compilers. The use of <compiler.h> might help a bit with that. The above is true for almost every microcontroller and its different compiler tools. Only for modern 32-bit controllers there is an EABI definition that is followed by many tools. Maarten > Hello, > > I've started working with SDCC a few days ago and, naturally, I have some > issues. I'm hoping you can help me solve them. I went through the mailing > list archive and I didn't see a similar question. > > I have a project for 8051 that requires IAR Workbench and SDCC working > together. That is, some parts of the project will be done in IAR and > should > later, as a library file, be included in a .c file made with SDCC. > For starters I'm just trying to do the opposite, to see how SDCC and IAR > work together. What I'm doing is: > - create an example.c file that includes 8051.h file from SDCC\include and > write to port P0 i.eg. P0=0x01; > - make a .lib out of it "sdcclib examplelib.lib example.rel" > - go to IAR, add this .lib file to my project. I've also added the path to > my lib in the preprocessor. > - use the functions from my examplelib library in my IAR project > > However, this does not work. When I add the library and try to build the > project, I keep getting the error: "Fatal Error[e8]: Corrupt file. > Unknown > or misplaced tag encountered in module NO MODULE NAME ( C:\...\pstlib.lib > ). Tag unknown [67]", "Error while running linker". > > Am I missing anything? > Thanks in advance. > Sanita |
From: Sanita D. <san...@gm...> - 2014-02-13 14:19:37
|
Thank you very much for your replies. If I understood you well, my original task (use IAR generated library in SDCC) is also not feasible? Do you know of any other C compiler that I might use as a replacement for SDCC. I also need my project to be as safe and reliable as possible. Maybe choosing an open source compiler is not a good decision? I would need something that's cheaper than IAR...? Thanks in advance Sanita On Thu, Feb 13, 2014 at 10:03 AM, Maarten Brock <sou...@ds...>wrote: > Hello Sanita, > > This is virtually impossible. There is no standard calling convention for > 8051. Every compiler uses its own invention, be it IAR, Keil or SDCC. > AFAIK only Raisonance and Keil are compatible. On top of that every > compiler uses its own object and library format. IAR has no clue how to > interpret the contents of an SDCC generated .rel file nor how to interpret > the sdcclib generated library. SDCC has another tool for generating > libraries called sdar which is similar to gnu AR, but I don't believe IAR > can handle that either. > > I'll make the story even worse. It's already difficult to keep source code > compatible between these compilers. The use of <compiler.h> might help a > bit with that. > > The above is true for almost every microcontroller and its different > compiler tools. Only for modern 32-bit controllers there is an EABI > definition that is followed by many tools. > > Maarten > > > Hello, > > > > I've started working with SDCC a few days ago and, naturally, I have some > > issues. I'm hoping you can help me solve them. I went through the mailing > > list archive and I didn't see a similar question. > > > > I have a project for 8051 that requires IAR Workbench and SDCC working > > together. That is, some parts of the project will be done in IAR and > > should > > later, as a library file, be included in a .c file made with SDCC. > > For starters I'm just trying to do the opposite, to see how SDCC and IAR > > work together. What I'm doing is: > > - create an example.c file that includes 8051.h file from SDCC\include > and > > write to port P0 i.eg. P0=0x01; > > - make a .lib out of it "sdcclib examplelib.lib example.rel" > > - go to IAR, add this .lib file to my project. I've also added the path > to > > my lib in the preprocessor. > > - use the functions from my examplelib library in my IAR project > > > > However, this does not work. When I add the library and try to build the > > project, I keep getting the error: "Fatal Error[e8]: Corrupt file. > > Unknown > > or misplaced tag encountered in module NO MODULE NAME ( C:\...\pstlib.lib > > ). Tag unknown [67]", "Error while running linker". > > > > Am I missing anything? > > Thanks in advance. > > Sanita > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Kustaa N. <Kus...@pl...> - 2014-02-13 14:28:00
|
>If I understood you well, my original task (use IAR generated library in SDCC) is also not feasible? Yes, it is not feasible. > Do you know of any other C compiler that I might use as a replacement for SDCC. Keil has already been mentioned. > Maybe choosing an open source compiler is not a good decision? What makes you say that? br Kusti ________________________________ This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Sanita D. <san...@gm...> - 2014-02-13 14:35:23
|
I'm not sure, that's why I'm asking. I haven't had much experience with open source tools, so I'm not familiar with their reliability when using in safety-related embedded systems. Thank you very much for the reply. Sanita On Thu, Feb 13, 2014 at 3:27 PM, Kustaa Nyholm <Kus...@pl...>wrote: > >If I understood you well, my original task (use IAR generated library > in SDCC) is also not feasible? > > Yes, it is not feasible. > > > Do you know of any other C compiler that I might use as a replacement > for SDCC. > > Keil has already been mentioned. > > > > Maybe choosing an open source compiler is not a good decision? > > What makes you say that? > > br Kusti > > > ------------------------------ > This e-mail may contain confidential or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. We will not be liable for direct, indirect, special or > consequential damages arising from alteration of the contents of this > message by a third party or as a result of any virus being passed on or as > of transmission of this e-mail in general. > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Kustaa N. <Kus...@pl...> - 2014-02-13 14:43:24
|
> using in safety-related embedded systems. Open source has several advantages: 1) with open source you evaluate/validate compiler internals which might me import if you take safety seriously 2) the tools cannot be discontinued, this has happened to me with commercial tools in the past, this is important down the road as after you deploy your system you gain experience and confidence in your code and compiler and all that is largely wasted if you need to change your tool chain 3) SDCC community/developers seem to be pretty responsive br Kusti ________________________________ This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Sebastien L. <seb...@lo...> - 2014-02-13 15:26:20
|
yes, but that's only the bright side. Also, -developers are not often paid, so you have to wait until they have enough free time -architecture changes are rare since it requires a lot of time to break big things and rebuild them -the number of contributors with enough skills and time to be able to dig deep inside the code of complex projects, and implement things that the main developers don't have time for, is not always so large. SDCC is good for z80 and targets that benefited from the new allocator, but the for example, PIC ones are still broken and generate mostly correct but inefficient code. why? because it would require a rewrite and no one can do that until His Mighty Noodleiness sends a wizard to do it. I know, some people will say "just fix it, it's open for a reason". But I just don't know how to do that and I don't have enough time for that. Even if it's a kind of criticism, I'm not complaining, I'm using the SDCC PIC16 port for lots of projects, but I have to recognize that mcc18 just produces better code. It's just the truth. I'm still an SDCC supporter, but I had to react. About critical systems, just go back reading the GNU GPL license, especially the upper-case section. Sébastien Lorquet Le 13/02/2014 15:43, Kustaa Nyholm a écrit : >> using in safety-related embedded systems. > > Open source has several advantages: > > 1) with open source you evaluate/validate compiler internals > which might me import if you take safety seriously > > 2) the tools cannot be discontinued, this has > happened to me with commercial tools in the past, > this is important down the road as after you > deploy your system you gain experience and confidence > in your code and compiler and all that is largely > wasted if you need to change your tool chain > > 3) SDCC community/developers seem to be > pretty responsive > > br Kusti > > > -------------------------------------------------------------------------------- > This e-mail may contain confidential or privileged information. If you are not > the intended recipient (or have received this e-mail in error) please notify the > sender immediately and destroy this e-mail. Any unauthorized copying, disclosure > or distribution of the material in this e-mail is strictly forbidden. We will > not be liable for direct, indirect, special or consequential damages arising > from alteration of the contents of this message by a third party or as a result > of any virus being passed on or as of transmission of this e-mail in general. > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Kustaa N. <Kus...@pl...> - 2014-02-13 18:52:24
|
On 13/02/2014 16:56, "Sebastien Lorquet" <seb...@lo...> wrote: >yes, but that's only the bright side. > >Also, > >-developers are not often paid, so you have to wait until they have >enough free time That is true, then again you don't get a good service from commercial player always either, especially the big ones. > >-architecture changes are rare since it requires a lot of time to break >big >things and rebuild them Having seen this from the inside of commercial software developers I'd say architecture changes maybe even rarer in them. And architecture change as such does not warm anyone. > >-the number of contributors with enough skills and time to be able to dig >deep >inside the code of complex projects, and implement things that the main >developers don't have time for, is not always so large. Very true. > >SDCC is good for z80 and targets that benefited from the new allocator, >but the >for example, PIC ones are still broken and generate mostly correct but >inefficient code. why? because it would require a rewrite and no one can >do that >until His Mighty Noodleiness sends a wizard to do it. Agree about the produced code quality but doubt about the need to rewrite everything, more likely just needs someone to get down to it, which is the problem as there is no-one atm with enough time. > It's just the truth. Yeah, nothing can be gained by trying to hide the truth. > > >About critical systems, just go back reading the GNU GPL license, >especially the >upper-case section. Hmm, I could not easily find a version with the upper-case section but I think I know what you refer to. What are you trying to say with that? When you are doing critical system (or any systems for that matter) you don't get any warranties or guarantees from anyone for the quality of their tools and especially of the code they produce, heck, most if not all the chips we all use have clause in the data sheet that you can't use them in critical systems, or words to that effect. At the end of the day it is the OEM who is responsible for the product, what ever it is. Both in the eye's of the law and the public/market place. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Sebastien L. <seb...@lo...> - 2014-02-14 11:01:06
|
Hello I'm just saying that freedom is not a direct measure of quality, which is obvious but may have been a bit overlooked in the original post. About critical software, and by that I mean "someone could die because of bad code" , you will need certified software, from the application you're writing to the compiler that produces the final binary code. GPL software explicitly states that it does not provide any warranty of fitness for any purpose etc etc, which, in critical software, translates to "be happy if things happen to work, but you cant blame us if it doesnt". And this is probably not acceptable as-is for, say, SpaceX. In such critical case, the compiler HAS TO work in a verifiable manner. Test suites are only a part of the checks. Formal verification is another one. The upper case sections can be found here at paragraphs 15 and 16 https://www.gnu.org/licenses/gpl-3.0.en.html (I agree that rewrites in commercial software can be rare, and this proves further that both worlds are similar in some ways :) ) (and Raphael Neider itself once told me that the PIC ports should be rewritten!) Sébastien Lorquet Le 13/02/2014 19:52, Kustaa Nyholm a écrit : > On 13/02/2014 16:56, "Sebastien Lorquet" <seb...@lo...> wrote: > >> yes, but that's only the bright side. >> >> Also, >> >> -developers are not often paid, so you have to wait until they have >> enough free time > > That is true, then again you don't get a good service from > commercial player always either, especially the big ones. > >> >> -architecture changes are rare since it requires a lot of time to break >> big >> things and rebuild them > > Having seen this from the inside of commercial software developers > I'd say architecture changes maybe even rarer in them. And architecture > change as such does not warm anyone. > >> >> -the number of contributors with enough skills and time to be able to dig >> deep >> inside the code of complex projects, and implement things that the main >> developers don't have time for, is not always so large. > > > Very true. > >> >> SDCC is good for z80 and targets that benefited from the new allocator, >> but the >> for example, PIC ones are still broken and generate mostly correct but >> inefficient code. why? because it would require a rewrite and no one can >> do that >> until His Mighty Noodleiness sends a wizard to do it. > > Agree about the produced code quality but doubt about the need to rewrite > everything, more likely just needs someone to get down to it, which > is the problem as there is no-one atm with enough time. > >> It's just the truth. > > Yeah, nothing can be gained by trying to hide the truth. > >> >> >> About critical systems, just go back reading the GNU GPL license, >> especially the >> upper-case section. > > > Hmm, I could not easily find a version with the upper-case section but I > think I know what you refer to. > > What are you trying to say with that? > > When you are doing critical system (or any systems for that matter) you > don't get any warranties or guarantees from anyone for the quality > of their tools and especially of the code they produce, heck, most if > not all the chips we all use have clause in the data sheet that you > can't use them in critical systems, or words to that effect. > > At the end of the day it is the OEM who is responsible for the product, > what ever it is. Both in the eye's of the law and the public/market place. > > br Kusti > > > > > > > This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Kustaa N. <Kus...@pl...> - 2014-02-14 14:49:04
|
On 14/02/2014 13:00, "Sebastien Lorquet" <seb...@lo...> wrote: >Hello > >I'm just saying that freedom is not a direct measure of quality, which is >obvious but may have been a bit overlooked in the original post. Hmm, the original question mentioned open source not freedom and I tried to say that with open source you can (in theory at least) have a look at the quality and decide for yourself where as with closed source you can't. > >About critical software, and by that I mean "someone could die because of >bad >code" , you will need certified software, from the application you're >writing to >the compiler that produces the final binary code. Right and with closed source you are at the mercy of your tool provider in two ways: 1) if they are willing to certify their software and 2) if their certification is worth anything, which is very hard to judge. > >GPL software explicitly states that it does not provide any warranty of >fitness >for any purpose etc etc, which, in critical software, translates to "be >happy if >things happen to work, but you cant blame us if it doesnt". And this is >probably >not acceptable as-is for, say, SpaceX. In such critical case, the >compiler HAS >TO work in a verifiable manner. That's a different spin that I would put on this. GPL just says that they are not to be held responsible. Most proprietary tool providers have similar texts in their licenses. So no difference. Googling for certified C-compilers is very educational, it boils down to the fact that you need to do your own assessment and bear the responsibility. > >Test suites are only a part of the checks. Formal verification is another >one. Any formally verified C compilers out there? Or for other languages? Prices? Anyone using them? > >The upper case sections can be found here at paragraphs 15 and 16 > >https://www.gnu.org/licenses/gpl-3.0.en.html Thanks. > >(I agree that rewrites in commercial software can be rare, and this proves >further that both worlds are similar in some ways :) ) :) >(and Raphael Neider itself once told me that the PIC ports should be >rewritten!) Well, he maybe right, but he may also be wrong! Many people use that as an escape clause when in reality refactoring and re-working the code is often a better (or only!) option. cheers Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Daniel <dan...@te...> - 2014-02-14 12:43:50
|
Dear All, Unfortunately for Sébastien, commercial software editors are really the first who have all sorts of disclaimers in their licenses. On top of that, only very few compilers are certified by a trustable institution (only ADA to my knowledge). Critical software depends therefore rather on programming rules and testing, than on a particular compiler. Moreover, any experience with both GPL and commercial tools shows evidently that support is a thousand times more efficient for GPL tools than for commercial ones. Cf. this list :-) Cheers, Daniel On 02/14/2014 12:00 PM, Sebastien Lorquet wrote: > Hello > > I'm just saying that freedom is not a direct measure of quality, which is > obvious but may have been a bit overlooked in the original post. > > About critical software, and by that I mean "someone could die because of bad > code" , you will need certified software, from the application you're writing to > the compiler that produces the final binary code. > > GPL software explicitly states that it does not provide any warranty of fitness > for any purpose etc etc, which, in critical software, translates to "be happy if > things happen to work, but you cant blame us if it doesnt". And this is probably > not acceptable as-is for, say, SpaceX. In such critical case, the compiler HAS > TO work in a verifiable manner. > > Test suites are only a part of the checks. Formal verification is another one. > > The upper case sections can be found here at paragraphs 15 and 16 > > https://www.gnu.org/licenses/gpl-3.0.en.html > > (I agree that rewrites in commercial software can be rare, and this proves > further that both worlds are similar in some ways :) ) > (and Raphael Neider itself once told me that the PIC ports should be rewritten!) > > Sébastien Lorquet > > Le 13/02/2014 19:52, Kustaa Nyholm a écrit : >> On 13/02/2014 16:56, "Sebastien Lorquet"<seb...@lo...> wrote: >> >>> yes, but that's only the bright side. >>> >>> Also, >>> >>> -developers are not often paid, so you have to wait until they have >>> enough free time >> That is true, then again you don't get a good service from >> commercial player always either, especially the big ones. >> >>> -architecture changes are rare since it requires a lot of time to break >>> big >>> things and rebuild them >> Having seen this from the inside of commercial software developers >> I'd say architecture changes maybe even rarer in them. And architecture >> change as such does not warm anyone. >> >>> -the number of contributors with enough skills and time to be able to dig >>> deep >>> inside the code of complex projects, and implement things that the main >>> developers don't have time for, is not always so large. >> >> Very true. >> >>> SDCC is good for z80 and targets that benefited from the new allocator, >>> but the >>> for example, PIC ones are still broken and generate mostly correct but >>> inefficient code. why? because it would require a rewrite and no one can >>> do that >>> until His Mighty Noodleiness sends a wizard to do it. >> Agree about the produced code quality but doubt about the need to rewrite >> everything, more likely just needs someone to get down to it, which >> is the problem as there is no-one atm with enough time. >> >>> It's just the truth. >> Yeah, nothing can be gained by trying to hide the truth. >> >>> >>> About critical systems, just go back reading the GNU GPL license, >>> especially the >>> upper-case section. >> >> Hmm, I could not easily find a version with the upper-case section but I >> think I know what you refer to. >> >> What are you trying to say with that? >> >> When you are doing critical system (or any systems for that matter) you >> don't get any warranties or guarantees from anyone for the quality >> of their tools and especially of the code they produce, heck, most if >> not all the chips we all use have clause in the data sheet that you >> can't use them in critical systems, or words to that effect. >> >> At the end of the day it is the OEM who is responsible for the product, >> what ever it is. Both in the eye's of the law and the public/market place. >> >> br Kusti >> >> >> >> >> >> >> This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. >> >> ------------------------------------------------------------------------------ >> Android apps run on BlackBerry 10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Maarten B. <sou...@ds...> - 2014-02-13 14:36:38
|
Hi again, >>If I understood you well, my original task (use IAR generated library in >> SDCC) is also not feasible? > > Yes, it is not feasible. Yup. >> Do you know of any other C compiler that I might use as a replacement >> for SDCC. > > Keil has already been mentioned. And Raisonance. But for these the same applies: they will not cooperate with IAR. Only IAR works with IAR. Of these 3 commercial compilers Raisonance is probably cheapest. Unless you use a specific brand of 8051's whose manufacturer provides a free version of Keil, like SiLabs does. Maarten |