Jump to content

chmotori

EstablishedMember
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About chmotori

  • Rank
    Newbrie
  1. Dave, I'm happy you already fixed this issue. Unfortunately, I'm stuck with my project since I cannot execute or debug the code. Have you an idea about when version 7.03 will be released? I recently bought a commercial licence for this new company I started to work with. I told my boss to buy this product because I already used it for a long time for non-commercial purposes, and I never had any problem. Now I cannot wait a month or two for the official release, I'm afraid I'll be fired before that time. Could you please build up a release candidate of the compiler? I'd appreciate it ve
  2. Hello, I recently upgraded to BoostC++ version 7.02, but it didn't solve a problem I'm having since a long time. I'll try to explain the issue with my own words, but then it's better to compile the project attached, and take a look to the code generated by the compiler. The program I've written currently is about 11kwords, that is a 67% of tyhe total memory space of the PIC16F1938. Analyzing the machine code generated by the compiler, right at the start (Reset vector at address 0x0000), there's a jump that should take the cpu to the area in which all of the static variables are initial
  3. Hi, with BoostC version 6.93, using the linker option -rt, the compilation summery reports the same amount both for available and used ROM memory, giving a (wrong) indication that 100% of available memory is being used. The project I'm working with is for PIC18F46K20, I turned on global optimization for the compiler (-O2), optimization for linker (-O1). With no -rt option for the linker, the summary reports: ROM available: 65536 bytes, used: 50308 bytes (76.8%), free: 15228 bytes (23.2%). When I add the option: -rt 0xF7FF, I get: ROM available: 50308 bytes, used: 50308 byte
  4. Hi, I don't know if it's a bug, but it's a bit annoying, that the boostC compiler (6.93RC2) only report a warning when i use the syntax: structVar->element where it's supposed to be: structVar.element since structVar is a struct variable, not a pointer to a struct. It's annoying especially because, when compiling ten or more files, the warnings are reported only at compile time, and are not summarized after the linker has finished. Regards, Elpidio
  5. Thanxs, in the meantime I did some further investigations... here is the disassembly listing of strlen library function: --- E:\Prg\SourceBoost\compiler\picantc\libc\string.c ------------------------------------------ 3272 6B95 CLRF 0x95, BANKED 3274 5194 MOVF 0x94, W, BANKED 3276 6EEA MOVWF 0xfea, ACCESS 3278 5193 MOVF 0x93, W, BANKED 327A 6EE9 MOVWF 0xfe9, ACCESS 327C 5195 MOVF 0x95, W, BANKED 327E 2B95 INCF 0x95, F, BANKED 3280 26E9 ADDWF 0xfe9, F, ACCESS 3282 50EE MOVF 0xfee, W, ACCESS
  6. Hi, I'm compiling a project for PIC18F46K20, the string library function unsigned char strlen(const char *src) returns incorrect string length on some occasions. I tried to investigate to get more hints, but didn't understand how to replicate the bug consistently. It occurs for some strings, while it doesn't for some others. All strings are in ram, pointed by a char *variable. As far as I can see, the value of the pointer is correctly passed to the library function, but after that I lose control of what's happening inside.... Let me know if you want me to post my project (it's a big projec
  7. ok, sent. if you need further information, please send me an e-mail (in case I forget to get a look at the messages in the forum).
  8. no problem, as you said previously, if you have such a policy of non-disclosure, I can send the whole folder. Just confirm me I have to send it to support@sourceboost.com.
  9. I had the same problem with one of my projects. There was a function, optimized as inline by the compiler, and called from my ISR, which gave me the same error. I tried moving the project folder to a different place, and it compiled successfully. I tried with both shorter and longer path, it didn't matter, it always compiled successfully, except in the original folder. At last, I found a way to make it compile in the original folder: I got a static variabile declared within the function, it was enough to move it outside, to make it work. Compiler: BoostC version 6.70 release cand
×
×
  • Create New...