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.
strncmp - problem - ver. 7.2 on PIC18F26K42
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.tull wrote:I have a code problem that worked in the previous version of the compiler on PIC18F26K22.
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 .
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.
@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.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.janni wrote: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.tull wrote:I have a code problem that worked in the previous version of the compiler on PIC18F26K22.
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 .
Serge T.
Learning is an endeless process but it must start somewhere!
Learning is an endeless process but it must start somewhere!
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.filip wrote:Yes, you are right, the strncmp does not work correctly, I will report this to our developers.
I gather, you're not in a position to draw any timeline for these fixes...Thank you for your explanation of the issue, apparently there are some things that needs to be fixed for this family.
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.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
janni wrote: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.
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
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.
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.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.
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.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
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.filip wrote: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.
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.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
Hi,
Please read the official statement regarding the K42/83 family :
viewtopic.php?f=91&t=73891
Regards,
Filip.
Please read the official statement regarding the K42/83 family :
viewtopic.php?f=91&t=73891
Regards,
Filip.
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
Thank you Filip and also to the rest of the team for this comprehensive update and explanation of the various measures that will be implemented.filip wrote:Hi,
Please read the official statement regarding the K42/83 family :
viewtopic.php?f=91&t=73891
Regards,
Filip.
I will look forward to the device support in the near future as I am sure many others will also.
-
- Posts: 5
- Joined: 28 Dec 2018 17:04
Re: strncmp - problem - ver. 7.2 on PIC18F26K42
I just bought 5pcs of PIC18F47K42 MCU's last week without reading some feedback in this forum. I tried working on the IVT for a half day but it just would'nt work. Hope ME team will keep up to their promise. I still prefer using MikroC pro for PIC and PIC32 in my projects. It is easy to use.