Jump to content

JorgeF

EstablishedMember
  • Content count

    294
  • Joined

  • Last visited

Everything posted by JorgeF

  1. To define or not to define

    Hi Ops!! Stealing an header file from a different compiler might yield some surprises. But if you really need to steal one for BoostC, better steal it from XC8 from Microchip. The target devices are the same for XC8 and BoostC (PIC10/12/16/18) so you won't risk any nasty surprise when using multibyte formats (16/24/32 bits). Anyhow, I would check it in detail, probably there are number of conditionals (#ifdef) based on the default symbols defined by the compiler itself. If you find any, adjust it for the "BoostC" equivalent symbols. Best regards Jorge
  2. To define or not to define

    Hi Nothing, the "#ifnedf" can't do a thing there. I guess that somewere along the way they moved the definition of "uint8" from the preprocessor to the compiler but didn't correctly adjust everything. The "#ifndef" is a pre-processor directive that will only detect a symbol defined with "#define" or the equivalent command line parameter. The "typedef" is a 'C' statement to be processed by the compiler. The preprocessor knows nothing about 'C' statements so it just ignores the "typedef". AFAIK the correct way to defined a type is using "typedef", but to be able to protect it against redefinition a "#define" is needed. So in my opinion it should be something like this. #ifndef UINT8_T #define UINT8_T typedef unsigned char uint8 #endif OTOH, the "stdint.h" header has all the standard integer types defined and is globally protected against multiple inclusion, so I see no point on adding this extra type definition anywhere in a project. Some guys just like to re-invent the wheel over and over.... Probably this all thing is just an artifact/bug resulting of a chain of evoluctionary steps of the "float" lib. Best regards Jorge
  3. sprintf incorrect output

    Hi In my previous post I was refering to a generic "C" "sprintf" function. Meanwhile I revised the "BoostC" manual and noticed that the "sprintf" implementation in "BoostC" is a very limited one. I did some testing and it looks like the positive sign is beeing misplaced. OTOH the function is only available for positive numbers (unsigned) so you may either drop the sign or just stuff it at the beginning of the generated string. Something along this lines .... buffer[0] = '+'; sprintf(buffer+1, "%02d", 1); You may need to adjust field lenght or the order of statements for fine tunning your result. HIH EDIT ADD: Besides the testing for this topic, I had never used "sprintf" in BoostC or XC8, simply because I consider it too heavy (code size and speed) for an 8 bit PIC. I allways use the lightweight counterparts and add any needed handcrafted code for the specific formatting on a project by project basis. Best regards Jorge
  4. sprintf incorrect output

    Hi I'm not that sure that the constant value "1" is interpreted as unsigned int. It will most probably be interpreted as (converted to) an "int" as "int" is the default format in "C". Anyhow the "sprintf" function will take anything you throw as a parameter and will "interpret" each parameter acording to the format specifier on the formating string. EDIT: Correction The above aplies to the "printf/sprintf" familly of functions usually found on "C" compilers for desktop or high end microcontrollers, not to the limited implementation available in "BoostC". Sorry for any incovenience. Best regards Jorge
  5. Hi Glad it helped. Best regards Jorge
  6. Hi Did you run "goodies" in "run as administrator" mode? It is trying to write to a folder under "program files(x86)" wich is write protected for any user level but the administrator. HIH Best regards Jorge
  7. NEED HELP

    Hi I don't see any error, just what should be expected when compiling an empty program. BoostC is an optimizing compiler meaning it throws away any unused code. Your "main" function is empty, so there is no generated object code (Assignement.obj), hence the linker can't find it. Put something usefull inside your "main" function and the linker will find an object file to link. HIH Best regards Jorge
  8. Hi There is one thing in your logic that you might want to re-evaluate. I wouldn't trust a compiler to organize the code space in a continuos block, most of the ones I know do spread chuncks of code all over the place just to optimize for the addressing scheme of the PIC (mnimize pagging). The same spreading, for the same reasons, might be found with RAM usage. If you intend to use some part of your flash memory for data you would better reserve it. Use the "-rt" command line switch to limit the maximum address available for the program and use the flash above that address for runtime data (NVM). A work around for your initial question can be to adjust the top of rom (-rt) close the the actual size of your release code and calculate the CRC from "0x0000" up to your "-rt" value. You can calculate the CRC verification from the data on the HEX file as it is a byte image of what will be recorded in the program flash. BTW: Make sure you do program your release code on blank chips so you can use the erased value of the flash in your CRC calculation. Just my 2 cents of it.... Best regards Jorge
  9. Hi I usually find that kind of information on the HEX file used to program the PIC. If you tell us what is your goal, maybe there are other ways, besides finding the last used flash address, to achieve it. Best regards Jorge
  10. License Registration not working

    Hi Assuming those object files are part of your code, the linker might be trying to reuse them without a new compilation. Just force a full recompilation of all the source code. Best regards Jorge
  11. Hi Yes I wrote that, but I also worte... And this comes from my assembly programming experience. When it comes to 8 bit PICs, I have a lot more finished products written in ASM than in 'C'. Bit scanning needs often surface whenever you have an array of sensors, a keyboard or even LED arrays like in 7 segment displays. On all those situations, no matter how many tricks i come up with, the individual bit access ends up being more costly (instruction cycles and program memory) than bit mask based operations. So my experience showed me that it can be done but its not worth the effort. I don't se this as an universal truth, simply an 8 bit PIC specific (hardware architecture and instruction set) conclusion. Give me a different microcontroller and I would, probably, end up with a different conclusion. I also have a large experience in high level programming on desktop systems (C, C++, VB, Java, ...) and I happily port algorithms and code design accross different hardware platforms and operating systems. But programming an 8 bit PIC is a totally different ball game, there is no hardware abstraction at all. The ball game also changes deeply when moving from 8bit PICs to 16bit PICs or to 32bit PICs. The platforms are so different that even using "C" or "C++" one needs to adjust the algorithms, data structures and even the whole conceptual approach to program design. Just my 2 cents.... Best regards Jorge
  12. Hi Your codding seems a bit odd, to say the least. Assigning independent addresses to the fields of a struct is against the basic semanthics of a struct. I suspect the compiler is simply ignoring it and a warning is missing, maybe some inactive (disabled) warning. In terms of assigning fixed addresses to variables, what you can do is to assign an address to a variable of type struct (MyPortStruct) but the internal organization of the struct is out of control. If the 2 port addresses are consecutive, you can place a 2 byte variable (int) on top of them and access the individual bits of that variable, anyhow, the BoostC compiler will not accept a variable bit index like in your for loop (another thread). My solution to access computed individual bit ports is to use the loop counter to generate a bitmask and use a bitwase operation. Best regards Jorge
  13. Hii jartim Why are you commenting a post from 2010. That guy "naim" has probably gone for long, the post above is his first and only since 2010. Best regards Jorge
  14. Hi I think you are guessing right! And in doing so the compiler saves one instruction, as you can see in your openning post the second form (not preserved) is one instruction shorter than the first (preserved). Best regards Jorge
  15. Hi Are you sure that in the context of the whole program, the value of "trembler @ 0x47" still needs to be preserved for the remaining code after 0x020B ? Best regards Jorge
  16. Hi If code can be generated to compute indexing of arrays, struct fields, ponters and so on, for sure it can also generate code to access a given bit in a byte or word from a variable. My guess is that a piece of generic code to do that would be heavy and ineficient, so they choose to leave it to the programmer, to write optimized code for each use case. Just my 2 cents.... Best regards Jorge
  17. Preprocessor Macros Do Not Work In Mplab-X V4

    Hi If my memory is not tricking me, that "item 2" refered a problem with the Sourceboost IDE and has nothing to do with MPLAB integration. Just my 2 cents... Best regards Jorge
  18. Update To Test_Bit

    Hi Any special reason to not use the bitwise not operator (~) or does it generate the same code^? Using a logical operator induces the compiler to do a type cast on the result of "test_bit" to a logical type (char or int) before checking its value. In strict 'C' the "!test_bit(...)" expression translates to something like "!(char)test_bit()" or "!(int)test_bit(...)" How about droping the old "test-bit()" and similar macros and using direct bit indexing, If I'm not worng its available since the first release of BoostC 7.xx AFAIK the "test_bit", "set_bit" and "clear_bit" macros have been deprecated several years ago. EDIT ADD: "semantics do matter!" Best reards Jorge
  19. Hi Thank you Pavel. So, if I understood it correctly all the important things are acounted for, its only missing optionals. All the registers relating to oscillator configurations, interrupts, memory paging/banking and other core features are defined. The compiler and linker do handle interrupts (context), the memory maps (ROM pages / RAM banks) and config words correctly, including the tricky dispatching code used by Novo. All I have to take care by myself are the peripherals. Good enought for me! EDIT ADD: BTW, I mostly use MPLAB 8/X Best regards Jorge
  20. Hi Pavel What exactly means "limited support" in the version log? Its something to do with the core processor or its only a libraries thing? Best regards Jorge
  21. Hi There is a awful lot of temporary variables. You are probably nesting several functions with many parameters. Can you show your code, we may be able to suggest some improvements. Best regards Jorge
  22. Pic16 Boostc Far Array Indexing Error

    Hi The problem must be related to the index size (-idx) of the compiler and linker command lines. But the option for an index size of 2 bytes is only available on the PIC18 compiler (large memory model). Looks like this RAM access improvement on the PIC16F1xxx family as created a problem for the PIC16 compilers. The pointer workaround works because the maths are done on the pointer variable and not on the indexing SFRs. Just my 2 cents on guessing... Best regards Jorge
  23. Pic16 Boostc Far Array Indexing Error

    Hi you can use a pointer as a workaround, it generates correct code. #include <system.h> unsigned char uc_arr[192]@0x2270; void main(void) { unsigned char cnt; unsigned char *ptr = uc_arr; for(cnt = 0; cnt < 192; cnt++) { *ptr++ = cnt; } } generated code (lines reordered in program flash address order) //////////////////////////////////////// // Code with no source :-) //////////////////////////////////////// 0000 2819 GOTO _startup for(cnt = 0; cnt < 192; cnt++) { 0009 01A0 CLRF main_1_cnt 000A label1 000A 30C0 MOVLW 0xC0 000B 0220 SUBWF main_1_cnt, W 000C 1803 BTFSC STATUS,C 000D 0008 RETURN *ptr++ = cnt; 000E 0822 MOVF main_1_ptr+D'1', W 000F 0085 MOVWF FSR0H 0010 0821 MOVF main_1_ptr, W 0011 0084 MOVWF FSR0L 0012 0AA1 INCF main_1_ptr, F 0013 1903 BTFSC STATUS,Z 0014 0AA2 INCF main_1_ptr+D'1', F 0015 0820 MOVF main_1_cnt, W 0016 0080 MOVWF INDF0 0017 0AA0 INCF main_1_cnt, F 0018 280A GOTO label1 } } 0019 _startup 0019 3180 MOVLP 0x00 001A 2804 GOTO main
  24. Hi Another detail. If your new system is Win10, its not enought to log in as administrator or with an account with administrator rights. You have to use the "command prompt in administrator mode". HIH Best regards Jorge
  25. Hi Most likely. I have a native 7.x licence that I already moved accross PC reinstalations, upgrades and even from one machine to another without any issues. Also I've seen the same behaviour in licencing on other software products, the upgrade licence needing the previous existence of the base licence. HIH Best regards Jorge
×