Jump to content

amohr

EstablishedMember
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by amohr

  1. ya, I was being stupid...thanks to microsoft (see the PDC?)
  2. I have 1000 lines of C code, and >1K of EEprom data, I don't want to have to step through that much ASM 1) trying to figure out how the compiler guy thinks, and 2) to eventually find my bug. No mainstream developer debugs in asm by default in any standard size project. small c projects are just toys, not applications you're actually trying to do work on.
  3. do you understand the difference between debugging c source and debugging asm source? apparently not. anyways, I did use it, and found my problem. It should definitely be noted somewhere that this debugger doesn't support simulating the ee registers.
  4. man, this new compiler (going from 5.06e -> 6.15) rocks! my favorite feature: short arrays! this is soooooooo useful. also, the code size generated is MUCH smaller. As an example, our firmware footprint went from like 0x1400 to 0x0BCE. thanks guys!!!
  5. sorry if I seemed harsh before, I was having some serious problems that ended up being this stupid problem with the programming. Now that that works I'm pretty happy again my appologies about this thread, please delete! after looking at the .asm I see that there just happens to be multiple register names assigned to the same address.
  6. here's what the code was: if(p1speed & 0x30) g_status |= 0x200; // and alternatively if(p1speed >> 4) g_status |= 0x200;
  7. when are you guys going to start allocating registers correctly for the PICs? for example: take the following: void foo() { } if I add the following in the function: static char data[] = { 1, 2, 3 }; it should NOT result in more global registers getting used up. all the registers should be general purpose, and the globals subtracted from that. If you wanted to do something neat (this should have been done a LONG time ago by someone...turning flash into a swap space for more memory. This would mean you would need to have a standard read + write flash routine (this w
  8. here's the assembly generated: //if(p1speed & 0x30) MOVLW 0x30 BSF STATUS, RP0 BCF STATUS, RP1 ANDWF serial_set_00017_arg_p1speed, W BTFSC STATUS,Z GOTO label4026532446 BCF STATUS, RP0 BSF gbl_g_status+D'1',1 label4026532446 //if(p1speed >> 4) BSF STATUS, RP0 BCF STATUS, RP1 MOVF serial_set_00017_arg_p1speed, F BTFSC STATUS,Z GOTO label4026532446 BCF STATUS, RP0 BSF gbl_g_status+D'1',1 label4026532446 you can see that it's not even doing the bitshift
  9. the problem is that that's the only way to place data at a particular address. I tried adding an ASM block with an ORG but the compiler complained. either way, since I can't debug FLASH data, i can't really use this functionality
  10. unsigned char foo(unsigned char x) { if(x >> 4) // do something } f(3) wouldn't "do something" in 6.15 it does. what's the deal?
  11. in order to conform with the MPASM de linker command, I believe this should not append a NULL to the end of the sting. If you want a null, I think you should add it explicitly with a \0, since there's no way to specify a string w/o nulls. what do you guys think?
  12. well could you please add support? It's supported in MPLab + it's fairly crucial and causes *much* grief not having it. Thanks, - Alex
  13. the code IS going in the memory, and I can see in the debugger that the address registers are getting set correctly, but neither eedath nor eedata are getting set by the debugger. I know for a fact that my read_flash routine is correct because it's already being used in a shipping product with C2C 5.06e
  14. SourceBoost 6.15 Target: 16F877 I have code similar to the following: #pragma DATA 0x1600, 1,1, 0x183,0, 36,1, 0,0x204,0 and a function called read_flash like so: unsigned short read_flash(unsigned short addr) { unsigned short value; clear_bit(intcon, GIE); eeadrh = addr >> 8; eeadr = addr & 0xff; set_bit(eecon1, EEPGD); set_bit(eecon1, RD); nop(); nop(); value = eedath; value <<= 8; value |= eedata; set_bit(intcon, GIE); return value; } but the data from the #pragma data section never gets read. Is there any way t
  15. bit access is pretty neat, but it doesn't appear to be supported for 16 bit variables. it seems it would be really easy to add support for this in the compiler. The other thing is that from what I see the compiler only supports integers, and not a variable. i.e., this is supported: PORTC.1 but this isn't: PORTC.foo it would also be nice if the set_bit + clear_bit routines would be enhanced to work in the same way. Perhaps the compiler could default to masking for 16bit variables. i.e. setting would be PORTC |= var_MASK; and clearing: PORTC &= ~var_MASK; the
  16. for my project PicAnt 5.04 generated the following stub for the interrupt handler: _interrupt _interruptint_save_cont_W swapf int_save_cont_STATUS swapf FSR, W movwf int_save_cont_PCLATH goto interrupt_body my interrupt body got compiled to address: 0x00CB note how PCLATH isn't being cleared! This means everytime the interrupt handler gets hit it jumps to random code (if PCLATH<4:3> points to the wrong page). eeeeeeee!!! Please fix as this is a very critical bug & contact me @ amohr@adobe.com - Alex
  17. so I have a function which initializes Timer1. in my main I do the following: intcon = 0; pie1 = 0; pir1 = 0; adcon0 = 0; adcon1 = 6; // Set PortA to Digital I/O trisa = 0; // PORTA to all output trisb = 0; trisc = 10100000b; trisd = 0; // PORTD to all output t1con = 00110000b; // tmr1 - 1:8 prescale, internal clock, turn off option_reg = 0; // portb pull-ups + tmr0 on clkout set_bit(intcon, PEIE); // PEripherial Interrupt Enable (need for any pie1 interrupt) set_bit(intcon, GIE); // Enable Global Inte
  18. support of pointers is _indespensible_ for any c coder. It's what makes the language so useful. I'd like to be able to pass a pointer of a variable to a routine to allow my routines to modify the contents of the caller's copy. Right now I have to have seperate routines for each long I declare This also means being able to get a referene to long variables i.e.: void doIt(long *val); long val = 1; doIt(&val); this should also work for char*, char[] arrays. bonus points for if you could return a reference of a long to a method that takes a char* array, and do t
  19. when dealing with storing program data in FLASH it's pretty indispensible for using longs...and in particular support of arrays of longs would be very useful! I currently have several routines to modify an array of bytes an return a long based on an integer offset...very ugly! which brings me to my next request....
  20. I had to implement a function called get_bit because I couldn't implement it as a macro since the compiler support for longs is so weak. The problem I found is that it's treating the long parameter as a reference! Which means that if I modify the parameter value in the function it's reflected in the caller's copy...i.e. char get_bit(unsigned long x, char y) { char i; for(i=0; i<y; i++) x >>= 1; x &= 1; return x; } long i = 1; // i == 1 get_bit(i, 2); // i now == 0 !!! eeeeeeeee
  21. the following works as expected: #define SET_BIT(x,y) x = (x | (1<<(y))) while the following always returns 0 #define SET_BIT(x,y) x = (x | (1<<(y-1)))
  22. the following genereates the error: Line 60: Error in array initialization #define DISABLED -1 char button_status[10] = { 0, DISABLED, DISABLED, DISABLED, DISABLED, DISABLED, DISABLED, DISABLED, DISABLED, DISABLED };
  23. when compiling the following I get the error: Line 49: Error in const array definition If I replace all the |'s with the real values it compiles. #define MOMENTARY 1 #define TOGGLE 2 #define LATCHING 4 #define COUNTING 8 #define REPEATING 16 #define ONBUTTON 32 // sets all other buttons as enabled #define OFFBUTTON 64 // sets all other buttons as disabled unsigned char button_type[10] = { LATCHING | ONBUTTON, MOMENTARY | OFFBUTTON, MOMENTARY | REPEATING, LATCHING, LATCHING, MOMENTARY, MOMENTARY | REPEATING, LATCHING, LATCHING, TOGGLE };
  24. so originally it worked (by moving the assembly to the end of the file), but now that my code just grew by a little bit I'm getting the error again I just thought of a way to get around this. Let me know if I can make the following assumption: I can declare char[] arrays globally in my C code, and then watch where PicAnt places these arrays by looking at the lst file, and then overwrite these memory locations through a bootloader. This sounds like it will work as long as PicAnt uses contiguous blocks of memory for the character arrays I create in my C code. Another thing: the P
×
×
  • Create New...