Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. Apart from the spelling of your instruction it's the assembler that seemd to be stoopid. Cheers Reynard
  2. You seem to have ANSEL set for input AN0 but the channel selection (CHSX) set for channel 1 (AN1). Don't forget when you change a channel to allow a settling time to charge up the sampling capacitor before you start the conversion. You have also set 32 Tosc which is 8us per bit. Conversion takes some 11 bit times exceeding your 20us timer. Best to wait for conversion complete (GO/DONE bit = 0). Not sure what the shifting of the result is supposed to be doing. You cannot squeeze 10 bits into an 8 bit char. Cheers Reynard
  3. On some PICs the ADC inputs are switched on by default at reset. Try setting the ANSEL = 0 to turn the ports from analogue to digital. Also note the delay_ms(x) takes an unsigned char so 255 is the maximum value. Switch on "All Warnings" and the compiler will grumble at you. Cheers Reynard
  4. If you go to "Settings - Options - Tools", you can insert the path and filename for the programmer you want to use. e.g. C:\Program Files\Microchip\PICkit 2 v2\PICkit2V2.exe If you press the "Set Default" button, then when you press the fancy P button on the toolbar it will call up the programmer for you. The name of the source (hex) file is on the main programmer screen next to the label "Source:". You will obviously have to import your hex file using the File menu. Cheers Reynard
  5. Hi Ben, A small detail I can see is that the memory address definitions don't match the constant definitions. It is possible they are incorrect in the header file i2c_driver.h as well. Also note that the timer_ms(x) takes an unsigned char so is limited to 255ms. All PICs I have used have hardware i2c so I am no familiar with the software implementation of bit banging. Cheers Reynard
  6. Hi Neil, Try the BoostC example page. There is a zip file with fp routines in it. You may need an addition key to get the libc source code. Cheers Reynard
  7. Thanks Pavel. Look forward to squeezing out these little quirks. Will work around it for now. Cheers Reynard
  8. That's bad news. As a constant the compiler should have done all the shifting not the PIC. Both MikroC and Hi-Tech C do the expected simple assignment. Cheers Reynard
  9. Here z is a long and a constant (126) is being shifted left by 23 bits. The result should be a simple assignment z = 0x7e000000 computed by the compiler. Why all those extra instructions ? z = (long)126 << 23; 0D6E 0E7E MOVLW 0x7E 0D70 6E44 MOVWF log_00000_1_z+D'2' 0D72 6A45 CLRF log_00000_1_z+D'3' 0D74 6A48 CLRF CompTempVar664+D'2' 0D76 6A49 CLRF CompTempVar664+D'3' 0D78 6A42 CLRF log_00000_1_z 0D7A 6A43 CLRF log_00000_1_z+D'1' 0D7C 3644 RLCF log_00000_1_z+D'2', F 0D7E 3645 RLCF log_00000_1_z+D'3', F 0D80 3644 RLCF log_00000_1_z+D'
  10. The PIC16F88 has two config words, CONFIG1 and CONFIG2. You probably have only define CONFIG1 and BoostC will have only produces a single word at address 2007. It is possible that the new PICKit code looks for both words (2007 and 2008) in the hex file hence the warning. Try setting the CONFIG2 in your source and see if the warning goes away. If you are happy with the default values offered by PICkit then just accept them. I don't have a PICkit so just having a stab at replying with an idea. Cheers Reynard
  11. Hmmmmmmmmm Maybe design features like this should be described in the manual as embedded assembler syntax rules or something. Cheers Reynard
  12. This statement gives "error:missing right paren" asm {bcf _y+3,7} But this statement compiles without any error asm {bcf _y+3,7 } Why is the closing (on same line) not seen in the first instance ? Cheers Reynard BoostC 6.90 XP Pro SP3, PIC18F8722
  13. Hi Dan, You can use the standard C macros for time and date which will generate text strings. char time[] = __TIME__; // "16:38:53" char date[] = __DATE__; // "Nov 30 2008" Cheers Reynard
  14. Bert, You may need to put a C wrapper around any called subroutines. void test(void); // Prototype. void test(void) { asm { // code here... } } Cheers Reynard
  15. Hi Neil, Done the 3 basic trig functions (sin,cos,tan) and they seem to be working OK. Worked in the atan function but with 500 iterations it takes a long time and accuracy only good to 3 places. Nothing wrong with the formula, Taylor series or something, but the build up of floating point errors using short floats. I found another bit of code that I have converted over to BoostC. It is very fast by a factor of 10 over the original code I have been working with and alot more accurate. The accuracy probably due to less arithmetic hence less floating point errors to build up.
  16. Nice to see that Dave is interested and I hope others are too. I have made a few more tweaks to the sine function which increased the speed by 42 percent from the original working source. float mcu_sin(float x) { float_rounding_mode = float_round_down; float ac = 0.0; float nv = 1.0; float xv = x; x = float32_mul(x, x); for(unsigned char cnt = 2; cnt < 50; cnt+=2) { ac = float32_add(ac, float32_div(xv, nv)); nv = float32_mul(nv, float32_from_int32((int32)((unsigned int)(cnt * (cnt + 1))))); xv = float32_mul(xv, x); xv = xv ^ 0x80000000l; } return ac; } The last line of t
  17. Hi Neil, Another little tweak would be to take the x squared outside of the for loop and you gain 12 percent in speed. x = float32_mul(x, x); for(unsigned char cnt = 2; cnt < 50; cnt+=2) Cheers Reynard
  18. Just tried it in MikroC and they allow it too. Another one for the BoostC to-do list. Cheers Reynard
  19. Hi Neil, Thanks for the float math and prinf functions. I thought I would put it to a small test with the sin function but ran into a small problem. nv = float32_mul(nv, float32_mul(float32_from_int32((int32)cnt), float32_from_int32((int32)(cnt + 1)))); This line does not work correctly. I think it may be due to recursion with the float32_mul function. The first time through the loop, nv has the value 12.00000 instead of 6.00000. Splitting these two multiplications up into separate calls seems to work OK. Cheers Reynard
  20. volatile and const are access modifiers and not part of a data type which typedef is just another name for a data type. You will have to stick to using 'volatile v8 myuc' to avoid errors. I am no expert on K&R C it's just my thinking. Cheers Reynard
  21. Reynard

    Float Lib Bug

    Don't get too upset Neil, I talk to anyone foo = bar[1]; 005E 5005 MOVF gbl_bar+D'4', W 0060 6E09 MOVWF gbl_foo 0062 5006 MOVF gbl_bar+D'5', W 0064 6E0A MOVWF gbl_foo+D'1' 0066 5007 MOVF gbl_bar+D'6', W 0068 6E0B MOVWF gbl_foo+D'2' 006A 5008 MOVF gbl_bar+D'7', W 006C 6E0C MOVWF gbl_foo+D'3' The assembler code appear to copy the 4 bytes. Cheers Reynard
  22. Reynard

    Float Lib Bug

    Works for me Neil using the same set-up as you. Simulator shows 4 byte copied. float foo; float bar[2] = {1.23,4.56}; foo = bar[1]; Simulator gives foo = 4.5599999 Cheers Reynard
  23. Alastair, Note that length is also an unsigned char, so you will compare zero bytes using 256. Cheers Reynard
  24. Hi Neil, Here is something to think about. #include <system.h> void MyFunc(void); void main() { MyFunc(); } void MyFunc(void) { char mychar; mychar = 0; } In the linker option, set -rb 0x7ffc to get the assembler code looking like this:- #include <system.h> void MyFunc(void); void main() { MyFunc(); 8004 EC00F040 CALL MyFunc_00000 } 8008 0012 RETURN void MyFunc(void) { char mychar; mychar = 0; 8000 6A01 CLRF MyFunc_00000_1_mychar } 8002 0012 RETURN } //////////////////////////////////////// // Code with no source :-) ////////////////////
  25. Hi Neil, You are looking for something like void func(int par) org 0x200 { // Function will start at address 0x200 nop; } OR #pragma funcorg <func_name> <starting_address> which can be done in MikroC but alas not in BoostC yet (that I know of). Cheers Reynard
  • Create New...