mikroProg Suite for PIC 2.30 released - but retains bugs

[PIC007]

It is all very well releasing new additions, but how about also channeling some resources into fixing some of the bugs and deficiencies being reported before releasing upgrades. Like...

*PC out of range - please reprogram and restart debugger > when you pause the debugger a bit too long on a breakpoint or during a single step through code.

*WriteChip: Executive return error code: > whenever it feels like it (and all to frequently) and requires a complete restart of one's system to clear.

*Where the Watch panel does not always update and it takes having to click, or move a scroll bar within it to get focus in order to have the variable refresh while paused on a breakpoint.

*Unnecessarily awkward method for the user to add variables to the "Watch lists" - have you tried to find a variable in the dropdown list when there are many hundred shown (as is the case when using vTFT program)? Why not make it user friendly, like MPLAB ICD3, where you can simply drag and drop a value to be "watched" to the watch panel. At worst, let user add a variable to be watched by being able to type its name (I did recently learn that you can right click on a variable and there is an add to watch option - the mikroPROG documentations did not mention this).

*Watch list only allows one type of value for each variable being watched. MPLAB you can click on the top bar to add another "value" column and display a different format i.e., you can have both the char and hex format for variables. mikroPROG allows you to only choose one or the other.

*It is annoying while single stepping through code if one inadvertently clicks on a library function and it moves into the assembler listing. It seems you can not get out of this till the very end (unless I am missing a trick) - "Step Out" does not appear to work in library assembler listings. Why not have a switch which the user can set if he wants debugger to skip libraries, delays etc, where one can inadvertently get hung up?

Why does it take so terribly long (and I mean several tens of minutes in cases where one may need to specify a large range between the start and end addresses) to load program code into the "CODE WATCH" debug window? It is almost not worth using this feature at all. Worse still, if after 15 minutes you decide you are tired of waiting while it slowly uploads the memory, there is no way to terminate this - other than to close down the compiler completely. There must be something wrong for it take so long to upload code watch - MPLAB and ICD3 has it there in an instant.


Sorry to put a damper on mikroElectronika's marketing machine - but frankly there are enough other people on this forum trying to make you aware that there are some serious issues you should be taking care of with your existing software tools.

Hopefully we can be taken seriously in this...

Thanks

[p.erasmus]

Hahahahhaah
I hope you get a responce in this forum if you do not say how great mikroE is then your post and bug reports get ignored
however the things you mention we have consistantly reported and asked to be fix or changed since the days of the non pro compilers and the funny part
is that since then mE is consitanly saying they are aware of these things and will fix it hahahahah but they never say when

the only progress we see is the addition of new hardware and libraries to support this hardware because they make money with it once you bought the hardware
the software issues has no priority at mE and I am very sorry to say this but it proofs to be correct time after time

as here no answer from mE

http://www.mikroe.com/forum/viewtopic.php?f=101&t=58517

again here
http://www.mikroe.com/forum/viewtopic.php?f=192&t=58929

I can easily put together 100 links from this forum showing how they promisse and never fix or even not answer to the problem


We have to live with this tool as it is or find another tool set the only problem is when you invested more that $3000.00 in the mE tools it is not so easy to pay again the same amount for the MCHP compilers

[IngSieb]

Hi,

@P.Erasmus: I think I agree with you.

My Story:
In the last years I worked with the 'old' MPLAB-IDE and the MPLAB-C Compiler.
Mostly I have had no problems with it, only the typically little bugs that are exist in software.
But with a new update most of them were eliminated.
Then, I thought about to change to MikroE (2 years ago) to get a new modern IDE/Compiler.
It seems very attractive: Good Price, many Hardware, many Tools, good descriptions, etc.
So, I decided to make one Project 2 years ago with MikroE-Tools. I think it was V4.??.
There were many bugs in the Editor/IDE and the Programme MikroProg has had also many problems.
O.k., I finished the Project with the conclusion:
O.k., the Basics of the IDE are good and in some years all the 'Children Illnesses' are eliminated.
Then, I can decide to change from Microchip-IDE to MikroE-IDE.
Now, I started a new project 2 weeks ago and I was wondering myself wich problems I have
with the actual Version. See viewtopic.php?f=192&t=59059 .
Also, the libraries could be better. There are no improvements.
What is the idea of libraries? Libraries should eliminate the work to understand the complexity
of the pheripherals (for example like API's) to speed up the users work.
For example:
To configure Timers with Capture/Compare and or PWM can be complex in some cases.
I wondering that MikroE has no libraries for Timer-Modules. MPlab has Timer libraries from the beginning!
The new TimerCalculator is a 'Joke'. You have also to understand completely the Timer structures to use it.
Also, the ADC library is not very strong. There is no possibilty to configure the ADC in that way you want.
For example, to use the ADC with an external voltage reference is not supported by this library.
That's very weak.
O.k., this is why I agrre with you.
I saw many updates with the addition of many processor types and hardware bricks.
And last weekend, I was thinking about the issue why there are not so many improvements, I was very
disappointed about the MikroE-IDE. I also thinking about the price of the IDE and the update policy.
It seems great to get liftime upgrades, but I come also to the conclusion that the IDE/compiler is only
a product to bind the user to the MikroE's hardware tools and bricks, to buy them.
So, the focus is mostly to the hardware and not equal to the develpment tools.
I think this is not the right way. The MikroE-IDE has potential and could be together with the hardware
to be a one of the best develpment tools.
But to become this, they have to do many improvements and a lot of work...
My conclusion:
I don't change completly to the MikroE products.
I think I spend my time in the next days to investigate the MPLAB-X.

Regards
IngSieb

[PIC007]

My conclusion:
I don't change completly to the MikroE products.
I think I spend my time in the next days to investigate the MPLAB-X.

Frankly I wish I never switched from MPLABx to mE . I did so because I thought the visual TFT would be helpful, but it is so full of its own problems I now prefer to write my own graphics.

As to the mikroC for dsPIC debugger - I have had problem after problem with it crashing and hanging my system. You pause a little too long at a breakpoint and the system hangs etc. I have grown to dread using it. It is not worth its name as a debugger. mE have acknowledged the problem to me, and infer it is unique to the PIC24EP/dsPIC24E family. If so, I suggest others take careful note and choose a different series for their development.

The IDE editor is also full of bugs and there are reports on this forum going back many years (and equally as old promises to fix it from mE).

[filip]

Hi,

I can only express my apologies because of the problems that you are facing.
The problem was acknowledged and the development team will do whatever it takes to fix it.

Again, I am very sorry for this issue.

Regards.
Filip.

[PIC007]

I appreciate your reply Filip. Hopefully the commitment to fix this is genuine.

For my part, I will undertake to post my appreciation here as soon as this is done.

Being able to run the debugger is an essential part of programming - particularly for those of us who make mistakes!

[Acetronics]

One more ...

How to program a 16F628 with the microprog suite ( 2.30 suite, classic program, no bootloader ) ???

verifying option fails ( 0000h programmed everywhere in the program memory ... sooo, it's a real good BUG !!! )

Alain

[filip]

Hi,

I'm using EasyPIC7 and mikroProg Suite for PIC 2.30 with 16F628 without any problems.
Can you please tell me which hardware are you using and if possible provide more details of this issue ?

Regards,
Filip.

[Acetronics]

Hi, Philip

that's very simple ...

I only use the Mikroprog suite ALONE with a MPLAB 8.92 compiled program, as I did for years.
Board is an EP5, but behaviour is the same with an EP7 ...

the Hex is correctly loaded in the Memory dump window ... but chip prog memory is programmed with ZEROs everywhere ... ( read from the chip memory )

note:
1) I'm not the only guy it happens : I tried if because another forumer told me he couldn't get his chip programmed. ( our programs are different ones )...

2) when changing some parameters in the options tab ( left under of the window ) programming SOMETIMES happens fine ( really far from each time ...)

3) looks chip programming is fine when using the MikroE IDE to run MikroProg

4) same behaviour with Mikroprog V2.29 ...

5) I use Win XP SP3 Home ( 32 bits )...

Alain

[filip]

Hi,

I am really unable to reproduce this issue.
Do you have maybe another 16F628 MCU taht you could try ?

Regards,
Filip.

[Acetronics]

Filip,

It would be MUCH better for you to admit your products are far from perfect ...
I always laugh when read there have been ONLY 5 bugs resolved since Oct. 2010 !!! http://www.mikroe.com/forum/viewtopic.p ... 42#p102115

I've OF COURSE tried 2 or 3 BRAND NEW 16F628-20 chips before speaking of a BUG.

Please, less promises ... and more good stuff ...

Alain - really tired about MikroE Promises ...

[MaGiK]

Hello Alain
Please pull down RB4 pin then try programming.
Let me know what happens.

Ohh .. One more thing, Please be kind to the technical support team. They're trying their best.

HTH
Best Regards

[Acetronics]

Hello Alain
Ohh .. One more thing, Please be kind to the technical support team. They're trying their best.

HTH
Best Regards

Hi, MaGik

halas ... just trying !!!

You know what ? there's at least ONE good thing : they recently introduced an auto-update for their softs ...


do not ask me why ....

Alain

[MaGiK]

Did pulling down RB4 solve your issue? If not, please tell me so that we can try a different approach.

Best Regards

[Acetronics]

Hi, MaGik

The issue is solved ...

it is called " Picstart + ", " PicKit 2 or 3 " or " ICD 2 " ...

Hope you will understand I'm really tired of " Bug Hunt " ... and I'm not the only one.

Alain