Hello,
I have a code problem that worked in the previous version of the compiler on PIC18F26K22. The UART buffer contains the "help" command and is compared with the "help" string:

if strncmp(rs_in,'help',4)=0

This condition, but not evaluated as true.

That's because the compiler doesn't really work for K42 processors . Effects you observe are due to linker error that makes use of several libraries impossible. Due to bigger RAM, K42 processors have FSRx registers (instrumental in indirect addressing) placed much higher in memory than previous PIC18 processors but linker ignores it while linking libraries. Effects are easy to imagine.

There are other quirks, also in software simulator (ICD wasn't even implemented), so I would not recommend using mE compilers with K42 processors yet.

Frankly, after finding errors in compiler, in simulator, in definition files, and in mikroProg Suite (not to mention new IDE quirks) I stopped analyzing the last release so there may be more problems than I know of. Obviously, mE is mainly concentrated on selling more hardware and software developers get barely enough time to be able to introduce changes that are directed at reaching this goal (vide mikroSDK addition). No time to remove years old bugs and quirks or solidly prepare for new processors .

_________________
Replacement libraries for mP PRO and PIC18 processors, mP PRO tips & trics

Hi,

@tull,
Yes, you are right, the strncmp does not work correctly, I will report this to our developers.
I apologize for the inconvenience caused by this.

@janni,
Thank you for your explanation of the issue, apparently there are some things that needs to be fixed for this family.

Regards,
Filip.

This is a very sad reality once more the compiler update add more bugs than before. Nothing is solved and almost useless new feature were implemented. The new Libstock Manager is only a selling opportunity and add nothing for the real developer. And now we probably need to wait for all the other family of compilers to be updated before solving this one.

_________________
Serge T.
Learning is an endeless process but it must start somewhere!

To save others disappointment - most of the String library won't work with K42 processors. Large part of Conversions will also be useless as well as many of routines that use indirect addressing in other libraries.

I gather, you're not in a position to draw any timeline for these fixes...

Just in case developers miss these things (when they'll have time for it) - compiler overuses MOVFFL instruction (even in assembly insert 2-word instruction MOVFF is always converted to 3-word MOVFFL) and doesn't notice that many SFRs are in access bank (for example, RAM bank is switched almost every time the STATUS register is involved). Lots of unneeded code is produced this way. And simulator does not emulate mentioned MOVFFL instruction, thus making simulation pointless.

_________________
Replacement libraries for mP PRO and PIC18 processors, mP PRO tips & trics

Just picked up this thread after finding a few err 'issues' when porting from PIC18F2523 to PIC18F26K42 and find this pretty frustrating...which started when IPEN_bit was not recognized, then manifesting itself with all sort of string related issues as I pursued the porting.

Thank goodness I found this as I exhausted some hours trying to evidence my issues for the team...so not for the first time, a big thanks to janni for the pretty damning summary.

@mE team - do you have an eta for full support of these devices?

Thanks

Ok, that explains a lot of the pain I've been having recently with the new 18F26K42 and MikroBasic. I've written (and tested) most of my program on a 18F45K22 and then started porting it to the new K42, which will be the target device used in the product. I was thinking that since most of the program is handling data communications and decision logic, it's pretty hardware independent, so I can simply test it on the K22 and when the K42 samples arrive, I'll just rewrite the HW setup section according to the datasheet and call it a day. Oh boy, how wrong I was. Even a simple memcpy doesn't work! Ok, fine, I've written my own memcpy that does work (although it's just a fancy wrapper for a loop), let's try the new multi-vector interrupt controller. I've given up after three hours of trying to fix the reset loop (due to MEMV condition). The compiler doesn't let me specify any other interrupt vector using the iv keyword, than 08h and 18h. Since there is absolutely zero information about these new features and how to use them properly with MikroE compilers, I was expecting to be able to simply assign the int. vector to a routine using the iv keyword. But nope. So unless I'm missing something obvious, this isn't working either. I won't even touch the DMA engine, which I wanted to use for UART RX, beacause I've already spent too much time troubleshooting the other issues.

Guys at MikroE, I like your products and I've been using mB with EasyPIC7 board for years. However, I'm not happy this time. If you list a certain chip as supported, it means to me that I can choose that chip when designing a product, because, well obviously, my toolchain supports it, so it's a no-brainer. It seems though, that we might have a different understanding of the word "supported". I've just spent three workdays pulling my hair out while running through the code over and over again, chasing errors that weren't even there.

Hi,

I am truly for the reported issues about the K42 family.

Obviously these issues are very serious and they will be treated as such, we didn't want in any way to deceive our customers,
simply some things pulled through without noticing.

I have notified our management regarding the K42 family problems, I'm sure this will be resolved and you will safely use the compiler.

Regards,
Filip.

Filip, do you have an ETA for this fix? Echoing Fakir's comments here, I too am a little disappointed this got through as I also relied on this device for costing a 3rd party's project. I had to explain to them why the project was delayed and it did not reflect well.

I understand these things can and do happen, but this was not a small bug or quirk in the compiler, but more a device definition catastrophe and would like to have at least some idea of time frame for remedy.

Thank you for you reply though.