"NECTO Studio is here!"
Ahhhh... no wonder you guys haven't been doing the work to get your legacy PIC IDEs up to snuff [mikroC PRO for PIC & MikroC PRO for dsPIC]. Based on the instabilities [avoid UNDO!], the poor planning [e.g. no way to capture config bits in the code, manual clock frequency entry -- vulnerabilities to portability, at the least], bare-bones Library implementations, functions that don't work (like Clock_kHz()), and the latest absolutely egregious compiler flaw that I just found (viewtopic.php?f=88&t=76240), why would I trust that your "NECTO" is a quality product that isn't going to frustrate the hell out of me?!?
"Looking at the past is not a reliable way to predict the future."
Here's another one: "Fool me once..."
Et tu, NETCO
-
steve42lawson
- Posts: 183
- Joined: 06 Mar 2008 17:35
- Location: St. George, UT
- Contact:
Et tu, NETCO
Humility is the lack of the desire to impress, not the lack of being impressive.
Re: Et tu, NETCO
Hi,
First of all, I apologize for the issues which you reported on the other topic, our development team will look into it ASAP.
Secondly, a few things you mentioned - no way to capture config bits in the code, manual clock frequency entry - are already on the developer's desk, I'm sure they will do their best to meet the needs of our users.
The peripheral library implementation is carried in such a way that most functionalities are covered in order to demonstrate the compiler's ability to work with the peripherals. Of course, there is a lot of place for improvements, especially for the professional users who tend to maximally exploit the peripherals with minimal RAM/ROM consumption.
I believe these users will most likely write their own libraries, rather than using predefined ones as they must ensure every line of code is written according to their needs.
Having this in mind, it is pretty difficult to know beforehand what is suitable for each user and consequently write the code which will satisfy all of them.
You mentioned Clock_kHz function is not working properly, so could you please elaborate this, I would like to test it ?
We will do our best to fix and improve the compiler so you or others users will not need to feel frustrated or aggravated in any way.
Regards,
Filip.
First of all, I apologize for the issues which you reported on the other topic, our development team will look into it ASAP.
Secondly, a few things you mentioned - no way to capture config bits in the code, manual clock frequency entry - are already on the developer's desk, I'm sure they will do their best to meet the needs of our users.
The peripheral library implementation is carried in such a way that most functionalities are covered in order to demonstrate the compiler's ability to work with the peripherals. Of course, there is a lot of place for improvements, especially for the professional users who tend to maximally exploit the peripherals with minimal RAM/ROM consumption.
I believe these users will most likely write their own libraries, rather than using predefined ones as they must ensure every line of code is written according to their needs.
Having this in mind, it is pretty difficult to know beforehand what is suitable for each user and consequently write the code which will satisfy all of them.
You mentioned Clock_kHz function is not working properly, so could you please elaborate this, I would like to test it ?
We will do our best to fix and improve the compiler so you or others users will not need to feel frustrated or aggravated in any way.
Regards,
Filip.
