Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About amohr

  • Rank
  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 would be REALLY handy too....you can use my version if you want). so if someone were to look at assembly genrated by your compiler, they should just see two things: global variables, and a bunch of GP registers. We should NOT see things like: serial_set_00017_arg_p2speed CompTempVar377 etc, etc. thoughts? It seems like your designer skipped out on the register allocation part of compiler design
  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 to fix this? It's really hindering debugging. Thanks so much, - Alex
  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 other thing is do you guys support > 8bit bit-fields? i.e. struct packed_struct { unsigned int f1:1; unsigned int f2:1; unsigned int f3:1; unsigned int f4:1; unsigned int type:4; unsigned int funny_int:9; } pack; THAT would be VERY useful! And savea whole mess of code-space.
  • Create New...