Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by mikew

  1. I am hoping that some of you ace programmers out there might be able to offer a few hints and tips; I don't expect a complete solution!! I have been trying to port a C program for the 16F876 from Hi-Tech C into SB. The program is for an OBD-II diagnostics hardware project, using the SAE J1850 VPW data link protocol. (If that means nothing, no matter) The Hi-Tech version works fine, but the ported version does not; there are only a few changes needed to convert from one to the other, for the declarations of port addresses etc. The 'send data' part seems to work OK, since I can monitor the one-wire data link and see the ECU respond to a request, but the 'receive data' part of the program seems not to catch anything. I've looked at the listing files generated for both compilers for the 'receive' section, and of course they are completely different!! Thus my first question is: how might I debug the SB code running in the same hardware as the HT code? Secondly, if I had created the project only in SB C, in the expectation that it should work correctly, how might I have narrowed down the source of the problem? My instinct would have been to blame the hardware - but I now know this is OK (Bit of a philosophical one, that!)
  2. Perhaps you can help with a problem, as I am not a very good C programmer. I have a PIC based program in which I have declared a flag in the header file. static bit signal; In the C program I initialise the flag by- signal=0; Later in the main body I use the flag as- signal = !signal; //simply to toggle the bit (?) This last line is marked as a warning that conversion of unsigned char to bit may lose data. In fact, the program compiles correctly and runs properly, also confirmed by examination of the listing file. My question is: what am I doing wrong to cause this warning to appear? Any help appreciated.
  3. More questions on this interrupt; if(pir1,TMR1IF) etc does not cause any error to be flagged, but I am unclear of the difference between this and if(pir1.TMR1IF) i.e. the use of dot rather than comma... Also, I have used (elsewhere) for example- if (test_bit(pir1,TMR1IF)) etc... which seems OK, but now I'm not sure! I'm starting to look at the code produced for such 'errors' but I may well be looking at the wrong stuff, that is not where the mistakes really are. mikew.
  4. Below is the ISR, with the unwanted 'IF' commented out. Now I look at it again, I think I see the problem, the declaration of TMR1F. This code has been ported from HI-Tech C; I thought I'd changed all these labels. Perhaps it should be: if (pir1,TMR1IF) etc.... And I suppose that TMR1F is not flagged as undeclared since it's in one of the included header files. My apologies, but my excuse is that I'm a hardware man, not a programmer!! /**************************** ISR **********************/ void interrupt(void) { unsigned char ticks; //temp store for Timer1 ticks /**** Timer1 OverFlow Interrupt ****/ // if(TMR1IF) // { tmr1h=0x38; // Reset Timer1 reg., adjusted for slow clock? tmr1l=0; ++ticks; if (ticks==2) /* timer ticks for 1 second */ { ticks=0; ++seconds; } if (seconds==60) { seconds=0; ++minutes; } if (minutes==60) { minutes=0; ++hours; } if (hours==24) { hours=0; } clear_bit(pir1,TMR1IF); /* Clear the Timer Flag */ // } }
  5. Thanks to those who offered help, and the problem is now solved - but I'm not sure the result indicates a bug. After many re-compilations of much the same code, I noticed once a warning was flagged that a redundant IF statement had been optimised out. This, of course, was in the ISR, and this is where all the code within the IF statement had gone!! The IF statement was intended to detect a Timer1 interrupt, and I guess the compiler/linker detects that only timer1 interrupts were enabled. It does seem a bit drastic to remove the code with optimization, though!
  6. [i think this may be in the wrong place?] Thanks for the reply; I suppose my question could have been better put as a request for ideas on an implementation of sprintf. I have some boilerplate for this, but it requires the stdarg, along with ctype and string. My skill with C is way below that needed to produce a bespoke solution. Does anyone have any ideas for sprintf? I notice mention of an lprintf in the manual, but the code and header files referred to are impenetrable to me; I can't any other reference to the useage of lprintf, which looks as though it might actually be what I'm looking for. Again, any help gratefully received. MikeW
  7. Myself i use and pass arrays of the max size i expect to use, and parse base on elements with nulls in unused parts. void _printTemp(unsigned char tempElements[10]) .... etc then i just make sure i check for the nulls when parsing and in the case of no data at all the first index will be a null and i can skip everything. Otherwise you could use a pointer as well and some type of linked list which would be a bit fancier way and better if you expect large amounts of data stored in another flash ... ( i havet tried this in boostC myself so i am not sure it it will like it ) i hope either idea might help. <{POST_SNAPBACK}>
  8. Disassembly of the hex code generated by BoostC Ver. 6.55 for a PIC16F876 shows that no code is produced for the ISR!! This is also the case looking at the listing file. I can see the vector at address 0004, where there appears to be some code for context saving, a jump to a label 'interrupt' where there is more code that seems to be for context restoration ending with retfie; all of the code for the ISR is missing. The program compiles/links without errors, but as a newcomer to this compiler I may be doing something wrong; for example, I am puzzled why the ISR function cannot be named - I guess because for this PIC there can only be one ISR. Any help and/or education gratefully received.
  9. Any of you expert PIC C programmers got any ideas about a stdarg.h for Boost C? Or perhaps a work-around for dealing with variable length parameter lists passed to functions.
  • Create New...