Jump to content

ryeg

EstablishedMember
  • Content Count

    111
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ryeg

  • Rank
    Enthusiast
  • Birthday 10/05/1942

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    North Carolina, USA
  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
×
×
  • Create New...