Urgently Add interrupt & RTC C code to MikroC for ARM.

[munishK301]

Hello Sir,

we had purchased MMB board for LM3S9B95 and MikroC Prog for ARM from your Company.
We are working on Industrial Project, but we stuck on finding functions for LM3S9B95 functions for Internal RTC and Interrupt functions.
In your Library Manager in MikroC Pro for ARM, all peripheral functions of LM3S9B95 are added,except RTc and Interrupt.
But We urgently need LM3S9B95 internal RTC C code and Interrupt functions so we can complete our Project and work further.
Please kindly provide us with these C code or Functions if possible or Add them to MikroC Library Manager.

Thanks,

Regards,
Munish Kaundal

[filip]

Hi,

I believe I have answered you here :
http://www.mikroe.com/forum/viewtopic.php?f=178&t=46761

Regards,
Filip.

[p.erasmus]

We urgently need LM3S9B95 internal RTC C code and Interrupt functions so we can complete our Project and work further.

So do others needs libraries for more than 1 year and you think you can insist on urgent RTC library
agh I forgot its for ARM so dont worry it will come quickly its only for the other compilers were it is so slow !!

[Mince-n-Tatties]

needs libraries for more than 1 year

that would be all the incentive i would need to learn how to do it myself.

[p.erasmus]

that would be all the incentive i would need to learn how to do it myself.

Yes I agree ,I am working on that.

[Mince-n-Tatties]

[LOE]

We urgently need LM3S9B95 internal RTC C code and Interrupt functions so we can complete our Project and work further.

So do others needs libraries for more than 1 year and you think you can insist on urgent RTC library
agh I forgot its for ARM so dont worry it will come quickly its only for the other compilers were it is so slow !!

I couldn't help but notice that for years you're complaining about extremely slow response by ME team in maintaining their Micrcochip product compilers and very slow addition of new libraries. I agree with you for the most part and the standard "Thank you for your suggestion, we will pass it to our developers" becomes annoying after one realises that those suggestions are (for the most part) de facto ignored. I suspect that ME team is understaffed in maintaining all those compilers but I guess they chose diversity over quality as part of their business strategy.

Could you please explain your rationale in sticking with MikroC rather than completely switch over to C18/30/32 if you're using them for more challenging tasks anyway? I would understand if it's the matter of compiler price but since you're using Microchip C compilers anyway that means you licensed them, so why stick with MikroC and getting frustrated?

I'm not challenging you BTW, I'm simply trying to better understand underlying logic behind, what seems to me, a rather strange love and hate relationship.

[p.erasmus]

Could you please explain your rationale in sticking with MikroC rather than completely switch over to C18/30/32 if you're using them for more challenging tasks anyway? I would understand if it's the matter of compiler price but since you're using Microchip C compilers anyway that means you licensed them, so why stick with MikroC and getting frustrated?

I can easily explain this !
(1) Commercially we do not use mikro Compilers exactly for the reason complaining about and it is not only about library support it is because when there are a issue in the compiler then a commercial product can not wait months and years for a fix or a work around .This mE does not understand or want to understand
We also use compilers that cost at least 10 times what the C18/C30/C32 cost

(2) Why I stick around mE easy I like to help people learning Micro Controllers(specially MCHP) and programming and here is many starters(newbies) ,I learned in this forum from people like Mince a Taties a lot, and after all our diferences I do like the guys from mE as I believe that they have the ability to produce great tools !! There development boards are great tools !!
(3) Tell me which person will not get frustrated when waiting more than 5 months with 2 releases in between with no fix for a problem ? useing it for Hobby or comercial projects does not matter

I agree with you for the most part and the standard "Thank you for your suggestion, we will pass it to our developers" becomes annoying after one realises that those suggestions are (for the most part) de facto ignored

I do think mE did not realize that the customers know this by know

I suspect that ME team is understaffed in maintaining all those compilers but I guess they chose diversity over quality as part of their business strategy.

This is quite possible which will not pay off in the ARM world in my opinion ARM is mostly used by Commercial product producing people small amout of hobbiests

[LOE]

I like your way thinking. I did notice that you and Mince quite often help other people and it's commendable (to say the least). Mince is perhaps a bit more harsh (if I'm not mistaken he is Scottish LOL) but both of you are doing great job. Thx!

I do concur with your assessment of ME weaknesses and advantages. I mentioned libraries because if they're aiming to the "not so commercial" market (I suspect they hate words like "hobby market") then a large number of simple to use libraries are a must and that's where they're often lagging behind with implementation of new libs. I myself come from the analogue design world and having a prior knowledge of C/C++ computer programming I found a relief that they're sticking to ANSI C and present a clear and understandable IDE at reasonable price. However, the moment I wanted to do more complex stuff I was stuck with close sourced libraries that behave strange at times when combined with more specific functions of MCUs. So after a few frustrating experiences using libs I lost my patience and basically do most of the programming without much use of libraries, although at times I use some of them to shorten up time spent programming basic stuff. So at this point I'm considering to switch over to Microchip C series of compilers, especially since some of the commissioned 3rd party companies I cooperate with use it (mostly C30) and just recently I have had a hard time going through some of their code.

That said, with the recent introduction of MPLAB X IDE and with ME development boards having additional ICD2/ICD3 connectors allowing the use of Microchip ICD tools I'm considering licensing C30 and switch over to it. I also licensed Proteus and find it a great time saver, especially with the possibility of COFF debugging and (as we all know) C30 produce Proteus compatible COFFs while ME is unwilling to solve the problem of incompatibility of MikroC generated COFFs and Proteus. Which is kind of ironic because Labcenter crew is very friendly and provide extremely good technical support and I'm rather sure they would do they best to help solve that issue. I suspect that ME guys see Proteus as a competitive product and are unwilling to spend some time communicating with Labcenter staff. The most ironic part is that it is nonsense considering the price difference between their development boards and Proteus with particular MCU family packages and in any case, number of supported models by Proteus is limited and is not real replacement for real life testing. They also introduced some of the ARM core models but I didn't see any mention of PIC32 line so that's also a thing that gives advantage to physical development solutions of ME.

Just out of curiosity, what are the compilers that are so expensive? I have had an opportunity to try out IAR a few years back for a brief time while working for a company that used them and they were quite pricey at that point. However, IAR was not 10 times as expensive as Microchip C series and if I'm not mistaken they abandoned their Microchip lines of compilers some time ago and I'm not aware of any compilers that would be so much more expensive.

Finally, I would like to add that I like ME product philosophy of physical development solutions and I haven't found anything comparable at such affordable prices. Their compilers cover most of my needs although I rarely use their libraries for the reasons I mentioned previously. Now, if they could just decide if they want to produce more "not so commercial" compilers (read "hobby compilers") and then stick to that philosophy by producing ever new libraries. Or if they want to go into more commercial waters but with much quicker response to bug fixes. In fact I suspect they can do both if they simply hire more developers. At the present they're positioned in "no man's land" and it makes hobbyists unhappy with slow addition of new libs while at the same time it makes professionals unhappy because of their very slow response in fixing reported bugs. That said, I think I will stick with MikroC for a while longer and see where it goes although so far there has been no indication that ME will change their "no man's land" philosophy. I believe they're great guys but they really should decide which way they plan to go in the future.

I hope some of the ME team will relate some of what's being said to their management. In fact in a few months I will probably have to travel to Belgrade on a business trip and I just might pop-up in their headquarters to tell it to them myself. And buy them a few chevapi and piva.

[p.erasmus]

if I'm not mistaken they abandoned their Microchip lines of compilers some time ago and I'm not aware of any compilers that would be so much more expensive.

Yes they did and I think it was the case the MCHP compiler were cheaper and had a lot of stack support ,IAR were doing the same as mE makeing the users angry with slow implementations !!
MCHPwill always fullly support all MCHP compilers as they also do with the Hightech compilers,There is a new compiler series under it way from MCHP however if you have an exsisting license you will be upgraded to the new compiler series with out any cost. you can safely use the MCHP compilers!

Just out of curiosity, what are the compilers that are so expensive?

We use Infineon TRICORE for engine ECU's and Infineon XC2700 series mcu's parallel to MCHP and the compilers for these mcu's are from Altium called TASKING VX they cost above $10K for a single seat license and around 2.5 for a 3 seat floating license ,however very little libraries basically only the ANSI C standard libs and then peripheral stacks but full blown optimized for speed recources ect it is a commercial compiler.

At the present they're positioned in "no man's land" and it makes hobbyists unhappy with slow addition of new libs while at the same time it makes professionals unhappy because of their very slow response in fixing reported bugs. That said, I think I will stick with MikroC for a while longer and see where it goes although so far there has been no indication that ME will change their "no man's land" philosophy

I could not say this in any better way

In fact in a few months I will probably have to travel to Belgrade on a business trip and I just might pop-up in their headquarters to tell it to them myself. And buy them a few chevapi and piva.

That would be a good idea!!

Thanks for your view on things it is appreciated

[filip]

Hi,

@Loe

I couldn't help but notice that for years you're complaining about extremely slow response by ME team in maintaining their Micrcochip product compilers and very slow addition of new libraries. I agree with you for the most part and the standard "Thank you for your suggestion, we will pass it to our developers" becomes annoying after one realises that those suggestions are (for the most part) de facto ignored. I suspect that ME team is understaffed in maintaining all those compilers but I guess they chose diversity over quality as part of their business strategy.

Please, we are doing very hard to provide our users the fastest possible solution, but as our market and product spectrum is very broad, there can be some delays when fulfilling these goals.

@p.erasmus
Please, we know what our users are wishing for, we have this all on our to-do list, and we haven't forgotten about these wishes.
I believe that you know that development can be pretty complex and time consuming, so I warmly ask you a patience from your side.

Regards,
Filip.

[p.erasmus]

@filip

I believe that you know that development can be pretty complex and time consuming, so I warmly ask you a patience from your side.

No problem

Regards

[LOE]

but as our market and product spectrum is very broad, there can be some delays when fulfilling these goals.

I think that was the exact thing that p.erasmus is complaining about and I tend to agree. If your resources are stretched then logic dictates that either you lessen the strain by restricting your growth factor or that you add sufficient number of people and resources to your development team.

That said, those are ME management business decisions (for better or worse) and all of complaints are meant in the constructive way.

[filip]

Hi,

Thank you LOE for your opinion, we appreciate your feedback regarding this matter,
but as you already know these are all management decisions, so we will let them do their job.

I'm sure they will come up with the decision that will be beneficial both for our users and company.

Regards,
Filip.