Jump to content

NDHolmes

EstablishedMember
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About NDHolmes

  • Rank
    Newbrie
  1. Let me be another to say that a native version of the BoostC compiler/linker that would run on Linux would be great, even if that doesn't include the IDE itself and all the GUI porting that would go with it. I'm perfectly happy to use gedit or the like. BoostC and the old C2C compiler are pretty much the only reasons I boot my workshop machine into Windows these days. I tried running it via a VM for a while, but with the hassle of network drives and the general sluggishness of the machine, it was unpleasant at best.
  2. Here's what my list file looks like around the relevant sections: ORG 0x00000000 0000 293B GOTO _startup ORG 0x00000004 0004 00A3 MOVWF Int1Context 0005 0E0A SWAPF PCLATH, W 0006 00A4 MOVWF Int1Context+D'1' 0007 118A BCF PCLATH,3 0008 120A BCF PCLATH,4 0009 2942 GOTO interrupt ...(snip)... 0142 interrupt ; { interrupt; function begin 0142 0E03 SWAPF STATUS, W 0143 00A5 MOVWF Int1Context+D'2' 0144 0E04 SWAPF FSR, W 0145 00A6 MOVWF Int1Context+D'3' 0146 1283 BCF STATUS, RP0 0147 1303 BCF STATUS, RP1 Since there's a jump in the interrupt hand
  3. Here's what my list file looks like around the relevant sections: ORG 0x00000000 0000 293B GOTO _startup ORG 0x00000004 0004 00A3 MOVWF Int1Context 0005 0E0A SWAPF PCLATH, W 0006 00A4 MOVWF Int1Context+D'1' 0007 118A BCF PCLATH,3 0008 120A BCF PCLATH,4 0009 2942 GOTO interrupt ...(snip)... 0142 interrupt ; { interrupt; function begin 0142 0E03 SWAPF STATUS, W 0143 00A5 MOVWF Int1Context+D'2' 0144 0E04 SWAPF FSR, W 0145 00A6 MOVWF Int1Context+D'3' 0146 1283 BCF STATUS, RP0 0147 1303 BCF STATUS, RP1 Since there's a jump in the interrupt hand
  4. While looking at why my code was never returning from the interrupt handler, I found the following... I don't believe the way the ISR context-saving assembly saves things off under BoostC for a PIC16F874 will actually work correctly. I could just be a moron today and this is all okay, but I've been staring at this for the better part of an hour, and can't find any possible way it could be working reliably. The saving side: MOVWF Int1Context SWAPF PCLATH, W MOVWF Int1Context+D'1' BCF PCLATH,3 BCF PCLATH,4 (GOTO interrupt, which continues below) SWAPF STATUS, W MOVWF Int1Context
  5. Dave - Thanks, don't know why that didn't occur to me earlier. Thanks for the tremendously quick response. Nathan
  6. If it wouldn't be too much trouble, I'd appreciate it if initialization of rom-type vars from arrays would be considered for the list of stuff to fix before the next public release. eg: rom char constdata[] = {32, 54, 109, 206}; Nearly all of my code has CRC routines or other things stored like this, and the current compiler tries to stick it in ram, of which there is far less than enough for such things... I figure from the linker note of (temporarily) that this inability isn't permanent. BC has shown vast improvements in the instructions it generates in other parts of my source th
  7. Since when is 245 % 204 not 41? Modulus is essentially the remainder of an integer division. Anyway, the better solution to your problem is: If you make the 10-bit number into a 16-bit number by left-aligning it, you've effectively multiplied it by 64 (6 bit positions). So, you want (1023*64) = 500 (assuming two decimals of precision). If you left-align the input bytes and divide by 131 (which is 1023*64/500), you'll come up with nearly 500 as a result. Stick the decimal in the right place in your BCD/display routines, and you're in business. I think I did that right, but
  8. I'm lazy, I didn't update the docs. Theoretically /dev/ttyS0 should work, but that may only be if you have the full Cygwin install on your machine. Just put com1 in instead of /dev/ttyS0 and everything should work.
  9. While I've never seen your specific problem, you shouldn't need any delay. As long as you're in 9-bit mode, RCIF shouldn't get triggered until the stop bit is received. Of course, if you're getting framing errors, the stop bit isn't there when it expects it. I'd suspect a couple of things: - Is the transmitter's clock out of tolerance (on the slow side), such that it's a borderline case whether it samples in a possibly low bit 0 rather than in the stop bit? - Is some other node transmitting before it's presumably supposed to? I don't know anything about your specifics, but I'v
  10. The link to the upgrade from 4.x C2C licenses actually tries to buy a single user, 3-node license. As soon as you fix it, I'll be buying one. Nathan
  11. I was just converting over to the Microchip-derived header files, and think I found an issue with what I assume to be the preprocessor. I put in Even with the #define list below commented out, I still get: line XX: Illegal redefinition of symbol: YYYY where XX and YYYY are every #define line below in the sample code. #include <p16f874.h> /* #define T0IE 5 #define T0IF 2 #define TRMT 1 #define TXIF 4 #define TXIE 4 #define RXIE 5 #define RXIF 5 #define SPEN 7 #define CREN 4 #define INTE 4 #define INTF 1 #define RD 0 */ void main(void) { while(1); }
  12. This is just a suggestion, don't know if others might find it useful or not. Could pattern scripts somehow be made (optionally) target-specific in C2C 5.00 (or later in the 4.x series)? The reason I ask is that I switch between projects for 16F874s and 16F628s on a semi-frequent basis when doing system-level debugging. It's a pain to put in and take out the appropriate pattern script for context-saving on the 874, and sometimes this lack of attentiveness leads to really strange bugs that further confuse me. As to how to implement it, perhaps directories under the scripts dir that wou
  13. You just never know where you're going to find a link to yourself. Thanks, Pavel. And thanks for the prompt support. The C2C compiler makes programming so much faster. As a guy who used to believe programming PICs in anything but assembly was uncivilized, I can't believe I just said that. Nathan
  14. As an added note, I've done a bit more debugging (after upgrading to IDE 4.5.2). Best sign of improvement - I get the traditional "Done" message now after successful assembly. It does work sporadically without any changes in "Build" mode. However, the surest way to get it to work is to go into the options and mess with the assembler command line. Once it's been changed, everything works again for one shot (usually) through build. Then back to assembler not found. Pavel, is there anything else I could check that might help you narrow down the problem? Nathan
  15. I actually got down to the workshop for the first time in several weeks today, and the first thing I did was upgrade from 4.1.8 to 4.5.0 (and then put the PicAntIDE 4.5.1 executable in). Now I've got an odd problem... The first time I try to build a project (one that I've been using for months and works nicely), I can build just fine. Runs through a compile, launches the assembler (mpasmwin.exe), but the status window at the bottom never indicates "Done". The, the next time I try to build, it gets through compile, and then: Assembling... Failed to start assembler Can't execute
×
×
  • Create New...