Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About IanM

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
  1. if(101<=sel<=150) and similar is no good. Replace with if(101<=sel && sel<=150) Remove the semicolons from the end of ALL the #defines!
  2. Goes with: Unimplemented pins read as '0', and is almost certainly for backwards compatibility. Thanks - its a useful correction.
  3. There is no 'which then gets written'. All writes to either goto LATx and appear on output pins immediately. Yes. Yes. No. LATx always reads as the last value written to it. You need to read section 11.1.2 Output Data Latches (LATx) and Data Direction Register (TRISx) of the PIC18 family reference manual DS39500A. Meanwhile, the attached image may help!
  4. *CONFIRMED* See the example: %ProgramFiles%\SourceBoost\Samples\Basic\interrupt.pic16.bas There is a documentation error and NONE of the program entry points should have capitalised initial letters, so its: main(), interrupt() and interrupt_low(), NOT: Main(), Interrupt() and Interrupt_low(). This is fairly logical as these are handled by the linker which is common to alll the Boost languages and C/C++ require case sensitivity and use all lower case entry point names. To see *exactly* what is happening, open the .casm file for your project after a successful link and you will see
  5. I have some PIC16F887 code hanging around. It wil need a few changes for your PIC: /*********************** PWMTEST ****************/ /* For PIC16F887 on Microchip 44-Pin Demo Board */ /* in Pickit 2 Debug Express kit */ /* Takes AN0 ADC input (from pot) and outputs */ /* inverted value as PWM on RC2. */ /************************************************/ #pragma CLOCK_FREQ 8000000 #include <PIC16F887.h> #include <boostc.h> #include <adc.h> //see DS41291E, page 210 #pragma DATA _CONFIG1, _LVP_OFF /* RB3 pin is digital I/O, HV on MCLR must be used for programmin
  6. For MOST PIC16 and PIC18 parts, the MINIMUM VREF (VREF+ - VREF-) is approx VDD_MAX/2. Check your datasheet for the minimum Vref for YOUR PIC! It will NEVER work properly with only 0.5V difference.
  7. Symantec have a certain reputation for false positives. Programs that patch or generate windows executables or DLLs frequently are misdetected as after all that is what viruses are trying to do. Anyone who has used a PC C compiler regularly will know that the output directory usually needs excluding from any virus scans. I GUESS that PREG may be doing something to the windows binaries so that they can be traced back to a particular licence number and customer for obvious licensing reasons and this is what has triggered it. IMHO you should report the false positive to Symantec in the hope t
  8. Read [THIS] on strings in C source code in ANSI C90. IMHO you should try the 'ajacent strings combine' method. rom char *httpHeader1 = "<html>" "<head>" "<title>Tower-Cam Test</title>" "<body>" "<h2>Tower Camera Sensors </h2>" "<p>Battery Voltage goes here:</P>" "<p> Temperature goes here:</p>" "<p>Time goes here:</p>" "</body>" "</html>"; //End of httpHeader1 string If that doesn't work, fall back line continuation characters (DavidB's post above) that I have used in #d
  9. Yes '$' has been around a while. IIRC I first met it in the early '80s in Hisoft GENS3 - a Z80 assembler: I dont expect to see MPASM object files used internally, because BoostLink does some special stuff that the Microchip linker doesn't handle. For similar reasons HiTech provide their own linker for PICC, however it would be nice to be able to 'import' MPASM format object files. Also you don't need a better list file, just open the .casm file!
  10. I dont think BoostC supports the MPASM $ operator (or most other complex MPASM expressions) :-( That's why a number of us are agitating for the capability to write library functions for BoostC in MPASM/GPASM. To get it 'all in one' why not try: //Make a 16 bit long value from adresh:adresl registers #define ReadADC( dst ) asm base: /* only legal place for a label */ \ asm bsf _adcon0,1 \ asm movlw 0x01 \ /*loopi:*/ asm addlw 0x01 \ asm btfss _status,0 \ asm bra _base+2 /*_loopi*/ \ asm bcf _adcon0,1 \ asm comf _adresl, W \ asm movwf
  11. Any chance of a 'quick fix' for the V6.97 and V7 IDEs based on installing the MPASM V5.20 I linked to in post#8? At least I could then reccomend your IDE again to people struggling with MPASM code and the MPLAB simulator. Your graphical plugin based debugger, although not as capable 'out the box' as the MPLAB one with scripting in SCL, is far easier for a novice or occasional user (or who cant afford the other graphical alternative - Proteus) to get to grips with and is far more stable. Once they are using the SourceBoost IDE it is obviously going to be easier to persuade them to try the
  12. While debugging is this badly broken I find it difficult to reccomend SourceBoost to others. In fact I also regard it as a 'dealbreaker'. Getting MPASM and 3rd party toolsuites working again under the SourceBoost IDE and also sorting out the GPIO plugin problem (maybe by aliaiasing GPIO to PORTA?) should be given a MUCH higher priority as your IDE's interoperability with Microchip's language suites and the quality of the MPLAB integration of your Boost.... language suits has been a major factor in me recommending SourceBoost over other third party development enviroments that lock you in
  13. Back in the days of TTL logic, one usually wired LEDs between the output and +5V (with a resistor), and almost always wired swirches between the input and 0V, with a pull-up resistor if you were sensible (TTL didn't really float). This was because of the asymmetric input and output stages of TTL. You will still see a lot of circuits that use inverted logic (0=ON) for LEDs and switches, even 30 years later with a different IC technology and it isn't all the ossified habits of those 'old farts' still in the design game! If you look carefully at the output specs in the datasheet, you wil
  14. EEEEEErrrrrr........ The PIC16F877 doesn't HAVE any comparitors! According to Microchip they were introduced in the PIC16F877A. Now Microchip doesn't always tell us if they've goofed and put in the silicon for some feature that dosn't work - so the PIC16F877 may actually secretly HAVE comparitors that DON'T WORK! Please see Microchip's DS39591A 'PIC16F87X to PIC16F87XA Migration' for comfirmation of this. HTH Ian http://ww1.microchip.com/downloads/en/DeviceDoc/39591a.pdf
  15. Answered on Microchip Forum: Hex copies to PIC18F4525 but fails to run Basically the problem appears to be missing config settings in the hex file.
  • Create New...