Jump to content

blowback

EstablishedMember
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About blowback

  • Rank
    Newbrie
  1. It'd be handy to have multiple plugin instances - eg just now I wanted two LEDs, and had to settle for a single LED and an LED block (only one of which I was interested in).
  2. The software uart routines don't generate interrupts, because they're foreground processes. If you getchar() or putchar() your code has to wait for these operations to complete. Look at the .asm file generated by the C compiler and you'll see what I mean. HTH bb
  3. Is there some sort of filename length limit in PicAnt/MPLAB? I have a project in a deeply nested folder underr my documents, and whilst it compiles fine, the assembler always barfs with a "DOS Error: file not found" error box. Usefully, it doesn't mention which file I've tried commenting out any includes in the .asm file to no avail. Then, I discovered if I moved the whole lot to a subdir of c:, it suddenly works again! bb
  4. Hmm, I tried your approach and it seemed to work for me. I did: short foo@20; char bar@20; char baz@21; foo = 0x55aa; bar = baz; which generated code like this: _foo_main equ 0x14 ;2 _bar_main equ 0x14 ;1 _baz_main equ 0x15 ;1 ;;;;;;;; foo = 0x55aa; movlw D'170' movwf _foo_main movlw D'85' movwf _foo_main+D'1' ;;;;;;;; bar = baz; movf _baz_main, W movwf _bar_main That seems to do pretty much what you want, I figure. You could also mix in a bit of assembler to do what you want: unsigned char lo(unsigned short x) { asm { movf param00_lo, W return }; } unsigned char hi(unsigned short x) { asm { movf param00_lo+D'1', W return }; } of couse they don't have to be functions, you could movwf to whichever variable you wanted the relevant byte in. HTH, bb
  5. I can't see anything in the compiler's documentation indicating that it supports enums...perhaps the C++ compiler does? bb
  6. ah....good point! Now you mention it, I can't see what on earth prompted me to ask such a stupid question in the first place
  7. Wotchamates, If I define a macro like this: #define FOO (porta,7) then a statement like this: set_bit(FOO); will generate an error "variable or number expected". Similarly "set_bit( FOO );" and "set_bit((FOO));" and any variations thereof. Bizarrely tho, "set_bit FOO;" is accepted! This is a little broken, no?
  8. consider this function: void foo(unsigned char n) { n = n + 7; // oh, for a += operator! } which generates a warning : "Possible truncation to 8 bit" What's that all about then? There's no truncation there, unless the expression is being promoted to 16 bits. The problem goes away if you replace 'char' with 'short' or 'int', and signedness seems to have no effect. Doesn't break anything, just a minor annoyance
  9. Ah, that's ok then - I'll stop hunting for the problem cheers bb
  10. Why do I get the error message: "Built in variables are obsolete. Use variables defined in the system header file" ?? I am using variables defined in the system header file - haven't used one of the all-caps built-in variable names at all. Also, it'd be handy if this warning included a line number.
×
×
  • Create New...