Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by edt

  1. This line needs to have "intcon.INT2IF" instead. INT2IF itself just evaluates to the index (0-7) of INT2IF in the intcon register. As far as I can see, everything else looks good. Under the SourceBoost directory (C:\Program Files\SourceBoost on my computer), there is a directory called "include" which has the definitions for each device. Find your device in there (eg. for a P16F73 find p16f73.h) and it will list all bit and register definitions. HTH
  2. Oh, sorry. It's SourceBoost 6.60 on PIC16 (p16f877a), with or without aggressive optimization enabled.
  3. What the Google is going on here? Line 10 is identical to line 7, but in line 10 the value is moved from BANK 0 to BANK 1 and then back to BANK 0. 1: #include <system.h> 2: 3: unsigned short tmr_val@0x20; 4: unsigned char fill[94]@0x22; 5: 6: void main(void) { 7: tmr_val = tmr1h << 8; 0003 1283 BCF 0x3, 0x5 0004 1303 BCF 0x3, 0x6 0005 01A0 CLRF 0x20 0006 080F MOVF 0xf, W 0007 00A1 MOVWF 0x21 8: tmr_val |= tmr1l; 0008 080E MOVF 0xe, W 0009 04A0 IORWF 0x20, F 9: if (tmr1h != (tmr_val >> 8)) { 000A 0821 MOVF 0x21, W 000B 060F XORWF 0xf, W 000C 1903 BTFSC 0x3, 0x2 10: tmr_val = tmr1h << 8; 000E 1683 BSF 0x3, 0x5 000F 01A0 CLRF 0x20 0010 1283 BCF 0x3, 0x5 0011 080F MOVF 0xf, W 0012 1683 BSF 0x3, 0x5 0013 00A1 MOVWF 0x21 0014 0820 MOVF 0x20, W 0015 1283 BCF 0x3, 0x5 0016 00A0 MOVWF 0x20 0017 1683 BSF 0x3, 0x5 0018 0821 MOVF 0x21, W 0019 1283 BCF 0x3, 0x5 001A 00A1 MOVWF 0x21 11: tmr_val |= tmr1l; 001B 080E MOVF 0xe, W 001C 04A0 IORWF 0x20, F 12: } 13: } 000D 0008 RETURN 001D 0008 RETURN
  4. Can you provide original C code that generates such unoptimized assembly. <{POST_SNAPBACK}> Certainly. #include <system.h> bit a, b, c, d, e, f, g, h; void main(void) { a = 0; b = 0; c = 0; d = 0; e = 0; f = 0; g = 0; h = 0; while (a || b || c || d || e || f || g || h); } For me with -Oa, this gives almost exactly the assembly I described. It matters how the compiler/linker allocate the bits, which is exactly why it's important for the compiler/linker to handle optimization (the programmer usually can't). Obviously this exact sequence is contrived, but similar cases pop up all the time. Sometimes the assignments are mixed in with other statements or don't affect the whole register. This shouldn't be optimized with volatile bits, but maybe a similar case should: a = b = c = d = e = f = g = h = 0; That sort of indicates that it should all be one operation. If I had to choose, though, I'd pick bit compatibility (arrays, structs, return types, maybe ptrs?) over bit optimization for now.
  5. As a side note, I believe SourceBoost supports bits as function parameters (but not as return types, etc.), so instead of send_one(void) and send_zero(void), you might get better mileage with send_bit(bit x). You'll probably avoid repeating yourself more that way.
  6. I believe 1 us at 4 MHz is 1 cycle, so if you wanted to be safe, you could put a nop there instead. I don't see the purpose either, so it would still be fine to run at other frequencies.
  7. I'm not quite sure what you mean, either. If you're talking specifically about the way I suggested, I didn't want to make a new integer temp variable for the mask, so I used a constant mask (0x01) and shifted the data down to it instead of shifting the mask up. I'm sure there are ways that optimize better, but I was aiming to be concise.
  8. Ah, that's what I saw. Thanks. Now I noticed that except for a break after 6.40, there was a new release almost every month up until November. I'm curious whether there are major enhancements in the works, SourceBoost is now considered mature and development is slowing down, or there just isn't enough time in the day to maintain that development.
  9. It's been a while since I looked at the UART library, but I don't think the software UART uses the USART SFR's (like SPBRG) at all.
  10. I think as long as you got something that works, "better" is a matter of opinion and depends on your situation, but here's how I would do it: void send_nexa_cmd(char cmd) { char i,j; for (j = 0; j < 2; j++ ) { for (i = 0; i < 12; i++) { if ( (cmd >> i) & 1 ) { send_one(); }else { send_zero(); } } send_stop(); delay_ms(10); } Printf("OK\n\r"); }
  11. I remember seeing some info about previous releases of SourceBoost like release dates and features added, but I've been looking for some time and can't find it anywhere now. Could you tell me any or all of the following? 1) if release history is available, where to look 2) any tentative plans for a date on the upcoming release(s) 3) anything you're prepared to disclose about features and bugfixes for the upcoming release(s)
  12. Raghunathan's suggestion will work in most cases. If you want to test a bit in a value like my_array[3] or 15 (anything but a normal variable), though, it won't work, even if you use parentheses. Then you have two options that I've seen: 1) create a temporary variable to hold the value and hope it optimizes out properly int tmp = my_array[3]; if (tmp.5) ... 2) use bit masks if ((my_array[3] & 0x20) == 0) ... Keep in mind the second solution will return an integer and the value won't necessarily be 1 or 0. Also watch precedence, since (val & 0x04 == 0) simplifies to (val & false).
  13. The linker should ensure that each code module fits into ROM on its own as long as it doesn't run out of ROM space. I don't think you need to take any precautions.
  14. Hmm...that's quite a hack. I expected BoostC to recognize "(x_H << 8) | x_L" and copy the bytes since it recognizes shifts by 8. I wouldn't want to uglify the C source for such a small gain. I guess if you use it enough... BTW, I hope you know to stop the timer before reading from it or take precautions. If it increments from 0x0FF to 0x100 between HI and LO reads, you'll read 0x000 or 0x1FF (for HI first and LO first, respectively). Maybe that won't matter in your application.
  15. The hardware is already designed, so _MCLR wouldn't work. I don't think the 'F73 supports a RESET instruction (I can't find it in the documentation). Good suggestions, though. Very good point... I had forgotten about all of that mess. Forcing a WDT reset may be the best option in this case, even if it isn't perfect.
  16. I need to reset a 16F877A from software. There are a few ways I can think to do it. I wanted to just use "goto 0" or something like "goto reset_vector", but the first doesn't like the absolute address and I don't know of a label for it (this will leave garbage on the call stack, but since the stack wraps around and overflows are ignored, it shouldn't be an issue). Right now I have it as: asm { movlw 0 movwf _pclath movwf _pcl } but it seems a bit obscure compared to a "goto". I've also seen people force a watchdog timer reset with an infinite loop, but that will mess up if the WDT is disabled and other things could go wrong with that. So, is some reset() function/macro or reset_vector label I haven't seen, or should I leave it like it is?
  17. Hmm...it is possible to have code in your headers, but if you allocate anything in your headers, you have to require that only one source file includes that header (the inclusion guard alone won't cut it). So besides inline functions, Picxie is right on that it is very unusual to define code in your headers.
  18. Maybe you just phrased your question strangely, but it sounds to me like you're not familiar with interrupts in general. If you need more information, check the 16f913 datasheet or the Microchip Mid-range Family datasheet, but basically your interrupt function will run whenever the hardware sets an interrupt flag for an enabled interrupt. To run interrupt code every 10ms, you need to do calculations on your clock freq, load the appropriate value into your choice of timer, and enable the interrupt for that timer. Then in your interrupt function, you'll need to check the interrupt flag, and if it is set, execute your code and clear the interrupt flag or disable the interrupt. HTH
  19. Isn't that a little excessive? I thought the whole point of separate source files was to only compile what changed. asquared, that's also been irritating me. I thought maybe I was missing a setting somewhere.
  20. Ah, thanks. That works beautifully. I hadn't noticed it in the documentation, but I had checked the "debug inline functions" option under MPLAB, and the given MTC file produces the flag -di instead of -i. I fixed mine and also added the aggressive optimization as an option since it was missing.
  21. I've noticed that the source code for inline functions does not show up in the debug data. It's become sort of frustrating for me. Is there any plan to fix that? I also noticed that optimizations that seem to be working in most cases don't appear to touch inline function calls. For instance, copy propagation doesn't seem to work on parameters or return values for inline functions. Is that fixable or is there a reason not to change it?
  22. edt

    Static Const

    I haven't found a use for it myself, but I'm sure someone has/will. If the constant gets propagated and optimized out of existence, as I'd hoped it could, it wouldn't have an address. Either it would have to return NULL or some dummy value for the address, or it would have to disable the optimization for any values that need an address. <{POST_SNAPBACK}> I think I figured out why the address of a const might matter. You could have a const array, which would need an address if the indexes can't be simplified to constants. In cases where the literal couldn't be propagated, ROM storage would still be much better than RAM. On a related note, I've been pondering whether the linker could handle a global (non-static) const in the same way. It seems to me that provided it's not an array, and all the object files are compiled with the same version compiler, the linker could export the value of the const instead of its address. Not necessarily suggesting that for sourceboost, but could that be possible/practical?
  23. I'd also love to see some parallel set/clear/tests on consecutive bits merged, e.g. bcf 0x70, 0 bcf 0x70, 1 ... bcf 0x70, 7 changed to clrf 0x70 and btfsc 0x70, 0 goto label btfsc 0x70, 1 goto label ... btfsc 0x70, 7 goto label changed to movf 0x70, 1 btfss status, Z goto label
  24. I agree. Better support for 1-bit values in general would help me a lot. Not sure exactly what you mean by bit/bool support, but I keep getting frustrated not being able to use a bit/bool in a struct or array.
  • Create New...