Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. To define or not to define

    Hi Jorge, Maybe borrow is better. I did say or other similar compiler. The MikroC PRO for PIC or ARV stdint.h files are very nice for SourceBoost use. But if you want to do your own typdedef and use float.h you could try this: #ifndef _FLOAT_H_ typedef unsigned char uint8; #endif Cheers Reynard
  3. 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
  4. To define or not to define

    So it's a bug then ? The current version of SB 7.42 doesn't ship with a copy of stdint.h. Not all novices know to steal a copy of stdint.h from gcc avr (or other similar compiler) and use that. Cheers Reynard
  5. 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
  6. To define or not to define

    In the header file <float.h> there is the following code. // define types #ifndef uint8 typedef unsigned char uint8; #endif According to the manual an identifier can only be defined using the #define directive. The #ifndef in this case is worthless and not doing the expected job. When I do this, // define types #ifndef uint8 typedef unsigned char uint8; #endif // define types #ifndef uint8 typedef unsigned char uint8; #endif the compiler complains as I am redefining uint8. The second typedef is not being blocked. So what is the #ifndef suppose to do here ? Cheers Reynard
  7. Earlier
  8. sprintf incorrect output

    Hi Jorge, I did my own implementation to get what I needed. The sprint does do negative numbers as well but sign is still in the wrong place (0-1 for -1). As you say it is a bit of a heavyweight. I am running at 64MHz with 64k rom PIC18 so not much of a problem. Cheers Reynard
  9. 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
  10. sprintf incorrect output

    Hi Jorge, It is confusing to the reader when the prototype says unsigned int but I suppose they had to say something as the function is non standard to normal C. The output is still incorrect whether you specify +1 or -1 as the value. Cheers Reynard
  11. 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
  12. sprintf incorrect output

    The sprint function is not outputting the expected formatted string. sprintf(strBuffer, "%+03d", 1); This format is producing 0+1 and not +01 as expected. Tested OK with gcc avr compiler. SourceBoost C 7.42, Windows 10 64bit. Interesting that this function takes an unsigned int value but will format a signed number. Cheers Reynard
  13. Try changing random_int = rand(); to random_int = rand() >> 1; This will reduce the possible random range by half but your code will operate on the positive half of the int range (when itoa implicitly converts unsigned to signed it will deal with lover half of the unsigned range which converted to signed will contain only positives).
  14. itoa is expecting a signed int and you are giving it an unsigned short. You should explictly cast it. ptr = itoa((int)random_int,buff,10);
  15. Ok, Well, I manged to figure out how to fix this anyway. The 'light' function uitoa_dec() will give me an unsigned number that I can use in the display. It still makes no sense to me why a defined unsigned short placed in a function requiring an unsigned short would somehow produce a signed result. Anyway, problem solved.
  16. I am attempting to use the rand and srand functions to generate a "random" pause between sections of my code. I am using the 18F2510, have added the rand.pic18.lib file to my project and have included the rand.h file in the program. I keep getting negative numbers in my random number variable. I don't understand this as the routine states that an unsigned short should be returned from the call. I wrote the following as a test of the rand and srand functions to see what is happening. char buff[9]; char* ptr; unsigned short random_int; srand(7123); for(i = 0; i < 10; i++) { lcd_clear(); random_int = rand(); ptr = itoa(random_int,buff,10); // contained in stdlib.h lprintf(ptr); } The values I get form this are as follows: 15322, -16984, -9592, -22399, -30702, -32477, 4657, 8984, 12677, 6234 Can someone please explain to me what I am doing wrong? I just modified the code to give me hex numbers instead of decimals (radix 16 instead of 10). The results are 3bda, bda8, da88, a881, 8812, 8123, 1231, 2318, 3185, 185a. None of these are negative from the standpoint of an unsigned short. Why am I getting signed numbers in this? What is the lprintf (or itoa) doing that it should not? What have I missed? Can someone please explain this to me?
  17. Hi Glad it helped. Best regards Jorge
  18. Thanks, This did the job - I was almost sure I did run it as administrator since I had also a problem with preg.exe which was solved by running as admin, seems I forgot to run as admin for this one.
  19. 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
  20. Hi, Bought the Pro License (7.42). Ran preg.exe Selected the goodies option Entered the license info and got a message that the key is valid and was stored Then ran goodies.exe Got the following message: "Failed to extract file c:\programfiles(x86)\sourceboost\lib\novolib_pic18t6e4ts2.lib How do I get the goodies?
  21. 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
  22. NEED HELP

    I'm new to C-Programming, i have downloaded the application over 5 times now. I am trying to get it to just compile. I have created my file path and opened a new workspace and project. But every time i try i get this error. Could really use some help diagnosing as i am at my wits end after 5 minutes and i thought this was going to be fun.. Any help is greatly appreciated. Craig.
  23. Dear Pavel, Dave There are some "new" PICs with 4 and 5 USARTs! lots of connectivity... It would be nice if Sourceboost would support them 4 USARTs family (9 types) : PIC18F65,66,67,85,86,86,95,96,97J94 5 USARTs family (3 types) : PIC18F65,66,67K40 Thanks!
  24. I have a routine like: EEPROMwrite(unsigned char addr, unsigned char* str, unsigned char len) { // print out hex of string of length "len"... } I call it using hex replacement values in a string, ie using the "\xnn" replacement method: EEPROMwrite(,addr, "\xFF\x00\x01",3); (prints 00 00 01) Now, if a "\x" replacement in the string contains FF (or ff) , the hex value read \ printed is 00 .. BUT if the value is preceded by another value (which is not 00 or FF), eg, EEPROMwrite(,addr, "\01\xFF\x00",3); (prints 01 FF 00) ... it correctly reads \ prints the hex value as FF! To be clear, EEPROMwrite(,addr, "\00\xFF\x00",3); (prints 00 00 00) ... does NOT print out FF, as the preceding value is 00.. I have checked the web and this does not seem to be expected behaviour - can you look into it please?
  25. I have a routine like: EEPROMwrite(unsigned char addr, unsigned char* str, unsigned char len) { // print out hex of string of length "len"... } I call it using hex replacement values in a string, ie using the "\xnn" replecement method: EEPROMwrite(,addr, "\xFF\x00\x01",3); Now, if a "\x" replacement in the string contains FF (or ff) , the hex value read \ printed is 00 .. BUT if the value is preceded by another value (which is not 00 or FF), eg, EEPROMwrite(,addr, "\01\xFF\x00",3); ... it correctly reads \ prints the hesx value as FF! To be clear, EEPROMwrite(,addr, "\00\xFF\x00",3); ... does NOT print out FF, as the preceding value is 00.. I have checked the web and this does not seem to be expected behaviour - can you look into it please?
  26. Thanks Pavel, that was the problem. Cannot believe I missed it, it was a long day. Rgds Tim
  27. You access function argument correctly. Must be something else that causes the problem. Have you included system.h? If W is undefined you'll get same error (to check replace W with 0)
  1. Load more activity
×