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. NDHolmes

    Possible Isr Context Saving Bug

    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 handler from the stub to the actual function, the PCLATH save makes sense. However, it doesn't address the problem of the fact the 873 and 874 don't have a truly shared bank. The only really workable solution is to hold working in both banks and status in a known location, usually by holding it in working while clearing the register bits. Then just restore status first and working comes from the right location. Nathan
  3. NDHolmes

    Possible Isr Context Saving Bug

    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 handler from the stub to the actual function, the PCLATH save makes sense. However, it doesn't address the problem of the fact the 873 and 874 don't have a truly shared bank. The only really workable solution is to hold working in both banks and status in a known location, usually by holding it in working while clearing the register bits. Then just restore status first and working comes from the right location. Nathan
  4. NDHolmes

    Possible Isr Context Saving Bug

    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+D'2' SWAPF FSR, W MOVWF Int1Context+D'3' BCF STATUS, RP0 BCF STATUS, RP1 Note that on an 874 (and 873), not dealing with STATUS as one of the first things leads to ambiguity as to which of the four banks the variables were placed into. Once RP0 and RP1 are cleared, we have no idea where the context variables went, so restoring them becomes a 50/50 shot in the dark. The restore code, for clarity: (Starts off in bank 0) SWAPF Int1Context+D'3', W MOVWF FSR SWAPF Int1Context+D'2', W MOVWF STATUS SWAPF Int1Context+D'1', W MOVWF PCLATH SWAPF Int1Context, F SWAPF Int1Context, W RETFIE For these parts, W would need to be mirrored into all banks (2, since the top two fold over onto the bottom two), but the rest need to be dealt with in such a way that they reside in a known bank for retrieval. My apologies if I've overlooked something and have reported a non-problem, but my code is doing really weird things that I can't explain unless the ISR is really mucking about with these variables. Nathan
  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 that I'm itching to try out the whole thing, but I can't really do much with it until this one gets finished. In the meantime, is there a way to work around this?
  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 my brain's asleep today. Been on vacation for a week and a half - not all back home yet. Nathan
  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've had several instances where firmware problems were causing spurious transmissions that would cause at the least corrupt data and at the worst framing errors. - Rather unlikely, but do you have some sort of termination issue with the network, causing a reflection that's occasionally being picked up as a low bit? Your baud rate is definitely high enough that this could be an issue if the right combination of things came together against you. Just some thoughts, but I've never had such problems with a 9-bit network. Nathan
  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 would contain target-specific scripts? Anything in scripts would always get run, as it works now, but anything in a subdirectory called PIC16F874 would run only for that target type. Or something like that... Just a thought... Nathan
  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 'Assemble' command However, if I just tell it to assemble from the Build menu, it works fine (except no indication in the status window that it's done assembling. I seem to remember there used to be such a thing.) I've checked the Settings.. Options... Tools fields, and they appear to be correct (and they're the same ones I've always used). For reference, the system is Win2k, up to SP3, on an Athlon-750 with 128Mb of RAM. I'm running MPLAB 5.70.00 standardly, though I have 6 installed. I tried it as well, with the same results.) Any ideas? Help! It's not work-stopping, but it darn annoying to have to manually compile and assemble and program every time. Nathan maverick@drgw.net
×