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_
  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
  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
  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 =
  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"
  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 hav
  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 &
  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
  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...