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 the code generated for each part of your source file. Your original file generates no code for Interrupt() as nothing calls it!
  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 programming */\ & _FCMEN_OFF/* Fail-Safe Clock Monitor is disabled */\ & _IESO_OFF /* Internal/External Switchover mode is disabled */\ & _BOR_ON /* BOR enabled */\ & _CPD_OFF /* Data memory code protection is disabled */\ & _CP_OFF /* Program memory code protection is disabled */\ & _MCLRE_ON /* RE3/MCLR pin function is MCLR */\ & _PWRTE_OFF/* PWRT disabled */\ & _WDT_OFF /* WDT disabled and can be enabled by SWDTEN bit of the WDTCON register */\ & _INTOSCIO /* I/O function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN */ #pragma DATA _CONFIG2, _WRT_OFF /* No prog memmory write protection */\ & _BOR40V /* Brown-out Reset set to 4.0V */ // The demo board has a pot (0-5V) on RA0/AN0 and an active low button on // RB0/INT. The eight LEDs on port D are active high. // RB6 and RB7 are reserved for ICSP/Debugging and should be set as inputs // and not used. void init(void) { //Initialise PortD trisd = 0; //configure port D portd = 0; //clear port D //Initialise ADC ansel=0b00000001; // AN0 is analog, all others (AN7-AN1) digital anselh=0b000000; // All (AN8-AN13) digital adcon1.ADFM=1; // AD result needs to be right justified adcon1.VCFG0=0; // Vref+ = Vdd adcon1.VCFG1=0; // Vref- = Vss set_bit( adcon0, ADCS1 ); // Select Tad = 32 * Tosc (this depends on the Xtal here 8 MHz, should work up to 20 MHz) clear_bit( adcon0, CHS0 ); // Channel 0 clear_bit( adcon0, CHS1 ); // clear_bit( adcon0, CHS2 ); // volatile bit adc_on @ ADCON0 . ADON; //AC activate flag adc_on = 1; // Activate AD module //Example 14-5: PWM Initialization - from MPASM code in datasheet #define PWM1 2 ccp1con=0; // CCP Module is off tmr2=0; // Clear Timer2 pr2=1000/4; // period register is 8 bit, 2 implied low bits ccpr1l=0; // Duty Cycle is 0% of PWM Period intcon=0; // Disable interrupts and clear T0IF trisc.PWM1=0; // Make pin output pie1=0; // Disable peripheral interrupts pir1=0; // Clear peripheral interrupts Flags ccp1con=0x0C; // PWM mode, 2 LSbs of Duty cycle = 00 t2con.T2CKPS1=1; // Select /16 prescaler t2con.TMR2ON=1; // Timer2 starts to increment /* ; The CCP1 interrupt is disabled, ; do polling on the TMR2 Interrupt flag bit ; PWM_Period_Match BTFSS PIR1, TMR2IF GOTO PWM_Period_Match ; ; Update this PWM period and the following PWM Duty cycle ; BCF PIR1, TMR2IF */ } void main(void) { unsigned short temp; init(); //Every 100ms sample ADC, discard 2 low bits and output on port D LEDS while( 1 ) { temp = adc_measure( 0 ); portd=temp>>2; temp=1023-temp; ccp1con=(ccp1con&0x0f)|((temp&0x03)<<4); ccpr1l=temp>>2; delay_ms( 100 ); } }
  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 that the next update will fix the problem. If the network administrator doesn't have established procedures in place for dealing with false positives, you need to change your network administrator! Cant help with how essential PREG is, but has its quarantining broken either the IDE or the compilers?
  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 #defines for large inline assembler macros so I *KNOW* they work.
  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 _##dst \ asm comf _adresh, W \ asm andlw 0x03 \ asm movwf _##dst##+1
  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 Boost... languages, and hopefully get their wallets out. I'm also begging for an update on the PICC Lite toolsuite interface (or has that been fixed since V6.95?) I would really like to be able to program baseline PICS in C *WITHOUT* having to suffer with MPLAB! Meanwhile, my development enviroment is 'frozen' at V6.95 so I dont break the MPASM debugging, My participation in the forums here is down by an order of magnitude inspite of this forum's ease of use and the many problems with the Microchip forum and I am strangely silent about the advantages of BoostC in my many posts over there.
  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 to therir software and even hardware to a far greater extent. While you are looking at that, we desperately need a cleaner way of mixing MPASM assembler and Boost.... code. Its probably not worth chasing the 'export to MPLINK compatible format' goal, but surely you can devise some way of translating MPASM output automatically for linking with a Boost..... project. If the formats are truely completely incompatible, please look at adding a 'tweaked' version of GPASM to your 'stable' of toolsuites so we can write MPASM compatible code and link it with other Boost.... languages. Regards Ian
  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 will see that many PICs are somewhat better at sinking current than sourcing it. This means that an actice low LED can be a bit brighter. Also there are so called 'weak pull-ups', internal pullup resistors that can be activated so an active low switch no longer needs an external pull-up. You will find them on Port B of the 16F88 and most other 18 pin PICs. You are right about not leaving inputs floating, but you may not realise yet that it applies to ALL inputs that are not actively driven, even unused ones. It is actually possible for a pin set as an input that your code does not use at all to cause problems! The general cure for UNUSED pins is set them as a LOW output (LOW to reduce the risk of short circuits).
  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...