Jump to content

ryeg

EstablishedMember
  • Content Count

    111
  • Joined

  • Last visited

Everything posted by ryeg

  1. Norton SONAR just deleted boostlink_pic18.exe from my machine without asking. What do I do now to get it back???? follow-on: Contacted Norton and they showed me how to unquarantine the file, but the compiler still doesnt build. Attached is and image of the error messages from SB. Rye
  2. Thanks for the comment -- it's got me thinking. I am starting to suspect a hardware problem too. Have a 256K eeprom hooked up and need to check wiring. Chip was OK in 877 circuit. The hangup happens in the i2c_stop routine; ...... volatile bit l_rcen@T_i2c_SSPCON2.i2c_RCEN, l_pen@T_i2c_SSPCON2.i2c_PEN, l_sen@T_i2c_SSPCON2.i2c_SEN; volatile bit l_rsen@T_i2c_SSPCON2.i2c_RSEN, l_acken@T_i2c_SSPCON2.i2c_ACKEN; l_bclif = 0; // initialise the collision flag for this command l_sspif = 0; if (T_MODE & i2c_HW) { // Hardware I2C implementation while (l_acken || l_rcen || l_pen || l_rsen || l_sen || l_rw) if (T_MODE & i2c_reset_wdt) clear_wdt(); l_pen = 1; // initiate STOP condition on the I2C bus while (l_acken || l_rcen || l_pen || l_rsen || l_sen || l_rw || !l_sspif) //Hangs up in this while loop if (T_MODE & i2c_reset_wdt) clear_wdt(); } else............... I have to take a look at the chip config setup too as I may have something wrong in that mess of stuff. The old adage "little things mean a lot" takes on new meaning in this stuff... Rye
  3. I am trying to get an 18F4550 set up for i2c operation and I (foolishly) thought it would be a snap since I have i2c running solid on a 16F877A. I though all I would have to do is set up the template parameters for the 4550 but it still hangs up in the first call to the i2c_init at the i2c_stop function. I have revised the i2c #defines as follows: // template defs -- worked for 16f877 changed to 18f4550 // CHANGES FROM 16F877 #define e_MSSP_PORT PORTB // was PORTC FOR 877 #define e_MSSP_TRIS TRISB // was TRISC FOR 877 #define e_SSPCON1 SSPCON1 // was SSPCON for 877 #define e_SSPCON2 SSPCON2 // same #define e_SSPSTAT SSPSTAT // same #define e_SSPADD SSPADD // same #define e_SSPBUF SSPBUF // same #define e_SSPIF_PIR PIR1 // same #define e_BCLIF_PIR PIR2 // same #define e_SSPIF_BIT SSPIF // same #define e_BCLIF_BIT BCLIF // same What might I have missed in making this transition?
  4. Got it! Just a matter of spending some time with the manual and a bit of messing around with the hardware. This setup works to give two separate comparators as shown in figure 12-1 of the manual: //comparator setup for two independent comparators using external reference cvrcon = 0x00; // voltage reference off cmcon = 0b00011011; //two independent comparators with outputs // ---- -011 two independent comparators with outputs // ---- x--- dont care // --11 ---- both outputs inverted // 00-- ---- set output polarity trisa = 0b00001111; //set up port configs // ---- 1111 RA0, RA1, RA2, RA3 all inputs // 0000 ---- RA4, RA5, RA6, RA7 all outputs (RA4 needs a pullup) My biggest problem was selecting the cmcon setup. I had accidentally set it to be "two independent comparators" rather than "two independent comparators with outputs". Live and learn.
  5. I'm sorry, I forgot to put the A on the end. I am using a 16F877A and am using the manual you suggest, but just cant seem to get my arms around the problem. Rye
  6. I am having a problem getting the comparator C2 to work on a 16F877 and I believe that there is some kind of 'trick' I dont remember ...or maybe just not reading manual right. ...or maybe just dumb. I have set all of port A to input except for the comparator output pin with trisa = 1110 1111 I am using two separate comparators with CM2:CM0 = 010 with C2OUT = C1OUT =1 The internal reference is turned off with CVRCON set to 0x00; The external reference is half supply into RA2 Analog input is RA1 e.g. //comparator cvrcon = 0x00; // reference off cmcon = 0b0011010; //two independent comparators trisa = 0b11011111; //all but port a are inputs except porta.5 I can "see" the input on RA1 and RA2 shows the correct Vref, but nothing on porta.5. Do I have to do something with adcon1? I'm sure somebody out there has fought this battle before, but I couldnt find anything on Google.. It's making me crazy.... Cheers Rye
  7. I am having trouble with V7.0 compiling an old project that was well behaved under V6.x. (I think) Whenever I #include the i2c_driver.h the compiler immediately issues: error: failed to parse input file makefile.i2ctest FAILURE: dont know how to parse the 'release\i2ctest.obj: i2ctest.c i2cddriver_16F877.h "serial.h" ' Here's the gutted code that exhibits the problem; </P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal> #include <system.h> #include <string.h> #include "i2c_driver_16F877.h" #include "serial.h"</P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal>//configuration word #pragma DATA _CONFIG, _PWRTE_OFF & _BODEN_OFF & _WDT_OFF & _LVP_OFF & _CPD_OFF & _DEBUG_OFF & _HS_OSC & _CP_OFF</P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal>//Set clock frequency #pragma CLOCK_FREQ 20000000</P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal> </P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal> </P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal>///////////////////////////////////////////////////////////////////////////////////////////////////</P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal>void main() { serial_printf("abc"); while (1); } </P> <P style="MARGIN: 0in 0in 0pt" class=MsoNormal> But wait, there's more: If I comment out the #include serial.h and the serial_printf statment() it compiles. If I leave the serial stuff above in the code and comment out the #include "i2c_driver_16F877.h" it compiles. But if both includes are in the code I get the error message shown above. I'm stumped.
  8. Hi Reynard: Thanks for verifying my thinking on the config1h setup. I had tried that several times before and tried it again.....and it didn't work again. Then it occured to me that it might be a hardware problem -- being a retired hardware engineer that seemed highly unlikely , but....... A detailed look-see of the crystal wiring showed that I didn't have pin 14 connected to the crystal. :angry: duh uh! Because of the apparent complexity of the config registers I was totally focused on them. Your comment somehow got me thinking in another direction. Thanks again. I now have an interrupt driven timer, a 9.6k serial port and PWM working on the 18F4550 if any of that might be of help to you. None of them are much different from the 16F877, but it's still slow going making sure that there is nothing buried in the manual that I might have missed. The 18F4550 is being used to generate a pure/stable 20Hz sine wave via class D (PWM) modulation of the PWM port. It works quite well with the second harmonic being about 36dB down from the fundamental and the rest are well below -40dB. Cheers Rye
  9. I am at the end my rope trying to get an 18F4550 to run with a crystal clock. I dont need the USB/PLL and just can't get the thing to work with the crystal clock. I can get it to work with the internal 8 MHz clock (thanks to RSABEAR) but cant seem to find the correct setup for a 20MHz crystal. My assumption is that the setup is buried somewhere in the config files, but I may be missing something is some of the other registers. Here's what works for my with the internal 8 MHz oscillator: // 8 Mhz Internal Clock #pragma DATA _CONFIG1L, _PLLDIV_1_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_1_1L #pragma DATA _CONFIG1H, _FOSC_INTOSCIO_EC_1H & _FCMEN_OFF_1H & _IESO_OFF_1H #pragma DATA _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _VREGEN_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _MCLRE_ON_3H #pragma DATA _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _DEBUG_OFF_4L & _XINST_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H</P> <P> #pragma CLOCK_FREQ 8000000 </P> <P> . . . osccon = 0b01110010; (in main)
  10. After a little Google research and the correct search terms I managed to come up with two really helpful articles about making the transition from 'empty' channel noise (aka random 'data') to a serial data transmission using the little inexpensive "dumb" receivers. Micro Linear and RadioTronix Of course, it you are using the slightly more expensive receivers with RSSI you could probably get away with just that, but both methods might be better than just one. A belt and suspenders (and a good packet protocol) never hurt anybody. Rye
  11. I am driving the USART in a 16F877 from a little $5 garage door opener type of UHF receiver. When there is no transmitted signal the receiver puts out noise and the USART generates junk characters -- which I can accomodate with packet structure and initial transmission of a bunch of characters for the USART to sync up on. Somewhere -- I think it was in this forum -- somebody did some deep thinking and came up with an optimum string of characters to send that will allow the USART to sync quickly, but I can't seem to find it. Anybody got any thoughts on the optimal start up sync string.... Regards Rye
  12. Here's one for the books that cost me an evening of messing around. I was setting up some registers in a working program and things didn't work like they usually did. It turns out that I had set up the registers using hex rather than binary notation i.e. I was setting the registers to 0x10101010 rather than 0b10101010. The compiler didn't complain. I woke up this morning, took one look and found the problem. It's amazing how we see what we want to see sometimes. Rye
  13. Thanks Ian. That's cleared things up for me and, as you suggest, will probably keep me from getting hung up on the issue in the future. I've been pushing the limit for far too long and needed a little kick. Regards Rye
  14. and the answer is............... cmcon0 I neglected to set cmcon0 <0:2> to make all of the ports into digital i/o ports. It appears as if the chip thought that the comparators were active and that was messing things up. Adding: cmcon0 = 0b00000111; fixed the problem. And yes, the manual clearly points it all out in section 4.1........................................ Live and learn Rye
  15. Thanks to everybody who replied to my last post on this situation. I think I now know how to avoid the problem, but it's still kind of interesting. It appears as if manipulation of port gpio.4 by main( ) has an effect on the gpio.0 which is driven from the interrupt. The .jpg scope image attachment shows the outputs of gpio.4 (bottom), which is driven by main( ), and the output of gpio.0 which is driven by the interrupt. Note that gpio.0 gets clobbered whenever main is driving gpio.4, but the timing seems to remain OK when things come back to 'normal' and main ( ) is running the math exercise. Here's the exerciser code: </P> <P>#include "system.h" #include <stdlib.h> #pragma DATA _CONFIG, _FCMEN_OFF&_IESO_OFF&_MCLRE_OFF&_WDT_OFF&_INTOSCIO #pragma CLOCK_FREQ 4000000 //processor is 12F683 using internal oscillator</P> <P> int xseconds = 0; unsigned char tick; unsigned char tick1;</P> <P>void interrupt( void ) { tmr0 +=9; tick++; if(tick>19) { tick=0; tick1++; if(tick1>49) //every 500 ms { gpio.0 = xseconds.0; //flash LED tick1=0; //reset tick1. xseconds++; } } intcon.2=0; //clear TMR0 overflow flag } </P> <P>//main program starts here void main(void) { intcon = 0b10101000; option_reg = 0b10000000; wdtcon = 0x00; // Watchdog not used osccon = 0b01100000; // Select internal oscillator at 4MHz osctune = 0x00; // Set frequency to factory tuned settings wdtcon = 0x00; // Watchdog not used ansel = 0x00; trisio = 0b00000000; int i = 0, x = 0; </P> <P> while(1) { for(i=0;i<=8;i++) // Math Exercise { x= x+10; delay_ms(250); x = x - 9; delay_ms(250); if(x > 250) x = 0; } for(i=0;i<=8;i++) // gpio.4 port exercise { gpio.4 = 1; delay_ms(250); gpio.4 = 0; delay_ms(250); } } }</P> <P> I know that the code isn't optimal, but it does demonstrate the situation. I'm not a C expert so go easy on my coding. I'm just an old retired guy doing stuff I enjoy......but I did read the C book (....a long time ago). Since I am using delays in both the math exercise section as well as when I am driving gpio.4, it appears as if the delays are not causing a problem. Somehow, driving gpio.4 bleeds over and messes up gpio.0, but does not impact the timing of the interrupt drive clock. Hardware issue???? It does,however, make sense not to use delays when using interrupts since the execution of the interrupt does make the delay even less accurate. I supect for not critical stuff it would be OK if one assumes the inherent inaccuracies. Thanks to Shri for pointing out that I did not have timer0 enabled and some of the comments about read before write were well taken. The R/W issue is a topic that I tend to avoid because it hurts my head to think just about it --- plus I have tooth marks all over me from being bitten by it before. Happy New Year all. Rye
  16. I am trying to get an interrupt driven timer working on a 12F683 and have encountered a perplexing problem. When nothing is going in in main(), the interrupt seems to work, but if I insert anything into main it stops working. In the code below the interrupt generates a 500ms ticks and flashes the LED accordingly. It works fine when there in nothing happening in the main() function, but inserting the code shown makes the interrupt erratic. #include "system.h" #include <stdlib.h> #pragma DATA _CONFIG, _FCMEN_OFF&_IESO_OFF&_MCLRE_OFF&_WDT_OFF&_INTOSCIO #pragma CLOCK_FREQ 4000000 //processor is 12F683 using internal oscillator</P> <P>int xseconds = 0; unsigned char tick; unsigned char tick1; void interrupt( void ) { tmr0 +=9; tick++; if(tick>19) { tick=0; tick1++; if(tick1>49) //every 500 ms { gpio.4 = xseconds.0; //flash LED tick1=0; //reset tick1. xseconds++; } } intcon.2=0; //clear TMR0 overflow flag } void main() { intcon = 0b1000000; option_reg = 0b10000000; osccon = 0b01100000; // 4 MHz internal oscillator (high accuracy not reqired) wdtcon = 0x00; // Watchdog not used trisio = 0b00001001; // GP3 and GP0 are inputs cmcon0 = 7; // all inputs are digital not (for comparitor manual page 56) ansel = 0x00; // sets ports 0-2 for digital use (not for A/D manual page 33) gpio = 0x00; // initialize GPIO port bits to zero</P> <P> for(i=0;i<10;i++) // flashing LED indicates successful start { gpio.5= 1; delay_ms(50); gpio.5 = 0; delay_ms(50); } while(1) { delay_ms(200); // if this code runs the interrupt gets crazy gpio.5 = !gpio.5; } } I have read the manual (honest), but after considerable study I can't seem to find the problem. ...and I wish I could figure out how to insert code correctly in these posts......... Happy New Year all
  17. Thanks Reynard, that what the problem was. My version of the manual (which I thought was current) still has the old file names. It looks like the compiler tried to correct itself since the Link name was changed, but the compile name was still the old one. I'm up and running and getting ready to fire up a PIC Kit 3 after using my beloved Wisp628 and the really nice SourceBoost IDE for years. I am hoping that the debugging capabilities of MPLAB will be helpful now that I am getting better with the PICs. I feel like a traitor leaving the SB IDE, but I am still a strong supporter of the Compiler -- plenty of bang for the buck and very user friendly for the newbies. Regards Rye
  18. I am trying to setup and get MPLAB working with BoostC using the manual instructions and get the error message when I try to build Source Boost Message Compiler executable was renamed from boost.pic16.exe to boostc.pic16.exe. If you see this dialog this means that you still try to use the old compiler name. ? ! Thanks
  19. Until recently I have been writing programs on one machine and doing the programming on another machine -- so I could not take advantage of the one click Compile, Link, Program option provided by the IDE settings>options>tools. Now I am trying to do it all on one machine using my well behaved WISP628 programmer and XWISP software and I am having a problem getting the whole sequence to happen all with one click. My command line is: c:\program files\xwisp\xwisp com7 go When I try it, I get the following: Building... BoostC Optimizing C Compiler Version 6.95 (for PIC16 architecture) http://www.sourceboost.com Copyright© 2004-2009 Pavel Baranov Copyright© 2004-2009 David Hobday Licensed to Ryerson Gewalt under Single user Full License for 1 node(s) Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only atd_gyro.c C:\aaaa\ATD_gyro\atd_gyro.c(49:5): warning: local variable 'tick' may be used uninitialized success BoostLink Optimizing Linker Version 6.95 http://www.sourceboost.com Copyright© 2004-2009 Pavel Baranov Copyright© 2004-2009 David Hobday warning unreferenced functions removed: lcd_print_hex in: C:\aaaa\ATD_gyro\lcd.c lcd_print_dec in: C:\aaaa\ATD_gyro\lcd.c lcd_print_dec_no_fill in: C:\aaaa\ATD_gyro\lcd.c lcd_print_dec_right_just in: C:\aaaa\ATD_gyro\lcd.c lcd_print_bin in: C:\aaaa\ATD_gyro\lcd.c Building CASM file Serious Warning: Possible sw stack corruption, function 'delay_10us' called by more than one asynchronous thread (main/Task, interrupt, interrupt low) Memory Usage Report =================== RAM available:368 bytes, used:86 bytes (23.4%), free:282 bytes (76.6%), Heap size:282 bytes, Heap max single alloc:95 bytes ROM available:8192 words, used:1127 words (13.8%), free:7065 words (86.2%) success "C:\Program Files\SourceBoost\boostc.pic16.exe" atd_gyro.c -t PIC16F877A "C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic16.lib atd_gyro.obj .\adc.obj .\lcd.obj /t PIC16F877A /d C:\aaaa\ATD_gyro /p atd_gyro c:\program files\xwisp\xwisp com7 go atd_gyro.hex Exit code was -1. [invalid argument.] Removing target: atd_gyro.hex Failed to locate output file 'C:\aaaa\ATD_gyro\atd_gyro.hex' Done Failed If, immediately after the failure, I click on Link and then click Program everything comes out just fine. I have tried the double quotes as recommended by the manual with no luck, but maybe I am putting them in the wrong place. I've tried it with several simple jobs with similar results. It may be an issue with the programmer/programmer software, but I wonder if anybody has had a similar experience. Perhaps there should be a delay after the link activity.... Cheers Rye
  20. Thanks for clearing that up for me guys. I had seen the stuff in the manual (yes, I occasionally read the manual) but the examples were a bit obscure in this case. I might suggest that Dave and Pavel consider beefing up the manual on this. Particularly the use of the .h file references. Regards Rye
  21. What do these statment mean? volatile bit adc_go @ ADCON0 . GO; volatile bit adc_on @ ADCON0 . ADON; It's one of those mysteries that I can't seem to find in the books. Rye
  22. Thanks Pavel. As usual you guy are always there to help when I get in a jam and that's what sets you apart from the bigger guys. I wish you continued success. Regards Ryeg
  23. I couldn't find rand.lib in my distribution, but did find rand.pic16.lib and suspect that's what the manual means. When you say that I should "include" the library into my project, I assume that what you mean is that I should add the library file to my list of project files in the IDE -- not #include <rand.pic16.lib>. ...or at least the former seems to compile. Am I correct? Rye To paraphrase Lewis Carroll: My words mean exactly what I want them to mean, no more, no less.
×
×
  • Create New...